Brak znacznika A.V w planie kont Optimy – gdzie szukać przyczyny?

Przy pracy na planie kont w Comarch ERP Optima łatwo założyć, że jeśli danego znacznika nie ma na liście, to problem leży w samym koncie. W praktyce przy znacznikach ZOiS bardzo często przyczyna jest poziom wyżej – w konfiguracji okresu obrachunkowego. To właśnie tam wybierany jest typ ZOiS, a od tego wyboru zależy, jaki zestaw znaczników pojawi się później do przypisania na kontach.

Dlaczego nie widać znacznika A.V?

Jeżeli w planie kont nie można wskazać znacznika A.V, nie warto od razu szukać obejścia na samym koncie. Specjalista wskazał najważniejszą rzecz: typ ZOiS wybiera się w konfiguracji na formularzu okresu obrachunkowego. Zależnie od tego, jakie zestawienie zostanie tam wybrane, Optima udostępnia odpowiednio dopasowane znaczniki.

Innymi słowy, wykaz znaczników nie jest oderwany od konfiguracji księgowej bazy. Jeżeli typ ZOiS nie odpowiada jednostce albo zakresowi sprawozdawczemu, którego potrzebujesz, na liście może nie być znacznika wymaganego dla dotacji w instytucji kultury.

Co sprawdzić w pierwszej kolejności?

Najpierw trzeba wejść w konfigurację okresu obrachunkowego i sprawdzić, jaki typ ZOiS jest wybrany na formularzu okresu. To ustawienie decyduje o tym, które znaczniki będą dostępne później przy pracy na planie kont. Dopiero po potwierdzeniu właściwego typu ZOiS ma sens ponowne sprawdzanie konta i przypisywanie znacznika.

<screen>

Jeżeli po zmianie albo weryfikacji typu ZOiS znacznik A.V nadal nie pojawia się w wykazie, wtedy warto sprawdzić aktualność wersji programu, poprawność słowników oraz to, czy baza nie ma problemu z załadowaniem właściwego zestawu znaczników. To już jest etap diagnostyczny, bo przyczyną może być nie tylko wybór w konfiguracji, ale też nieaktualne dane słownikowe albo problem konkretnego środowiska.

<screen>

Dlaczego kolejność ma znaczenie?

Próba ręcznego poprawiania planu kont bez sprawdzenia okresu obrachunkowego może prowadzić donikąd. Konto korzysta z dostępnego wykazu znaczników, a ten wykaz wynika z ustawień okresu i typu ZOiS. Jeśli źródłowa konfiguracja jest niewłaściwa, użytkownik będzie próbował przypisać znacznik, którego Optima po prostu nie pokazuje w danym kontekście.

Dlatego najpierw trzeba potwierdzić typ ZOiS, potem dostępność znacznika w wykazie, a dopiero na końcu przypisać go do odpowiedniego konta lub analityki. Taka kolejność ogranicza ryzyko, że problem zostanie rozwiązany pozornie, ale wróci przy kolejnym sprawozdaniu lub kontroli planu kont.

Perspektywa ELTE-S: najpierw konfiguracja okresu, potem plan kont

Przy znacznikach kont w Optimie najważniejsze jest ustalenie, skąd system bierze listę dostępnych pozycji. W tym przypadku odpowiedź specjalisty jest konkretna: typ ZOiS wybierany na formularzu okresu obrachunkowego wpływa na dostępne znaczniki. Dlatego diagnostykę należy zacząć od okresu obrachunkowego, a nie od przypadkowego zmieniania kont w planie kont.

Jeśli w Twojej bazie brakuje wymaganego znacznika, warto uporządkować konfigurację okresu obrachunkowego i typ ZOiS zanim zaczniesz poprawiać plan kont lub analitykę.

Porozmawiajmy o usprawnieniach.

Korekta kursu na fakturze zaliczkowej w Optimie – dlaczego KSeF pokazuje ją inaczej?

