Radosław Kostrzewa

Jeśli jest to zapis powiązany z ewidencją VAT, a w konfiguracji rejestru księgowego jest ten parametr, oraz kontrahent na rozrachunku posiada NIP, to kwota VAT zostanie automatycznie zaktualizowana o wartość podsumowania VAT z ewidencji VAT.

Dzień dobry Obecna mechanika zapisywania stanu sprawozdań działa w oparciu o wyznaczenie i zapis na jedną datę "Na dzień". Po tej dacie jest wybrane w wersjach porównawczych zapisany stan sprawozdania z poprzedniego roku. Mam w poprzednim roku zapisane stany sprawozdań dla RZS porównawczego na każdy ostatni dzień miesiąca narastająco od początku roku. W kolejnym roku oprócz tego jw. potrzebuję wygenerować RZS ale tylko w okresach miesięcznych, czyli wtedy otrzymuję RZS w zakresie 01.03.2023-31.03.2023 (a nie 01.01.2023-31.03.2023). Oczywiście jeśli w poprzednim okresie mamy tylko jedną wersję zapisaną na dany dzień, nie mogę uzyskać porównań dla obu. Oczywiście, obejściem jest powielenie sprawozdania i zrobienie RZS per miesiąc na odrębnej definicji, i do tego teraz muszę uciec, ale to w przyszłości wymaga podwójnej kontroli definicji funkcji dla kont. Tutaj też brakuje tego co jest w nexo - możliwość skopiowania istniejącej definicji z innego sprawozdania (bez struktury). Opcja wysyłania do XML całej struktury z definicją i import jako nowego, może będzie działać, dopiero sprawdzę, czy potem porównanie opiera się o samą nazwę definicji, przy zapisanych stanach sprawozdań.

A skąd system ma wiedzieć, jaka kwota VAT powinna być wprowadzona?

Zależy, jak są księgowania ustawione. Jeśli mamy rozróżnienie księgowania VAT-u w okresy bieżące i przyszłe, to o ile nie ma bezpośredniego powiązania, to jest kluczowa informacja, dzięki której weryfikuje się łatwiej zgodność rejestru VAT i jego rozliczenia w danym miesiącu deklaracją z kontami księgowymi. Nie mniej jeśli dekrety są na sztywno zaksięgowane, to w samym okresie księgowań już się tego nie poprawi, ale jeśli był błąd i to i tak powinien być PK przeksięgowujący. Same wpisy zaś w rejestrze VAT należałoby poprawnie skorygować przez zapis stornujący dla danego okresu i ponownym zapis we właściwym okresie.

Tylko persaldo działa w obrębie jednego wskazania konta i wszystkich analityk, nie można wskazywać persalda dla wielu swobodnie wskazanych kont.

Nie doszło nic więcej. Link @Jacek Izydorczyk wskazuje na opcję rozwiązania funkcji sferycznie. Można też to zaadresować, przez wyodrębnienie na oddzielne syntetyki z kosztów finansowych i operacyjnych pozycji, które muszą być liczone per saldem. Wtedy analitycznie pod rodzajem mamy analitykę kosztu i przychodu, a z górnej części analityki mamy persaldo do pobrania istniejącymi funkcjami persadla do wykorzystania w sprawozdaniach. Dla przypomnienia, persaldem należy wykazać: aktywa finansowe (finansowe) różnice kursowe (finansowe) niefinansowe aktywa trwałe (operacyjne)

Przy zaczytaniu listy baz przy uruchamianiu programu. Szczególnie jeśli uruchomimy Gratyfikanta nexo i na liście odznaczymy 'Tylko Gratyfikant' i dostajemy komplet baz. Chociaż tutaj może działać inna mechanika - ale też wpierw otwierałem drop-down tą listę, żeby mieć pewność, że jest zaczytana.

Tak, racja, zmieszałem dwie rzeczy. I faktycznie, pomysł na przerobieniem tego na znacznik, jest słuszny. A ilość osób do wypadkowego z całego roku swoją drogą.

