Radosław Kostrzewa

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.

To może należałoby to gdzieś opisać? Bo do tej porty stosowałem to zgodnie z opisem w dokumentacji, tj: Teraz nie zasymuluję, czy przy tej opcji wszystko rozliczy się poprawnie, ale jakoś pozostaję w przekonaniu, że samo rozliczenie technicznie stworzonej umowy i rachunku jest poprawne - de facto i bez tego parametru wyliczony podatek jest od kwoty brutto. Zwrócę uwagę, że w poście: @Jacek Filipkiewicz nic nie wspomniał, że parametr liczenia od brutto powinien być zaznaczony.

Jeszcze jedna rzecz przy okazji zaliczek. Jeśli została z zaliczki wygenerowana dyspozycja i powiązana z operacją, to w dokumentach powiązanych do zaliczki widać wiązania do wszystkich operacji z WB z którym powiązana była operacja do dyspozycji zaliczki. Jest to standardowy problem całego nexo zgłoszony już dawno. Nie mniej, pierwszą rzeczą, którą bym się spodziewał w powiązaniach, to rachunki i LP z wypłatami, z których te naliczenia powstały. Tego nie ma w ogóle.