Korekta kursu waluty na fakturze zaliczkowej potrafi wyglądać myląco. W Comarch ERP Optima użytkownik widzi korektę, przyczynę, tabelę VAT i różnice po przeliczeniu na PLN. Po stronie KSeF ten sam dokument może jednak nie pokazywać prostego zestawienia „kurs przed korektą – kurs po korekcie”. To nie musi oznaczać, że korekta została wysłana błędnie. Zgodnie z odpowiedzią specjalisty najważniejszy jest XML, bo to on pokazuje, co faktycznie zostało przekazane do KSeF.

Optima pokazuje korektę czytelniej niż podgląd KSeF

Przy korekcie kursu faktury zaliczkowej Optima może pokazywać zmianę w sposób bardziej zrozumiały dla księgowego. Sama korekta kursu nie musi zmieniać wartości w walucie obcej. Zmienia przede wszystkim wartości przeliczone na PLN, czyli podstawę opodatkowania, VAT i należność wynikającą z zastosowania właściwego kursu. Dlatego w Optimie tabela VAT może pokazywać różnicę między wartościami przed korektą i po korekcie, a wizualizacja w KSeF może wyglądać dużo mniej opisowo.

KSeF nie jest historią zmian kursu

Wizualizacja KSeF nie działa jak raport porównawczy, który pokazuje użytkownikowi: „było 4,10, jest 4,25”. KSeF prezentuje dokument zgodnie ze strukturą e-faktury. Przy korekcie faktury zaliczkowej wartości podstawy opodatkowania, podatku i należności mogą być pokazane jako różnica względem dokumentu pierwotnego, a nie jako pełna historia zmian kursów. Dlatego brak czytelnego opisu korekty kursu na podglądzie KSeF sam w sobie nie przesądza o błędzie wysyłki.

Co powinno być widoczne w XML

Specjalista wskazał, że w strukturze FA(3) dla takiej korekty trzeba sprawdzić przede wszystkim elementy techniczne dokumentu. Chodzi o RodzajFaktury = KOR_ZAL, DaneFaKorygowanej, numer KSeF faktury pierwotnej, P_15ZK jako kwotę zapłaty przed korektą, KursWalutyZK jako kurs stosowany przed korektą oraz wartości różnicowe w PLN. PrzyczynaKorekty również może wystąpić, ale to pole jest fakultatywne, więc sam brak bardzo opisowej przyczyny w podglądzie nie musi jeszcze oznaczać błędu.

<screen>

Najpierw XML, dopiero potem kolejna korekta

Jeżeli użytkownik próbuje wystawić kolejną korektę wartości i wyzerować fakturę zaliczkową, trzeba uważać na kolejność dokumentów. Optima może pracować na aktualnym stanie dokumentu po pierwszej korekcie, a nie na stanie sprzed tej korekty. To oznacza, że program nie zawsze pozwoli wrócić do kursu pierwotnego w sposób, którego użytkownik oczekuje. W praktyce najpierw trzeba sprawdzić XML pierwszej korekty, powiązanie z fakturą pierwotną i wartości po korekcie. Dopiero po tej kontroli można zdecydować, czy kolejna korekta ma sens i jak ją wystawić, żeby nie pogłębić problemu.

<screen>

Kiedy problem zgłaszać do Comarch

Jeżeli XML zawiera poprawne dane, faktura korygująca jest powiązana z właściwą fakturą zaliczkową, a wartości różnicowe w PLN są zgodne, problem może dotyczyć tylko sposobu prezentacji dokumentu w KSeF. Jeżeli jednak w XML brakuje kursu, powiązania z dokumentem pierwotnym albo wartości są inne niż w Optimie, wtedy temat trzeba zgłosić serwisowo do Comarch. Do zgłoszenia najlepiej dołączyć fakturę pierwotną, korektę, XML oraz opis różnicy między tym, co pokazuje Optima, a tym, co widać w KSeF.

Perspektywa ELTE-S: nie zeruj dokumentu bez kontroli XML