Tak, racja, jest tylko znacznik. Ale osób do chorobowego a nie wypadkowego Co prawda nie dot. to bezpośrednio migracji, ale jest jeszcze w ZUS raport IWA do wypełnienia dla płatników, którzy za cały rok osiągnęli min. 10 osób do ubezpieczenia wypadkowego. Zawsze można to wziąć z danych programu kadrowego z poprzedniego roku, kłopot będzie przy migracji 'w trakcie'. Warto coś zrobić, bo przy migracji 90 podmiotów to zrobiły istotną część narzutu czasowego na tą migrację, uwzględniając, że nie ma też tego w prosty sposób do uzyskania raportem w Gratyfikancie GT.

Zapomniała Pani o umowach zleceniach - a tam nie każde @Tomasz Zasadziński - tak przy okazji, wpisz sobie np. datę 30-11-0220 ...i zatwierdź, a potem do poprawki

1. Na jednym z ostatnich etapów kreatora jest konieczność ręcznego podania informacji o ilości osób do ubezpieczenia wypadkowego na 30.11. Skoro mamy miesiąc rozpoczęcia pracy z programem, to nie można by tego z bazy GT wyliczyć? Tym bardziej że i w GT ta dana nie jest na wyciągnięcie ręki dostępna. 2. Technicznie wprowadzone umowy (tak, wiem, będę tym już nudził, za odsetki), która w GT wygląda (demo) tak: Przenosi się do GT bez zaznaczenia chekboxu liczenia umowy od kwoty brutto. Tak, wiem, że w GT nie ma tego parametru, ale skoro możemy zarówno po rodzaju przychodu jak i sprawdzeniu czy parametry umowy wyliczą podatek od brutto, czy nie, może warto to uwzględnić, bo potem trzeba te umowy popoprawiać. 3. To mniej istotne, ale nadmiarowo w nexo na takiej umowie zaznaczone jest generowanie raportu RPA. Tam i tak nie ma się co z tego liczyć, wydaje mi się, że lepiej może być dla wydajności, jakby zupełnie tego nie było.

Jak podmiotów jest naprawdę dużo (mówimy o setkach), i nawet dzieje się to na mocnym serwerze z pełnym SQL-em, dużą ilością ram i dyskami M.2, nie jest szczęśliwe, że wyszukiwanie w tym miejscu po jednym znaku się aktywuje. Chociaż dwa znaki...

Gdzie, oprócz policzenia tego ręcznie po umowach, oraz opcjonalnie poza własnym zestawieniem, mogę otrzymać z programu taką informację?

Bo nie opisał Pan w dokumentach z portalu ich Typem dokumentu. Dlatego nie widać.

Po imporcie dokumentów z PB tworzą się DDK-o typie Faktura zakupu. Jak Pan taki dokument opisze, może Pan to sobie zweryfikować.

Kontrahentów, rozrachunki można zaimportować standardowym mechanizmem HOP-a przez serwisanta. Byle zrzucić to do XLS-a z Optimy, co nie powinno być problemem. Natomiast nie wiem co kryje się pod hasłem sprzedaż i koszty - ale jeśli chodzi o istniejące dekrety, to to już nie koniecznie. Z teorii się da, ale z praktyki nie znam kogoś, kto by się na to decydował z uwagi na koszty.

Dla potomności. Problemem był fakt, że przenosiliśmy BZ z roku 2022 z GT (utworzone w GT BO dla 2023) do nexo do roku 2023. W nexo było też awansem otwarty okres obrachunkowy 2024. BO z GT z roku 2023 lądowało w nexo jako PK bilansu otwarcia roku 2024... Suplement: InsERT w swoich założeniach nie przewidział, że użytkownicy będą wielokrotnie uruchamiać kreator. Ale tak samo, jak nie zostało przewidziane to, że nie da się często w całości mieć w GT w sposób prawidłowy przygotowanych wszystkich danych. W końcu można zamykać jeden rok i otwierać drugi przez 3 miesiące. Przy przenoszeniu danych kreatorem do nowej bazy - nie ma prawa powstać więcej niż jeden okres obrachunkowy w nexo. Nie jest obsłużone ponowne przenoszenie BO jak w nexo jest więcej niż jeden okres obrachunkowy.