Przy korektach kursu na fakturach zaliczkowych najgorsze, co można zrobić, to wystawiać kolejne korekty metodą prób i błędów. Jeżeli jedna korekta już poszła do KSeF, kolejna może opierać się na zmienionym stanie dokumentu. Bez sprawdzenia XML łatwo doprowadzić do sytuacji, w której dokumenty są formalnie powiązane, ale użytkownik nie ma pewności, co faktycznie zostało przekazane do KSeF. Najpierw kontrola XML i powiązań, potem decyzja o dalszej korekcie.

Porozmawiajmy o usprawnieniach.

ERP XL i PKO BP – błąd numeru konta przy imporcie przelewów zagranicznych

Import przelewów zagranicznych do banku potrafi zwrócić mylący komunikat. Użytkownik widzi w PKO BP błąd numeru konta i zakłada, że sam rachunek kontrahenta jest nieprawidłowy. W praktyce przy przelewach międzynarodowych bank weryfikuje nie tylko numer rachunku, ale też dane banku, kraj oraz kod SWIFT. Dlatego problem może wynikać z konfiguracji banku przypisanego do rachunku kontrahenta w Comarch ERP XL.

Numer rachunku to nie wszystko

Przy przelewach krajowych systemy bankowe są zwykle bardziej tolerancyjne. Jeżeli numer rachunku ma poprawną strukturę, przelew często przechodzi bez dodatkowych wymagań. Przy przelewie zagranicznym plik musi zawierać pełniejszy zestaw danych, a brak jednego elementu może zostać pokazany przez bank jako błąd numeru konta.

<screen>

Dlatego pierwszym krokiem nie powinno być ręczne poprawianie samego rachunku, tylko sprawdzenie całej konfiguracji banku i kontrahenta, z którego ERP XL generuje plik przelewu.

Sprawdź kartę banku przypisaną do rachunku kontrahenta

W Comarch ERP XL należy zweryfikować ustawienia karty banku, który został przypisany do rachunku bankowego kontrahenta. To z tych danych system korzysta przy generowaniu pliku przelewu. Jeżeli karta banku jest niepełna albo błędnie uzupełniona, plik może wyglądać poprawnie na pierwszy rzut oka, ale bank odrzuci go podczas importu.

<screen>

Najważniejsze pola to kraj banku oraz kod SWIFT. W przelewach międzynarodowych te dane są częścią zlecenia i bank może ich wymagać nawet wtedy, gdy sam numer IBAN wygląda poprawnie.

Dlaczego bank pokazuje błąd numeru konta

Komunikat banku nie zawsze precyzyjnie wskazuje pole, które jest problemem. PKO BP może zgłosić błąd numeru konta, chociaż źródłem problemu jest brak kodu SWIFT, nieprawidłowy kraj banku albo błędne powiązanie rachunku z kartą banku. Z punktu widzenia importu pliku cały zestaw danych rachunku jest niespójny, więc bank odrzuca zlecenie.

<screen>

To szczególnie częste przy rachunkach zagranicznych pobranych z dokumentów, integracji albo faktur z KSeF, gdzie dane techniczne mogą wymagać uzupełnienia po stronie kartoteki kontrahenta.

Co sprawdzić w praktyce

Najpierw warto otworzyć kontrahenta i jego rachunek bankowy w ERP XL, a następnie przejść do banku przypisanego do tego rachunku. Trzeba porównać numer IBAN, kraj banku i SWIFT z danymi z faktury lub od kontrahenta. Jeżeli rachunek jest zagraniczny, warto też sprawdzić, czy nie został potraktowany jak krajowy albo podpięty pod niewłaściwy bank.

<screen>

Po poprawie danych dobrze jest wygenerować plik jeszcze raz i dopiero wtedy ponowić import w PKO BP. Sama korekta danych w bankowości elektronicznej może rozwiązać pojedynczy przelew, ale nie naprawi przyczyny w ERP XL.

Perspektywa ELTE-S: najpierw dane banku, potem plik przelewu

Przy błędach importu przelewów zagranicznych z ERP XL nie warto zaczynać od założenia, że KSeF albo księgowanie faktury wygenerowały zły plik. Najpierw trzeba sprawdzić źródło danych: rachunek kontrahenta, przypisany bank, kraj i SWIFT. Dopiero potem ma sens analiza struktury pliku oraz wymagań PKO BP dla danego typu przelewu.

Jeżeli firma często płaci kontrahentom zagranicznym, warto uporządkować kartoteki banków i rachunków kontrahentów w ERP XL, żeby każdy przelew zagraniczny miał komplet danych wymaganych przez bank i nie zatrzymywał się dopiero na etapie importu pliku.

Porozmawiajmy o usprawnieniach.

Kolejna korekta faktury w Optimie – dlaczego odwołuje się do poprzedniej korekty?

Korekty faktur w Comarch ERP Optima działają według logiki aktualnego stanu dokumentu, a nie według prostego powrotu do faktury pierwotnej za każdym razem. Dlatego użytkownik, który ma już dwie korekty i chce wystawić trzecią, może być zaskoczony, że program odnosi się do drugiej korekty. W praktyce jest to jednak mechanizm chroniący spójność ilości, cen i wartości.

Trzecia korekta bazuje na stanie po drugiej korekcie

Jeżeli do faktury wystawiono już dwie korekty, dokument pierwotny nie jest już jedynym punktem odniesienia. Po pierwszej i drugiej korekcie zmienił się stan faktyczny dokumentu. Mogły zmienić się ilości, ceny, rabaty, wartości albo inne elementy wpływające na końcowe rozliczenie.

<screen>

Dlatego przy wystawianiu trzeciej korekty Optima bierze pod uwagę stan po korekcie numer 2. To właśnie ten stan jest aktualny z punktu widzenia systemu.

Dlaczego program nie wraca do faktury pierwotnej

Gdyby każda kolejna korekta była liczona od faktury pierwotnej, system mógłby łatwo pominąć skutki wcześniejszych korekt. W efekcie trzecia korekta mogłaby korygować ilości lub wartości, których w obecnym stanie dokumentu już nie ma, albo naliczać różnice tak, jakby poprzednie zmiany nigdy się nie wydarzyły.

<screen>

Właśnie dlatego Optima traktuje korekty jako ciąg zdarzeń. Każda następna korekta pracuje na stanie po poprzedniej, czyli na korekcie n-1.

Co oznacza korekta n-1 w praktyce

Korekta n-1 oznacza, że kolejna korekta odnosi się do ostatniego aktualnego stanu dokumentu. Jeśli wystawiasz trzecią korektę, punktem odniesienia jest stan po drugiej. Jeśli wystawiałbyś czwartą, punktem odniesienia byłby stan po trzeciej. Dzięki temu dokument zachowuje logiczną historię zmian.

<screen>

To nie oznacza, że faktura pierwotna znika albo przestaje być ważna. Ona pozostaje początkiem całego łańcucha, ale bieżące rozliczenie dokumentu wynika już z sumy wszystkich wcześniejszych korekt.

Jak sprawdzić historię korekt

Przy większej liczbie korekt warto korzystać z opcji pokazania powiązanych korekt i przeanalizować kolejność dokumentów. Najważniejsze jest ustalenie, co zmieniła pierwsza korekta, co zmieniła druga i jaki stan pozostał do dalszej korekty. Dopiero wtedy trzecia korekta będzie miała sens księgowy i handlowy.

<screen>

Jeżeli oczekiwany efekt korekty nie zgadza się z tym, co pokazuje program, problem zwykle nie leży w samym odwołaniu do drugiej korekty, tylko w tym, że wcześniejsze korekty zmieniły dokument inaczej, niż zakłada użytkownik.

Perspektywa ELTE-S: korekty trzeba czytać jako ciąg zmian