Jeszcze takie pytanie, co chce Pan z Optimy zaimportować?

Należy też zaktualizować dane w ZUS. Zakładam, że nazwa skrócona się zgadza, ale w XML-u wychodzą dane niezgodne z danymi w bazie Płatnika - i tu może być problem. W celu aktualizacji danych w ZUS (co po ich zmianie Płatnik sobie te dane zaktualizuje sam), należy z Płatnika wysłać ZUS ZPA, oraz w Płatniku wygenerować i wydrukować i podpisać druk ZIPA i złożyć do ZUS. Czy to zostało zrobione? ps. można w wyeksportowanym pliku XML z Gratyfikanta wpisać stare dane dot. JDG i spróbować zaimportować do Płatnika.

Na moment, jak te umowy powstały - to nie potwierdzę, bo nie pamiętam. Ja wiedziałem, że tak umowa jest sparametryzowana, że rachunek wyliczy się poprawnie. Jak najbardziej mógł być, teraz na pewno jest, bo sprawdziłem. Zasymulowałem wprowadzenie takiej umowy bez zaznaczenia chekboxu. Przy próbie zapisu pojawia się dodatkowe okienko - i jak zgodzę się to się umowa zapisuje, dopiero jak wrócę do edycji umowy jest to lepiej obrazowane - bo oprócz ostrzeżenia na dole obramowywany jest ten chekbox - i to jest na pewno bardzo fajne.

No ale z uwagi na ustawienie koszów 0, braku ZUS, podatek był de facto liczony od kwoty brutto... Zasymulowałem to sobie - i jedna rzecz jest faktycznie dobra, że podświetla się ten chekbox, żeby go zaznaczyć. Natomiast parametryzując w sposób ręczny umowę w odpowiedni sposób, wiedząc, że założenia liczenia podatku od kwoty brutto (algorytmu) będą spełnione, przyznam, że byłem przekonany, że to jest ok. Ale może też naleciałości z GT. Nie mniej sprecyzowanie tych zapisów nie kosztuje chyba dużo?

No właśnie największy problem jest w tym, że nie ma tego nigdzie dobrze opisanego. Nie lepiej w tym opisie dot. znacznika opisać, że musi być zaznaczony dla wszystkich zaliczek PIT rozliczanych tytułem PIT-8A? Ja się autentycznie zafiksowałem na tych cudzoziemcach, bo do tej pory faktycznie przy rachunkach dla nich to było wykorzystywane.

W tym raporcie przydałaby się jeszcze kolumna daty likwidacji ŚT.

Teraz to już musztarda po obiedzie, więc najbliższe wersje nie zbawią. Doskonale rozumiem, że zasoby zjada KSeF - nie mniej jakby to dało radę przed kolejnymi rozliczeniami rocznymi, to wystarczy.

Dla uzupełnienia. Rachunki są już dawno zaksięgowane. Zrobiłem zatem ich update na bazie, żeby włączyć parametr liczenia od 'brutto' i mogę potwierdzić, że przy tym parametrze, wartości w zaliczce PIT dla PIT-8A wyszły poprawnie. PIT-8AR też wyszedł poprawnie w zakresie rozliczenia tego podatku jako Odsetki (C.14). Nie mniej czy można się spodziewać poprawienia generowania dyspozycji bankowych, bo tutaj i tak cała kwota wchodzi tytułem PIT-4 ? ps. i bardzo proszę poprawienie instrukcji/dokumentacji - najlepiej może zrobić wątek w e-pomocy.