Przy kolejnych korektach w Optimie najważniejsze jest myślenie o dokumencie jako o historii następujących po sobie zmian. Faktura pierwotna jest punktem startowym, ale każda korekta aktualizuje stan dokumentu. Następna korekta musi więc bazować na tym aktualnym stanie, a nie na pierwotnej wersji sprzed wszystkich zmian.

Jeżeli w firmie często pojawiają się wieloetapowe korekty, warto uporządkować zasady ich wystawiania i kontroli, żeby operatorzy wiedzieli, dlaczego program odnosi się do poprzedniej korekty i jak sprawdzać końcowy efekt całego łańcucha dokumentów.

Porozmawiajmy o usprawnieniach.

Faktura cykliczna w Optimie – czy może mieć nabywcę i odbiorcę?

Faktury cykliczne w Comarch ERP Optima są wygodne przy powtarzalnej sprzedaży, ale potrafią zaskoczyć w momencie tworzenia szablonu. Użytkownik widzi nabywcę, nie widzi odbiorcy i zaczyna zakładać, że mechanizm cykliczny obsługuje tylko jeden podmiot. W praktyce możliwość wskazania nabywcy i odbiorcy istnieje, tylko trzeba uzupełnić dane w odpowiednim miejscu szablonu.

Gdzie dodać nabywcę i odbiorcę

Podczas tworzenia faktury cyklicznej należy przejść do zakładki 3. Podmiot. To właśnie tam dodaje się dane nabywcy oraz odbiorcy. Jeżeli odbiorca nie zostanie wskazany na szablonie, później przy generowaniu dokumentu użytkownik może odnieść wrażenie, że faktura cykliczna nie obsługuje takiego układu.

Najważniejsze jest więc nie samo zatwierdzenie pierwotnej faktury, ale poprawne uzupełnienie szablonu cyklicznego. To szablon decyduje, jakie dane zostaną użyte przy kolejnych generowanych fakturach.

Co dzieje się podczas generowania faktury

Jeżeli w szablonie faktury cyklicznej na zakładce Podmiot uzupełniono zarówno nabywcę, jak i odbiorcę, podczas generowania dokumentu Optima tworzy fakturę sprzedaży z tymi danymi. Oznacza to, że mechanizm cykliczny może przenieść oba podmioty na wygenerowaną FA.

<screen>

Warto po wygenerowaniu pierwszego dokumentu testowego wejść w formularz faktury i sprawdzić, czy nabywca oraz odbiorca są wpisani poprawnie. To najprostszy sposób odróżnienia problemu z danymi od problemu z samym wydrukiem.

Szablon dokumentu a wydruk faktury

Czasem problem nie leży w szablonie faktury cyklicznej, tylko w wydruku. Podczas generacji powstaje standardowa FA, a wydruk idzie domyślnym wydrukiem z Optimy. Jeżeli formularz dokumentu zawiera nabywcę i odbiorcę, ale na wydruku widać tylko jednego z nich, trzeba sprawdzić wzorzec wydruku, a nie samą fakturę cykliczną.

<screen>

To ważne rozróżnienie, bo użytkownik może poprawnie ustawić szablon, ale nadal widzieć niepełny efekt na papierze lub PDF, jeśli używany wzorzec wydruku nie prezentuje odbiorcy.

Perspektywa ELTE-S: sprawdź szablon i wydruk osobno

Przy fakturach cyklicznych najlepiej rozdzielić dwa etapy: dane zapisane w szablonie oraz sposób prezentacji na wydruku. Jeżeli w zakładce 3. Podmiot wpiszesz nabywcę i odbiorcę, Optima powinna wygenerować FA z oboma podmiotami. Jeżeli mimo to odbiorcy nie widać, trzeba sprawdzić, czy problem dotyczy wygenerowanej faktury, czy tylko domyślnego wydruku.

Przy większej liczbie faktur cyklicznych warto przygotować jeden poprawny szablon i przetestować pierwszy wygenerowany dokument razem z wydrukiem, żeby później automatyzacja nie powielała niepełnych danych.

Porozmawiajmy o usprawnieniach.