Delegacje krajowe

Funkcjonalność ta pozwala na rejestrację i obsługę delegacji krajowych wraz z powiązanymi z nimi wnioskami o zaliczkę. Dodawanie delegacji możliwe jest za pośrednictwem aplikacji Comarch HRM oraz z poziomu systemu Comarch ERP XL. Dalsza praca z delegacjami (rozliczenie delegacji i zaliczek oraz ewidencja księgowa) są możliwe jedynie z poziomu Comarch ERP XL.

Wnioski pracowników

Dodawanie wniosków możliwe jest z poziomu listy wniosków udostępnionej we wszystkich modułach, w menu Dokumenty.

Uwaga

Dokument wniosku pracownika można sparametryzować w definicji tego dokumentu w module Administrator, w sekcji Księgowość

Uwaga

Lista wniosków pracownika jest dostępna tylko dla operatorów powiązanych z pracownikiem. Jeżeli operator niepowiązany z pracownikiem będzie próbował otworzyć listę wniosków, wówczas wyświetlony zostanie komunikat: “Aktualnie zalogowany operator nie jest powiązany z żadnym pracownikiem.”

Z poziomu modułu Księgowość każdy operator będzie widział na liście wszystkie wnioski. Z poziomu pozostałych modułów każdy operator na liście wniosków będzie widział tylko własne wnioski. Dodatkowo, z poziomu pozostałych modułów, operatorzy, którym na karcie zostanie nadane uprawnienie „Wgląd do listy wniosków” (zakładka Parametry/Księgowe, obszar: Delegacje, Wnioski) będą widzieli wszystkie wnioski dodane do bazy. Uprawnienie jest dedykowane szczególnie do pracowników działów księgowych, którzy będą mieli dostęp do wszystkich delegacji. Została wyszczególniona jeszcze jedna grupa użytkowników, którzy będą mieli dostęp do listy wniosków ograniczonych do dokumentów przypisanych pracownikom podległym w strukturze. W tym celu na roli pracownika należy wybrać jedno lub kilka praw dotyczących wniosków pracowników:

Uwaga

Role należy w pierwszej kolejności zdefiniować w module administrator, w sekcji “Role pracowników” (Firma/Role), a dopiero wówczas można je przypisać pracownikom. Zdefiniowane role podpinane są na karcie pracownika, na zakładce “Role.”

Uwaga

Wniosek o zaliczkę jest tylko jednym z dostępnych typów wniosków i jest dedykowany dla funkcjonalności delegacji. Pozostałe typy będzie można wykorzystać niezależnie w innych modułach.

W Słownikach Kategorii (w Module Administrator), w gałęzi Inne/Typy wniosków można zdefiniować własne typy wniosków. Wartością domyślną jest jednak Wniosek o zaliczkę.

Jedynie predefiniowany typ „Wniosek o zaliczkę” umożliwia podanie na wniosku kwoty oraz wygenerowanie z niej zaliczki (zapisu k/b). Pozostałe własne typy wniosków nie mają tej funkcjonalności.

Z poziomu zakładki Ogólne na zatwierdzonym wniosku, za pomocą wybierając odpowiedni rejestr k/b oraz operację, można dodać zapis k/b – zaliczkę pracownika na poczet powiązanej delegacji.

Wnioski o zaliczkę można również powiązać z delegacją wybierając opcję Delegacja i wskazując odpowiedni dokument.

Po wystawieniu wniosku na odpowiedniego pracownika, możliwe jest jego zatwierdzenie lub odrzucenie. W systemie zapisywane są informacje o operatorze (i powiązanym z nim pracowniku) dokonującym tych operacji. Na wnioskach zatwierdzonych lub odrzuconych nie można zapisywać już żadnych zmian, nie jest możliwe również ich usunięcie. Większość z tych funkcji dostępna jest również w menu kontekstowym rozwijanym spod prawego klawisza myszy z poziomu listy wniosków.

Dodawanie delegacji w Comarch HRM

Aby korzystać z tej funkcjonalności konieczne jest posiadanie aplikacji HRM lokalnie – Comarch ERP WAMC albo w modelu usługowym dostępnym w chmurze Comarch. Szczegółowe informacje o aplikacji Comarch HRM (w  tym m.in. instalacja i aktualizacje, konfiguracja aplikacji) zamieszczone są w Bazie wiedzy Comarch HRM dostępnej pod linkiem: https://pomoc.comarch.pl/hrm/pl/

Aby móc rozliczać delegacje, zaliczki i dokonać ewidencji księgowej w Comarch ERP XL konieczna jest dwustronna synchronizacja baz systemów XL i XL HR. Sposób synchronizacji systemu Comarch ERP XL z Comarch ERP XL HR został szczegółowo opisany w biuletynie technicznym XL064 – Współpraca Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR.pdf. Dodatkowo w Konfiguracji/ zakładka HR wymagane jest ustawienie Operatora dla zapisów z aplikacji Comarch HRM. W przypadku braku tych ustawień pojawi się następujący komunikat: „W module Administracja XL nie ustawiono operatora do realizacji zapisów w bazie danych. Prosimy o kontakt z Administratorem systemu”.

Uwaga

Sekcja “Operator dla zapisów z aplikacji Comarch HRM” będzie możliwa do edycji w momencie odznaczenia parametru “Blokada synchronizacji struktury podległościowej”. Wskazany w konfiguracji operator jest, tzw. “operatorem technicznym”. Taki operator nie może być powiązany z kartą pracownika. Będzie on widniał na dokumentach delegacji/wniosku, jako podmiot, który wystawił te dokumenty. Operator powinien zostać dodany do centrum praw. Ustawienia definicji delegacji danego centrum będą pobierane przy dodawaniu delegacji w HRM. 

Aplikacja HRM opiera się na strukturze podległościowej, dlatego też ustawiając synchronizację z Comarch ERP XL HR, w Comarch ERP XL należy odznaczyć parametr „Blokada synchronizacji struktury podległościowej”.

Uwaga

W przypadku systemu Comarch ERP XL bezwzględnie musi być włączona dwustronna synchronizacja z bazą danych Comarch ERP XL HR. Rozłączenie synchronizacji może spowodować brak dostępu do aplikacji Comarch HRM oraz nieodwracalne błędy związane z brakiem spójności i utratą wprowadzonych danych.

Kroki dodawania delegacji w aplikacji zostały opisane w Bazie wiedzy Comarch HRM. Dostępnej pod linkiem: https://pomoc.comarch.pl/hrm/pl/index.php/dokumentacja/delegacje/

Dodawanie delegacji w Comarch ERP XL

Obsługa delegacji możliwa jest z poziomu listy delegacji udostępnionej we wszystkich modułach, w menu Dokumenty.

Uwaga

Lista delegacji jest dostępna tylko dla operatorów powiązanych z pracownikiem. Jeżeli operator niepowiązany z pracownikiem będzie próbował otworzyć listę delegacji, wówczas wyświetlony zostanie komunikat: “Aktualnie zalogowany operator nie jest powiązany z żadnym pracownikiem.”

Każdy operator na liście delegacji będzie widział własne delegacje. Dodatkowo operatorzy, którym na karcie zostanie nadane jedno z uprawnień dotyczących delegacji umieszczonych na zakładce Parametry/Księgowe, obszar Delegacje, Wnioski, będą widzieli wszystkie delegacje dodane do bazy. Uprawnienia te są dedykowane szczególnie dla pracowników działów księgowych, którzy będą rozliczali i księgowali delegacje.

Została wyszczególniona jeszcze jedna grupa użytkowników, którzy będą mieli dostęp do listy delegacji ograniczonych do dokumentów przypisanych pracownikom podległym w strukturze. W tym celu na roli pracownika należy wybrać jedno lub kilka praw dotyczących poleceń wyjazdu służbowego:

Uwaga

Role należy w pierwszej kolejności zdefiniować w module Administrator: Firma/Role/Role pracowników, a dopiero wówczas można je przypisać pracownikom. Zdefiniowane role podpinane są na karcie pracownika, na zakładce Role.

W Module Administrator w sekcji Definicje dokumentów w gałęzi Księgowość, dodany został nowy typ dokumentu: Delegacja.

W konfiguracji Modułu Księgowość dodano zakładkę: Delegacje. Na zakładce umieszczono listę: Stawki diet i ryczałtów.

Użytkownik może dowolnie zdefiniować stawki diet i ryczałtów dla danego kraju wybierając zielony przycisk plusa.

Kolory dokumentów Delegacji na liście:

Delegacja: zakładka Ogólne

Delegacja mająca status dokumentu wprowadzonego składa się z 3 podstawowych zakładek: Ogólne, Atrybuty, Załączniki. Zakładki: Atrybuty oraz Załączniki mają analogiczne zastosowanie jak w pozostałych miejscach systemu. W miarę zmiany statusu delegacji, na dokumencie pojawiać się będą dodatkowe zakładki.

Numer dokumentu Delegacji nadany jest przez system, numeracja jest zależna od ustawień w Konfiguracji: Sprzedaż/Parametry 1. Domyślne ustawionym rodzajem delegacji jest delegacja krajowa. Obecnie pole nie podlega modyfikacji.

Na zakładce Ogólne dokumentu delegacji znajduje się również check „Zaakceptowano.” Po zweryfikowaniu danych ujętych na dokumencie delegacji, można ją zaakceptować (również z poziomu menu kontekstowego). Może tego dokonać operator posiadający szczególne uprawnienia, np. kierownik.

Uwaga

Zaakceptowanie Polecenia wyjazdu służbowego możliwe jest, gdy:

• Pracownik wprowadzający, jak i akceptujący polecenie wyjazdu służbowego jest przypisany do struktury podległościowej
• Pracownik akceptujący ma podpiętą rolę (na roli pracownika wskazane jest Centrum oraz dodane prawa dotyczące poleceń wyjazdu służbowego: Akceptacja/anulowanie poleceń wyjazdu podwładnych; Akceptacja/anulowanie poleceń wyjazdu pracowników centrum

Jeżeli powyższe warunki nie zostaną spełnione przy próbie zaakceptowania Polecenia wyjazdu służbowego pojawi się komunikat: “Operator nie ma uprawnień do akceptacji polecenia wyjazdu” 

Po zaakceptowaniu delegacji na dokumencie pojawią się dodatkowe zakładki: Rozliczenie oraz Płatności. Po wykonaniu tej czynności, delegacja będzie miała stan „Zaakceptowanego polecenia wyjazdu.” Jeśli operator ma przypisane uprawnienie (Parametry/Księgowe, obszar: Delegacje, Wnioski) „Modyfikacja zaakceptowanych poleceń wyjazdu”, wówczas na zaakceptowanej delegacji będzie mógł zmienić daty trwania delegacji, jej miejsce oraz cel.

Po zaakceptowaniu delegacji automatycznie zostają zatwierdzone wszystkie wnioski o zaliczkę powiązane z tą delegacją.

Delegacja: zakładka Rozliczenie

Sekcja Przejazdy:
Jeśli delegacja ma status „Zaakceptowane polecenie wyjazdu”, to z tego poziomu można dodawać nowe przejazdy oraz aktualizować istniejące. Służą do tego standardowe ikony:

[Dodaj] – umożliwia dodanie nowego przejazdu.
[Zmień] – umożliwia podgląd i edycję istniejącego rekordu.
[Usuń] – umożliwia usunięcie rekordu.

Po wskazaniu ikony zielonego plusa podnoszona jest formatka Przejazdy, w której wskazać należy szczegóły przejazdu.

Formatka składa się z 2 zakładek: Ogólne oraz Atrybuty. Zakładka Atrybuty jest analogiczna jak w pozostałych miejscach systemu. Na zakładce Ogólne należy wskazać szczegółowe informacje na temat przejazdu.

W związku z udostępnieniem funkcjonalności Delegacji, w module Administrator w Słownikach Kategorii w gałęzi Transport, magazyn dodano nową kategorię: Rodzaje środków transportu. Oprócz predefiniowanych wartości, użytkownik ma możliwość dodawania własnych kategorii w tym obszarze.

Uwaga

Po wskazaniu w formatce przejazdu środka transportu innego niż samochód służbowy i transport własny, parametry: Samochód,  Kierowca stają się wyszarzone.

W gałęzi Transport, magazyn w obszarze Rodzaje przejazdów, dodana została kategoria Delegacje. Ten typ przejazdu będzie domyślnie powiązany z przejazdami generowanymi z poziomu delegacji i na tych przejazdach wyświetlany.

Zapisanie przejazdu skutkuje pojawieniem się takiej pozycji na liście przejazdów. Pod listą przejazdów znajduje się pole „Liczba godzin delegacji”, które zostaje automatycznie wyliczone na podstawie dodanych przejazdów, jako różnica pomiędzy godziną wyjazdu z pierwszego przejazdu i godziną powrotu z ostatniego przejazdu.

Listę przejazdów pracowników można uruchomić klikając na zakładkę Środki trwałe/ Samochody. Lista ta składa się z 3 zakładek: Ogólne, Przejazdy, Wydatki. Dodany z poziomu delegacji przejazd będzie widoczny w tej liście. 

Sekcja Wydatki:
Wprowadzenie przejazdu w sekcji Przejazdy powoduje automatyczne utworzenie wydatku w gałęzi Wydatki.

W gałęzi Rodzaje wydatków (Słowniki kategorii/ Inne) wprowadzone są predefiniowane wartości powiązane z obszarem Delegacji. Na kategorii wydatku udostępniono przycisk, umożliwiający wskazanie konta księgowego z planu kont odnoszącego się do danego wydatku. Użytkownik ma również możliwość definiowania własnych kategorii w tym obszarze.

W obszarze wydatków, używając ikonki zielonego plusa, można również wprowadzać pozostałe wydatki związane z delegacją. Ikona ta będzie aktywna w momencie podświetlenia konkretnej kategorii wydatku w sekcji „Rodzaj wydatku”.

Lista wydatków pracowników dostępna jest również z poziomu, m.in. modułu Księgowość, zakładka Dokumenty. Na formatce wskazać należy rodzaj oraz typ wydatku. Wydatek powiązać można z dokumentem faktury lub noty memoriałowej. Można również wskazać kontrahenta. Powiązanie wydatku z dokumentem może nastąpić również z poziomu dokumentu delegacji, zakładki Rozliczenia. W sekcji Rodzaj wydatku udostępniono funkcje pozwalające na takie powiązanie.

Pod listą wydatków znajdują się pola dotyczące wyżywienia oraz diet i ryczałtów.  Na podstawie tych danych oraz ilości godzin trwania delegacji wyliczana jest ilość należnych diet. Ilość wyliczana jest automatycznie przy zapisie delegacji lub na żądanie, za pomocą przycisku pioruna. Użytkownik może wprowadzać również ilości ryczałtów należnych za noclegi lub dojazdy. Po wprowadzeniu zmian na tej zakładce, pracownik może oznaczyć „wydatki do akceptacji.” Parametr będzie możliwy do edycji do momentu zapisu formatki delegacji. Po zapisaniu zmian parametr zostanie wyszarzony.

Kolejnym krokiem jest akceptacja wydatków. W tym celu należy zaznaczyć parametr „Zaakceptowano wydatki”. Obydwie czynności można wykonać również z menu kontekstowego dostępnego na liście delegacji.

Uwaga

Wyłącznie z menu kontekstowego dostępne są odwrotne operacje – cofnięcie akceptacji wydatków (DLG wraca do stanu „Wydatki do akceptacji”) oraz cofnięcie przekazania wydatków do akceptacji (DLG ma wówczas stan „Zaakceptowane polecenie wyjazdu”).

Delegacja: zakładka Płatności

Po oznaczeniu wydatków jako zaakceptowane, na zakładce Płatności, automatycznie wygenerowana zostaje płatność rozliczająca koszty delegacji. Sposób generowania płatności jest zależny od ustawienia parametru „Generuj płatności w wersji rozszerzonej” w definicji dokumentu delegacji.

Zakładka Płatności składa się z 2 sekcji: Delegacja oraz Dokumenty związane z wydatkami. W definicji dokumentu znajduje się parametr „Generuj płatności w wersji rozszerzonej”, którego zaznaczenie będzie miało wpływ na to, czy płatność powiązana z delegacją będzie generowana na kwotę wydatków nie powiązanych z dokumentami będącymi źródłem płatności, czy też na kwotę równą kwocie wszystkich wydatków. W sekcji Delegacja prezentowane są płatności delegacji, czyli kwoty pochodzące z wydatków delegacji niezwiązanych z dokumentami. Płatnikiem na płatności jest pracownik wskazany na delegacji. W sekcji Dokumenty związane z wydatkami prezentowane są płatności pochodzące z dokumentów powiązanych z wydatkami delegacji. Modyfikacja płatności jest możliwa do momentu zaksięgowania delegacji.

Delegacja: zakładka Księgowość

Zakładka ta pojawia się na dokumencie Delegacji po zmianie jej statusu na „Zaakceptowano wydatki.” Wówczas na dokumencie delegacji można dodawać opis analityczny, a po jej zatwierdzeniu podlega ona księgowaniu (zakładka Dekretacja zostaje odszarzona).

Delegacje: zakładka Atrybuty

Na tej zakładce można opisać dany wniosek zdefiniowanymi w systemie i przypiętymi do danego obiektu atrybutami (definiowanie atrybutów odbywa się w module: Administrator).

Delegacje: zakładka Załączniki

Na zakładce możliwe jest umieszczenie załączników dotyczących wniosku. Możliwe jest tu umieszczanie zdjęć, plików tekstowych, arkuszy kalkulacyjnych, itp. Użytkownik ma pełną dowolność w określeniu formatu, w jakim zapisane i przechowywane będą załączniki. Sposób dodawania załączników został opisany w module: Administrator (rozdział: Załączniki).

Uwaga

Z menu kontekstowego możliwe jest usunięcie Polecenia wyjazdu służbowego tylko ze statusem Wprowadzona, w innym przypadku możliwe jest tylko anulowanie Polecenia wyjazdu służbowego. Można tego dokonać, gdy:

• Pracownik wprowadzający, jak i anulujący polecenie wyjazdu służbowego jest przypisany do struktury podległościowej
• Pracownik, który anuluje delegacje ma podpiętą rolę (na roli pracownika wskazane jest Centrum oraz dodane prawa dotyczące poleceń wyjazdu służbowego: Akceptacja/anulowanie poleceń wyjazdu podwładnych; Akceptacja/anulowanie poleceń wyjazdu pracowników centrum

Jeżeli powyższe warunki nie zostaną spełnione przy próbie anulowania Polecenia wyjazdu służbowego pojawi się komunikat: “Operator nie ma uprawnień do anulowania polecenia wyjazdu”

Wstęp

Podczas importu listy płac z systemu Comarch ERP XL HR do systemu Comarch ERP XL, mogą pojawić się błędy uniemożliwiające poprawny import. Najczęściej wynikają one z  nieprawidłowej konfiguracji synchronizacji. Często dotyczą one również list płac importowanych wraz z opisem analitycznym. Są one związane z uprawnieniami  Operatora importującego listę płac lub też z brakiem pozycji synchronizowanego wymiaru. Należy przy tym pamiętać, że tylko trzy wymiary systemowe mogą być synchronizowane, tj. Centrum, Projekty, Lokalizacja.

Błędy zgłaszane w przypadku niewłaściwych uprawnień operatora

Podczas importu list płac pojawia się błąd: Wystąpił błąd podczas dodawania linii opisu analitycznego. Błędny element opisu (nieistniejąca pozycja lub brak odpowiednich uprawnień)

Jeżeli podczas importu wyświetlony zostanie powyższy komunikat, oznacza to, że Operator importujący jest zwykłym Użytkownikiem, bez odpowiednich uprawnień i lista płac nie zostanie zaimportowana do Comarch ERP XL.

Aby Operator mógł zaimportować listę płac, musi posiadać uprawnienia:

Nie ma znaczenia umiejscowienie pracownika w strukturze podległościowej. Struktura podległościowa jest wykorzystywana do sporządzenia podzielnika wynagrodzeń, który jest stosowany zamiennie z opisem analitycznym w Comarch ERP XL HR. Podczas importu listy płac sprawdzana jest wyłącznie struktura kosztowa.

Błędy zgłaszane w przypadku niespójności w wymiarach analitycznych

Nie udało się pobrać centrum dla elementu wypłaty: Nazwa wydziału. Błąd dodawania do tabeli PIKKwoty (Instrukcja INSERT powoduje konflikt z ograniczeniem FOREIGN KEY „FK_PIKPrimary”. Konflikt występuje w bazie danych „CDN_XL_baza” w tabeli „CDN.PIKElem”.Wykonywanie instrukcji zostało przerwane)

Jeżeli podczas importu pojawia się powyższy komunikat, oznacza to, że w systemie Comarch ERP XL brak jest pracownika i centrum kosztowego ( wydziału), którym opisana jest lista płac w systemie Comarch ERP XL HR.

W takim przypadku należy uaktualnić wydział w systemie Comarch ERP XL HR. Uaktualnienie wydziału polega na ponownym zapisaniu formularza danych wydziału, przy włączonym parametrze: Współpraca z systemem Comarch ERP XL. W systemie Comarch ERP XL dopisany zostanie wydział, jako centrum w strukturze kosztowej. Listę płac będzie można zaimportować prawidłowo po ponownym uruchomieniu modułu: Księgowość, ponieważ struktura kosztowa odczytywana jest przy starcie tego modułu.

Uwaga

Rozbieżności pomiędzy strukturą kosztową Comarch ERP XL i wydziałami Comarch ERP XL HR mogą być spowodowane :

–  usunięciem lub dodaniem w Comarch ERP XL centrum kosztowego przy wyłączonej synchronizacji z systemem Comarch ERP XL HR,

– usunięciem lub dodaniem w Comarch ERP XL HR nowego wydziału przy wyłączeniu parametru konfiguracyjnego: Współpraca z systemem Comarch ERP XL.

Wystąpił błąd podczas dodawania linii opisu analitycznego. Błędny element opisu (nie istniejąca pozycja(KOD: Pracownik, Lp: 3, TypKwoty: 0, Wartość: 5940.5) lub brak odpowiednich uprawnień)

Jeżeli podczas importu pojawia się powyższy komunikat, oznacza to, że w systemie Comarch ERP XL brak jest pracownika, dla którego została naliczona wypłata w systemie Comarch ERP XL HR lub do pracownika nie zostało przypisane centrum kosztów w systemie Comarch ERP XL. Aby prawidłowo zaimportować listę płac, należy uaktualnić kartę pracownika wraz z wydziałem w systemie Comarch ERP XL HR. Uaktualnienie polega na ponownym wybraniu wydziału na karcie pracownika i  zapisaniu karty przy włączonym parametrze: Współpraca z systemem Comarch ERP XL.

W Comarch ERP XL, dopisany zostanie zarówno pracownik na liście pracowników oraz jego wydział jako centrum w strukturze kosztowej. Po ponownym uruchomieniu modułu: Księgowość, listę płac będzie można poprawnie zaimportować.

W niektórych przypadkach zachodzi konieczność ponownego naliczenia listy płac w Comarch ERP XL HR i ponowny import do Comarch ERP XL.

Wystąpił błąd podczas określania wymiaru projekt. Nazwa opisu analitycznego. Nie znaleziono wymiaru

Jeżeli podczas importu zostanie wyświetlony powyższy komunikat, oznacza to, że lista płac w Comarch ERP XL HR jest opisana wartością wymiaru: Projekt, który w Comarch ERP XL nie istnieje. Należy wykonać aktualizację tego wymiaru, a więc edytować i zapisać formularz projektu w Comarch ERP XL HR, przy włączonym parametrze: Współpraca z systemem Comarch ERP XL.

Listę płac będzie można zaimportować prawidłowo po ponownym uruchomieniu modułu: Księgowość.

Wystąpił błąd podczas określania wymiaru lokalizacja. Nazwa opisu analitycznego. Nie znaleziono wymiaru

Jeżeli podczas importu zostanie wyświetlony powyższy komunikat, oznacza to, że lista płac w Comarch ERP XL HR jest opisana wartością wymiaru: Lokalizacja, który w Comarch ERP XL nie istnieje. Należy wykonać aktualizację tego wymiaru, a więc edytować i zapisać formularz lokalizacji w Comarch ERP XL HR, przy włączonym parametrze: Współpraca z systemem Comarch ERP XL.

Listę płac będzie można zaimportować prawidłowo po ponownym uruchomieniu modułu: Księgowość.

Uwaga

Rozbieżności pomiędzy listą pracowników, listą projektów oraz listą lokalizacji w Comarch ERP XL HR i Comarch ERP XL mogą być spowodowane:

– usunięciem lub dodaniem w Comarch ERP XL pracownika, po dokonaniu exportu lub synchronizacji z Comarch ERP XL HR,

– dodaniem w Comarch ERP XL HR nowego pracownika po wyłączeniu parametru konfiguracyjnego: Współpraca z systemem Comarch ERP XL,

–  usunięciem lub dodaniem w Comarch ERP XL lokalizacji, projektu przy wyłączonej synchronizacji z systemem Comarch ERP XL HR,

– usunięciem lub dodaniem w Comarch ERP XL HR  lokalizacji, projektu przy wyłączeniu parametru konfiguracyjnego: Współpraca z systemem Comarch ERP XL.

Opis analityczny zawierający wydział nadrzędny: FIRMA

Jeżeli pracownik jest przypięty do wydziału nadrzędnego FIRMA w Comarch ERP XL HR i opis analityczny listy płac również zawiera wydział Firma, wówczas lista płac zostanie zaimportowana do Comarch ERP XL bez wypełnionego wymiaru: Centrum, na opisie analitycznym.

Uwaga

Sytuacja taka  spowodowana jest brakiem możliwości opisywania wymiaru: Centrum wydziałem głównym w Comarch ERP XL.  W Comarch ERP XL HR opis analityczny zawierający wydział główny jest natomiast dopuszczalny.

Błędy zgłaszane w przypadku nieprawidłowej konfiguracji synchronizacji

Podczas próby zaimportowania nieprzeniesionych danych z systemu Comarch ERP XL HR, pojawia się błąd: Błąd wewnętrzny procedury . Wystąpił błąd ADO: User does not have permission to perform this action.-2147217900

Uwaga

Opisane poniżej czynności mogą być wykonywane wyłącznie przez administratora systemu lub osobą z uprawnieniami do zarządzania serwerem bazy danych.

W celu uzyskania bardziej szczegółowych informacji o przyczynie braku importu danych, należy  z poziomu narzędzia Microsoft SQL Server Management Studio wykonać procedurę:

exec cdn.ImportListPlacOptima ID_Zestawu,1

W miejsce pierwszego parametru funkcji należy wstawić ID zestawu transformacji DTS, za pomocą którego wykonywany jest import ( jest to wartość pola:  DZE_ID z tabeli CDN.DTSZestawy).

Drugi parametr procedery przyjmuje zawsze wartość 1.

Zwracane wyniki procedury:

Could not find server ‘server _Place’ in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers.Msg 50000, Level 16, State 1, Procedure ImportListPlacOptima, Line 146 102:Błąd dodawania rekordu do CDN.##DTS_O_TypWyplata

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że nie został utworzony zlinkowany serwer lub podczas jego dodawania, wskazana została nieprawidłowa nazwa serwera, na którym znajdują się bazy Comarch ERP XL HR i Comarch ERP XL lub utworzony został zlinkowany serwer bez końcówki: ‘_Place’.

Konieczne jest dodanie zlinkowanego serwera lub usunięcie już istniejącego i dodanie go ponownie ( za pomocą skryptu dostępnego w biuletynie technicznym: XL114 – Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4).

W wersji 2017.0 Comarch ERP XL wprowadzono automatyczne tworzenie zlinkowanwgo serwera oraz jego mapowanie na bazy Comarch ERP XL oraz Comarch ERP XL HR .

W celu uruchomienia współpracy oraz utworzenia zlinkowanego serwera należy w  konfiguracji systemu Comarch ERP XL na zakładce: HR zaznaczyć check: Synchronizuj strukturę organizacyjną i dane kadrowe oraz uzupełnić pozostałe dane zgodnie z biuletynem: XL064 – Współpraca Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR.

Podczas próby zaimportowania nieprzeniesionych danych z systemu Comarch ERP XL HR, nic się nie dzieje ( listy płac nie importują się)

Uwaga

Opisane poniżej czynności mogą być wykonywane wyłącznie przez administratora systemu lub osobą z uprawnieniami do zarządzania serwerem bazy danych.

W celu uzyskania informacji o przyczynie braku importu danych, należy  z poziomu narzędzia Microsoft SQL Server Management Studio wykonać procedurę:

exec cdn.ImportListPlacOptima ID_Zestawu,1

W miejsce pierwszego parametru funkcji należy wstawić ID zestawu transformacji DTS, za pomocą którego wykonywany jest import ( jest to wartość pola:  DZE_ID z tabeli CDN.DTSZestawy).

Drugi parametr procedery przyjmuje zawsze wartość 1.

Zwracane wyniki procedury:

The OLE DB provider “SQLNCLI11” for linked server “server_Place” does not contain the table “”CDN_ KonfiguracjaOptima”.”CDN”.”WalNazwy””. The table either does not exist or the current user does not have permissions on that table

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że login SQL po którym następuje linkowanie serwerów ( zazwyczaj CDNDTS) nie został zmapowany na bazę konfiguracyjną Comarch ERP XL HR.

W celu zmapowania loginu należy, we właściwościach loginu,  na zakładce: User Mapping, wskazać bazę konfiguracyjną Comarch ERP XL HR, a  w obszarze Database role membership for: zaznaczyć role:  CDNRaport, public.

The OLE DB provider “SQLNCLI11” for linked server “server_Place” does not contain the table “”CDN_FirmaOptima”.”cdn”.”TypWyplata””. The table either does not exist or the current user does not have permissions on that table

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że login SQL po którym następuje linkowanie serwerów ( zazwyczaj CDNDTS) nie został zmapowany na bazę firmową Comarch ERP XL HR.

W celu zmapowania loginu należy, we właściwościach loginu,  na zakładce: User Mapping, wskazać bazę firmową Comarch ERP XL HR, a  w obszarze Database role membership for: zaznaczyć role:  CDN, CDNRaport, public, db_owner.

Komunikat ten pojawi się również jeżeli w zestawie transformacji DTS wskazano nieprawidłowo nazwę serwera, na którym znajdują się bazy Comarch ERP XL HR i Comarch ERP XL.

The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.The statement has been terminated.Msg 50000, Level 16, State 1, Procedure ImportListPlacOptima, Line 205 106:Błąd dodawania do CDN.##DtsListyXL

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że w zestawie transformacji DTS został nieprawidłowo określony format daty w polu: Przenoszenie danych od daty.

Prawidłowy format daty to: DD-MM-RR

Login failed for user ‘CDNDTS’

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że podczas dodawania zlinkowanego serwera, wskazane zostało nieprawidłowe hasło, dla loginu SQL po którym wykonywanie jest linkowanie ( zazwyczaj jest to login CDNDTS). Konieczna jest zmiana hasła z poziomu właściwości zlinkowanego serwera (Microsoft SQL Server Management Studio ->Server Objects->Linked Servers-> Properties ( zlinkowanego serwera)-> zakładka: Security)

Cannot insert duplicate key row in object ‘CDN.Slowniki’ with unique index ‘SLWWartosci’.The statement has been terminated

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że  prawdopodobnie doszło do zaburzenia wartości SLW_SlsID w tabeli Cdn.Slowniki dla składników płac ( wartość pola powinna być zgodna z wartością pola Sls_Id z tabeli Cdn.SlownikiStruktura dla składników plac).

W celu poprawy rozbieżności należy wykonać  update pola slw_slsid w tabeli Cdn.Slowniki dla składników płac.

Uwaga

Wszystkie czynności naprawcze  należy  najpierw wykonać w środowisku testowym.

Podczas próby zaimportowania nieprzeniesionych danych z systemu Comarch ERP XL HR, pojawia się komunikat: Menedżer transakcji partnera wyłączył swoją obsługę transakcji zdalnych/sieciowych

Jeżeli synchronizacja wykonywana jest między serwerami w różnych fizycznych lokalizacjach, konieczne jest uruchomienie i skonfigurowanie usługi systemowej MSDTC, czyli koordynatora transakcji rozproszonych.

Ustawienia usługi zostały opisane w biuletynach technicznych: XL064 – Współpraca Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR oraz XL114 – Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4.

 

 

Ewidencja korekty podatku odliczonego

Zakup towaru czy usługi – jeżeli związany jest z wykonywanymi przez podatnika czynnościami opodatkowanymi – uprawnia do odliczenia podatku naliczonego w zasadzie bez ograniczeń. Nie podlega natomiast odliczeniu podatek naliczony od zakupów służących działalności zwolnionej z VAT. W sytuacji gdy podatnik prowadzi tzw. działalność mieszaną (opodatkowaną VAT i zwolnioną) i dokonanego zakupu nie można jednoznacznie przyporządkować do danego rodzaju czynności wykonywanych przez podatnika, podatek VAT odlicza się proporcjonalnie.

Ustalenie korekty podatku naliczonego od zakupu towarów Wg ustawy o VAT, podatek naliczony do odliczenia od zakupów dokonanych w danym roku, liczony jest na podstawie struktury sprzedaży zrealizowanej w roku poprzednim. Po zakończeniu bieżącego roku , podatek odliczony musi zostać skorygowany, tj. wyliczony na podstawie struktury sprzedaży za okres roku bieżącego. Korekta podatku odliczonego będzie zatem różnicą pomiędzy podatkiem VAT odliczonym na podstawie współczynnika struktury sprzedaży z roku poprzedniego, a podatkiem VAT, jaki powinien być odliczony na podstawie struktury sprzedaży roku bieżącym.

Ustawienia konfiguracyjne

W konfiguracji w części dotyczącej Księgowości na zakładce: Parametry 2 należy określić, czy współczynnik sprzedaży ma być zaokrąglany. Podatnik nie ma bowiem obowiązku stosowania wskaźnika proporcji przy działalności mieszanej w sytuacji, gdy wskaźnik ten jest stosunkowo wysoki lub niski. Art. 90 ust. 10 ustawy o VAT określa, że w sytuacji gdy proporcja:

Ustalenie korekty podatku naliczonego od zakupu towarów

Załóżmy, że:

Rok poprzedni np.: 2015

Jak zarejestrować korektę w systemie Comarch ERP XL

Sposób 1

Aby zarejestrować korektę w systemie Comarch CDNXL, należy:

Sposób 2

Aby nie liczyć wartości korekty ręcznie można:

Reasumując:

W tym konkretnym przypadku od kwoty podatku VAT 27.959,02, która ze względu na zadeklarowany sposób odliczenia („Warunkowo”) oraz miesiąc ujęcia na deklaracji 01/2017 zostanie skorygowana o współczynnik struktury z 2016 r., zostanie odjęta wartość podatku odliczonego w 2016 r., czyli 24.044,76.

Struktura sprzedaży z roku 2016 = 97%.

Warto zauważyć, że w deklaracji podatkowej, w której podatnik rozlicza podatek VAT przewidziano odrębne rubryki, uwzględniające roczne korekty podatku naliczonego (a także korekty związane ze zmianą przeznaczenia nabytych towarów i usług). W części D.3. deklaracji VAT-7, VAT-7K i VAT-7D wpisuje się odpowiednio kwoty korekty podatku naliczonego od nabycia środków trwałych oraz korekty podatku od pozostałych nabyć. Jeżeli kwota ta ma wartość ujemną, czyli podatek naliczony w wyniku korekty ulega zmniejszeniu, to należy ją ująć w deklaracji ze znakiem “–”.

W tym przykładzie na deklaracji VAT-7(17), w pozycji 48 pojawi się wartość 27.959,02 x 97% – 24.044,76 = 3075,49, zaokrąglona do kwoty 3.075.

Ustalenie korekty podatku naliczonego od zakupu środków trwałych

W przypadku Środków Trwałych, okres korekty do tyczy 5 lat (nieruchomości – 10 lat).

Załóżmy, że:

W rozliczeniu za rok 2016 „przysługiwało” odliczenie w wysokości 8.882,11. Odliczono 8.040,65 (86% kwoty 9.349,59). Przez okres 5 lat, należy skorygować kwoty podatku naliczonego. W związku z tym, kwotę podatku naliczonego tj. 9.349,59 należy podzielić przez 5 (9.349,59/5 = 1.869,92). Przez 5 należy podzielić także kwotę, która została odliczona 8.040,65/5 = 1.608,13.

W tym konkretnym przypadku korekta podatku odliczonego za 2016 będzie wynosiła: 1.869,92-1.608,13 = In plus 261,79.

W poniższej tabeli zobrazowano proces korygowania podatku odliczonego na przestrzeni 5 lat, przy założeniu, że proporcja za rok 2015 wynosiła 86%.

Łączna wartość odliczonego podatku VAT: 8.040,65+168,29-168,29+56,1+56,1-486,18 = 7.666,67.

Jak zarejestrować korektę w systemie ERP XL

Sposób 1

Aby zarejestrować korektę w systemie Comarch CDN XL, należy:

Sposób 2

Po zarejestrowaniu faktury zakupu dot. ŚT można od razu (aby nie umknęło) zarejestrować dodatkowy zapis, który automatycznie może korygować podatek odliczony nie tylko za jeden rok, ale także na przestrzeni 5 lat.

Analiza zostanie przeprowadzona przy przykładzie zakupu ŚT na kwotę 50.000 (VAT 9.349,59).

Pozycja 1
Netto: 0,00
VAT: 1.869,92 ( 1/5 kwoty 9.349,59)
Odliczenie podatku VAT – „Warunkowo” (kwota podatku będzie korygowana przez strukturę sprzedaży)
Miesiąc ujęcia na deklaracji VAT-7 – 2017/01.

Pozycja 2
Netto: 0,00
VAT: (-1608,13), (1/5 kwoty 8.040,65, która faktycznie została odliczona – Wsp. proporcji jest nam znany)
Odliczenie podatku VAT – „TAK”
Miesiąc ujęcia na deklaracji VAT-7 – 2017/01.

W celu rozliczenia podatku VAT w latach następnych, w analogiczny sposób należy dodać osiem kolejnych pozycji, które rozliczą (skorygują podatek VAT) w latach: 2018, 2019, 2020, 2021.

Uwaga

Na pozycjach tabelki VAT należy pamiętać o prawidłowym ustawieniu parametru decydującego o miesiącu oraz roku ujęcia pozycji na deklaracji VAT-7.

Na deklaracji VAT-7, zapis oznaczony jako: Inwestycja lub Nieruchomość lub Środek transportu oraz Korekta podatku odliczonego, pojawi się w polu 47.

Reasumując:

Korektę podatku odliczonego dot. nabycia środków trwałych (nieruchomości) można wprowadzić w postaci jednego zapisu zbiorczego, obejmującego wartość wszystkich nabytych w danym roku środków trwałych (nieruchomości) lub w postaci oddzielnych zapisów, korygujących podatek odliczony od zakupu poszczególnych środków trwałych (nieruchomości).

Zapisy korygujące zbiorcze lub pojedyncze, można wprowadzać na przestrzeni 5 (ewentualnie 10) lat. Dzięki mechanizmowi – odliczenie: Warunkowo, pozwalającemu na automatyczne wyliczanie podatku naliczonego do odliczenia w oparciu o strukturę, istnieje także możliwość wprowadzenia jednego zapisu, zawierającego n-pozycji, który automatycznie będzie korygował podatek odliczony na przestrzeni 5 lat (w przypadku środków trwałych) lub 10 lat (w przypadku nieruchomości).

Pomocne wydruki

Zestawienie sprzedaży wg proporcji – jeden z 4 dostępnych wydruków z odpowiednim stopniem szczegółowości.

Weryfikacja wysokości podatku naliczonego niepodlegającego odliczeniu

Załóżmy, że:

W związku z tym, że wyliczona kwota jest większa niż 500 PLN, od tego momentu Użytkownik powinien stosować wskaźnik struktury sprzedaży w wysokości 99%. W konfiguracji modułu księgowość należy przestawić parametr w ramach sekcji: Wskaźnik struktury sprzedaży. Parametr ten należy odznaczyć.

W systemie Comarch CDNXL udostępniono wydruk: Rozliczenie podatku nalicz. niepodlegającego odliczeniu, który ma na celu ułatwienie wyliczenia kwoty podatku niepodlegającej odliczeniu. Wydruk ten dostępny jest z poziomu zakładki: VAT okna: Rejestr VAT dla rejestrów zakupu. Wydruk wykonywany jest za wskazany w ramach jego parametrów okres i dla określonego współczynnika. Wydruk ten ma sens tylko dla współczynnika 99%.

 

Wstęp

Schematy księgowań bazują na powtarzalności pracy w księgowości. W każdym miesiącu dokumenty są księgowane w pewien powtarzalny sposób, na takie same konta księgowe. Zastosowanie mechanizmów schematów księgowań usprawnia sam proces księgowania dokumentów powodując, że dekrety na konta księgowe tworzone są w sposób automatyczny.

Każdy dokument w systemie Comarch ERP XL podlega księgowaniu przy użyciu schematów księgowań. Schematy księgowań wymagają zdefiniowania na samym początku pracy z programem, aby dokumenty mogły zostać automatycznie rozksięgowane na konta.

Budowa prostych schematów nie jest trudna, jednak ich zaawansowane stosowanie wymaga znajomości budowy bazy danych.

W poniższym dokumencie zostaną podane scenariusze tworzenia schematów księgowań wraz z ewentualnymi wskazówkami.

Warunki w nagłówku schematu księgowego

W systemie Comarch ERP XL w nagłówku schematu księgowego dostępne jest definiowanie warunków dla dzienników oraz dat księgowania umożliwiające ograniczenie liczby schematów księgowych.

Na zakładce Ogólne dostępne są przyciski pozwalające na:

Warunek dla dziennika

Na zakładce Ogólne dostępny jest przycisk pozwalający na wybór konkretnego dziennika lub utworzenie warunków dla dzienników.

Po wybraniu przycisku <Dodaj> zostanie udostępnione okno Warunek dla dziennika, z poziomu którego można zbudować warunki dla wybranych dzienników przy użyciu konstruktora filtra lub zapytania SQL.

Warunek daty księgowania

Na zakładce Ogólne schematu księgowego dostępne są parametry pozwalające na wskazanie konkretnej daty księgowania lub utworzenia warunków dla dat księgowania.

Po wybraniu opcji Warunek: daty księgowania oraz przycisku <Dodaj> zostanie udostępnione okno: Warunek daty księgowania, z poziomu którego można zbudować warunki dla wybranych dat przy użyciu konstruktora filtra lub zapytania SQL.

Zakładanie kont z wykorzystaniem schematów księgowań

Księgowanie dokumentów generujących płatności

Przy księgowaniu wartości brutto dokumentu na konto rozrachunkowe kontrahenta należy bezwzględnie pamiętać, że w schemacie księgowym tworzymy pozycję, które odwołuje się do Płatności tzn. w polu: Oblicz dla, wybieramy Płatność.

Nie należy księgować wartości na konta rozrachunkowe w oparciu o nagłówek (kwota Brutto). Księgowanie w oparciu o nagłówek, bądź też poprzez ręczną predekretację na dokumencie, może spowodować rozbieżności pomiędzy rozrachunkami a rozliczeniami. Mogą powstać błędy, związane z brakiem rozrachunku pomimo istnienia rozliczenia i odwrotnie, niemożnością dokonania rozrachunku (rozliczenia), naliczaniem różnic kursowych w niewłaściwych wysokościach.

Schemat księgowy może zakładać zarówno konta podane w formie liczby np. 220-01 jak i konta zdefiniowane w formie wyrażenia. Warunkiem założenia konta w planie kont przy użyciu schematu księgowego jest zaznaczenie na pozycji schematu pola: Załóż konto. Należy pamiętać, że konta zakładane przez schemat księgowy zakładane są na jednym poziomie (gdy w planie kont istnieje tylko syntetyka główna oraz w konfiguracji nie został zaznaczony parametr: Tworzenie kont pośrednich).

Przyklad

Wprowadzono wyrażenie ‘201-‘&Trn_TrnSeria&’-‘&Twr_Kod. Konto założone przy użyciu tego schematu będzie wyglądało następująco: 201-KR-01, gdzie kontem syntetycznym jest 201, a analityką będzie wyrażenie KR-01. Nie ma możliwości rozróżnienia poziomów analityki, czyli w naszym przykładzie nie można tak założyć tego konta aby analityką na pierwszym poziomie było wyrażenie KR, a analityką na drugim poziomie było 01, chyba że analityka KR już istnieje w planie kont.

Zakładanie kont pośrednich, a więc kont na różnych poziomach zostanie omówione w osobnym rozdziale.

Tworząc wyrażenie można odwołać się do dostępnych pól z tabel.

W zależności czy odwołujemy się w pozycji schematu księgowego do Płatności, Nagłówka, Elementów, VAT-u czy opisu analitycznego dostępne są różne tabele:

Pola z innych tabel, pozostających w relacjach z dostępnymi tabelami, również można wykorzystywać przy użyciu odpowiednio skonstruowanych zapytań SQL-owych.

Kilka wyrażeń można łączyć ze sobą za pomocą znaków &. Dodatkowo, gdy już w polu konto mamy wprowadzone jakieś wyrażenie np. ‘700-‘&Tre_typTwr i teraz chcę dodać kolejną część związaną z kontem magazynowym zapisanym na karcie towaru, wystarczy jak ustawię kursor na końcu wprowadzonego wyrażenia i prawym klikiem myszy wybiorę z dostępnej listy opcję: Towaru-magazyn wówczas doklejone zostanie: TWR_Konto1.

Przykłady odwoływania się do dostępnych pól w wyrażeniu konta księgowego:

Funkcje sub, choose w schematach księgowych

W wyrażeniach zakładających konta można odwoływać się również do funkcji typu: sub, choose.

Funkcja sub

Przyklad

Na karcie towaru, w polu: konto magazynu, podano konto 300-01. Następnie zakładam schematem konto przychodów ze sprzedaży (syntetyka 700), którego analityką ma być część kont magazynowego towaru znajdującego się na księgowanej fakturze, a dokładnie w naszym przykładzie wyrażenie 01. W schemacie zakładającym konto sprzedaży mogę więc wykorzystać funkcję sub i wyrażenie będzie wyglądało następująco:

‘700-‘&sub(Twr_Konto1,5,2) gdzie 5 i 2 oznacza, że bierzemy pod uwagę 2 znaki zaczynając od piątego.

Funkcja choose

Może zdarzać się, że pozycje pewnych dokumentów będą księgowane na określone konto pobierane z określonej lokalizacji, a w przypadku braku wskazania konta zaksięgujemy dokument na jedno zbiorcze konto.

Przyklad

Wartość netto faktury księgujemy na konto znajdujące się na karcie towaru znajdującego się na dokumencie. W przypadku braku określenia wskazania konta na karcie towarowej wartość netto faktury księgujemy na konto rozliczenie zakupu np. 300-01.

Wyrażenie na pozycji schematu księgowego może wówczas wyglądać następująco:

Choose(Twr_Konto1=’’, ‘300-01’, Twr_Konto1)

Opis analityczny

W przypadku opisu analitycznego mamy możliwość odwoływania się do wymiarów standardowych typu: centrum, lokalizacja, kategoria, projekt, a także do wymiarów zdefiniowanych we własnym zakresie.

Księgowanie w oparciu o opis analityczny najczęściej wykorzystywane jest do rozksięgowania wartości netto dokumentu na odpowiednie wymiary kosztowe, przychodowe. Wartości dokumentów, w zależności od zdefiniowanych wymiarów, można rozbić na właściwe centra, lokalizacje, projekty według obranego klucza.

Przyklad

Firma posiada 3 centra kosztowe: dział produkcji, dział logistyczny, dział administracji. Dodatkowo posiada lokalizację w Krakowie i Wrocławiu, w których to znajdują się przedstawiciele każdego centrum.

Dokumenty kosztowe oraz przychodowe są opisywane analitycznie tak, aby właściwe rozłożyć koszty i przychody na określone centra.

Dodatkowo plan kont ma dostosowaną strukturę kont zespołu 5 i 7 do podziału zgodnego z centrami oraz lokalizacją.

Struktura kont zespołu 5 wygląda następująco:

Syntetyka- centrum- lokalizacja- kategoria

Centra mają na kartach przypisane właściwe konta: administracja: 501, logistyka: 502, produkcja: 503

Lokalizacje mają w polu konto zapisane wyrażenie, które będzie wykorzystywane przy zakładaniu kont tj: Kraków: KR, Wrocław: WR.

Konta zespołu 5 będą zakładane poprzez schemat księgowy. Pozycja schematu księgowego zakładająca konta będzie wyglądała następująco:

produkcja: 503

Lokalizacje mają w polu konto zapisane wyrażenie, które będzie wykorzystywane przy zakładaniu kont tj: Kraków: KR, Wrocław: WR.

Konta zespołu 5 będą zakładane poprzez schemat księgowy. Pozycja schematu księgowego zakładająca konta będzie wyglądała następująco:

gdzie na liście kategorii finansowych odzwierciedlone zostaną konta analityczne zespołu 4 np. amortyzacja własnych śr. trwałych konto 400-01, zużycie materiałów 401-03 itd. W wyrażeniu zakładającym konto zespołu 5, wykorzystano funkcję „sub” po to, aby z kategorii finansowej wziąć pod uwagę tylko oznaczenie dotyczące syntetyki, czyli np. 400, 401 itp.

Zapytanie SQL w polu Kwota, Konto, Opis

W  polach: Kwota, Konto (Debet, Credit) oraz Opis istnieje możliwość skorzystania z opcji: Zapytanie SQL

Warto korzystać z tej opcji jeśli kwota, czy też konto/opis mają być budowane w oparciu o uprzednio przygotowane zapytanie SQL. Po wybraniu tej opcji pojawia się okno: Zapytanie SQL do którego możemy wkleić przygotowanie zapytanie, przy czym jeżeli zapytanie ma dynamicznie odnosić się do księgowanego obiektu zamiast konkretnych  “gidnumerów” księgowanego obiektu, używamy znaku “@”. System księgując dany dokument zastąpi wyrażenie danymi konkretnego obiektu:

Po zapisaniu okna system sam przekształci zapytanie sql do poniższej postaci:

Uwaga

Znaku “@” możemy używać po wybraniu opcji Zapytanie SQL w polach Kwota, Konto: Credit, Debet i Opis. Nie można go używać w polu: Warunek schematu księgowego.

Uwaga

Jeżeli w zapytaniu sql korzystamy z własnej funkcji /procedury należy nadać uprawnienia dla CDNRaport do jej wywołania

Przyklad

Wyrażenie, które łączy makro z zapytaniem sql powinno wyglądać następująco:

SQL(‘select ”a”’)&’ ‘& @KON

Wyksięgowanie różnic groszowych

W procesie księgowania dokumentów zdarzają się sytuacje związane z tym, że strony księgowe nie bilansują się pomimo, że schemat jest właściwie skonstruowany. Przyczyną tego stanu rzeczy mogą być zaokrąglenia np. pomiędzy wartością netto liczoną dla elementów, a wartością netto liczoną dla nagłówka.

Bardzo często tego typu różnice groszowe ujawniają się właśnie podczas predekretacji dokumentu. Powinny one zostać wyksięgowane specjalnie skonstruowanymi pozycjami na konta techniczne.

Przykładowo, jeśli na nagłówku dokumentu wystąpiła kwota wyższa o jeden grosz niż na elementach, to należy dodać następujące dwie pozycje: 1. Oblicz dla: Nagłówka, kwota: Netto 2. Oblicz dla: Elementów, kwota: -Netto (minus netto) Obydwie pozycje należy zaksięgować na techniczne konto po stronie, na której schemat proponuje kwotę niższą o ten jeden grosz. Przy zaznaczonym parametrze: Sumuj kwoty o tych samych kontach, obydwie pozycje dadzą w sumie brakujący grosz. Analogicznie można postąpić przy różnicy groszowej występującej między innymi tabelami.

Istnieje również możliwość wyksięgowania takich różnic poprzez dodanie w schemacie księgowym pozycji opartej o zapytanie sql, które będzie wyliczać takie różnice groszowe.

Przyklad

Aby wyeliminować różnice groszowe na spinaczu (S)FS należy zdefiniować dodatkową pozycję schematu: Oblicz dla: Nagłówka i w polu: Kwota, wpisać następujące wyrażenie:

TRN_NettoR – SQL(‘SELECT SUM(TRE_KsiegowaNetto) FROM CDN.TraElem JOIN CDN.TraNag ON TRE_GIDTyp=TRN_GIDTyp AND TRE_GIDFirma=TRN_GIDFirma AND TRE_GIDNumer=TRN_GIDNumer WHERE TRN_SpiTyp=’ & TRN_GIDTyp & ‘ AND TRN_SPIFirma=’ & TRN_GIDFirma & ‘ AND TRN_SPINumer=’ & TRN_GIDNumer)

Dla dokumentu niebędącego spinaczem np. paragonu należy wprowadzić następujące wyrażenie:

TRN_NettoR -SQL(‘ SELECT SUM(TRE_KsiegowaNetto) FROM CDN.TraElem WHERE TRE_GIDTyp=’ & TRN_GIDTyp & ‘ AND TRE_GIDNumer=’ & TRN_GIDnumer )

Schemat księgowy dla faktury końcowej pochodzącej z faktury zaliczkowej zawierający pozycję dotyczącą wyksięgowania kwoty netto faktur zaliczkowych z konta przychodów przyszłych okresów na konto przychodów bieżących za pomocą sql-a. Wprowadzenie pozycji przy użyciu SQL-a, pomaga wyeliminować różnice groszowe, które uniemożliwiają zaksięgowanie dokumentu – strony nie bilansują się. Poniżej przykład takiego schematu księgowego:

Poz.	Konto Winien	Konto Ma	Kwota	Opis
1		730-01	Netto	Netto
2		220-01	VAT	VAT
3	*ODBIORCA		Płatność	Należność
4	731-01	310-01	Wartość_zakupu	Koszty
5	854-01	730-01	SQL('select sum(trn_nettor) from cdn.trarozliczzal join cdn.tranag on trn_gidtyp = trz_zaltyp and trn_gidnumer = trz_zalnumer where trz_kontyp= '&trn_gidtyp&' and trz_konnumer= '&trn_gidnumer)	Netto faktury zaliczkowej

Kwota netto zaliczki

Zmienna Zaliczka pozwala na wyksięgowanie kwoty netto zaliczki. Można wybrać ją w polu: Kwota pozycji schematu, podczas księgowania na podstawie nagłówka lub elementów:

Zmienna ta pozwala na bezpośrednie wyksięgowanie kwoty zaliczki z dokumentów związanych z fakturą zaliczkową, bez konieczności użycia zapytania SQL przedstawionego w poprzednim rozdziale. Przy jej pomocy kwotę netto zaliczki można wyksięgować z:

Po stronie sprzedaży:

Po stronie zakupu:

Pole warunek na pozycji schematu księgowego

Na pozycji schematu istnieje możliwość zdefiniowania warunku po spełnieniu którego nastąpi księgowanie na definiowaną pozycję. W polu istnieje możliwość skorzystania z konstruktora filtra, który umożliwi wybranie odpowiednich kolumn z tabeli, która jest dostępna dla danej pozycji. Przykładowo dla pozycji zbudowanych dla Płatności będą to kolumny tabel: cdn.TraPlat i  cdn.KntKarty

Uwaga

Na  pozycjach   schematów  księgowych  dokumentów handlowych (z tabeli cdn.TraNag) i not memoriałowych, w polu: Warunek, wszelkie odwołanie do pola  tabeli cdn.KntKarty  powinno być poprzedzone aliasem PDMKNT  np. PDMKNT.knt_powiazany=0

Kwoty VAT-u

Na dokumentach “vatowskich”, na zakładce: VAT, istnieje kilka elementów pozwalających na określenie, do jakiego miesiąca zaliczymy VAT, czy będzie to miesiąc równy miesiącowi wpływu dokumentu. Możemy określić parametry związane z odliczeniami VAT-u, a także, czy ujmujemy określoną kwotę na deklaracji VAT-7 czy też nie.

W zależności od zaznaczenia określonych parametrów kwota VAT-u jest księgowana na inne konto.

Przyklad

Na konto 221-01 księgujemy wartości VAT-u z faktur zakupu w przypadku gdy miesiąc ujęcia na deklaracji VAT-7 jest równy miesiącowi wpływu dokumentu oraz gdy odliczenia VAT-7 są ustawiona na tak lub warunkowo.

Taką pozycję w schemacie księgowym można zapisać następująco, wykorzystując pole warunek:

Kwoty netto

Przykładowo zakładamy konto sprzedaży (zespół 7) w zależności od serii wybranej na dokumencie, stawki podatku VAT na elemencie oraz typu towaru określonego na karcie (towar, produkt, usługa koszt).

Przykładowa pozycja takiego schematu może wyglądać następująco:

W schematach księgowych można wykorzystywać również atrybuty.

Przyklad

Definiuję na liście atrybutów atrybut o nazwie kontrahent obcy, wartościami, jakie będzie mógł przyjmować, będą: tak, nie. Następnie, w schemacie zakładam konta, w zależności od określonych wartości, jakie przyjmuje atrybut przypisany do kontrahenta: 212-01 kontrahenci krajowi (czyli atrybut ustawiony na NIE) , 212-02 kontrahenci obcy (czyli atrybut ustawiony na TAK):

Schemat:

W polu konto wprowadzamy wyrażenie:

‘212-01-‘&FORMAT(KNT_GIDNUMER,@N06)

W polu warunek wprowadzamy zapytanie, które pozwoli na join pomiędzy tabelą KntKarty, a tabelą Atrybuty:

exists (Select * from Cdn.Atrybuty With (NOLOCK)

Where

Atr_Obityp=knt_gidTyp

and Atr_ObiFirma=knt_gidFirma

and Atr_ObiNumer=knt_gidNumer

and (Atr_AtkID=1 and Atr_Wartosc=’nie’))

Pozycja na konto ‘212-02-‘&FORMAT(KNT_GIDNUMER,@N06) będzie wyglądała analogicznie tyle tylko, że wartość atrybutu w warunku będzie określona na: tak.

Zapytanie SQL w polu warunek

W polu: Warunek wpisujemy wyłącznie tę część zapytania SQL która występuje po wyrażeniu “where” . Warunkiem jest, aby na dalej liście mieć bezpośrednie odwołanie do danej tabeli.

Przyklad

Księgowanie w oparciu o Nagłówek (dostępna tabela cdn.TraNag)

1. select * from cdn.TraNag where exists(select tno_trnnumer from cdn.TrNOpisy where TnO_TrnNumer=TrN_GIDNumer and TnO_TrnTyp=trn_gidtyp)
2. select * from cdn.TraNag  where trn_gidnumer in (select tno_trnnumer from cdn.trnopisy join cdn.TraNag Nag on Nag.Trn_GidTyp=Tno_TrNTyp and Nag.TRN_GIDNumer=Tno_TrNNumer where TnO_Opis LIKE ‘%’ + ‘reklamacja’ + ‘%’ )

 

Uwaga

Znaku “@” możemy używać po wybraniu opcji Zapytanie SQL w polach Kwota, Konto: Credit, Debet i Opis. Nie można go używać w polu: Warunek schematu księgowego.

Uwaga

Jeżeli w zapytaniu sql korzystamy z własnej funkcji /procedury należy nadać  uprawnienia dla CDNRaport do jej wywołania

Księgowanie dokumentów związanych z realizacją zadań produkcyjnych

W systemie Comarch ERP XL nie ma możliwości przyjęcia na magazyn wyrobów wg Technicznego Kosztu Wytworzenia (w skrócie TKW). Wyroby mogą być przyjęte wg kosztów surowców bezpośrednich lub w cenach ewidencyjnych. Sposób ewidencji wyrobów, wg TKW lub wg cen ewidencyjnych wyznacza różne sposoby ewidencji na kontach księgowych wyrobów i rozliczania z nimi kosztów.

W związku z tym, że na poziomie modułu „Produkcja” nie można dokonać wyceny i przyjąć na magazyn wyrobów wg TKW, zalecamy ewidencję wyrobów w cenach ewidencyjnych oraz rozliczanie kosztów na kontach księgowych celem ustalenia Technicznego Kosztu Wytworzenia.

W tym wariancie koszty muszą być rozliczane za pośrednictwem konta ‘580’ – Rozliczenie produkcji. Po stronie Ma konta 580 księgowana jest wartość wyrobów (półfabrykatów) przyjętych na magazyn wg kosztu ewidencyjnego, a po stronie Wn księgowany jest rzeczywisty koszt wytworzenia wyprodukowanych i przyjętych na magazyn wyrobów gotowych oraz półfabrykatów. Saldo konta ‘580’ wyksięgowywane jest na konto „Odchylenia od stałych cen ewidencyjnych’ (621). Zatem na wartość bilansową wyrobów gotowych (półfabrykatów) składać się będzie suma sald kont: „Wyroby gotowe” (601) i „Odchylenia od stałych cen ewidencyjnych” (621).

W związku z tym, że z poziomu modułu „Produkcja” istnieje możliwość odniesienia w koszty produkcji podstawowej wyłącznie kosztów surowców bezpośrednich (z możliwością przypisania ich do poszczególnych asortymentów), pozostałe koszty (wydziałowe, zarządu, itp.) należy rozliczyć na poziomie modułu księgowego za pomocą księgowań okresowych, z wykorzystaniem lub nie kluczy podziałowych.

W systemie Comarch ERP XL dokumentami związanymi z realizacją produkcji są:

RW – Wydanie surowców, półfabrykatów do produkcji;

PW – Przyjęcie wyprodukowanych wyrobów gotowych, półfabrykatów na magazyn lub zwrot nadmiaru pobranego do produkcji surowca lub półfabrykatu;

ZP – Zlecenie Produkcje dokumentujące przebieg produkcji z podziałem na: czynności, zużyte do produkcji surowce (w cenie zakupu lub w cenie ewidencyjnej), półprodukty (w cenie ewidencyjnej, lub koszcie wg zużytych surowców) oraz wyprodukowane w ramach zlecenia produkcyjnego wyroby gotowe, półprodukty tzw. półfabrykaty (w koszcie ewidencyjnym oraz koszcie wg zużytych surowców).

Wszystkie powyższe dokumenty można zaksięgować korzystając ze schematów księgowych. Należy się jednak zastanowić i podjąć decyzję, czy będą księgowane wszystkie dokumenty: RW, PW, ZP, czy też tylko RW, PW. Pomocną w tym zakresie będzie analiza scenariuszy, jaka ma miejsce w przedsiębiorstwie.

Wyżej wspomniana wiedza jest istotna, ponieważ przekłada się na ujmowanie dokumentów na kontach księgowych także w aspekcie czasowym. Z poziomu dokumentu RW oraz zlecenia produkcyjnego można dokonać wyksięgowania kosztu zużytych surowców wg cen zakupu – wartość zużytych surowców w produkcji. Z poziomu PW i zlecenia produkcyjnego udostępniono natomiast możliwość wyksięgowania kosztu zużytych do produkcji surowców wg cen zakupu, oraz wg kosztu ewidencyjnego w podziale na poszczególne wyroby – koszt poszczególnych wyrobów wg zużytych surowców bezpośrednich, jak również przyjęcie wyrobów wg cen ewidencyjnych. Należy zatem uważać, aby przez nieuważne zdefiniowanie schematów księgowych nie zdublować informacji na kontach księgowych.

Księgowanie dokumentów RW

Dokument RW dokumentuje przesunięcie surowców z magazynu do produkcji. Poniżej przedstawione zostały przykłady schematów księgowych zdefiniowanych dla dokumentu RW.

Przyklad

Przesunięcie surowców w cenie zakupu do produkcji (konto 312 – Materiały w przerobie), a następnie ujęcie na koncie kosztowym – Zużycie materiałów (411)

Legenda:

312 – materiały w przerobie

*MAGKONTO – magazyn surowców na stanie

411 – koszty zużycia materiałów

Kwota Netto:

– w przypadku surowców – cena zakupu

– w przypadku półproduktów – koszt wg surowców, lub koszt ewidencyjny (wyliczany lub z góry ustalony)

Przyklad

Przesunięcie do produkcji od razu księgowane jest w koszty konta zespołu „4”.

Przyklad

Przesunięcie surowców w cenie zakupu do produkcji (konto 312 – Materiały w przerobie). Ujęcie na kontach zespołu „4” nastąpi w wyniku księgowania Zlecenia Produkcyjnego.

Księgowanie dokumentu PW

Dokument PW pozwala na zaksięgowanie wyrobów gotowych oraz półproduktów wg cen ewidencyjnych na konto zespołu „6”, np. 601- Wyroby gotowe. Za jego pośrednictwem można także dokonać wyksięgowania wartości wyrobów wg zużytych do ich produkcji surowców. Służy do tego celu kwota „Koszt surowców”. Kwotę tą wprowadzono z myślą o scenariuszu, w którym zlecenie zamykane jest w innym miesiącu aniżeli zostało otwarte, a ponadto produkty przyjmowane są na magazyn na przestrzeni kilku miesięcy.

Poniżej przykłady schematów księgowych:

Przyklad

Pozycja 1 – zaksięgowanie wyrobów w cenie ewidencyjnej na konto Magazyn Wyrobów (601)

Pozycja 2 – zaksięgowanie wyrobów w wartości zużytych surowców na konto Produkcji podstawowej

Pozycja 3 – zaksięgowanie wyrobów w wartości zużytych surowców na konto Rozliczenie produkcji (580) i wyksięgowanie z konta produkcji podstawowej.

Poniżej definicja pozycji schematu księgowego pozwalająca na zaksięgowanie wartości wyrobów wg surowców bezpośrednich.

Przyklad

Pozycja 1 – zaksięgowanie wyrobów w cenie ewidencyjnej na konto Magazyn Wyrobów (601). Zaksięgowanie wyrobów w wartości zużytych surowców na konto produkcji podstawowej oraz konto Rozliczenie produkcji (580) nastąpi z poziomu Zlecenia Produkcji.

Księgowanie dokumentu ZP

Funkcja księgowania dla zlecenia produkcyjnego jest udostępniana po jego zamknięciu.

Z poziomu zlecenia produkcyjnego mamy możliwość wyksięgowania:

1. Kwoty odchyleń

Ideą rozliczenia zlecenia produkcyjnego jest rozłożenie wszystkich kosztów poniesionych w ramach zlecenia na wytworzone w nim produkty. Jeżeli tak się nie stanie, wówczas część kosztów, która nie znalazła odzwierciedlenia w koszcie produktów zostanie ujęta w pozycji: Odchylenie kosztu oraz Odchylenie kosztu surowca na zakładce: Ogólne, zlecenia produkcyjnego.

Kwoty odchyleń można księgować wybierając jedną z kwot dostępnych w opcji: Oblicz dla: Nagłówka:

Odchylenia kosztu surowca

Odchylenia kosztu ewidencyjnego

Wybierając jedną z dostępnych „dla Nagłówka” kwot, system pobierze wartość z analogicznego pola na zleceniu produkcyjnym (patrz poniższy rysunek).

2. Pozostałe kwoty

Oprócz kwot odchyleń, z poziomu Zlecenia Produkcji można wyksięgować następujące wartości:

Zanim omówione zostaną poszczególne kwoty udostępnione dla opcji: „Surowców”, „Produktów” parę słów o znaczeniu poniższych pojęć wykorzystywanych w nazewnictwie poszczególnych kwot:

1. Produkt finalny – produkt przyjmowany na magazyn dokumentem PW. Może nim być produkt gotowy, jak również półprodukt przyjęty na magazyn celem sprzedaży lub wykorzystania w innym zleceniu produkcyjnym;
2. Półprodukt własny– produkt wykorzystany w dalszym cyklu produkcyjnym w ramach tego samego zlecenia;
3. Półprodukt obcy – produkt wykorzystany w cyklu produkcyjnym, który został wyprodukowany w ramach innego zlecenia produkcyjnego. Półprodukt obcy może być przyjęty na magazyn dokumentem PW, ale nie musi – może zostać powiązany z zasobem na innym zleceniu. W pierwszym przypadku półprodukt obcy będzie traktowany jako surowiec, w drugim przypadku jako półprodukt obcy.

Kwoty dla opcji „Oblicz dla: Surowców”

Wybierając opcję „Oblicz dla surowców” dostępne są następujące kwoty:

1. Koszt surowca finalny – koszt obejmuje wyłącznie koszt surowców produktów, półproduktów finalnych tj. wyrobów, które są produktem finalnym procesu produkcyjnego, udokumentowanym przyjęciem na magazyn dokumentem PW;
2. Koszt surowca półproduktów własnych – koszt obejmuje koszt surowców wg ceny zakupu półproduktów wyprodukowanych i zużytych w ramach tego samego zlecenia do produkcji innego produktu (półproduktu);
3. Koszt surowca półproduktów obcych – koszt obejmuje koszt surowców wg ceny zakupu półproduktów wyprodukowanych w ramach jednego zlecenia a zużytych do produkcji wyrobu finalnego w innym zleceniu, przy czym tego rodzaju półprodukty nie są przyjmowane na magazyn dokumentem PW, ma natomiast miejsce powiązanie pomiędzy zleceniami;
4. Koszt ewidencyjny finalny – patrz objaśnienie do „Koszt surowca finalny”. Różnica polega na tym, że nie jest to kosz wg ceny zakupu lecz koszt ewidencyjny.
5. Koszt ewidencyjny półproduktów własnych – patrz objaśnienie do „Koszt surowca półproduktów własnych”. Różnica polega na tym, że nie jest to kosz wg cen zakupu, lecz koszt ewidencyjny;
6. Koszt ewidencyjny półproduktów obcych – patrz objaśnienie do „Koszt surowca półproduktów obcych”. Różnica polega na tym, że nie jest to kosz wg cen zakupu, lecz koszt ewidencyjny.

Kwoty dla opcji: „Oblicz dla: Produktów”

Identyczne kwoty udostępniono dla opcji Oblicz dla: Produktów. Różnica polega tylko na tym, że w ramach kwot ma miejsce grupowanie wg produktów.

Poniżej przedstawiono przykładowy schemat księgowania dokumentu ZP.

Przyklad

Pozycja 1 – zaksięgowanie kosztu surowców zużytych do realizacji danego zlecenia (411)

Pozycja 2 – zaksięgowanie kosztu surowców zużytych do produkcji poszczególnych wyrobów na konto produkcji podstawowej (z podziałem na poszczególne produkty)

Pozycja 3 – zaksięgowanie kosztu surowców zużytych do produkcji poszczególnych wyrobów na konto Rozliczenie produkcji (580) i wyksięgowanie z konta produkcji podstawowej

Sposoby dokumentowania operacji produkcyjnych oraz ich ujęcie na kontach

Poniżej lista operacji, które powstają w procesie produkcyjnym, sposób ich ujęcia na kontach księgowych oraz sposób dokumentowania.

Operacja	Kwota	Konto WN	Konto MA	Dokument
Przyjęcie wyrobów gotowych na magazyn	Cena ewidencyjna (koszt planowany)	601-Wyroby gotowe	580 - Rozliczenie produkcji	PW
Sprzedaż wyrobów gotowych	Cena ewidencyjna (koszt planowany)	711 – Koszt własny sprzedanych wyrobów	601 - Wyroby gotowe	FS
Wyksięgowanie kosztu wytworzenia wyrobów gotowych	Techniczny koszt wytworzenia: Koszty bezpośrednie, Koszty wydziałowe, Koszty pośrednie,Uzasadniona część kosztów zarządu bezpośrednio związanych z produkcją wyrobów gotowych	580 – Rozliczenie produkcji	501 – Produkcja podstawowa	Księgowania okresowe z zastosowaniem kluczy podziałowych
Zarachowanie odchyleń	Odchylenia debetowe (SDT)	621 – Odchylenia od cen ewidencyjnych	580 – Rozliczenie produkcji	Księgowania okresowe
	Odchylenia kredytowe (SCT)	580 – Rozliczenie produkcji	621 – Odchylenia od cen ewidencyjnych	Księgowania okresowe
Zarachowanie odchyleń od cen ewidencyjnych sprzedanych wyrobów	Odchylenia debetowe (SDT)	711 – Koszt własny sprzedanych wyrobów	621 – Odchylenia od cen ewidencyjnych	Księgowania okresowe
	Odchylenia kredytowe (SCT)	621 – Odchylenia od cen ewidencyjnych	711 – Koszt własny sprzedanych wyrobów	Księgowania okresowe

Scenariusz 1

Surowce wydawane do produkcji nie pod konkretne zlecenia.

Obieg dokumentów: RW, Zlecenie Produkcyjne, PW – z poziomu Zlecenia produkcyjnego.

Operacja	Kwota	Konto WN	Konto MA	Dokument	Uwagi
Wydanie surowców do produkcji	Koszt surowców wg cen zakupu	319 – surowce w przerobie	311 – magazyn surowców	RW
	Koszt surowców wg cen zakupu	411 - koszt surowców bezpośrednich	319 – surowce w przerobie	RW
	Koszt surowców wg cen zakupu	501-02 – produkcja w toku	490 – Rozliczenie kosztów	RW	Na poziomie planu kont brak możliwości odniesienia kosztów surowców na konto produkcji w toku wg asortymentu produkcji
Zarachowanie kosztów surowców zużytych bezpośrednio w produkcji	koszt surowców wg cen zakupu	501-01-XXX-YY	501-02 – produkcja w toku	Zlecenie Produkcyjne
	- (koszt surowców wg cen zakupu)	501-02 – produkcja w toku		Zlecenie Produkcyjne	Zapis techniczny korygujący obroty na koncie 501-02.
	- (koszt surowców wg cen zakupu)		501-02 – produkcja w toku	Zlecenie Produkcyjne	Zapis techniczny korygujący obroty na koncie 501-02.

Scenariusz 2

Surowce wydawane do produkcji pod konkretne zlecenia. Zamknięcie zlecenia w tym samym miesiącu, w którym zostało otwarte.

Obieg dokumentów: Zlecenie Produkcyjne, RW, PW generowane z poziomu Zlecenia produkcyjnego

Operacja	Kwota	Konto WN	Konto MA	Dokument	Uwagi
Wydanie surowców do produkcji	Koszt surowców wg cen zakupu	319 – surowce w przerobie	311 – magazyn surowców	RW
	Koszt surowców wg cen zakupu	411 - koszt surowców bezpośrednich	319 – surowce w przerobie	RW lub ZP	Schemat księgowy ZP Oblicz dla: Surowców, Kwota: Koszt surowców finalnych + Koszt surowców obcych
	Koszt surowców wg cen zakupu	501-01-XXX-YYY lub 501-02 – produkcja w toku	490 – Rozliczenie kosztów	RW lub ZP	Na poziomie planu kont brak możliwości odniesienia kosztów surowców na konto produkcji w toku wg asortymentu produkcji
Zarachowanie kosztów surowców zużytych bezpośrednio w produkcji	koszt surowców wg cen zakupu	501-01-XXX-YY	501-02 – produkcja w toku	Zlecenie Produkcyjne	Dekret niezbędny, jeżeli koszt surowców najpierw zaksięgowano na konto produkcji w toku.
	- (koszt surowców wg cen zakupu)	501-02 – produkcja w toku		Zlecenie Produkcyjne	Zapis techniczny korygujący obroty na koncie 501-02.
	- (koszt surowców wg cen zakupu)		501-02 – produkcja w toku	Zlecenie Produkcyjne	Zapis techniczny korygujący obroty na koncie 501-02.

Dokument różnic kursowych

W zależności od ustawień konfiguracyjnych księgowanie różnic kursowych odbywa się:

1. bez pośrednictwa dokumentu RK – dekret różnicy kursowej
2. za pośrednictwem dokumentu RK – jeżeli zostanie wybrany parametr konfiguracyjny

Księgowanie automatyczne

Automatyczne księgowanie dokumentu różnic kursowych jest uruchamiane po zaksięgowaniu wszystkich dokumentów źródłowych. Sposób ujmowania dokumentu Różnic Kursowych na kontach księgowych odbywa się na identycznych zasadach jak księgowanie wygenerowanego automatycznie dekretu różnic kursowych. Różnica kursowa księgowana jest na tym koncie rozrachunkowym i po tej stronie konta, na którą została zaksięgowana płatność, zapis kasowy/bankowy o mniejszym kursie walut (kontrola kursów walut).

Poniżej przykład liczbowy dot. wygenerowania RK w przypadku rozrachunku.

	Euro	Kurs	Wn	Kwota	Ma	Kwota
Płatność	1000	4	201-01	4000
Zapis kasowy	1000	3			201-01	3000
Różnica Kursowa			WaN_KontoMinus	1000	201-01	1000

Poniżej przykład liczbowy dot. wygenerowania RK w przypadku kompensaty:

	Euro	Kurs	Wn	Kwota	Ma	Kwota
Płatność	1000	4	201-01	4000
Płatność	1000	3			202-01	3000
Kompensata	1000	3	202-01	3000	201-01	3000
Różnica Kursowa			WaN_KontoMinus	1000	201-01	1000

Księgowanie schematem

W celu zaksięgowania dokumentu różnicy kursowej należy spełnić następujące wymogi:

1. Dokumenty źródłowe muszą być zaksięgowane;
2. Kwota Różnic Kursowych (dodatnia, ujemna) musi być zaksięgowana po odpowiedniej stronie konta rozrachunkowego zgodnego z „kontem dokumentu źródłowego. (Bierzemy pod uwagę konto zapisu o mniejszym kursie);
3. Jeżeli w wyniku księgowania RK błędnym schematem, nie doszłoby do powstania rozrachunku – system uniemożliwi księgowanie;
4. Predekretacja nie może zawierać kilku tych samych kont rozrachunkowych. Jeżeli pojawią się co najmniej dwa takie same konta rozrachunkowe, próba księgowania zakończy się niepowodzeniem i standardowym komunikatem – „Brak możliwości ustalenia kont rozrachunkowych”;
5. Nie dojdzie do zaksięgowania dokumentu RK także w sytuacji gdy jeden z dekretów związanych z dokumentem źródłowym zostanie rozrachowany z dekretem „z poza kręgu rozliczeń” – wprowadzonym „z ręki” lub związanym z dokumentem nie biorącym udziału w rozliczeniach;
6. Musi być spełniona zasada bilansowania się.

W schematach księgowych dla Różnic kursowych udostępnione zostały następujące kwoty:

Oblicz dla:	Kwota	Konto	Opis	Warunek
Nagłówka	Dodatnia, Ujemna, Kwota	Konto, Konto dokumentu, Konto plus, Konto minus	@Numer – numer RK, @Dok- numer zewn., @Opis - opis @Opisauto - opis atomatyczny	Flaga „Status” wartość: Przychody, Koszty, Kompensaty, Inne
Opis analityczny	Zgodnie z obowiązującym standardem

Przykładowy schemat dla dokumentu różnicy księgowej został zamieszczony poniżej.

Przyklad

Definicja schematu księgującego dokument RK

Lp	Konto debet	Konto credit	Kwota	Opis	Warunek
1	Konto dokumentu	Konto plus	Dodatnia	@NUM, @DOK
2	Konto minus	Konto dokumentu	Ujemna	@NUM, @DOK
3		901-01	Dodatnia	@NUM, @DOK	Status: Przychody
4		901-01	(-)Ujemna	@NUM, @DOK	Status: Przychody
5	901-02		Ujemna	@NUM, @DOK	Status: Koszty
6	901-02		(-) Dodatnia	@NUM, @DOK	Status: Koszty

Pozycja 1. Ujęcie bilansowe – pozwalające na zaksięgowanie RK dodatniej

Kwota: Dodatnia

Konto Debet: Konto dokumentu

Konto Credit: Konto plus

Opis: @Numer, @Opis

Warunek: brak

Pozycja 2. Ujęcie bilansowe – pozwalające na zaksięgowanie RK ujemnej

Kwota: Ujemna

Konto Debet: Konto minus

Konto Credit: Konto dokumentu

Opis: @Numer, @Opis

Warunek: brak

Pozycja 3. Ujęcie podatkowe – pozwalająca na zaksięgowanie RK dodatniej o charakterze „przychodowym”

Kwota: Dodatnia

Konto Debet:

Konto Credit: 901-01 Konto pozabilansowe

Opis: @ Numer, @Opis

Warunek: wartość flagi status = „przychody”

Pozycja 4. Ujęcie podatkowe – pozwalająca na zaksięgowanie RK ujemnej o charakterze „przychodowym”

Kwota: (-) Ujemna

Konto Debet:

Konto Credit: 901-01 Konto pozabilansowe

Opis: @ Numer, @Opis

Warunek: wartość flagi status = „przychody”

Pozycja 5. Ujęcie podatkowe – pozwalająca na zaksięgowanie RK dodatniej o charakterze „kosztowym”

Kwota: (-)Dodatnia

Konto Debet: 901-02 Różnice kosztowe – Konto pozabilansowe

Konto Credit: –

Opis: @ Numer, @Opis

Warunek: wartość flagi status = „koszty”

Pozycja 6. Ujęcie podatkowe – pozwalająca na zaksięgowanie RK ujemnej o charakterze „kosztowym”

Kwota: Ujemna

Konto Debet: 901-02 Różnice kosztowe – Konto pozabilansowe

Konto Credit: –

Opis: @ Numer, @Opis

Warunek: wartość flagi status = „koszty”

Jak widać z powyższego przykładu różnice dla transakcji przychodowych będą księgowane po stronie Ma – dodatnie ze znakiem plus, ujemne ze znakiem minus. Różnice kursowe dla transakcji kosztowych będą księgowane zawsze po stronie Wn – dodatnie ze znakiem minus, ujemne ze znakiem plus. Różnice kursowe, którym wybrano flagę „Kompensaty” oraz „Inne” będą księgowane wyłącznie w ujęciu bilansowym.

Zakładanie kont pośrednich przez schemat księgowy

Zakładanie kont pośredniego poziomu może odbywać się za pomocą schematów księgowych, podczas przenoszenia planu kont oraz z poziomu karty kontrahenta. Warunkiem założenia konta pośredniego jest zaznaczony w konfiguracji parametr Tworzenie kont pośrednich (Księgowość/Parametry 1). W celu założenia konta pośredniego poziomu należy przy włączonym w konfiguracji parametrze Tworzenie kont pośrednich, posłużyć się znakiem ‘-‘ oddzielającym od siebie kolejne poziomy. Z kolei dwa myślniki ‘−−’ oznaczają konto zakładane na tym samym poziomie. Poniższy rysunek prezentuje pozycję schematu księgowego, zakładającą konto: 510-001-ADM-404-01, gdzie 510 to konto syntetyczne, 001 konto analityczne pierwszego poziomu, ADM – konto analityczne drugiego poziomu, 404-01 – konto analityczne trzeciego poziomu. Żeby poprawnie przebiegło założenie tego typu konta, w schemacie wyrażenie zakładające konto musi być zdefiniowane następująco: ‘510-001-ADM-404−−01’.

W sytuacji, kiedy akronim kontrahenta zawiera myślnik i schemat księgowy zakłada konto kontrahenta po akronimie: ‘201-‘&knt_akronim, żeby uniknąć tworzenia konta pośredniego poziomu, przy włączonym w konfiguracji parametrze “Tworzenie kont pośrednich”, należy skorzystać z funkcji zk – zmiana kreski, która zamienia jeden myślnik na dwa myślniki, tym samym uniemożliwiając tworzenie konta pośredniego poziomu. Wyrażenie w schemacie księgowym powinno wyglądać następująco: ‘201-‘&zk(knt_akronim).

Dostępne parametry w schematach księgowych funkcji księgującej dokumenty TraNag

Zmodyfikowano i uporządkowano dostępne parametry w schematach księgowych funkcji księgującej dokumenty TraNag. Księgowanie po opisie analitycznym nie uległo zmianie w stosunku do wcześniejszych wersji. Poniżej przedstawiono zastosowanie parametrów w schematach księgowych dla określonych typów dokumentów.

Księgowanie dokumentów niespiętych, np. WZ, PZ

Oblicz dla: Nagłówka - nagłówek księgowanego dokumentu
Warunek - dozwolone pola KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka K.TRN_ rekord nagłówka dokumentu korekty w przypadku KK	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego @NUM - numer systemowy dokumentu @OPIS - opis dokumentu @KOR - numer korekty dokumentu @KON - akronim kontrahenta z nagłówka dokumentu @MIA - miasto kontrahenta z nagłówka dokumentu
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu TRE_ pozycja dokumentu TWR_ towar na pozycji dokumentu TRS_ dostawa danej pozycji dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka K.TRN_ rekord nagłówka dokumentu korekty w przypadku KK	Kwota i wyrażenie dozwolone pola TRN_ nagłówek dokumentu TRE_ pozycja dokumentu TWR_ towar na pozycji dokumentu TRS_ dostawa danej pozycji dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu TRE_ pozycja dokumentu TWR_ towar na pozycji dokumentu TRS_ dostawa danej pozycji dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego @NUM - numer systemowy dokumentu @OPIS - opis dokumentu @KOR - numer korekty dokumentu @KON - akronim kontrahenta z nagłówka dokumentu @MIA - miasto kontrahenta z nagłówka dokumentu

Oblicz dla: Płatności - płatności dokumentu
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu TRP_ płatność dokumentu KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności K.TRN_ rekord nagłówka dokumentu korekty w przypadku KK	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu TRP_ płatność dokumentu KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu TRP_ płatność dokumentu KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego @NUM - numer systemowy dokumentu @OPIS - opis dokumentu @KOR - numer korekty dokumentu @KON - akronim kontrahenta z nagłówka dokumentu @MIA - miasto kontrahenta z nagłówka dokumentu

Oblicz dla: Tabeli VAT - VAT dokumentu
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu TRV_ VAT dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka K.TRN_ rekord nagłówka dokumentu korekty w przypadku KK	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu TRV_ VAT dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu TRV_ VAT dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego @NUM - numer systemowy dokumentu @OPIS - opis dokumentu @KOR - numer korekty dokumentu @KON - akronim kontrahenta z nagłówka dokumentu @MIA - miasto kontrahenta z nagłówka dokumentu

Księgowanie spinaczy, np. (S) FZ, (S) FS

Oblicz dla: Nagłówka – nagłówek księgowanego dokumentu
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka K.TRN_ rekord nagłówka dokumentu korekty w przypadku KK	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego spinacza @NUM - numer systemowy spinacza @OPIS - opis spinacza @DOKSP - numer dokumentu obcego spinacza @NUMSP- numer systemowy spinacza @OPISSP - opis dokumentu spinacza @KOR - numer korekty dokumentu spinacza @KON - akronim kontrahenta z nagłówka spinacza @MIA - miasto kontrahenta z nagłówka spinacza @VAT - VATRejestr/VATNumer

Oblicz dla: Elementów - elementy dokumentów spiętych (pozycje wraz z dostawami)
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu spiętego TRE_ pozycja dokumentu spiętego TWR_ towar na pozycji dokumentu spiętego TRS_ dostawa dla danej pozycji dokumentu spiętego KNT_ kontrahent z nagłówka dokumentu spiętego URZ_ urząd z nagłówka dokumentu spiętego BNK_ bank z nagłówka dokumentu spiętego PRC_ pracownik z nagłówka dokumentu spiętego OA.TNO_ rekord opisu dokumentu spiętego	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu spiętego TRE_ pozycja dokumentu spiętego TWR_ towar na pozycji dokumentu spiętego TRS_ dostawa dla danej pozycji dokumentu spiętego KNT_ kontrahent z nagłówka dokumentu spiętego URZ_ urząd z nagłówka dokumentu spiętego BNK_ bank z nagłówka dokumentu spiętego PRC_ pracownik z nagłówka dokumentu spiętego	Opis - pola wykorzystywane jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu spiętego TRE_ pozycja dokumentu spiętego TWR_ towar na pozycji dokumentu spiętego TRS_ dostawa dla danej pozycji dokumentu spiętego KNT_ kontrahent z nagłówka dokumentu spiętego URZ_ urząd z nagłówka dokumentu spiętego BNK_ bank z nagłówka dokumentu spiętego PRC_ pracownik z nagłówka dokumentu spiętego Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego dokumentu spiętego @NUM - numer systemowy dokumentu spiętego @OPIS - opis dokumentu spiętego @DOKSP - numer dokumentu obcego spinacza @NUMSP- numer systemowy spinacza @OPISSP - opis dokumentu spinacza @KOR - numer korekty dokumentu spiętego @KON - akronim kontrahenta z nagłówka dokumentu spiętego @MIA - miasto kontrahenta z nagłówka dokumentu spiętego

Oblicz dla: Płatności - płatności dokumentu spinacza i dokumentów spiętych
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu generującego daną płatność, dotyczy zarówno spinacza jak i dokumentów spiętych. Warunek dla poszczególnych dokumentów (spinacz/spięte) należy rozróżnić używając wirtualnego pola PoziomTRN, które przyjmuje wartości: 0 dla spinacza, 1 - dla dokumentu spiętego. TRP_ płatność dokumentu spiętego jak i spinacza.Poszczególne poziomy można rozróżnić jak dla pól TRN_ KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności OA.TNO_ rekord opisu dokumentu generującego daną płatność (spinacz/spięte)	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu (spinacz + spięte) TRP_ płatność dokumentu (spinacz + spięte) KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności UWAGA: W tym przypadku nie działa użycie wirtualnego pola PoziomTRN	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu (spinacz + spięte) TRP_ płatność dokumentu (spinacz + spięte) KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności UWAGA: W tym przypadku nie działa użycie wirtualnego pola PoziomTRN Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego generującego daną płatność @NUM - numer systemowy dokumentu generującego daną płatność @OPIS - opis dokumentu generującego daną płatność Powyższe zmienne mogą zawierać dane zarówno dokumentów spiętych jak i spinaczy @DOKSP - numer dokumentu obcego spinacza @NUMSP- numer systemowy spinacza @OPISSP - opis dokumentu spinacza W przypadku gdy księgowana płatność pochodzi ze spinacza to @NUM=@NUMSP, @DOK=@DOKSP itp. @KOR - numer korekty dokumentu generującego daną płatność @KON - akronim kontrahenta z płatności @MIA - miasto kontrahenta z płatności

Oblicz dla: Tabeli VAT - VAT spinacza
Warunek - dozwolone pola TRN_ lub z aliasem A.TRN_ nagłówek dokumentu spinacza TRV_ VAT dokumentu spinacza KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka K.TRN_ rekord nagłówka dokumentu korekty dokumentu spinacza w przypadku KK	Kwota i wyrażenie Konta - dozwolone pola TRN_ nagłówek dokumentu spinacza TRV_ VAT dokumentu spinacza KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	Opis - pola wykorzystywane jedynie jako parametry wejściowe do funkcji SQL() TRN_ nagłówek dokumentu spinacza TRV_ VAT dokumentu spinacza KNT_ kontrahent z nagłówka URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego dokumentu z którego pochodzi VAT (spinacza) @NUM - numer systemowy dokumentu z którego pochodzi VAT (spinacza) @OPIS - opis dokumentu z którego pochodzi VAT @DOKSP - numer dokumentu obcego spinacza @NUMSP- numer systemowy spinacza @OPISSP - opis dokumentu spinacza @KOR - numer korekty dokumentu spinacza @KON - akronim kontrahenta z nagłówka spinacza @MIA - miasto kontrahenta z nagłówka spinacza @VAT - VATRejestr/VATNumer

Księgowanie dokumentów RS

Oblicz dla: Nagłówka - nagłówek dokumentu RS
TRN_ lub z aliasem A.TRN_ nagłówek dokumentu	TRN_ nagłówek dokumentu	TRN_ nagłówek dokumentu Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego RS @NUM - numer systemowy dokumentu RS @OPIS - opis dokumentu RS @DOKPAK - numer dokumentu obcego RS @NUMPAK - numer systemowy RS @OPISPAK - opis dokumentu RS @DOKSP - brak opisu @NUMSP- brak opisu @OPISSP - brak opisu @KOR - numer korekty dokumentu RS @KON - brak opisu @MIA - brak opisu

Oblicz dla: Elementów - elementy dokumentów spiętych bezpośrednio do RS oraz spiętych do spinaczy spiętych do RS (pozycje wraz z dostawami)
TRN_ (lub z aliasem A.TRN_) nagłówek dokumentu którego elementem jest: dokument spięty do spinacza spiętego do RS (np. WZ->S'FS->RS) lub dokument spięty do RS (FS->RS). Warunek dla poszczególnych dokumentów (spinacz/spięty) można rozróżnić używając wirtualnego pola PoziomTRN, które przyjmuje wartości: 0 - dla RS, 1 - dla dokumentu spiętego do RS, 2 - dla dokumentu spiętego do spinacza spiętego do RS S.TRN_ nagłówek spinacza spiętego do RS. Warunek dotyczy sytuacji, gdy element pochodzi z dokumentu spiętego do spinacza spiętego do RS TRE_ element zarówno dokumentu spiętego do spinacza spiętego do RS jak i dokumentu spiętego bezpośrednio do RS. Poszczególne poziomy można rozróżnić jak dla pól TRN_ TWR_ towar dla danego elementu (analogicznie do TRE_) TRS_ dostawa dla danej pozycji (analogicznie do TRE_) KNT_ kontrahent z nagłówka dokumentu z którego pochodzi element URZ_ urząd z nagłówka dokumentu z którego pochodzi element BNK_ bank z nagłówka dokumentu z którego pochodzi element PRC_ pracownik z nagłówka dokumentu z którego pochodzi element OA.TNO_ rekord opisu dokumentu do którego należy element OS.TNO_ rekord opisu dokumentu spinacza do którego spięty jest dokument z danym elementem	TRN_ nagłówek dokumentu z którego pochodzi element TRE_ bieżąca pozycja TWR_ towar na danej pozycji TRS_ dostawa dla danego towaru KNT_ kontrahent z nagłówka dokumentu z którego pochodzi element URZ_ urząd z nagłówka dokumentu z którego pochodzi element BNK_ bank z nagłówka dokumentu z którego pochodzi element PRC_ pracownik z nagłówka dokumentu z którego pochodzi element	TRN_ nagłówek dokumentu z którego pochodzi element TRE_ bieżąca pozycja TWR_ towar na danej pozycji TRS_ dostawa dla danego towaru KNT_ kontrahent z nagłówka dokumentu z którego pochodzi element URZ_ urząd z nagłówka dokumentu z którego pochodzi element BNK_ bank z nagłówka dokumentu z którego pochodzi element PRC_ pracownik z nagłówka dokumentu z którego pochodzi element @DOK - numer dokumentu obcego z którego pochodzi element @NUM - numer systemowy dokumentu z którego pochodzi element @OPIS - opis dokumentu z którego pochodzi element @DOKPAK - numer dokumentu obcego RS @NUMPAK - numer systemowy dokumentu RS @OPISPAK - opis dokumentu RS @DOKSP - numer dokumentu obcego spinacza spiętego do RS @NUMSP- numer systemowy spinacza spiętego do RS @OPISSP - opis dokumentu spinacza spiętego do RS @KOR - numer korekty dokumentu z którego pochodzi element @KON - akronim kontrahenta z nagłówka dokumentu z którego pochodzi element @MIA - miasto kontrahenta z nagłówka dokumentu z którego pochodzi element

Oblicz dla: Płatności - płatności dokumentów spiętych bezpośrednio do RS, płatności spinaczy spiętych do RS oraz płatności dokumentów spiętych do spinaczy spiętych do RS
TRN_ (lub z aliasem A.TRN_) nagłówek dokumentu z którego pochodzi płatność: dokument spięty do spinacza spiętego do RS (WZ->(S)FS->RS), spinacz spięty do RS ((S)FS->RS), dokument spięty do RS (FS->RS). Warunek dla poszczególnych dokumentów (spinacz/spięte) należy rozróżnić używając wirtualnego pola PoziomTRN, które przyjmuje wartości: 0 - dla RS, 1 - dla dokumentu spiętego do RS (również spinaczy spiętych do RS), 2 - dla dokumentu spiętego do spinacza spiętego do RS. S.TRN_ nagłówek spinacza spiętego do RS do którego spięte są dokumenty generujące daną płatność TRP_ płatność dokumentu spiętego do spinacza spiętego do RS lub spinacza spiętego do RS lub dokumentu bezpośrednio spiętego do RS. Poszczególne poziomy można rozróżnić jak dla pól TRN_ KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności OA.TNO_ rekord opisu dokumentu generującego płatność OS.TNO_ rekord opisu dokumentu spinacza do którego spięty jest dokument generujący daną płatność	TRN_ nagłówek dokumentu z którego pochodzi płatność: dokument spięty do spinacza spiętego do RS (WZ->(S)FS->RS), spinacz spięty do RS ((S)FS->RS), dokument spięty do RS (FS->RS). TRP_ płatność KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności UWAGA: W tym przypadku nie działa użycie wirtualnego pola PoziomTRN	TRN_ nagłówek dokumentu z którego pochodzi płatność: dokument spięty do spinacza spiętego do RS (WZ->(S)FS->RS), spinacz spięty do RS ((S)FS->RS), dokument spięty do RS (FS->RS). TRP_ płatność KNT_ kontrahent z płatności URZ_ urząd z płatności BNK_ bank z płatności PRC_ pracownik z płatności UWAGA: W tym przypadku nie działa użycie wirtualnego pola PoziomTRN @DOK - numer dokumentu obcego z którego pochodzi płatność @NUM - numer systemowy dokumentu z którego pochodzi płatność @OPIS - opis dokumentu z którego pochodzi płatność @DOKPAK - numer dokumentu obcego RS @NUMPAK - numer systemowy RS @OPISPAK - opis dokumentu RS @DOKSP - numer dokumentu obcego spinacza (spiętego do RS) do którego spięty jest dokument generujący daną płatność @NUMSP - numer systemowy spinacza (spiętego do RS) do którego spięty jest dokument generujący daną płatność @OPISSP - opis dokumentu spinacza (spiętego do RS) do którego spięty jest dokument generujący daną płatność @KOR - numer korekty dokumentu z którego pochodzi płatność @KON - akronim kontrahenta z płatności @MIA - miasto kontrahenta z płatności

Oblicz dla: Tabeli VAT - VAT dokumentu RS
TRN_ lub z aliasem A.TRN_ nagłówek dokumentu RS TRV_ VAT dokumentu RS KNT_ kontrahent z nagłówka dokumentu RS URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	TRN_ nagłówek dokumentu RS TRV_ VAT dokumentu RS KNT_ kontrahent z nagłówka dokumentu RS URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka	TRN_ nagłówek dokumentu RS TRV_ VAT dokumentu RS KNT_ kontrahent z nagłówka dokumentu RS URZ_ urząd z nagłówka BNK_ bank z nagłówka PRC_ pracownik z nagłówka Zmienne do bezpośredniego wybrania w polu Opis @DOK - numer dokumentu obcego RS @NUM - numer systemowy dokumentu RS @OPIS - opis dokumentu RS @DOKPAK - numer dokumentu obcego RS @NUMPAK- numer systemowy RS @OPISPAK - opis dokumentu RS @KOR - numer korekty dokumentu RS @KON - akronim kontrahenta z nagłówka RS @MIA - miasto kontrahenta z nagłówka RS @VAT - VATRejestr/VATNumer

Przyklad

Zastosowanie wirtualnego pola PoziomTRN w warunku schematu księgowego:

Pozycja schematu księgowego ma dotyczyć tylko tych płatności, dla których nagłówki dokumentów, z których pochodzą te płatności mają:

– dla spinacza spiętego do RS serię ‘AAA’

– dla dokumentu spiętego do spinacza spiętego do RS serię ‘CCC’

Warunek w schemacie będzie wyglądał następująco:

((PoziomTRN=1 and TRN_TrnSeria=’AAA’) or (PoziomTRN=2 and TRN_TrnSeria=’CCC’))

Księgowanie po poziomach

Księgując spinacz można za pomocą predefiniowanych zmiennych schematu księgowego sięgnąć bezpośrednio do dokumentu spiętego. Na definicji pozycji schematu księgowego zostało dodane pole: Poziom, w którym dokonujemy wyboru, z jakiego poziomu księgowanego dokumentu będzie pobierana wartość na predekret. Funkcjonalność ta została udostępniona w schematach księgujących dokumenty TraNag, dla opcji:

W ramach funkcjonalności dla poszczególnych opcji udostępniono następujące poziomy:

Dla Nagłówka:

Dla Elementów:

Dla Płatności:

Uwaga

Korzystając z tabel parametrów przedstawionych w poprzednim rozdziale należy zwrócić uwagę, na jakim poziomie odbywa się księgowanie. Przykładowo dla dokumentu RS, do którego spięty jest spinacz (S)FS wygenerowany z dokumentu WZ: Wybierając Poziom 1 na pozycji schematu księgowego dla RS odwołujemy się do dokumentu (S)FS, więc system zachowuje się tak, jak przedstawiono to w tabelach dotyczących spinaczy. Wybierając natomiast Poziom 2: pola pozycji schematu sięgają bezpośrednio do WZ, czyli zgodnie z tabelami dotyczącymi dokumentów niespiętych.

Poziomy dostępne dla Nagłówka

Dokumentu księgowanego:

Tak zdefiniowana pozycja schematu księgowego odwołuje się do Nagłówka dokumentu księgowanego, niezależnie od tego czy dokument jest spinaczem, spinaczem spinaczy, czy dokumentem niespiętym. Jest to domyślny poziom opcji Oblicz dla: Nagłówka.

Księgowanie dokumentów niespiętych, np. WZ, PZ

Dokumentu początkowego:

Pozycja schematu odwołuje się do nagłówka dokumentu księgowanego.

Poziom 1:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 2:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Księgowanie spinaczy, np. (S)FS, (S)FZ

Dokumentu początkowego:

Pozycja schematu odwołuje się do nagłówka dokumentu początkowego, w tym przypadku jest nim dokument spięty.

Poziom 1:

Pozycja schematu odwołuje się do nagłówka dokumentu spiętego do spinacza.

Poziom 2:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Księgowanie dokumentów RS

Przypadek dokumentu RS jest szczególny, w związku z faktem, że istnieje możliwość spinania do niego zarówno dokumentów, które same są spinaczami oraz dokumentów, które spinaczami nie są. Taką sytuację przedstawia dokument RS, do którego spięto: paragon PA, oraz dokument (S)FS, który jest spinaczem dokumentu WZ. Poniższa tabela obrazuje, do jakiego dokumentu będzie odwoływać się pozycja schematu księgującego dokument RS, w zależności od poziomu wybranego w definicji tej pozycji:

Wybrany poziom:	Pozycja schematu odwołuje się do nagłówka dokumentu:
	PA	(S)FS	WZ
Dokumentu początkowego	x		x
Poziom 1	x	x
Poziom 2			x

Poziomy dostępne dla Elementów

Wszystkie:

Tak zdefiniowana pozycja schematu księgowego odwołuje się do Elementów, niezależnie od tego na którym poziomie księgowanego dokumentu elementy występują: czy na poziomie dokumentu do niego spiętego, na poziomie jego dokumentu początkowego, czy na samym księgowanym dokumencie. Jest to domyślny poziom opcji Oblicz dla: Elementów.

Księgowanie dokumentów niespiętych, np. WZ, PZ

Dokumentu księgowanego:

Pozycja schematu odwołuje się do elementów dokumentu księgowanego.

Poziom 1:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 2:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Księgowanie spinaczy, np. (S)FS, (S)FZ

Dokumentu księgowanego:

Elementy transakcji na tym poziomie nie występują, na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 1:

Pozycja schematu odwołuje się do elementów dokumentu spiętego.

Poziom 2:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Księgowanie dokumentów RS

Na dokumentach RS elementy transakcji mogą występować jednocześnie na różnych poziomach. Taką sytuację przedstawia dokument RS, do którego spięto: paragon PA, oraz dokument (S)FS, który jest spinaczem dokumentu WZ. Dokumenty, do których bezpośrednio przyłączone są elementy transakcji w systemie, to w tym przypadku PA i WZ. Dokument księgowany: RS oraz spinacz: (S)FS własnych elementów transakcji nie posiadają. Poniższa tabela obrazuje, do jakiego dokumentu będzie odwoływać się pozycja schematu księgującego dokument RS, w zależności od poziomu wybranego w definicji tej pozycji:

Wybrany poziom:	Pozycja schematu odwołuje się do elementów dokumentu:
	PA	(S)FS	WZ
Wszystkie	x		x
Dokumentu księgowanego	elementy transakcji na tym poziomie nie występują
Poziom 1	x
Poziom 2			x

Poziomy dostępne dla Płatności

Wszystkie:

Tak zdefiniowana pozycja schematu księgowego odwołuje się do płatności księgowanego dokumentu, niezależnie od tego, czy płatność powstała na poziomie dokumentu do niego spiętego, na poziomie jego dokumentu początkowego, czy na samym księgowanym dokumencie. Jest to domyślny poziom opcji Oblicz dla: Płatności.

Księgowanie dokumentów niespiętych, np. WZ, PZ

Dokumentu księgowanego:

Pozycja schematu odwołuje się do płatności dokumentu księgowanego. Jeżeli dokument nie generuje płatności, wtedy na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 1:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 2:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Księgowanie spinaczy, np. (S)FS, (S)FZ

Dokumentu księgowanego:

Pozycja schematu odwołuje się do płatności dokumentu księgowanego. Jeżeli płatność została wygenerowana na poziomie dokumentu spiętego (WZ, PZ), wtedy na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 1:

Pozycja schematu odwołuje się do płatności dokumentu spiętego. Jeżeli dokument spięty (WZ, PZ) nie generuje płatności, wtedy na pozycję dekretu nie zostanie pobrana żadna wartość.

Poziom 2:

Poziom nie występuje w tym przypadku, na pozycję dekretu nie zostanie pobrana żadna wartość.

Księgowanie dokumentów RS

Na dokumentach RS płatności mogą występować jednocześnie na różnych poziomach. Taką sytuację przedstawia dokument RS, do którego spięto: paragon PA, oraz dokument (S)FS, który jest spinaczem dokumentu WZ. Dodatkowo, w zależności od ustawień systemowych dokument WZ może generować płatność lub nie. Wobec tego rozróżnia się dwie sytuacje:

Jeżeli dokument WZ generuje płatność, wtedy płatność znajdująca się na (S)FS nie jest jego własną płatnością, lecz pochodzi z dokumentu WZ. Własnych płatności nie generuje też sam dokument księgowany: RS. Dokumentami, do których bezpośrednio przyłączone są płatności w systemie, to w tym przypadku PA oraz WZ. Poniższa tabela obrazuje, do jakiego dokumentu będzie odwoływać się pozycja schematu księgującego dokument RS, w zależności od poziomu wybranego w definicji tej pozycji:

Wybrany poziom:	Pozycja schematu odwołuje się do płatności dokumentu:
	PA	(S)FS	WZ
Wszystkie	x		x
Dokumentu księgowanego	płatności na tym poziomie nie występują
Poziom 1	x
Poziom 2			x

Jeżeli dokument WZ nie generuje płatności, wtedy płatność wygenerowana zostaje na dokumencie (S)FS spinającym ten WZ. Dokument księgowany: RS własnych płatności nie generuje, zatem dokumentami, do których bezpośrednio przyłączone są płatności w systemie, to w tym przypadku PA oraz (S)FS. Poniższa tabela obrazuje, do jakiego dokumentu będzie odwoływać się pozycja schematu księgującego dokument RS, w zależności od poziomu wybranego w definicji tej pozycji:

Wybrany poziom:	Pozycja schematu odwołuje się do płatności dokumentu:
	PA	(S)FS
Wszystkie	x	x
Dokumentu księgowanego	płatności na tym poziomie nie występują
Poziom 1	x	x
Poziom 2	płatności na tym poziomie nie występują

Tworzenie sum na poziomie dokumentów spinanych

W systemie dostępna jest funkcjonalność dotycząca parametru: Sumuj kwoty o tych samych kontach. Sumowanie można dodatkowo zawęzić do danej pozycji schematu poprzez zaznaczenie parametru: Dla danej pozycji schematu. Dodatkowo dla opcji Oblicz dla: Nagłówka, Elementów i Płatności możliwe jest wskazanie poziomu, w ramach którego odbywać się będzie sumowanie dla pozycji.

Przyklad

Księgowanie spinacza (S)FZ spinającego kilka dokumentów PZ: Użytkownik systemu księgując w oparciu o elementy wartość zakupu na jedno konto, np. rozliczenie zakupu, chciałby uzyskać na dekrecie osobne pozycje związane z poszczególnymi dokumentami PZ.

Ponieważ dokumenty PZ są w tym przypadku zarówno poziomem pierwszym w stosunku do spinacza (S)FZ, jak i dokumentami bezpośrednio związanymi z elementami transakcji, zamierzony efekt można osiągnąć poprzez zastosowanie na pozycji schematu jednego z dwóch poniższych ustawień:

Pozycja schematu księgowego – tworzenie sum na poziomie dokumentów PZ

Możliwe jest albo zsumowanie kwoty do jednej pozycji (przy włączonym sumowaniu), albo rozbicie na n pozycji, po jednej dla każdego z elementów znajdujących się na dokumentach PZ.

Różnicę pomiędzy sumowaniem pozycji po Poziomie 1 księgowanego dokumentu, a po poziomie Nagłówka dokumentu elementu, można zaobserwować na dokumencie RS:

Przyklad

Księgowanie spinacza spinaczy – dokumentu RS:

Przykład dotyczy dokumentu RS, który spina dwa paragony oraz dwa spinacze, gdzie każdy ze spinaczy spina dwa dokumenty WZ. Użytkownik systemu księguje na to samo konto kwotę netto elementów transakcji.

Stosując na pozycji schematu księgowego sumowanie po Poziomie 1, na dekrecie powstanie po jednej pozycji dla każdego dokumentu spiętego bezpośrednio do RS, czyli 4 pozycje z kwotami netto odpowiednio dla paragonów i dokumentów (S)FS:

Stosując na pozycji schematu sumowanie po poziomie Nagłówka dokumentu elementu, na dekrecie powstanie 5 pozycji, po jednej dla każdego z dokumentów posiadającego bezpośrednie powiązanie z elementami transakcji, czyli dla poszczególnych paragonów i dokumentów WZ:

Sumowanie dla pozycji schematu podczas księgowania po poziomach

W związku z możliwością odwołania się na pozycji schematu księgowego do różnych poziomów księgowanego dokumentu, od wyboru poziomu uzależniona jest opcja sumowania w ramach pozycji. Zależność tą ilustrują poniższe tabele:

Oblicz dla: Nagłówka
Poziom pozycji schematu:	Sumowanie możliwe według:
Dokumentu księgowanego	Nagłówek dokumentu księgowanego
Dokumentu początkowego	Nagłówek dokumentu księgowanego Poziom 1
Poziom 1	Nagłówek dokumentu księgowanego
Poziom 2	Nagłówek dokumentu księgowanego Poziom 1

Możliwości sumowania po poziomach są analogiczne dla Elementów oraz Płatności:

Oblicz dla: Elementów/Płatności
Poziom pozycji schematu:	Sumowanie możliwe według:
Dokumentu księgowanego	Nagłówek dokumentu księgowanego
Poziom 1	Nagłówek dokumentu księgowanego Poziom 1
Poziom 2	Nagłówek dokumentu księgowanego Nagłówek dokumentu elementu/płatności Poziom 1 Poziom 2
Wszystkie	Nagłówek dokumentu księgowanego Nagłówek dokumentu elementu/płatności Poziom 1 Poziom 2

Wybór poziomu księgowania daje możliwość wyksięgowania z danego dokumentu wartości tylko dla konkretnego poziomu, a jeżeli księgowanie odbywa się na to samo konto, opcja sumowania pozycji po poziomach pozwala na zsumowanie na dekrecie wyksięgowanych wartości według poziomu innego niż poziom księgowania, czy poziom dokumentu księgowanego. Ilustruje to poniższy przykład:

Przyklad

Sumowanie pozycji po poziomie innym niż wybrany poziom księgowania.

Sumowanie danej pozycji schematu księgowego możliwe jest po wybranym w polu: Poziom poziomie księgowania, lub każdym innym wyższym poziomie. Zastosowanie na pozycji schematu księgowego opcji:

– Oblicz dla: Elementów Poziomu 2

– Sumuj kwoty o tych samych kontach dla danej pozycji dla Poziomu 1,podczas księgowania dokumentu RS przedstawionego w poprzednim przykładzie, da następujący efekt:

Księgowanie dotyczy Elementów Poziomu 2 dokumentu RS, w związku z tym wyksięgowane zostaną kwoty tylko dla dokumentów WZ, ponieważ tylko one znajdują się na Poziomie 2 w stosunku do księgowanego dokumentu RS, posiadają też bezpośrednie połączenie z elementami transakcji. Pozycje na dekrecie zostaną zsumowane po Poziomie 1 dokumentu RS, czyli w tym przypadku po poziomie spinaczy (S)FS. Wobec tego na predekrecie RS powstaną dwie pozycje, po jednej dla każdego z dokumentów (S)FS, z kwotami pobranymi ze spiętych do nich dokumentów WZ, a konkretnie z elementów dokumentów WZ.

Uwaga

Jeżeli podczas predekretacji zwracane są błędy do łatwiejszej analizy można uruchomić testowanie wyrażeń schematu. Testowanie uruchamiane jest na konkretnym schemacie (z obszaru sprzedaż) po wybraniu przycisku: [Włącz testowanie wyrażeń schematu przy kolejnej predekretacji dokumentu]. Testowanie zadziała jednorazowa przy kolejnej predekretacji.Sprawdzane są wyrażenia na konkretnym dokumencie. Można za jego pomocą wychwycić błędy, które zależą od konkretnych danych. np. błędy konwersji typów lub zwracanie przez zapytania SQL(‘…’) więcej niż jednego rekordu. Tryb zostaje wyłączony po każdorazowym predekretowaniu z użyciem danego schematu.

Wstęp

Testy integralności z zakresu modułu: Księgowość, służą do monitorowania poprawności, spójności, przejrzystości bazy pod kątem danych księgowych, do koordynowania prawidłowości relacji między odpowiednimi tabelami. W przypadku istniejących nieprawidłowości testy zgłaszają w logu błędy, ostrzeżenia i zwracają rekordy, będące efektem błędogennej sytuacji w bazie, bądź skutkiem czynności wykonywanych przez Użytkownika w sposób niepoprawny (powodujących zaburzenia w utrzymaniu spójności danych).

Poniższy rysunek przedstawia listę dostępnych standardowych testów integralności z księgowości.

Poza wymienionymi, istnieje również możliwość definiowania odpowiednich testów, w zależności od potrzeb Użytkownika, przy wykorzystaniu wyrażenia SQL (zakładka Testy definiowane).

Ponadto, można określić zakres czasowy, dla którego będzie wykonywany test i tym samym otrzymania wyników odnoszących się właśnie dla tego przedziału czasowego. Takich ustawień, jak również parametryzacji zapuszczanych testów integralności związanych np. z poziomem szczegółowości loga, dokonuje się na zakładce: Ogólne, okna: Testy integralności.

Celem niniejszego biuletynu jest analiza testów integralności oscylujących wokół zagadnień księgowych, w kontekście zwracanych przez test typowych błędnych rekordów. Skoncentrowano się głównie na propozycjach napraw, potencjalnie mogących wystąpić, niepoprawnych zdarzeń w bazie.

Ogólne zasady analizy komunikatów

W komunikatach zwracanych przez testy integralności zawarta jest informacja dotycząca lokalizacji błędnych rekordów w bazie danych. Namiar składa się z nazwy tabeli (lub przedrostka) oraz z czterech cyfr oddzielonych dwukropkami. Cyfry oznaczają kolejno: GIDTyp, GIDFirmę, GIDNumer oraz GIDLp danego rekordu.

Przyklad

Niepoprawny typ rejestru kasowego 26, nazwa Bank BPH S.A., KAR_GID (752:1:2:0).

Przedrostek KAR_GID wskazuje na tabelę Rejestry (patrz dokumentacja tabel), cyfry w nawiasach to:

752 – pole KAR_GIDTyp
1 – pole KAR_GIDFirma
2 – pole KAR_GIDNumer
0 – pole KAR_GIDLp

Na podstawie powyższych danych bez trudu można odszukać problemowy rekord i przeprowadzić analizę zaistniałej sytuacji.

Test: Zgodność sum nagłówków upomnień

Test porównuje kwotę z nagłówka upomnienia (UPN_KwotaOds) z sumą jego elementów (UPE_KwotaOds). W przypadku wystąpienia nieprawidłowości zwracany jest poniższy komunikat:

Niezgodność, UpoNag GID (2833:1:150994946:0) , różnica pomiędzy nagłówkiem i elementami upomnienia 3.72 PLN. (2833:1:150994946:0)

Proponowane rozwiązanie: ponowne wystawienie upomnienia.

Test: Zgodność kasy

Poprawność stanów kasowych

Porównywane są raporty kasowe/bankowe z zapisami. Sprawdzana jest zgodność pól KRP_PrzychodyWal (oraz KRP_RozchodyWal) z sumą pól KAZ_Kwota. Jeżeli waluta systemowa jest różna od waluty raportu, test sprawdza zgodność pól KRP_Przychody (oraz KRP_Rozchody) z sumą KAZ_Kwota (przeliczoną po odpowiednim kursie na walutę systemową).

W przypadku wystąpienia niezgodności pojawia się następujący komunikat:

Niezgodność, raport 04/BPH/1 otwarcie 2021-04-14, zamknięcie 2021-04-14, GID (800:1:3:0), przychód różnica (w walucie rejestru)         -900.00, raport          100.00, zapisy        1,000.00.

Proponowane rozwiązanie: uruchomić z poziomu modułu Administrator, funkcję specjalną: Odbudowa stanów kas.

Poprawność rejestrów i operacji kasowych

W pierwszym kroku test informuje Użytkownika o istnieniu niepoprawnych rejestrów kasowych. Błąd zwracany jest w sytuacji gdy pole  KAR_Typ przyjmuje niepoprawną wartość. Komunikat został przedstawiony poniżej:

Niepoprawny typ rejestru kasowego 26, nazwa Bank BPH S.A., KAR_GID (752:1:2:0).

Rozwiązanie:

Należy wykonać odpowiedni update na pole KAR_Typ. (Patrz dokumentacja tabel).

Następnie sprawdzana jest poprawność operacji kasowych. Pole KAO_Typ przyjmuje wartości:

Jeżeli jedna operacja przyjmuje kilka typów to wartość w tym polu wyliczana jest jako suma poszczególnych typów (przykładowo Kasa+Karta w polu KAO_TYP przyjmuje wartość 5).

Błąd opisany jest komunikatem:

Niepoprawny typ operacji kasowej 200, nazwa zapłata za FVZ, KAO_GID (768:1:3:0).

Rozwiązanie:

Należy ustawić odpowiedni typ na definicji operacji kasowej/bankowej. (Narzędzia / operacje kasowo/bankowe)

W ostatnim etapie kontrolowana jest poprawność operacji kasowych/bankowych względem poszczególnych rejestrów.

Komunikat błędu wygląda następująco:

Niezgodność typu rejestru kasowego 2 (nazwa rejestru rejestr EURO)  i typu przypisanej operacji 1 (nazwa operacji przyjecie zapł. za FVS) , KRO_Pozycja 1.

Rozwiązanie:

Należy dokonać analizy błędnego rejestru i powiązanych z nim operacji. Wprowadzane zmiany dotyczyć będą typu rejestru lub typów przypisanych do niego operacji. (sposób zmian opisany został powyżej).

Test: Zgodność rozrachunków

Test integralności na zgodność rozrachunków jest bardzo istotnym testem, monitorującym poprawność danych księgowych. Waga zgłaszanych przez ten test błędów jest znacząca, szczególnie biorąc pod uwagę negatywne skutki, jakie może powodować bagatelizacja naprawy zwracanych w ramach tego rodzaju testu rekordów.

Zgodność rozrachunków z dekretami

Typowe błędy zwracane w logu przez ten test integralności:

Niezgodność kwot, data 2021-09-20, dziennik (J)LOKA2/04/09/1/1, DT_GID (432:257:130788:1), różnica kwot -8490.67 USD, kwota 8334.2, pozostaje 0, kwota w rozrachunkach 16824.87.

Tego typu błąd zgłaszany jest w następujących przypadkach (problem przedstawiony w zależności od tabeli, której dotyczy):

W ujęciu technicznym warunek generujący błąd wygląda następująco:

DT_Kwota – DT_Pozostaje jest różne od sumy ROZ_Kwota (w przypadku gdy waluta dekretu nie jest walutą systemową) lub ROZ_KwotaSys (gdy waluta dekretu = waluta systemowa)

Rozwiązanie:

Naprawy powyższych zaburzeń trzeba dokonać poprzez wybranie z menu modułu: Administrator, funkcji specjalnej: Uzgadnianie rozliczeń/rozrachunków. Funkcja powoduje m.in. uaktualnienie kwoty: Pozostaje na dekretach księgowych, zapisach kasowych/bankowych, płatnościach dokumentów – tak, aby stanowiła ona równowartość różnicy kwoty, na którą wprowadzony jest dekret, zapis, płatność oraz sumy rozliczeń.

Niezgodność flagi: Nierozliczony, data 2021-12-02, dziennik (BUFOR)DZK/04/12/5, DT_GID (432:121:90:-1), kwota pozostaje 0, nierozliczony 1.

Rekord zgłasza błąd o niezgodności parametrów zapisu księgowego: w tabeli Dekrety dekret posiada parametr nierozliczony (pole DT_Nierozliczony=1), natomiast analizując ten sam dekret w programie zauważamy, że kwota Pozostaje na Rozrachunkach jest równa 0 (zatem DT_Pozostaje=0, DT_Rozliczony=1).

Remedium stanowi uruchomienie funkcji specjalnej: Uzgadnianie rozliczeń i rozrachunków, w wyniku czego nastąpi uzgodnienie parametrów: DT_Nierozliczony, DT_Pozostaje.

Może również wystąpić sytuacja odwrotna, tzn. dekret posiada parametr: DT_Nierozliczony=0 oraz DT_Pozostaje różne od 0, co zgłaszane jest w logu następująco:

Niezgodność flagi nierozliczony, data 2021-10-29, dziennik (BUFOR)RK/04/10/26/3, DT_GID (432:57858:1881:3), kwota pozostaje 24.6, nierozliczony 0.

W celu naprawy, należy uruchomić funkcję specjalną: Uzgadnianie rozliczeń i rozrachunków.

Również  uruchamiamy tę funkcję w przypadku błędu typu:

Niezgodność flagi nierozliczony dla konta nierozrachunkowego 223-001, data 2021-09-03, dziennik (BUFOR)KOSZT/04/09/2/3, DT_GID (432:57868:63:3), nierozliczony 1.

Często przyczyną problemów związanych z niezgodnością parametrów, jest dokonanie podmiany sql-em statusu konta z rozrachunkowego na zwykłe, w sytuacji, kiedy już istniały zapisy księgowe na koncie. Jeśli konto powinno posiadać status rozrachunkowe, wówczas należy zmienić status tego konta na rozrachunkowe. Jeżeli ma pozostać nierozrachunkowe, dekrety powinny mieć zmieniony parametr nierozliczony na 0.

Zgodność rozrachunków z rozliczeniami

Test monitoruje poprawność prowadzenia rozrachunków dekretów księgowych w kontekście ich zgodności z dokonawanymi rozliczeniami płatności dokumentów źródłowych, w wyniku zaksięgowania których, dekrety te powstają. W systemie CDN XL występuje ścisła korelacja pomiędzy rozliczeniami dokumentów generujących płatność zaksięgowanych na konto rozrachunkowe (rozrachunkowe specjalne) w oparciu o tabelę płatności (pozycja schematu księgowego, pole: Oblicz dla: Płatności wprowadzona na konto rozrachunkowe) a rozrachunkami dekretu na konto rozrachunkowe odwołującego się w źródłach (cdn.zrodla) właśnie do tego dokumentu. Zaburzenia w funkcjonowaniu opisanej prawidłowości i tym samym naruszenia spójności danych księgowych zgłaszane są przez test: Zgodność rozrachunków z rozliczeniami. W większości przyczyn wadliwego działania tego mechanizmu należy dopatrywać się w niepoprawnej jego obsłudze (błąd oprogramowania).

W przypadku błędu, test zwraca poniższy komunikat:

Brak rozrachunku dla rozliczenia R2_ID = 1 dokumentów KB-04/KASAG/1/1 (784:1:1:0) oraz FS-1/04/KRAK (2033:1:360710145:0) na koncie 201-00003

Rozliczenie, zaksięgowanie dokumentów na konto rozrachunkowe (rozrachunkowe specjalne) w oparciu o tabelę płatności nie zostało poprawnie obsłużone, w kontekście spójności rozliczeń z rozrachunkami. Naprawy tego typu błędów można wykonać w następujący sposób:

Jeśli przyczyną był niepoprawnie skonstruowany schemat księgowy trzeba odksięgować rozliczone ze sobą dokumenty i następnie wykonać ponowne księgowanie tych dokumentów zmodyfikowanym poprawnie ułożonym schematem księgowań, jeżeli z kolei problem był efektem błędu oprogramowania należy ponownie zaksięgować dokumenty wersją programu uwzględniającą poprawkę błędu (uaktualnienie HR).

Rozrachunki dokonane bez wykorzystania dekretu kompensacyjnego

Test zgłasza błąd:

Rozrachunek, ROZ_GID (433:257:141575:2) – rozliczone zostały dwa dekrety wprowadzone na różne konta księgowe: 201-00001 i 201-00010

Rozrachowane zostały ze sobą dekrety na dwa różne konta rozrachunkowe bez wygenerowania dekretu kompensacyjnego, przy pomocy którego de facto powinny być one ze sobą rozliczone. Naprawy błędu można dokonać analogicznie, jak w przypadku naprawy błędu z rozrachunkami w celu ich uzupełnienia. Można również dokonać odrozliczenia dekretów i ponownego ich rozrachowania wersją uwzględniającą poprawkę błędu. W momencie dokonania ponownego rozrachowania dekretów, zostanie utworzony dekret kompensacyjny.

Test: Zgodność rozliczeń

Zgodność rozliczeń z zapisami kasowymi

W pierwszym etapie test sprawdza następujace warunki:

-dla KAZ_Waluta=KAZ_WalutaRoz sprawdzane jest zgodność różnicy KAZ_Kwota – KAZ_Pozostaje z sumą kwot ROZ_Kwota. W przypadku niezgodności pojawia się komunikat:

Niezgodność kwot, Zapisy GID (784:1:7:0), nr KW 1/04, rok 2021, seria EURO, nr w obrębie raportu 04/EURO/1/1, różnica -10, w Zapisach  183.5, w Rozrachunkach 193.5.

-dla KAZ_Waluta<>KAZ_WalutaRoz sprawdzana jest zgodność różnicy KAZ_Kwota – KAZ_Pozostaje z sumą ROZ_KwotaSys oraz zgodność różnicy KAZ_KwotaRoz – KAZ_PozostajeRoz z sumą ROZ_Kwota

Niezgodność kwot KAZ_PozostajeRoz, KAZ_KwotaRoz, ROZ_Kwota. Zapisy GID (784:1:44:0), nr WB 1/06, rok 2021, seria BPH, nr w obrębie raportu 06/BPH/1/1, różnica 0, w Zapisach  299877, w Rozrachunkach 0.

Kwota “Pozostaje do rozliczenia” na zapisie bankowym/kasowym jest różna od kwoty “Pozostaje do rozrachowania” na dekrecie wynikowym, na konto rozrachunkowe pochodzącym z zaksięgowania tego zapisu bankowego/kasowego.

Rozwiązanie:

Należy uruchomić funkcję z apteczki uzgadniającą kwoty Pozostaje: Uzgadnianie rozliczeń/rozrachunków.

W drugim etapie test weryfikuje poprawność flag (rozliczony/nierozliczony) na poszczególnych zapisach. Błąd zwracany jest w następujących sytuacjach:

Komunikat o błędzie w w/w przypadkach wygląda następująco:

Niezgodność flag w Zapisy GID (784:1:20:0), nr WB 5/04, rok 2021, seria BPH, nr w obrębie raportu 04/BPH/3/1, pozostaje 0, flaga rozliczona 0.

Rozwiązaniem problemu jest uruchomienie funkcji z apteczki (Uzgadnianie rozliczeń/rozrachunków), która dokona odpowiednich modyfikacji flag.

Zgodność rozliczeń z płatnościami

Na początku kontrolowana jest zgodność walut poszczególnych rozliczonych płatności. W razie występowania rozbieżności pojawia się komunikat:

Niezgodność walut, TraPlat GID (1521:1:385876081:1), dokument FZ-5/06/KRAK, waluta EUR, rozliczenie KAZ:GID (784:1:8:0), waluta PLN. (1521:1:385876081:0)

W dalszej części test dokonuje kontroli następującego warunku:

TrP_Kwota – TrP_Pozostaje = suma Roz_Kwota

W przypadku, gdy powyższe równanie nie jest spełnione test generuje komunikat:

Niezgodność kwot, TraPlat GID (2033:1:360710147:1), dokument FS-1/04/WAR, różnica 4630, w TraPlat 9630, w Rozrachunkach 5000. (2033:1:360710147:0)

Rozwiązanie:

Należy uruchomić funkcję specjalną: Uzupełnienie rozliczeń/rozrachunku (tabela TraPlat).

Kolejna część testu porównuje flagi płatności z kwotą pozostałą do rozliczenia. Można wyróżnić dwie nieprawidłowe sytuacje:

Jeśli jeden z powyższych warunków został spełniony, system zwraca komunikat:

Niezgodność flag w TraPlat GID (434:1:4:5), dokument KMP-2021/3, flaga pozostaje 0, flaga rozliczona 0. (434:1:4:0)

Test: Poprawność dokumentów różnic kursowych

Zgodność dokumentów związanych na dokumencie różnicy kursowej z tabelą CDN.Rozliczenia

W pierwszym etapie kontrolowana jest zgodność dokumentów zawartych na różnicy kursowej z wpisami w tabeli rozliczenia. Test dokonuje porównania następujących pól:

z tabeli RożniceKursowe:

RKN_Dok1Typ, RKN_Dok1Numer, RKN_Dok1Lp, RKN_Dok2Typ,  RKN_Dok2Numer, RKN_Dok2Lp

z polami z tabeli Rozliczenia:

r2_Dok1Typ, r2_Dok1Numer, r2_Dok1Lp, r2_Dok2Typ, r2_Dok2Numer, r2_Dok2Lp

W razie wykrycia niezgodności test zwraca komunikat:

Dokumenty związane na dokumencie różnicy kursowej RK-1/06 są niezgodne ze stanem w tabeli CDN.Rozliczenia

Rozwiązanie

Należy dokonać ponownego rozliczenia dokumentów.

Zgodność księgowań dokumentu różnicy kursowej z rozrachunkami

Test kontroluje poprawność rozrachunków związanych z zaksięgowanym dokumentem różnicy kursowej. Sprawdzane są wpisy w tabeli Rozliczenia w następujących polach: R2_Dekret1Numer oraz R2_Dekret2Numer , które powiązane są zarówno z rozliczanymi dokumentami jak i różnicą kursową.

W razie nieprawidłowości system zwraca poniższy komunikat:

Dokument różnicy kursowej RK-1/06 jest zaksięgowany ale nie rozrachowany

Rozwiązanie:

Dokonać ponownego rozrachunku.

Test: Sprawdzenie kompletności księgowań

Sprawdzenie istnienia dekretów wynikowych

Test dokonuje kontroli poprawności wpisów w tabeli Zrodla. Każdy wpis w tej tabeli powinien być łącznikiem pomiędzy dokumentem (jego nagłówkiem – pola Zro_TrnNumer, Zro_TrnTyp, itd) i jego dekretem (pola Zro_DtNumer, Zro_DtTyp, itd.). Test kontroluje tabelę cdn.Zrodla pod kątem poprawności wpisów w polach Zro_DtNumer, Zro_DtTyp. W razie błędu zwracany jest poniższy komunikat:

Istnieje rekord w tabeli Zrodla bez dekretu wynikowego , Zro_DTGID (432:1:0:1), data 2021-11-26, zródło BilansOtwarciaNag (7680:1:159383553:10).

Rozwiązanie:

odksięgowanie wadliwego dokumentu (nazwa tabeli oraz odpowiednie dane identyfikujące zawarte są w komunikacie) i jego ponowna dekretacja.

Sprawdzenie istnienia dokumentów źródłowych oraz flagi zaksięgowano

Test jest kontynuacją kontroli poprawności zapisów z tabeli cdn.Zrodla. Tym razem sprawdzana jest poprawność wpisów w polach Zro_TrnNumer, Zro_TrnTyp, które odnoszą się do nagłówków dokumentów źródłowych. W razie błędów pojawia się komunikat jak poniżej:

Istnieje rekord w tabeli Zrodla bez dokumentu źródłowego Zapisy, Zro_TrnTyp 784, Zro_TrNGID (784:1:19:0), data 2021-04-21.

Inny komunikat zwracany przez omawiany test dotyczy błędów związanych z ustawieniem flagi zaksięgowano na dokumencie. W sytuacji, gdy istnieje wpis w tabeli cdn.Zrodla, a dokument oznaczony jest flagą niezaksięgowano (Trn_zaksiegowano=0) zwracany jest komunikat:

Błąd: rekord w tabeli Zrodla wskazuje na rekord w tabeli TraNag bez ustawionej flagi Zaksiegowano , Zro_TrnTyp 2033, Zro_TrNGID (2033:1:360710146:0), data 2021-03-09

W przypadku gdy w tabeli cdn.zródła pole Zro_DtTyp ma niewłaściwą wartość, a dokument ma flagę zaksięgowano, wyświetlany jest komunikat jak poniżej:

Brak dekretu wynikowego. Nieprawidłowy ZRO_DTTyp dla ustawionej flagi Zaksiegowano, tabela Zapisy, Zro_TrnTyp 784, Zro_TrNGID (784:1:10:0), Zro_DTGID (0:1:48:1), data 2021-04-04.

Rozwiązanie:

naprawa wyżej wymienionych problemów polega na odksiegowaniu błędnych dokumentów i ich ponownej dekretacji.

Sprawdzenie istnienia nagłówka dekretu wynikowego

Zapis w tabeli Zrodla oznaczający nagłówek przyjmuje w polu Zro_DtLp wartość równą 0. W przypadku gdy w bazie istnieją dekrety nie spełniające tego warunku system generuje komunikat:

Błąd: Brak wskazania na nagłówek dekretu wynikowego dla dokumentu z tabeli ImpNag, Zro_TrnTyp 3344, Zro_TrNGID (3344:1:2:0), data 2021-11-15.

Rozwiązanie:

Nie ma uniwersalnego rozwiązania. Należy dokonać analizy zgodności zapisów w tabeli Zrodla, Dekrety i Dzienniki. Jeśli uda się zlokalizować błędny zapis księgowy od strony aplikacji, należy go wykasować i ponownie zaksięgować dokument. (Konieczna może okazać się zmiana pola trn_zaksiegowano na 0).

Sprawdzenie ilości księgowań dokumentów

System dopuszcza możliwość jednokrotnego księgowania dokumentów. Wyjątkiem od reguły są przeszacowania, które księgowane są dwukrotnie.

Istniejące rekordy w tabeli Zrodla wskazują że rekord z tabeli TraNag, Zro_TrnTyp 2033 został zaksięgowany więcej niż jeden raz , Zro_TrNGID (2033:1:385876032:0), data 2021-11-24.

Rozwiązanie:
Należy odksięgować błędny dokument oraz dokonać ponownej dekretacji.

Sprawdzenie kompletności księgowania raportów

Test sprawdza czy dany raport kasowy/bankowy został zaksięgowany i porównuje jego status z przypisanymi mu zapisami kasowymi/bankowymi. Błąd generowany jest w dwóch sytuacjach:

Komunikat zwracany w przypadku wystąpienia nieprawidłowości wygląda następująco:

Zaksięgowany zapis w niezaksięgowanym raporcie: rejestr EURO, raport 06/3, otwarcie 2021-11-09, zamknięcie 2021-11-13, KRP_GID (800:1:23:0), KAZ_GID (784:1:45:0), zapis 06/EURO/3/2.

Rozwiązanie

Po zweryfikowaniu zwracanych rekordów od strony bazy według wskazanych w teście parametrów (także kontrola tabeli cdn.Zrodla), należy zbadać poprawność sytuacji w programie. W razie konieczności wskazane jest odksięgowanie dokumentów i ponowne ich zaksięgowanie.

Test: Zgodność zapisów księgowych (dekretów)

Zgodność z tabelą Dziennik oraz kwot nagłówka z sumą kwot jego pozycji

Test porównuje wartość pola DZK_SumaDT z sumą Dt_Kwota (dla DT_DC=1) oraz Dzk_SumaCt z sumą Dt_Kwota (dla DT_DC=2). W przypadku wystąpienia niezgodności pojawia się komunikat:

Niezgodność dekretu, GID (432:1:11:1), dziennik (BUFOR)S-TOW/04/03/3, rok 2021, miesiąc  3, dzień  9, WINIEN, dekret zbiorczy  8534 PLN, pozycje 3373 PLN, różnica 5161 PLN

W kolejnym etapie kontrolowana jest zgodność pomiędzy rekordami dekretu i dziennika. Test sprawdza poniższe warunki:

DT_Rok <> DZK_Rok
DT_Miesiac <> DZK_Miesiac
DT_Dzien <> DZK_Dzien
DT_Dziennik <> DZK_Dziennik
DT_Bufor <> DZK_Bufor

W przypadku, gdy jeden z powyższych warunków zostanie spełniony, system zgłasza komunikat o błędzie. Jego tekst został zaprezentowany ponizej:

Niezgodność pomiędzy dekretem – dziennikiem, DT (432:1:9:5), dziennik (BUFOR)S-TOW/04/03/1, rok 2021 – 2020, miesiac 3 – 3, dzien 9 – 9

Rozwiązanie

W obu powyższych przypadkach należy odksięgować błędny dokument i dokonać ponownej dekretacji.

Zgodność kwot Winien, Ma w nagłówku dekretu

Test dokonuje kontroli poprawności dekretów poprzez sprawdzenie następującego warunku:

DZK_SumaDt-DZK_SumaCt=0

W przypadku niezgodności pojawia się komunikat:

Niezgodność nagłówka dekretu, GID (432:1:12:1), dziennik (BUFOR)S-TOW/04/03/4, rok 2021, miesiąc  3, dzień  9, MA 13630 PLN, WINIEN 1363 PLN, różnica 12267 PLN

Rozwiązanie

Należy odksięgować i ponownie zaksięgować błędne dokumenty.

Sprawdzenie czy konta na dekretach istnieją w tabeli Konta

Test kontroluje czy konta, na które zostały wprowadzone dekrety księgowe istnieją w tabeli Konta. W razie nieprawidłowości zwracany jest poniższy komunikat:

Konto 010-01 na dekrecie S-TOW/06/09/1 nie istnieje w tabeli CDN.Konta, waluta PLN, DC 2, DT:GID (432:1:146:2)

Rozwiązanie

Należy odszukać błędny dekret oraz porównać pole DT_KKSNumer z polem KKS_GidNumer (tabela Konta). Jeśli to konieczne należy wykonać update na pole DT_KKSNumer w tabeli cdn.Dekrety wprowadzając odpowiedni gidnumer konta (wcześniej błędnie wprowadzony był Null).

Sprawdzenie czy dekrety mają wypełnione pole DT_Dziennik

W przypadku nieprawidłowości test zwraca komunikat:

Dekret z dnia 2021-03-08 ma niewypełnione pole DT_Dziennik, DT_Konto 502-02-WAR-426, DT_DC 1, waluta PLN, DT_GID(432:1:1:8).

Rozwiązanie

W większości zgłaszanych przypadków, należy dokonać poprawy poprzez usunięcie dekretu wynikowego dokumentu i następnie ponowne jego zaksięgowanie.

Jeżeli istnieją w bazie problemy związane ze sklejonymi dekretami (dekrety pochodzące z różnych dokumentów mają identyczne gidnumery DT_GidNumer) można posłużyć się poniższym selectem dla ich namierzenia:

select a.dzk_gidnumer, case a.dzk_bufor when ” then ” else ‘(‘ + a.dzk_bufor + ‘)’ end +a.dzk_dziennik + ‘/’ + cast(a.dzk_rok%100 as char(2)) + ‘/’ + cast(a.dzk_miesiac as char(2))+ ‘/’ + cast(a.dzk_rmnumer as varchar(5)) ‘Numer pk’,case b.dzk_bufor when ” then ” else ‘(‘ + b.dzk_bufor + ‘)’ end + b.dzk_dziennik + ‘/’ + cast(b.dzk_rok%100 as char(2)) + ‘/’ + cast(b.dzk_miesiac as char(2))+ ‘/’ + cast(b.dzk_rmnumer as varchar(5)) ‘NumeR pojedynczego’ from cdn.dziennik a join cdn.dziennik b on a.dzk_gidnumer=b.dzk_gidnumer where a.dzk_gidlp=0 and b.dzk_gidlp<0 order by a.dzk_gidnumer

W przypadku istnienia tego typu błędów, naprawy należy dokonać usuwając dekret wynikowy z błędnym DT_GidNumer i dokonać ponownego zaksięgowania dokumentu bądź ponownie wprowadzić dekret, jeśli nie miał on powiązań z tabelą cdn.Zrodla.

Sprawdzenie poprawności dekretów w okresie obrachunkowym

Test kontroluje, czy dekrety księgowe posiadają prawidłowe DT_KKSNumer w tabeli cdn.Dekrety, to znaczy zgodne z KKS_GidNumer konta z okresu obrachunkowego, w którym jest wprowadzony dekret księgowy. W przypadku nieprawidłowości, czyli w przypadku gdy dekrety mają DT_KKSNumer z innego okresu obrachunkowego niż mieści się data dekretu, test zwraca komunikat:

Dekret o numerze (BUFOR)R.KUR/08/12/1/1, GID (432:123:432:1) z okresu Księga 2021 r. posiada błędny GIDNumer konta (728) dla konta 204-00009

Rozwiązanie

Należy wykonać update na pole DT_KKSNUmer w tabeli cdn.Dekrety wprowadzając gidnumer konta (pole KKS_GidNumer w tabeli cdn.Konta) z odpowiedniego okresu obrachunkowego.

Test: Poprawność kont i ich stanów

Sprawdzenie poprawności numerów kont

Test sprawdza czy numer konta zawiera nieprawidłowe znaki  tj.  *, ?, (spacja), ‘ oraz czy konta zawierają małe litery (powinny być tylko duże). Typowy komunikat o błędzie:

Niezgodność: numer konta zawiera nieprawidłowe znaki, konto 09*, GID(448:1:1499:0).

Rozwiązanie

Wyeliminować błędne znaki z numeru konta za pomocą update’u na pole KKS_Konto. Jeśli konto nie jest używane (zostało założone omyłkowo) należy usunąć odpowiedni rekord.

Zgodność stanów kont

Test sprawdza dla każdego okresu zgodność stanów kont analitycznych. Test oparty został o następujące warunki:

DTS_ObrotyDebetBuf=suma(Dt_Kwota) dla DT_DC=1
DTS_ObrotyCreditBuf=suma(Ct_Kwota) dla DT_DC=2

DTS_ObrotyDebet=suma(Dt_Kwota) dla DT_DC=1
DTS_ObrotyCredit=suma(Ct_Kwota) dla DT_DC=2

W przypadku nieprawidłowości test zwraca poniższy komunikat:

Niezgodność konta 010-01 stan MA w buforze, rok 2021, miesiąc 09, różnica -6575 PLN.

Rozwiązanie

Uruchomić funkcję specjalną – odbudowa stanów kont.

Test sprawdza dla każdego okresu zgodność kont syntetycznych z ich analityką. Test został oparty o poniższe warunki:

DTS_ObrotyDebet = suma (DTS_ObrotyDebet z analityki)
DTS_ObrotyCredit = suma (DTS_ObrotyCredit z analityki)
DTS_ObrotyDebetBuf = suma (DTS_ObrotyDebetBuf z analityki)
DTS_ObrotyCreditBuf = suma (DTS_ObrotyCreditBuf z analityki)

Jeśli powyższe warunki nie zostaną spełnione system zwraca komunikat:

Niezgodność, konto 010, rok 2021, miesiac 9, poziom 0, obroty MA , różnica 654 PLN, MA 658, suma MA 4.

Rozwiązanie

Uruchomić funkcję specjalną – Odbudowa stanów kont.

Sprawdzenie istnienia kont w okresach obrachunkowych, ustawienia waluty

W pierwszej kolejności test sprawdza czy pole KKS_Waluta jest puste. Jeśli taka sytuacja ma miejsce test zwraca informację o błędzie:

Konto z nieustawioną walutą , konto 094, GID(448:1:14:0).

Rozwiązanie

Wykonać update na pole KKS_Waluta.

W dalszym etapie waluta pobrana z konta porównana jest z walutami zdefiniowanymi w systemie. W przypadku gdy waluta na koncie nie ma swojego odpowiednika w systemie generowany jest komunikat:

Konto z niezdefiniowaną w systemie walutą PLm, konto 095, GID(448:1:15:0).

Rozwiązanie

Wprowadzić do systemu walutę wykorzystaną na koncie. Jeśli na koncie znajduje się błednie określona waluta należy wykonać odpowiedni update na pole KKS_Waluta.

Sprawdzenie konta zapisu

Test sprawdza czy na kontach syntetycznych (z podpiętą analityką tj. KKS_Analityka=0) istnieją dekrety. Jeśli taka sytuacja ma miejsce test generuje komunikat:

Niezgodność. Istnieje dekret dla konta syntetycznego 201, DT_GID (432:1:125:1), rok 2021, miesiąc 01.

Rozwiązanie

Nie istnieje uniwersalne rozwiązanie problemu. Należy dokonać analizy zastanej sytuacji i odpowiedzieć na następujące pytania:

Czy konto powinno mieć podpięta analitykę (system dopuszcza księgowanie na konto syntetyczne jeśli nie ma ono podpietej analityki – należy zaznaczyć odpowiednie ustawienie w konfiguracji)?

Czy dekrety zostały wprowdzone na odpowiednie konto?

W zależności od uzyskanych odpowiedzi modyfikacje dotyczyć będą dekretów księgowych bądź kont.

Test: Noty memoriałowe

Zgodność nagłówków not memoriałowych z pozycjami

Test dokonuje kontroli następujących warunków:

W przypadku błędu pojawia się komunikat:

Niezgodność wartości KwotaRoz między nagłówkiem a pozycjami noty: NM-DELEG/2021/05/1, GID: (4144:1:3:0), w nagłówku: 1440, z pozycji: 646. (4144:1:3:0)

Rozwiązanie

W celu uzgodnienia kwot na nagłówku i pozycjach noty całkowicie wystarczające jest otworzenie do edycji wskazanej w teście noty memoriałowej, a następnie jej zapisanie. Kwoty zostaną uzgodnione.

Zgodność nagłówków not memoriałowych z definicją

W pierwszym etapie test sprawdza miejsce określenia podmiotu na definicji noty memoriałowej. Dla not ,którym:

kontrolowana jest tabela MemNag pod względem prawidłowości wpisów. Pola dotyczące kontrahentów dla tak zdfiniowanych not powinny przyjmować wartość 0. Jeśli jest inaczej test zwraca poniższy komunikat:

Niezgodność: pole kontrahenta na nocie: NM-2021/11/1, GID(4144:1:7:0), powinno być puste dla tego rodzaju dokumentu. (4144:1:7:0)

Rozwiązanie

Należy podnieść notę do edycji i ponownie zapisać.

W następnej kolejności test kontroluje czy podmiot określony na nocie memoriałowej ma swój odpowiednik w tabelach KntKarty (dla kontrahentów) lub PrcKarty (dla pracowników). W przypadku stwierdzenia niezgodności generowany jest komunikat jak poniżej:

Niezgodność: brak pracownika w tabeli PrcKarty określonego na nocie: NM-2021/11/4, GID(4144:1:10:0). (4144:1:10:0)

Rozwiązanie

Należy podnieść notę do edycji i wybrać ponownie kontrahenta/pracownika.

W kolejnym etapie kontrolowana jest zgodność typu noty memoriałowej wg poniższych warunków:

W przypadku gdy jeden z powyższych warunków nie został spełniony, system generuje komunikat:

Niezgodność: nieprawidłowe wartości MEN:KwotaRoz lub MEN:KwotaPrz dla noty typu przychód, nota: NM-2021/11/1, GID(4144:1:7:0). (4144:1:7:0)

Rozwiązanie

Zmienić typ noty memoriałowej na jej definicji lub ponownie zapisać błędną notę.

Test: Bilans otwarcia

Zgodność płatności z pozycjami dokumentów bilansu otwarcia

Test sprawdza prawidłowość powiązań pomiędzy bilansem otwarcia a jego płatnościami. Błędy zgłaszane przez program mogą dotyczyć dwóch sytuacji:

Rozwiązanie

Nie istnieje uniwersalne rozwiązanie w/w problemów. Należy przeanalizować każdy ze zwróconych rekordów z osobna opierając się na poniższych warunkach łączenia płatności z dokumentem BO.

BOs_trpTyp=TrP_GIDTyp and
BOs_trpFirma=TrP_GIDFirma and
BOs_trpNumer=TrP_GIDNumer and
BOs_trplp=TrP_GIDlp

Zakończenie

Systematyczne koordynowanie spójności bazy danych stanowi fundament w celu utrzymania poprawności danych. Testy integralności są kluczowym narzędziem pomocnym w analizie problemów zaburzających prawidłowość danych, dlatego Użytkownik systemu powinien być świadomy faktu, że regularne ich uruchamianie i natychmiastowa reakcja na występujące problemy stanowią podstawę otrzymania rzetelnego obrazu prowadzenia ksiąg rachunkowych.

Jednolity Plik Kontrolny w Comarch ERP XL

Funkcjonalność Jednolitego Pliku Kontrolnego umożliwia generację plików XML udostępnianych na żądanie uprawnionych organów kontrolujących, zgodnie z przepisami Ordynacji Podatkowej, a także bezpośrednie raportowanie z systemu do Ministerstwa Finansów za pomocą usług sieciowych.

Jednolity Plik Kontrolny (JPK) obsługiwany w Comarch ERP XL składa się z 4 struktur:

Duże przedsiębiorstwa w rozumieniu ustawy o swobodzie działalności gospodarczej mają obowiązek obsługi wszystkich tych struktur.  Dla pozostałych struktur, składanych na żądanie, ustalono dla nich okres przejściowy do 1 lipca 2018 roku.

Ogólny opis obsługiwanych plików

JPK_FA

Zestawienie faktur sprzedaży w danym okresie w danej walucie. Plik ten składany jest na żądanie organu kontrolującego. Ministerstwo wycofało się z pomysłu raportowania zarówno transakcji sprzedaży jak i zakupu, pozostawiając jedynie obowiązek przesłania w tej strukturze faktur sprzedaży.

Organ kontrolujący powinien określić okres za jaki plik ten będzie przesyłany oraz walutę jakiej dotyczy. Powinien również zdefiniować jakie jest kryterium przydzielenia dokumentu do danego okresu, czyli czy decydująca będzie data wystawienia dokumentu, czy może moment sprzedaży.

Struktura tego pliku jest mocno oparta na art. 106e ustawy o VAT, która wymienia wszystkie elementy jakie faktura powinna zawierać. W normalnym obrocie gospodarczym duża część tych pól nie jest uzupełniana i stąd oznaczone zostały one jako opcjonalne. W przypadku jednak gdy mamy do czynienia z obrotem zwolnionym z podatku VAT to należy podać przyczynę zwolnienia, a jeśli jest to korekta faktury VAT, to również numer dokumentu korygowanego oraz przyczynę korekty.

Sama struktura składa się z dwóch powiązanych ze sobą list czyli nagłówka dokumentu (obowiązkowe elementy faktury jak nazwy kontrahentów, data wystawienia itd.) oraz pozycji tej faktury (nazwa towaru, ilość sztuk, cena jednostkowa itp.)

Przykładowy wiersz takiego pliku określający nagłówek dokumentu sprzedaży dla kontrahenta ABC SA za 1000 zł netto:

Data wystawienia	Nr faktury	Nazwa nabywcy	Adres nabywcy	Nazwa sprzedawcy	Adres sprzedawcy
2017-01-14 00:00:00	FS-65/17	ABC Spółka Akcyjna	Ul. Fiołkowa 10, 30-333 Kraków	Comarch Spółka Akcyjna	Al. Jana Pawła II 39A, 31-864 Kraków

NIP sprzedawcy	NIP nabywcy	Data sprzedaży	Netto 23%	VAT 23%	Należność	Rodzaj faktury
6770065406	1234123412	2017-01-10 00:00:00	1000	230	1230	VAT

Oraz powiązane z tym wiersze określające pozycje tej faktury

Numer faktury	Nazwa towaru	Jedn. Miary	Ilość	Cena jedn.	Wartość	Stawka podatku
FS-65/17	Kabel światłowodowy FL FOC	m.	100	9.50	950	23
FS-65/17	Kabel ethernet cat.6	m.	15	0.8	12	23
FS-65/17	Transport	szt.	1	38	38	23

JPK_MAG

Plik JPK_MAG jest zestawieniem ruchu na magazynie. Struktura obejmuje tylko podstawowe dokumenty jak PZ, PW, WZ, RW, MM, czyli najczęstsze operacje w firmach handlowych i usługowych. Od wersji 2025.0 zostały ujęte także wszystkie dokumenty KK dotyczące danego magazynu, wygenerowane w okresie za jaki sporządzany jest JPK_MAG. Struktura nie przewiduje jednak innych dokumentów pośrednio związanych z obrotem magazynowym. Analizując plik JPK_MAG nie uzyskamy zatem pełnej zgodności z faktycznymi obrotami na danym magazynie.

JPK_MAG również składany jest na żądanie organu kontrolującego, który oprócz określenia zakresu dat obrotu magazynowego powinien również wskazać konkretny magazyn, którego ten plik ma dotyczyć.

Poniżej przykładowe zestawienie przyjęcia towaru do magazynu (wydanie z magazynu wygląda analogicznie)

Numer PZ	Data PZ	Wartość	Data otrzymania	Dostawca	Numer faktury	Data faktury
PZ-8/17	2017-01-08 00:00:00	115.5	2017-01-08 00:00:00	TelMaster Spółka Akcyjna	456/17/ETH	2017-01-07 00:00:00

oraz powiązane wiersze określające pozycje tego dokumentu PZ

Numer PZ	Kod towaru	Nazwa towaru	Ilość	J.m.	Cena jedn.	Wartość
PZ-8/17	EthC6	Kabel ethernet cat.6	150.000000	m.	0.77	115.50

W przypadku gdy obrót magazynowy jest bezpośrednio powiązany z fakturą zakupu/sprzedaży, to taki sam numer znajdzie się zarówno w polu Numer PZ jak i Numer faktury.

W pliku JPK_MAG, w sekcji PZ uwzględnione zostały również dokumenty PW oraz ich korekty PWK. Zasady ujęcia tych dokumentów są podobne do tych, które obowiązują dla dokumentów PZ/PZK. W danej deklaracji JPK_MAG ujmowane są PW/PWK, dla których spełnione są poniższe warunki:

Poszczególne informacje dotyczące dokumentów PW/PWK ustalane są w identyczny sposób, jak dla innych dokumentów tej sekcji. Wyjątek w tym zakresie stanowi informacja o Dostawcy, ustalana w następujący sposób:

W przypadku rozchodu wewnętrznego, jak i przesunięć międzymagazynowych struktura wygląda nieco inaczej:

Numer RW	Data dok.	Wartość	Data wydania
RW-2/17	2017-01-09 00:00:00	2.31	2017-01-09 00:00:00

Numer RW	Kod towaru	Nazwa towaru	Ilość	J.m.	Cena jedn.	Wartość
RW-2/17	EthC6	Kabel ethernet cat.6	3.000000	m.	0.77	2.31

oraz powiązane wiersze określające pozycje tego dokumentu RW

JPK_KR

Plik JPK_KR jest zestawieniem zapisów księgowych w analizowanym okresie. Podobnie jak w przypadku JPK_FA czy JPK_MAG ten plik również jest składany na żądanie. Pozwala on na prześledzenie obrotów na kontach i powiązanych z nimi zapisów księgowych. Takie zestawienie powinno być co do zasady sporządzone dla zapisów księgowych zatwierdzonych, ale dla celów wewnętrznych Comarch ERP XL pozwala je wygenerować również dla księgowań w buforze.

Pojedyncza pozycja zestawienia obrotów i sald zawiera zestaw informacji związanych z tym kontem, czyli jego kod, nazwę, typ (bilansowe, rozrachunkowe, wynikowe), bilans otwarcia, obroty Wn i Ma, oraz saldo Wn i saldo Ma.

Powiązane z zestawieniem obrotów i sald są pozycje dziennika, gdzie wskazany jest nr dowodu, data operacji czy wartość całego dekretu:

Lp	Numer zapisu	Opis dziennika	Nr dowodu	Rodzaj	Data operacji	Data wystawienia	Data księgowania
1	DZK/17/01/1	Domyślny dziennik	FS-65/17	faktura	2017-01-10 00:00:00	2017-01-14 00:00:00	2017-01-10 00:00:00

Operator	Opis	Kwota
JKOWAL	FS-65/17 ABC	1452.20

Po rozwinięciu związanych z tym wpisem w dzienniku zapisów księgowych zobaczymy ujęcie tej operacji na poszczególnych kontach księgowych.

Lp	Numer zapisu	Konto Wn	Kwota Wn	Opis Wn	Konto Ma	Kwota Ma	Opis Ma
1	DZK/17/01/1	201-ABC	1230	FS-65/17 ABC
2	DZK/17/01/1				731-01	1000	FS-65/17 ABC
3	DZK/17/01/1				221-01	230	FS-65/17 ABC
4	DZK/17/01/1	732-01	222.50	FS-65/17 ABC	331-01	222.50	FS-65/17 ABC

JPK_WB

Ostatni z plików dostępnych w systemie jest również składany na żądanie organu kontrolującego i zawiera zestawienie operacji bankowych w zadanym okresie. Warto zwrócić uwagę, że plik ten jest składany dla konkretnego rachunku bankowego, a nie wszystkich operacji płatności w firmie.

Zgodnie z założeniami Ministerstwa Finansów plik ten docelowo będzie generowany przez Bank na życzenie podatnika.

JPK_WB w swojej strukturze jest bardzo zbliżony do wyglądu wyciągu bankowego prezentując szczegóły płatności i saldo rachunku po jej zaksięgowaniu przez bank:

Lp	Data	Podmiot	Opis	Kwota	Saldo
1	2017-01-28 00:00:00	ABC Spółka Akcyjna	Zapłata za FS-65/17	1230	6867.64

Konfiguracja systemu

Aby umożliwić podgląd i generowanie plików JPK konieczne jest nadanie odpowiednich uprawnień użytkownikowi systemu. Jedynie operator z uprawnieniem Generowanie JPK ma prawo otworzenia listy dokumentów Jednolitego Pliku Kontrolnego.

Do uzupełniania danych podmiotu na JPK wykorzystywane są informacje zawarte w pieczątce firmy na zakładkach Deklaracje (Nazwa pełna, Identyfikator REGON) oraz Deklaracje cd. (Adres siedziby). Zalecamy również uzupełnienie danych kontrahenta wewnętrznego, który może być wykorzystywany na dokumentach wewnętrznych rejestru VAT.

Uwaga

Na zakładce Podmiot w poszczególnych plikach JPK podawany jest dwuznakowy kod kraju, a nie jego nazwa. Kod kraju w systemie jest domyślnie ustawiony na ‘PL’, a zatem podmioty o siedzibie położonej za granicą, powinny zmieniać ten kod na sobie właściwy bezpośrednio na pliku JPK.

Lista plików JPK

W module księgowość na zakładce Narzędzia został dodany przycisk o nazwie Jednolity Plik Kontrolny. Użytkownik z nadanymi uprawnieniami „Generowanie JPK” może otworzyć listę plików JPK, gdzie może dodać nowy lub obejrzeć już istniejące pliki.

Na liście umieszczono listę rozwijalną umożliwiającą wybór interesującego nas rodzaju JPK, zestaw najważniejszych filtrów oraz przyciski do dodania nowego pliku danego typu, a także podglądu lub usunięcia już istniejącego. W przypadku plików o statusie zaakceptowana lub zatwierdzona możliwy jest ich eksport w postaci XML na dysk, bądź też przesłanie drogą elektroniczną na bramkę Ministerstwa Finansów.

Generacja pliku JPK

Po wybraniu interesującego nas typu dokumentu i wciśnięciu przycisku dodaj ukaże się okno Ogólne, na którym ustawia się parametry generacji. Dla każdego z tych plików należy wskazać okres za jaki plik ma być sporządzany, kryterium daty decydującej o przypisaniu dokumentu do okresu, urząd skarbowy, do którego adresowany jest ten plik (Ważne – urząd na swojej karcie musi mieć wpisany kod urzędu), a także zestaw dodatkowych parametrów istotnych dla danego typu JPK (JPK_FA – waluta, JPK_MAG – magazyn, JPK_WB – rejestr bankowy, JPK_KR – zapisy w buforze). Zestaw tych parametrów koniecznych do generacji powinien być określony przez organ kontrolujący.

Pola zakładki Ogólne

1. Okres – wybierany jest miesiąc poprzedni.
2. Numer i wersja – pola ustawiane automatycznie definiują kolejny numer pliku generowanego za ten miesiąc oraz jego wariant. Pola te mają znaczenie tylko dla systemu XL i nie są przenoszone na plik wynikowy.
3. Status – nowy plik domyślnie tworzony jest w statusie bufor. Oznacza to, że jest on wersją roboczą i jako taka nie może być eksportowana poza system. W statusie bufor możliwe jest również całkowite usunięcie pliku. Po zmianie statusu na „Zaakceptowana” JPK jest już w pełni funkcjonalny – można taki plik eksportować i przesyłać poza system. Z tego poziomu możliwe jest również cofnięcie deklaracji do bufora i jej usunięcie. Natomiast po zmianie na „Zatwierdzony” nie jest już możliwe usunięcie tego JPK i pozostanie on w systemie na stałe. Z tego poziomu można już tylko zmienić status pliku na „Anulowana”, co pozwala na utworzenie korekty za ten okres.
4. Cel złożenia formularza – JPK_VAT w wariancie drugim oferuje możliwość definiowania czy składany plik jest korektą czy złożeniem po raz pierwszy. Analogicznie jak w przypadku VAT-7 nie pozwala to jednak na istnienie dwóch zaakceptowanych lub zatwierdzonych deklaracji za ten sam okres (gdy jeden jest plikiem pierwotnym, a drugi korektą). Aby utworzyć korektę deklaracji konieczne jest zatem cofnięcie pierwotnego dokumentu do bufora lub jego anulowanie.
5. Wskaźnik struktury sprzedaży – Ustawienie tego parametru ma wpływ na wartość odliczenia VAT dla zakupów. Wskaźnik domyślnie jest wyliczany przez system (opcja Obliczony). Użytkownik ma jednak możliwość jego ręcznej zmiany przez ustawienie opcji Szacunkowy.
6. Urząd – po wciśnięciu przycisku rozwija się okno z listą urzędów do wyboru. Należy na niej wskazać urząd, do którego adresowany jest ten plik. Urząd ten na swojej karcie powinien mieć wskazany kod urzędu (4 cyfry). Jest to konieczne do poprawnego wygenerowania pliku, gdyż właśnie ten kod oznacza adresata w XML.
7. Wprowadził, zmodyfikował, zatwierdził – pola określają akronim użytkownika, który operował na danym pliku JPK. Ich wartości nie są przekazywane w pliku wynikowym.
8. Status e-deklaracji, Numer referencyjny, Data rejestracji, Data potwierdzenia – pola zawierają informacje o wyniku przesłania pliku JPK drogą elektroniczną (skrócona wersja UPO).
9. Uwagi – pole tekstowe, w które użytkownik może wpisać swoje uwagi odnośnie tego pliku. Zawartość tego pola można edytować niezależnie od statusu deklaracji. Jego zawartość nie jest przekazywana do wynikowego pliku.

W zdecydowanej większości przypadków generacja pliku wymaga jedynie ustawienie miesiąca oraz wskazania docelowego urzędu. Po ustawieniu parametrów generacji i wciśnięciu przycisku przelicz, plik JPK zostanie wygenerowany.

Automatyczne uzupełnianie pól plików JPK

Podczas generacji plików JPK automatycznie działa kilka algorytmów mających na celu automatyczną poprawę najczęściej popełnianych błędów, które mogą spowodować niezgodność pliku ze schematem. Wszystkie te zmiany są później wyszczególniane na etapie walidacji (patrz rozdział Wbudowany walidator). Zmiany są dokonywane bezpośrednio na pliku JPK i nie mają wpływu na dokumenty źródłowe. Generowane zmiany opisano poniżej:

JPK_VAT

Mechanizm generacji JPK_VAT został wyposażony w dodatkowe mechanizmy zabezpieczające przed wytworzeniem pliku, który mimo poprawnego wprowadzenia dokumentów źródłowych nie zostałby zwalidowany.

Wprowadzono następujące usprawnienia:

1. Sprzedaż VAT-7
   1. Brak NIP-u nabywcy – pole uzupełniane słowem BRAK
   2. Brak nazwy nabywcy – pole uzupełniane słowem BRAK
   3. Brak adresu nabywcy – pole uzupełniane słowem BRAK
   4. Dokument wewnętrzny stworzony na podstawie ręcznych pól deklaracji (np. zwrot kwoty wydatkowanej na zakup kas rejestrujących) – pola identyfikujące nabywcę wypełnione na podstawie danych kontrahenta wewnętrznego
2. Zakup VAT-7
   1. Brak NIP-u dostawcy – pole uzupełniane słowem BRAK
   2. Brak numeru dokumentu – pole uzupełnione słowem BRAK

Uwaga

Automatyczne uzupełnianie numeru dokumentu dla faktur zakupu słowem „brak” jest zachowaniem mającym wyłącznie ergonomiczne zastosowanie. Ułatwia to bowiem wyszukanie i poprawę błędów na poziomie wynikowego XMLa w sytuacji, gdy dokument jest już zatwierdzony i nie jest możliwe wprowadzenie zmian bezpośrednio w systemie.

Chociaż wpisanie słowa „brak” na poziomie numeru dokumentu w JPK_VAT umożliwia akceptację pliku na bramce Ministerstwa Finansów, to jednocześnie może spowodować niezgodność podczas krzyżowej kontroli podatnika i stąd konieczność ręcznej naprawy.

JPK_FA

Schemat opublikowany przez Ministerstwo Finansów przewiduje, że zarówno NIP nabywcy jak i sprzedawcy spełniają zasady budowy polskiego NIPu, co nie musi być prawdą w przypadku kontrahentów zagranicznych.

Może to spowodować brak walidacji części poprawnie wystawionych faktur. Dlatego też w przypadku, gdy numer kontrahenta nie spełnia kryteriów polskiego NIP jest on pomijany w pliku XML.

JPK_WB

Podczas generacji plików JPK_WB sprawdzane jest, czy transakcja wystawiona jest na kontrahenta nieokreślonego (***INNY***). Jeśli tak, w to pole wstawiana jest nazwa „Inny”.

Eksport pliku na dysk

Eksport pliku na dysk dostępny jest dla zaakceptowanych lub zatwierdzonych plików JPK. Sam plik XML można wykorzystać do dalszej analizy poza systemem ERP bądź też jako kopia zapasowa pliku.

W formie pliku XML taki plik można również przesłać na życzenie organów kontrolujących. Aby wywiązać się z obowiązku comiesięcznego raportowania JPK_VAT, konieczne jest jednak wykorzystanie wysyłki na bramkę Ministerstwa.

Wysłanie e-deklaracji

Wysyłka e-deklaracji dostępna jest dla zaakceptowanych lub zatwierdzonych plików JPK. Odbywa się ona w sposób dwuetapowy, czyli poprzez wysłanie pliku, a następnie odebranie UPO.

W przypadku JPK_VAT jest to jedyny dozwolony sposób składania tych plików. Sam proces wysyłki obejmuje kompresję oraz szyfrowanie danych, jest to zatem zalecany sposób przesyłania również innych struktur Jednolitego Pliku Kontrolnego.

Po wybraniu zaakceptowanego pliku i wciśnięciu przycisku „Wyślij do MF” pojawia się okno z parametrami wysyłki pliku JPK.

Użytkownik ma możliwość określenia parametrów dotyczących źródła pochodzenia pliku, jak i też samego typu wysyłki.

Sekcja Przygotowanie pliku JPK

Opcje dostępne w tej sekcji pozwalają na automatyczne wysłanie pliku z systemu Comarch ERP XL (Generuj plik i wyślij), lub też na wysłanie uprzednio wyeksportowanego pliku XML (Wyślij istniejący plik).

W zależności od wybranej opcji użytkownik ma możliwość albo wybrania folderu roboczego, gdzie przechowywany będzie plik podczas eksportu z systemu, albo też na określenie ścieżki dla już istniejącego XMLa.

Ze względu na wielkość plików XML, nie jest możliwe przeprowadzenie podczas importu sprawdzenia, czy wybrany z dysku XML faktycznie odpowiada wskazanemu dokumentowi JPK w systemie. Dlatego też podczas wysyłki z wybraniem opcji „Wyślij istniejący plik” pojawi się komunikat: „Upewnij się, że wybrany plik XML jest wygenerowany na podstawie wskazanego dokumentu JPK. Czy kontynuować wysyłkę?”

Jeśli zostanie wybrany plik z dysku, to rezultat takiej transmisji (m.in. UPO) będzie przypisany do wybranego pliku JPK w systemie, z którego poziomu teoretycznie dokonano wysyłki.

 

Sekcja Typ wysyłki

Specyfikacja interfejsów usług JPK opracowana przez Ministerstwa Finansów nakazuje określenie, czy przesyłany plik jest wysyłany cyklicznie, czy też na żądanie, w ramach aktualnie przeprowadzanej kontroli. W przypadku przesyłania pozostałych plików (JPK_FA, JPK_MAG, JPK_KR, JPK_WB) powinna być zaznaczona opcja Na żądanie.

Po wybraniu odpowiednich parametrów wciśnięcie przycisku , pozwala na wybór właściwego certyfikatu i wysłanie danych. Wtedy też do dokumentu JPK zostanie przypisany odpowiedni numer referencyjny, który pozwala na pobranie Urzędowego Poświadczenia Odbioru (UPO).

Po zaznaczeniu wysłanego dokumentu na liście JPK i wciśnięciu przycisku Pobierz UPO, zostanie pobrane poświadczenie odbioru przypisane do numeru referencyjnego wskazanego pliku. Numer referencyjny oraz aktualny status e-deklaracji widoczny jest na zakładce Ogólne pliku JPK.

Uwaga

Ze względu na wielkość plików JPK okres oczekiwania na odbiór UPO trwa z reguły kilka godzin

Wykorzystanie bazy danych

W celu zapewnienia niezależności plików JPK od ewentualnych zmian dokumentów źródłowych, wartości zawarte w JPK są przechowywane w osobnej tabeli bazy danych. Zważywszy na duży zakres raportowanych informacji, przechowywanie wszystkich wygenerowanych plików JPK, może spowodować znaczący przyrost wielkości bazy danych.

Uwaga

Ograniczenie wielkości bazy danych poprzez usunięcie starych plików JPK:

1. Dokonanie wydruku pliku JPK i otrzymanego UPO
2. Eksport pliku JPK na dysk w postaci XML dla celów dowodowych
3. Zmiana statusu pliku z zaakceptowana na bufor
4. Usunięcie pliku z listy JPK

Struktura pliku XML

Wzór schematów XML, jakie mają być przekazywane w formie JPK został opublikowany na stronie internetowej Ministerstwa Finansów:

http://www.mf.gov.pl/administracja-podatkowa/dzialalnosc/jednolity-plik-kontrolny

Zgodnie ze schemami każda struktura składa się z co najmniej czterech powtarzalnych elementów:

Modyfikacja pliku XML poza programem Comarch ERP

Ministerstwo nie zabrania ręcznego przygotowywania lub modyfikacji plików XML, które są przesyłane do organów kontrolujących, oczywiście w zakresie w jakim te zmiany zgodne są ze stanem rzeczywistym i mają na celu zapewnienie ich zgodności z obowiązującym schematem.

Takim częstym przypadkiem jest nieuzupełnienie obligatoryjnej informacji na zatwierdzonym dokumencie np. nazwy kontrahenta jednorazowego czy też jego numeru NIP. Jeśli nie ma możliwości poprawienia tej informacji w systemie ERP, to często jedynym wyjściem jest wygenerowanie pliku XML na dysk i ręczne poprawienie danego wiersza.

Plik XML można otworzyć i edytować w każdym edytorze tekstowym np. notatniku, choć na rynku dostępną są również bardziej zaawansowane narzędzia, które dysponują m.in. możliwością kolorowania składni XML. Wiele z tych rozwiązań jest darmowych.

Po ręcznym poprawieniu błędnego wiersza taki plik można przekazać na nośniku elektronicznym organom kontrolującym bądź też przesłać drogą elektroniczną. Do tego służy parametr Wyślij istniejący plik na oknie wysyłki elektronicznej. Po wybraniu zmodyfikowanego pliku z dysku możliwe jest jego podpisanie i przesłanie za pomocą mechanizmu wbudowanego w Comarch ERP XL.

Nie jest natomiast zalecane modyfikowanie wartości pozycji bądź też dodawanie nowych pozycji lub ich usuwanie. Związane jest to z wbudowanym w XML zabezpieczeniem w postaci sum kontrolnych, gdzie zapisana jest liczba wierszy danego typu oraz ich łączną wartość. Każdorazowa modyfikacja tych danych źródłowych związana z liczbą oraz wartością pól, pociąga za sobą również konieczność poprawienia odpowiednich sum kontrolnych.

Kopia zapasowa plików JPK

Automatyczny backup

W oknie Konfiguracja komputera na zakładce [Eksport] znajduje się sekcja, gdzie domyślnie przechowywane są wyeksportowane pliki raportów i rejestrów VAT. Jest to również domyślna lokalizacja dla eksportu plików JPK.

W przypadku, gdy wysyłany będzie plik JPK_VAT na bramkę Ministerstwa Finansów, to automatycznie w tej lokalizacji znajdzie się kopia tego pliku w formacie XML.

Pole URL

Na zakładce [Ogólne] nad sekcją Uwagi dodano specjalne pole o nazwie URL, gdzie przechowywana jest informacja o ścieżce do kopii zapasowej pliku w formacie XML. Pole to uzupełnianie jest automatycznie w przypadku:

wysłania pliku JPK_VAT na bramkę Ministerstwa Finansów

podczas ręcznego eksportu pliku JPK za pomocą ikonki eksportu.

Pole URL jest aktywne niezależnie od statusu formularza, dzięki czemu w przypadku ręcznego przenoszenia kopii pliku można zaktualizować jej lokalizację w systemie ERP

Częściowe usuwanie plików JPK

Wygenerowane pliki JPK (FA, MAG, KR, WB) przechowywane są w bazie danych niezależnie od danych źródłowych. Może to powodować niepotrzebny przyrost bazy danych w dłuższej perspektywie czasowej. Dodano możliwość częściowego usuwania plików JPK przy jednoczesnym zachowaniu najważniejszych informacji.  Po potwierdzeniu wyboru ikonką zapisu, system sprawdza, czy pole URL informujące o lokalizacji kopii zapasowej nie jest puste. Usunięcie danych z bazy nie jest bowiem możliwe, jeśli nie ma została wskazana żadna lokalizacja backupu. Po poprawnym usunięciu danych szczegółowych status deklaracji zmienia się na „Usunięta”. W dalszym ciągu na „usuniętym” pliku JPK widoczne są wszystkie pola informujące o statusie deklaracji, wartości podatku naliczonego i należnego a także listy agregujące pokazujące rozbicie kwot na poszczególne pola deklaracji VAT-7. Nie ma już natomiast dostępnych wartości szczegółowych, które od tej pory znajdują się tylko na wygenerowanej kopii zapasowej.

Analiza wygenerowanego pliku JPK

Po wygenerowaniu pliku JPK w systemie Comarch ERP XL dostępne są mechanizmy pozwalające na sprawdzenie poprawności tego pliku, zarówno poprzez podgląd poszczególnych dokumentów, jak i również poprzez automatyczny walidator.

Listy szczegółowe

W każdym z plików oprócz standardowego zestawu zakładek (Ogólne, Nagłówek, Podmiot, Sumy ctrl, Załączniki), znajdują się zakładki przedstawiające listy właściwych danych liczbowych związanych z tym plikiem.

Na samej górze znajduje się rozwijalna lista agregatu, a poniżej powiązana lista szczegółowa.

Najprostszym sposobem sprawdzenia merytorycznej poprawności wygenerowanego pliku JPK jest wykorzystanie tzw. agregatów. Agregaty są podsumowaniem informacji szczegółowych zawartych w poszczególnych plikach JPK. Nie wchodzą one w zakres pliku wynikowego, ale pozwalają użytkownikowi sprawdzić zbiorcze wartości oraz ułatwiają nawigowanie w samym pliku. Z reguły jako kryterium podziału przyjęto dzień (JPK_FA, JPK_MAG, JPK_WB). Dla JPK_VAT najbardziej naturalnym kryterium było pole deklaracji VAT-7, a dla JPK_KR konto bilansowe i dlatego właśnie te pola są głównymi elementami listy agregującej.

Poniższa lista szczegółowa jest ściśle powiązana z agregatem. Wybierając jakąś pozycję agregatu, dolna lista jest automatycznie zawężana tylko do powiązanych z nią wierszy.

Przykładowo plik JPK_FA zawiera zestawienie faktur sprzedaży z całego miesiąca stycznia. Faktury w agregacie (Podsumowanie faktur w JPK) pogrupowane są zgodnie z kryterium daty.

Użytkownik wybierając datę 11 stycznia widzi na dolnej liście (Faktury) tylko dokumenty wystawione z datą 11 stycznia. Jeśli wybierze konkretną fakturę sprzedaży, to na najniższej liście (Wiersze faktury) widzi wszystkie pozycje tego dokumentu.

Dla JPK_VAT dodatkowo na listach zakupu i sprzedaży dodano przycisk Wyświetl wszystkie, który wyświetla całą listę szczegółową, bez ograniczenia do pola wskazanego w agregacie.

Podgląd dokumentu źródłowego

Na listach szczegółowych zawarto powiązanie między zapisem na liście JPK, a dokumentem źródłowym, z którego ten zapis pochodzi.

Aby zobaczyć dokument, z którego pochodzi dany wpis na liście JPK, należy zaznaczyć go na liście i wcisnąć przycisk Dokument źródłowy. Wówczas w trybie do podglądu otworzy się żądany dokument.

Mechanizm walidacji pliku

Część pól, które w JPK są obligatoryjne, nie są wymagane w systemie Comarch ERP XL. Niestety wystarczy jeden dokument, który nie ma wypełnionego odpowiedniego pola, aby cały plik nie przeszedł walidacji. Ze względu na bardzo duży zakres plików JPK, ręczne kontrolowanie poprawności danych jest praktycznie niemożliwe. Z tego powodu w Comarch ERP XL wprowadzono funkcję sprawdzającą poprawność danych, która weryfikuje m.in. wypełnienie pól obowiązkowych.

Za funkcjonalność tą odpowiada przycisk Walidacja znajdująca się na bocznej belce pliku JPK:

 

Po wciśnięciu przycisku uruchamia się okienko zdarzeń systemowych, na którym można zobaczyć postęp weryfikacji pliku JPK.

Wyniki weryfikacji można podzielić na dwie kategorie:

1. Błędy – niewypełnienie pól obowiązkowych, które mogą spowodować brak walidacji pliku po stronie Ministerstwa np. brak nazwy dostawcy na fakturze zakupu w JPK_VAT.
2. Ostrzeżenia – niespójność niektórych danych zawartych w plikach JPK. Ich niezgodność nie powoduje automatycznego odrzucenia pliku jako błędnego, może natomiast być przedmiotem dalszych pytań ze strony organów kontrolujących, jak np. brak numeru NIP nabywcy towaru w JPK_VAT, czy też określenia przyczyny zwolnienia towaru z podatku VAT w JPK_FA.

Przeprowadzenie walidacji nie jest w systemie Comarch ERP XL elementem wymagalnym do zaakceptowania oraz wysłania JPK. Jest to jedynie narzędzie pomocnicze, które wskazuje pozycje, które mogą wymagać poprawy przed wysłaniem pliku do organów kontrolujących.

Dokładny opis sposobu walidacji pliku, który jest wykorzystywany w Comarch ERP XL znajduje się w kolejnej części tego biuletynu.

Eksport do arkusza

Pliki JPK mają udostępniony na górnej belce w menu kontekstowym przycisk Eksport do arkusza. Jego wciśnięcie powoduje wygenerowanie nowego arkusza kalkulacyjnego zawierającego wszystkie pozycje zawarte w danym pliku.

Szablony Excela

Jeśli występuje konieczność okresowej analizy pliku JPK w arkuszu kalkulacyjnym wygodnym rozwiązaniem jest wykorzystanie szablonu Excela. Wraz z instalatorem do Comarch ERP XL dodano katalog predefiniowanych szablonów Excela. Każdy z tych szablonów można zmodyfikować we własnym zakresie. Dostępne są pliki:

Każdy z tych plików został zaprojektowany do otwierania konkretnego rodzaju JPK.

Pliki szablonów mają rozszerzenie .xltm, co oznacza szablony Excela z obsługą makr. Z reguły obsługa makr jest wyłączona przez Microsoft Office, co jest widoczne nad paskiem funkcji arkusza:

Aby wykorzystać przycisk „Otwórz XML” do wskazania lokalizacji odpowiedniego pliku na dysku, konieczne jest włączenie obsługi makr poprzez wciśnięcie przycisku „Włącz zawartość”.

Jeśli ostrzeżenie się nie pojawiło, to najprawdopodobniej obsługa makr w tym pliku została już wcześniej zaakceptowana.

Makra wykorzystywane w szablonach Comarch służą do otwarcia plików źródłowych i ich edycja została zabezpieczona hasłem. Stanowi to zabezpieczenie użytkownika końcowego przed uruchomieniem niesprawdzonego przez Comarch, a zatem potencjalnie niebezpiecznego skryptu umieszczonego w szablonie.

Pozostała ingerencja w plik jest już dozwolona (dodawanie i modyfikowanie formuł, wykresów itd.)

Domyślnie Szablon Excela jest otwierany w trybie „Nowy”, czyli tworzony jest nowy plik w Excela w oparciu o ten szablon, który można zapisać na dysku. Automatycznie system nadaje mu kolejny numer, więc w tytule dokumentu widzimy np. „JPK_VAT-20171 – Microsoft Excel” Jeśli konieczna jest modyfikacja samego szablonu, należy z menu kontekstowego tego pliku wybrać opcję Otwórz. W takim przypadku modyfikujemy już sam szablon, co widać także w tytule pliku (JPK_VAT-2017.xltm).

Jeśli w arkuszu nie jest dostępna zmiana niektórych normalnych właściwości komórek (kolor tła, obramowanie itp.) może to oznaczać, że Microsoft Office otworzył plik w trybie ochrony. Odblokowanie właściwości następuje w wyniku wybrania z zakładki Recenzja przycisku Nie chroń arkusza. Zdjęcie ochrony z pliku nie oznacza jednak umożliwienia dostępu do wewnętrznych makr. Te są w dalszym ciągu zabezpieczone.

Wbudowany walidator

System Comarch ERP XL posiada wbudowany mechanizm do walidacji plików JPK. W przeciwieństwie do innych systemów dostępnych na rynku walidacja odbywa się jeszcze przed wygenerowaniem wynikowego pliku XML, czyli bezpośrednio na bazie danych. Taka walidacja jest znacznie szybsza oraz pozwala na generowanie ostrzeżeń, czyli zwracania uwagi na pola, które zostały wypełnione, ale ich wartość może wskazywać na błędy w dokumencie źródłowym.

Nie jest natomiast sprawdzana sama struktura utworzonego XMLa, gdyż takie sprawdzenie następuje już na poziomie bramki MF. Może się zatem zdarzyć, że wbudowany walidator nie wykryje błędu, ale MF taki plik odrzuci. Są to sytuacje bardzo rzadkie, które mogą mieć miejsce, gdy obligatoryjne pole podstawowe jest uzupełnione niestandardowymi danymi np. kod waluty jest dwuznakowy, zamiast trzyznakowego (ZŁ zamiast PLN), numer w polu REGON nie spełnia polskiego standardu itp.

W takim przypadku należy wygenerować plik XML i wykorzystać zewnętrzny walidator, który wskaże błąd w strukturze. Można również zwrócić się z tym do partnera lub asysty technicznej Comarch.

Do wyświetlenia rezultatu walidacji wykorzystywane jest okno zdarzeń systemowych. Sam proces sprawdzenia danych jest bardzo szybki, a zatem może się zdarzyć, że po wciśnięciu walidacji jedynie mignie ekran. Oznacza to, że walidator nie miał do zakomunikowania żadnych błędów i ostrzeżeń, a zatem okno zdarzeń systemowych od razu się zamknęło.

Aby okno zdarzeń systemowych pozostało otwarte nawet po poprawnej walidacji należy zmienić ustawienia na karcie operatora odznaczając parametr: Zamknij gdy brak błędów w sekcji Log systemowy.

JPK_VAT
Do usprawnień zabezpieczających przed błędami generacji (opisanych w rozdziale poświęconym generowaniu
plików JPK) został również dostosowany mechanizm walidacji pliku JPK_VAT. Zważywszy na pola obligatoryjne
system wyszukuje następujące zdarzenia oraz podaje w którym wierszu pliku takie zdarzenie wystąpiło:

Sprzedaż VAT-7:

a. Brak NIP-u nabywcy – pole uzupełniane słowem BRAK – ostrzeżenie
b. Brak NIP-u nabywcy – pole nie zostało uzupełnione automatycznie – błąd
c. Brak nazwy nabywcy – pole uzupełniane słowem BRAK – ostrzeżenie
d. Brak nazwy nabywcy – pole nie zostało uzupełnione automatycznie – błąd
e. Brak adresu nabywcy – pole uzupełniane słowem BRAK – ostrzeżenie
f. Brak adresu nabywcy – pole nie zostało uzupełnione automatycznie – błąd
g. Niepełny adres nabywcy (tyko kod pocztowy 00-000) – ostrzeżenie
h. Brak numeru faktury – błąd (pole to nadawane w systemie XL automatycznie przy tworzeniu
faktury, więc taka sytuacja nie powinna wystąpić)

Zakup VAT-7:

a. Brak NIP-u sprzedawcy – pole uzupełniane słowem BRAK – ostrzeżenie
b. Brak nazwy sprzedawcy – błąd
c. Brak adresu sprzedawcy – błąd
d. Brak numeru dokumentu – pole uzupełniane słowem brak – ostrzeżenie

Dla każdego błędu oraz ostrzeżenia system wskazuje w jakim wierszu wystąpił błąd (numer Lp. na listach
Szczegółowa sprzedaż oraz Szczegółowy zakup).

 

JPK_FA

Walidator do struktury JPK_FA wyszukuje następujące zdarzenia:

1. Brak numeru faktury – błąd
2. Brak nazwy sprzedawcy – błąd
3. Brak adresu sprzedawcy – błąd
4. Brak przyczyny korekty, gdy dokument jest korektą – błąd
5. Brak podanej przyczyny zwolnienia z VAT, gdy na dokumencie wystąpiła transakcja ze stawką VAT zwolniony (w polu Zwolnienie z VAT wpisano wartość „true”) – ostrzeżenie
6. Brak nazwy lub adresu komornika sądowego lub organu egzekucyjnego, gdy w polu Faktura komornika wpisano wartość „true” – ostrzeżenie
7. Brak nazwy, adresu lub numeru przedstawiciela podatkowego, gdy w polu Przedstawiciel podatku wpisano wartość „true” – ostrzeżenie
8. Brak nazwy procedury marży, gdy w polu FV marża wpisano wartość „true” – ostrzeżenie

Dla każdego błędu oraz ostrzeżenia system wskazuje numer dokumentu, datę wystawienia oraz nazwę dostawcy.

JPK_MAG

Walidator do struktury JPK_MAG wyszukuje następujące zdarzenia:

1. Brak nazwy dostawcy dla PZ – błąd
2. Brak nazwy odbiorcy dla WZ – błąd
3. Brak wiersza dokumentu PZ, WZ, RW lub MM dla którego został zadeklarowany nagłówek (puste dokumenty magazynowe) – ostrzeżenie
4. Różna wartość dokumentu magazynowego zadeklarowanego w nagłówku od sumy wartości jego pozycji – ostrzeżenie

Dla każdego błędu oraz ostrzeżenia system wskazuje numer i nazwę dokumentu.

Dokumenty magazynowe przenoszone do JPK_MAG są ściśle powiązane z dokumentami handlowymi. W zdecydowanej większości przypadków walidator nie powinien zatem zgłaszać żadnych błędów.

JPK_KR

Walidator do struktury JPK_KR wyszukuje następujące zdarzenia:

1. Brak numeru zapisu (Id. księgowy) na zapisach księgowych – błąd
2. Brak numeru dowodu księgowego – błąd
3. Niezgodność sumy bilansowej zapisu – ostrzeżenie

Do każdego błędu oraz ostrzeżenia system wskazuje numer zapisu oraz identyfikator błędów.

Utworzenie zapisu księgowego w Comarch ERP XL w normalnym toku użytkowania systemu wymaga uzupełnienia wszystkich pól obligatoryjnych. W zdecydowanej większości przypadków walidator nie powinien zatem zgłaszać żadnych błędów.

JPK_WB

Walidator do struktury JPK_WB wyszukuje następujące zdarzenia:

1. Brak wskazania kontrahenta (kontrahent INNY) – ostrzeżenie

Zalecenia rejestracji dokumentów dla JPK

W poniższym rozdziale zostanie opisany sposób rejestracji dokumentów w sposób umożliwiający poprawne wygenerowanie plików JPK. Wygenerowanie dokumentu, który się poprawnie waliduje nie oznacza jeszcze poprawności merytorycznej. Dlatego ten rozdział ten należy rozpatrywać w powiązaniu z biuletynem technicznym XL105 – Deklaracja VAT-7, który opisuje sposób cechowania dokumentów, aby trafiały we właściwe pola deklaracji VAT-7.

Ogólne pola obowiązkowe w kontekście JPK

W tym rozdziale przedstawione są pola obowiązkowe w kontekście wszystkich struktur JPK, czyli wykorzystywane niezależnie od generowanej struktury.

Dane kontrahenta (Nazwa, Adres, NIP)

Dane kontrahenta pobierane są z karty kontrahenta zgodnie z ujęciem historycznym, czyli pobierane są wartości, obowiązujące na dzień wystawienia konkretnego dokumentu.

Do poprawnego uwzględnienia danych kontrahenta potrzebne są informacje:

1. Nazwa kontrahenta
2. Ulica,
3. Kod pocztowy,
4. Miasto,
5. Numer NIP wraz z prefiksem w przypadku transakcji wewnątrzwspólnotowych. Niepotrzebne prefiksy w przypadku transakcji krajowych są automatycznie usuwane, więc zalecamy dla każdego kontrahenta dodawać prefiks numeru NIP.

W przypadku wybrania kontrahenta jednorazowego pobierane są dane podane dla danego kontrahenta jednorazowego. Należy zatem podawać dane dotyczące nazwy, adresu oraz NIPu kontrahenta jednorazowego, od którego został zakupiony towar bądź usługa.

W przypadku ujmowania na rejestrze zakupów dokumentów SAD odpowiednie dane pobierane są z karty urzędu. Jako numer identyfikacyjny wystawcy podawany jest Kod Urzędu Celnego.

Numer faktury (numer obcy)

Numer faktury w systemie znajduje się zarówno na dokumentach sprzedaży i zakupu w polu Faktura na zakładce Nagłówek w wariancie pełnym  oraz na zakładce Ogólne w widoku uproszczonym . W polu tym należy wpisać numer faktury, widniejący na fakturze otrzymanej od kontrahenta. W przypadku faktur sprzedaży pole to jest automatycznie wypełnianie numerem dokumentu.

 

JPK_FA

Struktura JPK_FA jest najbardziej rozbudowaną z raportowanych struktur. W największej mierze korzysta również z dodatkowych atrybutów przez co jej obsługa może wymagać dodatkowego nakładu pracy.

Miało to szczególne znaczenie w kontekście faktur zakupowych, które pierwotnie również miały być ujmowane w tej strukturze. Ze względu na praktykę gospodarczą oraz wzrost nakładów pracy jakie wiązałyby się z rejestrowaniem faktur zakupu tak, aby spełniały wymogi JPK_FA, Ministerstwo Finansów w swoim komunikacie z dnia 28.07.2016 oświadczyło, że w pliku JPK_FA prezentowane są tylko faktury sprzedaży.

Poniżej zaprezentowano parametry konfigurujące ujmowania faktur na poszczególnych polach struktury JPK_FA.

 

Parametr JPK_FA na nagłówkach dokumentów

Na nagłówkach dokumentów, które domyślnie są uwzględniane w pliku JPK_FA pojawił się czek o nazwie JPKFA. Jego zaznaczenie decyduje o ujęciu danego dokumentu na liście JPK_FA. Nie ma on wpływu na inne struktury JPK, również na JPK_VAT.

Domyślnie parametr ten jest zaznaczony. Po jego odznaczeniu dana faktura nie będzie uwzględniana na JPK_FA.

Został wprowadzony głównie z uwagi na faktury a-vista, które mogą mieć charakter techniczny (korygować podatek VAT należny/naliczony) i nie powinny być eksportowane do pliku JPK_FA.

Przy dodawaniu nowej faktury parametr jest domyślnie zaznaczony, co oznacza, że faktura zostanie ujęta w pliku JPK_FA. Również na dokumentach wystawionych w wersjach wcześniejszych, przekonwertowanych do wersji 2016.3 parametr JPKFA będzie zaznaczony.

Jeżeli dokument nie powinien być ujęty w pliku JPK_FA, parametr należy odznaczyć. Można to zrobić ręcznie, z poziomu dokumentu lub też wykorzystać do tego mechanizm do seryjnej zmiany wartości tego parametru. W celu seryjnej zmiany wartości parametru JPK_VAT na liście dokumentów należy zaznaczyć odpowiednie faktury oraz poziomu menu kontekstowego wybrać opcje:

Zmiany wartości parametru JPKFA można dokonać na dokumentach o dowolnym statusie, tj. będących w buforze, zatwierdzonych jak również zaksięgowanych.

Na tzw. formularzach „pełnych” faktur zakupu i sprzedaży, parametr JPKFA został udostępniony na zakładce Nagłówek, obok nowego pola „Przyczyna zwolnienia z VAT”.

Na tzw. „formularzach „uproszczonych”, udostępnianych dla faktur a-vista, parametr JPKFA umieszczono na zakładce Ogólne, obok nowego pola „Przyczyna zwolnienia z VAT”, który został dodany pod polami prezentującymi informacje o Płatności.

Z kolei na dokumentach FAI, dokumentujących transakcje zakupu od kontrahentów z Unii i z poza Unii, na których nie jest wykazywany podatek VAT a tym samym przyczyna zwolnienia z podatku VAT, parametr JPKFA umieszczono obok pola Faktura.

Faktury bez pozycji

Schemat JPK_FA przewiduje również przesłanie informacji o poszczególnych pozycjach na danej fakturze. Wszystkie te informacje są pobierane automatycznie z pozycji powiązanych z danym nagłówkiem faktury. Nie wymaga to zatem dodatkowej pracy ze strony użytkownika.

Ponieważ system Comarch ERP XL przewiduje możliwość dodawania faktur a-vista bez pozycji, z wykorzystaniem wyłącznie tabelki VAT, dla celów JPK zostanie do nich dodany automatycznie wiersz ze wskazaniem towaru o nazwie „Koszt” oraz wartości zgodnej z rejestrem VAT. W przypadku, gdy na tabelce VAT znajdują się wiersze z różnymi stawkami VAT, odpowiednie wartości zostaną również przeniesione do listy JPK. Analogiczne rozwiązanie zostało przyjęte dla faktur zaliczkowych, gdzie dla pozycji towarowych prezentowany jest wiersz o nazwie „Zaliczka na poczet zamówienia nr…”.

Faktury korygujące

W przypadku faktur korygujących pole Rodzaj faktury automatycznie przyjmuje wartość „KOREKTA”. Schemat MF przewiduje jeszcze możliwość dodania dodatkowego opisu do korekty w postaci trzech pól: Przyczyna korekty, Numer faktury pierwotnej oraz Okres korekty.

Uzupełnienie tych pól odbywa się w systemie Comarch ERP XL w następujący sposób:

1. Przyczyna korekty uzupełniana jest na nagłówku faktury korygującej. Uzupełnienie tego pola jest obligatoryjne. W przypadku pozostawienia pustej wartości dla faktury korygującej plik JPK będzie niepoprawny.
2. Numer faktury pierwotnej pobierany jest z pola „Korygowana” na nagłówku faktury korygującej. Jeśli pole to jest nieuzupełnione, w pole na JPK wpisywany jest numer własny faktury korygującej.
3. Okres korekty pobierany jest automatycznie. Jest to albo data faktury korygowanej (w formacie „Od – do” pokrywającej jeden dzień), albo cały zakres dat w przypadku, gdy korekta dotyczy rabatu retrospektywnego.

Uwaga

W przypadku gdy jeden z dokumentów korygujących nie ma uzupełnionej przyczyny korekty spowoduje to brak walidacji dla całego pliku XML. W takim przypadku należy odnaleźć ten dokument, uzupełnić przyczynę korekty oraz powtórnie przeliczyć i wygenerować plik XML JPK.

Przyczyna zwolnienia z VAT

W przypadku gdy mamy do czynienia z dokumentem, na którym jedna z pozycji jest objęta stawką VAT zwolniony, należy na nagłówku dokumentu ustalić przyczynę zwolnienia z podatku VAT.

Uwaga

W przypadku dokumentów synchronizowanych z systemów zewnętrznych, przyczynę zwolnienia należy wskazać ręcznie po zaimportowaniu dokumentu w Comarch ERP XL.

Słownik przyczyn

Przyczyna zwolnienia z podatku VAT oparta została na zamkniętym słowniku kategorii, dodanym w gałęzi: Transakcje jako „Przyczyna zwolnienia z VAT”. Na formatce, poza wskazaniem przyczyny zwolnienia (Wartość), rozumianej jako konkretny przepis prawny, można wskazać podstawę zwolnienia, tzn. zwolnienie wynika z polskiej ustawy, dyrektywy unijnej, innej podstawy.

Jednocześnie udostępnione zostały trzy predefiniowane przyczyny.

Przypisywanie na dokumentach

Przypisywanie przyczyny zastosowania stawki zw. jest na nagłówku dokumentu i odnosi się ona do wszystkich elementów z taką stawką na dokumencie. Nie ma możliwości wpisywania ręcznie wartości z poziomu dokumentu, tzn. poza wartością pustą możliwy jest wybór z zamkniętej listy słownikowej.

Kontrolka dla wskazania przyczyny zwolnienia z VAT jest zawsze dostępna na nagłówku dokumentu, domyślnie z wartością pustą. Użytkownik dodając element ze stawką zw. może (przed lub po dodaniu elementu) wskazać konkretną przyczynę zwolnienia ze stawki VAT.

Powyższe zostało obsłużone na dokumentach j.n:

Podczas dodawania nowego dokumentu jako przyczyna zwolnienia ustalana będzie wartość pusta, dodatkowo: 

Zmiana przyczyny na zatwierdzonym dokumencie

Dodatkowo dla uprawnionych użytkowników jest możliwość zmiany przyczyny zwolnienia na zatwierdzonym dokumencie. Stosowne uprawnienie nadawane jest na karcie operatora, jako wspólne dla operacji zmiany przyczyny korekty jak i zmiany przyczyny zwolnienia z VAT. Odpowiedni parametr dostępny jest na zakładce {Parametry/Ogólne} jako „Zamiana przyczyny korekty/zw. z VAT na zatw. dokumencie”.

Seryjne ustalanie przyczyny zwolnienia z VAT

Jednocześnie udostępniona została możliwość seryjnego ustalania przyczyny zwolnienia z VAT na zatwierdzonych dokumentach. Jest ona dostępna z poziomu rejestru VAT, jako kolejny parametr dla opcji: Zmień seryjne faktury dostępnej w menu kontekstowym na liście rejestrów VAT.

Ustalanie nowej wartości przyczyny zwolnienia z VAT, analogicznie jak w przypadku zmiany na nagłówku dokumentu możliwe jest dla operatorów z uprawnieniem: Zmiana przyczyny korekty/zw. z VAT na zatw. dokumencie.

Faktura ujmowana w kilku rejestrach VAT

Plik JPK_FA jest niezależny od rejestrów VAT znajdujących się w systemie Comarch ERP XL. W przypadku gdy jedna faktura jest ujmowana w kilku rejestrach może to spowodować błędne wygenerowanie pliku JPK_FA, gdyż dla każdego z nich domyślnie zaznaczany jest czek JPKFA.

Rozwiązaniem może być zarejestrowanie jednej faktury zawierającej wszystkie pozycje. W nagłówku takiej faktury należy pozostawić zaznaczony parametr JPKFA, czyli ujęcie jej w pliku JPK_FA.

Na zakładce VAT należy wskazać rejestr oraz wydzielić pozycje, które powinny trafić do tego rejestru. Na pozostałych pozycjach należy zaznaczyć parametr ‘Nie uwzględniaj na deklaracji VAT-7’. Nie zostaną one zatem ujęte na tym etapie w żadnym rejestrze VAT.

Dla dotychczas nieujętych, w rejestrze VAT wprowadzić dodatkowe a-visty, z pozycjami, które mają trafić do odpowiednich rejestrów. Na tego rodzaju fakturach odznaczyć parametr JPKFA.

W efekcie w pliku JPK_FA zostanie ujęta tylko faktura źródłowa, ze wszystkimi pozycjami, która zostanie prawidłowo rozbita na odpowiednie rejestry VAT w systemie.

Kwalifikacja specyficznych pól atrybutami

Aby udostępnić pełną funkcjonalność JPK_FA część pól została dotyczących specyficznych zdarzeń gospodarczych zostało wprowadzone atrybutami.

I tak przykładowo aby zakwalifikować fakturę jako wystawioną przez przedstawiciela podatkowego konieczne jest przypisanie polu przedstawiciel podatkowy wartości true oraz określenie nazwy, adresu i numeru przedstawiciela podatkowego. Odbywa się to z wykorzystaniem atrybutów JPK_P_21, JPK_P_21A, JPK_P_21B, JPK_P_21C.

Poniżej podsumowanie wszystkich atrybutów, które mogą być wykorzystywane w systemie oraz opis ich dokładnego wykorzystania:

Kolumna	Nazwa atrybutu	Typ atrybutu
Metoda kasowa	JPK_P_16	Flaga
Samofakturowanie	JPK_P_17	Flaga
Faktura komornika	JPK_P_20	Flaga lub Kontrahent
Nazwa komornika	JPK_P_20A	Tekst lub Kontrahent
Adres komornika	JPK_P_20B	Tekst lub Kontrahent
Przedstawiciel podatkowy	JPK_P_21	Flaga lub Kontrahent
Nazwa przedstawiciela	JPK_P_21A	Tekst lub Kontrahent
Adres przedstawiciela	JPK_P_21B	Tekst lub Kontrahent
Numer przedstawiciela	JPK_P_21C	Tekst lub Kontrahent
Śr. transportu - data dopuszczenia	JPK_P_22A	Data
Śr. transportu – przebieg	JPK_P_22B	Liczba lub Tekst
Nowy statek – liczba godzin	JPK_P_22C	Liczba lub Tekst
WTT – drugi podatnik	JPK_P_23	Flaga
FV marża biur podróży	JPK_P_106E_2	Flaga
FV marża	JPK_P_106E_3	Flaga
Procedura marży	JPK_P_106E_3A	Tekst: dopuszczalne wartości: procedura marży - towary używane procedura marży - dzieła sztuki procedura marży - przedmioty kolekcjonerskie i antyki

Metoda kasowa – atrybut (JPK_P_16)

W przypadku dostawy towarów lub świadczenia usług, w odniesieniu do których obowiązek podatkowy powstaje zgodnie z art. 19a ust. 5 pkt 1 lub art. 21 ust. 1 – wyrazy “metoda kasowa”, należy podać wartość “true”; w przeciwnym przypadku – wartość – “false”

Aby przy danym dokumencie został zmieniony typ Metoda kasowa z false na true, należy przypisać do niego atrybut o nazwie JPK_P_16, typie flaga i wartości „Tak”.

Samofakturowanie – atrybut (JPK_P_17)

W przypadku faktur, o których mowa w art. 106d ust. 1 – wyraz “samofakturowanie”, należy podać wartość “true”; w przeciwnym przypadku – wartość – “false”

Aby przy danym dokumencie został zmieniony typ Samofakturowanie z false na true, należy przypisać do niego atrybut o nazwie JPK_P_17, typie flaga i wartości „Tak”.

Faktura komornika – atrybuty

W przypadku, gdy mamy do czynienia z fakturą, którą w imieniu kontrahenta wystawia organ egzekucyjny lub komornik sądowy (art. 106c Ustawy o VAT). Powinny zostać uzupełnione wszystkie pola:

1. Faktura komornika – ustawić wartość true, poprzez przypisanie dla dokumentu atrybutu o nazwie JPK_P_20, typie flaga i wartości „Tak”.
2. Nazwa komornika – przypisać dla dokumentu atrybut o nazwie JPK_P_20A o typie Tekst i wartości odpowiadającej nazwie organu egzekucyjnego lub komornika sądowego.
3. Adres komornika – przypisać dla dokumentu atrybut o nazwie JPK_P_20B o typie Tekst i wartości odpowiadającej adresowi organu egzekucyjnego lub komornika sądowego.

Alternatywnie można utworzyć atrybuty JPK_P_20, JPK_P_20A oraz JPK_P_20B o typie Kontrahent. Wówczas przy wyborze odpowiedniego kontrahenta na atrybucie dokumentu, flaga Faktura komornika zostanie ustawiona na true, a dane o nazwie komornika oraz adresie komornika zostaną pobrane z karty przypisanego do atrybutu kontrahenta.

Od wersji 2016.3.1 zalecanym rozwiązaniem jest utworzenie atrybutu JPK_P_20 o typie kontrahent, a następnie przypisanie go do faktury. Nie jest już konieczne tworzenie i przypisywanie pozostałych atrybutów (JPK_P_20A oraz JPK_P_20B), gdyż dane adresowe komornika zostaną pobrane z karty kontrahenta.

Przedstawiciel podatkowy – atrybuty

W przypadku, gdy mamy do czynienia z fakturą, którą w imieniu i na rzecz podatnika wystawia jego przedstawiciel podatkowy, powinny zostać uzupełnione wszystkie następujące pola:

1. Przedstawiciel podatkowy – ustawić wartość true, poprzez przypisanie dla dokumentu atrybutu o nazwie JPK_P_21, typie flaga i wartości „Tak”.
2. Nazwa przedstawiciela – przypisać dla dokumentu atrybut o nazwie JPK_P_21A o typie Tekst i wartości odpowiadającej nazwie przedstawiciela podatkowego.
3. Adres przedstawiciela – przypisać dla dokumentu atrybut o nazwie JPK_P_21B o typie Tekst i wartości odpowiadającej adresowi przedstawiciela podatkowego
4. Numer przedstawiciela – przypisać dla dokumentu atrybut o nazwie JPK_P_21C o typie Tekst i wartości odpowiadającej numerowi przedstawiciela podatkowego

Alternatywnie można utworzyć atrybuty JPK_P_21, JPK_P_21A, JPK_P_21B oraz JPK_P_21C o typie Kontrahent. Dla przedstawiciela podatkowego należy utworzyć odpowiednią kartę kontrahenta. Wówczas flaga Przedstawiciel podatkowy zostanie ustawiona na wartość ‘true’, a dane o nazwie oraz adresie zostaną pobrane z takiej karty kontrahenta. Numer przedstawiciela podatkowego (atrybut JPK_P_21C) zostanie pobrany z numeru NIP dla danej karty kontrahenta.

Od wersji 2016.3.1 zalecanym rozwiązaniem jest utworzenie atrybutu JPK_P_21 o typie kontrahent, a następnie przypisanie go do faktury. Nie jest już konieczne tworzenie i przypisywanie pozostałych atrybutów (JPK_P_21A, JPK_P_21B oraz JPK_P_21C), gdyż dane adresowe przedstawiciela podatkowego zostaną pobrane z karty kontrahenta.

Nowe środki transportu – atrybuty

W przypadku, gdy przedmiotem wewnątrzwspólnotowej dostawy są nowe środki transportu należy podać datę dopuszczenia nowego środka transportu do użytku oraz:

1. przebieg pojazdu – w przypadku pojazdów lądowych, o których mowa w art. 2 pkt 10 lit. a ustawy
2. liczbę godzin roboczych używania nowego środka transportu – w przypadku jednostek pływających, o których mowa w art. 2 pkt 10 lit. b ustawy , oraz statków powietrznych, o których mowa w art. 2 pkt 10 lit. c ustawy

Do tego w schemacie JPK_FA służą pola Śr. transportu data dopuszczenia, śr. transportu – przebieg oraz Nowy statek – liczba godzin.

W przypadku, gdy przedmiotem dokumentu jest wewnątrzwspólnotowa dostawa nowego środka transportu należy dodać do niego atrybut o nazwie JPK_P_22A oraz typie Data.

Ponadto można uzupełnić przebieg pojazdu w przypadku pojazdów lądowych – do tego służy atrybut JPK_P_22B o typie Tekst, albo liczba godzin używania w przypadku jednostek pływających oraz statków powietrznych (atrybut JPK_P_22C o typie Tekst).

WTT – drugi podatnik – atrybut (JPK_P_23)

W przypadku faktur wystawianych przez drugiego w kolejności podatnika, o którym mowa w art. 135 ust. 1 pkt 4 lit. b i c, w wewnątrzwspólnotowej transakcji trójstronnej (procedurze uproszczonej) – dane określone w art. 136, należy podać wartość “true”; w przeciwnym przypadku – wartość “false”

Aby przy danym dokumencie został zmieniony typ z false na true, należy przypisać do niego atrybut o nazwie JPK_P_23, typie flaga i wartości „Tak”.

FV marża biur podróży – atrybut (JPK_P_106E_2)

W przypadku świadczenia usług turystyki, dla których podstawę opodatkowania stanowi zgodnie z art. 119 ust. 1 kwota marży, faktura – w zakresie danych określonych w ust. 1 pkt 1-17 – powinna zawierać wyłącznie dane określone w ust. 1 pkt 1-8 i 15-17, a także wyrazy “procedura marży dla biur podróży”, należy podać wartość “true”; w przeciwnym przypadku – wartość – “false”.

Aby przy danym dokumencie został zmieniony typ z false na true, należy przypisać do niego atrybut o nazwie JPK_P_106E_2, typie flaga i wartości „Tak”.

FV marża i procedura marży – atrybuty

W przypadku dostawy towarów używanych, dzieł sztuki, przedmiotów kolekcjonerskich i antyków, dla których podstawę opodatkowania stanowi zgodnie z art. 120 ust. 4 i 5 marża, należy podać wartość “true”; w przeciwnym przypadku – wartość – “false”.

Aby przy danym dokumencie został zmieniony typ z false na true, należy przypisać do niego atrybut o nazwie JPK_P_106E_3, typie flaga i wartości „Tak”.

W takim przypadku należy również podać tytuł procedury marży w polu Procedura marży. Aby to zrobić należy przypisać do dokumentu również atrybut JPK_P_106E_3A o typie tekst i odpowiedniej wartości. Schema MF ogranicza wybór do następujących określeń:

1. procedura marży – towary używane
2. procedura marży – dzieła sztuki
3. procedura marży – przedmioty kolekcjonerskie i antyki

JPK_KR

Księgi rachunkowe – ogólny schemat

Dane zawarte w pliku JPK_KR rozbite są na kilka powiązanych ze sobą struktur – Zestawienie Obrotów i Sald, Zapisy na kontach oraz Dziennik.

Zestawienie obrotów i sald

Wszystkie pozycje są uzupełniane automatycznie na podstawie obligatoryjnych pól w systemie Comarch ERP XL. Nie jest potrzebna dodatkowa praca ze strony użytkownika systemu.

Zapisy na kontach

Wszystkie pozycje są uzupełniane automatycznie na podstawie obligatoryjnych pól w systemie Comarch ERP XL. Nie jest potrzebna dodatkowa praca ze strony użytkownika systemu.

Dziennik

W systemie XL możliwe jest utworzenie zapisu księgowego, który nie ma uzupełnionego pola Id. księgowy. Wartość z tego pola jest później wykorzystywana podczas generowania JPK_KR.

Aby zapobiec takim sytuacjom zalecamy domyślne ustawienie dodatkowego identyfikatora dokumentu i zapisu księgowego w parametrach konfiguracji modułu księgowość.

Uwaga

Podczas generacji pliku JPK_KR można uwzględnić w nim zapisy w buforach. Podczas eksportu tego pliku do organów kontrolujących, parametr ten powinien być odznaczony, czyli eksportowane powinny być jedynie zatwierdzone zapisy księgowe.

JPK_MAG

Magazyny – ogólny schemat

Dane zawarte w pliku JPK_KR rozbite są na kilka struktur magazynowych – PZ, WZ, RW, MM.

PZ

Schemat PZ odzwierciedla przyjęcia towarów lub materiałów z zewnątrz, które może odbywać się na podstawie kilku dokumentów obecnych w systemie, które mogą generować ruch magazynowy m.in. PZ oraz FZ.

Wg schematu polem obligatoryjnym jest nazwa dostawcy. Nazwa ta pobierana jest z karty kontrahenta wskazanego na dokumencie źródłowym. W przypadku kontrahenta jednorazowego jest to nazwa wskazana na danych kontrahenta jednorazowego.

WZ

Schemat WZ odzwierciedla wydanie towarów lub materiałów z zewnątrz, które może odbywać się na podstawie kilku dokumentów obecnych w systemie, które mogą generować ruch magazynowy m.in. WZ oraz FS.

Wg schematu polem obligatoryjnym jest nazwa odbiorcy. Nazwa ta pobierana jest z karty kontrahenta wskazanego na dokumencie źródłowym. W przypadku kontrahenta jednorazowego jest to nazwa wskazana na danych kontrahenta jednorazowego. W przypadku dokumentów źródłowych PA/PAK/WKA/WKK możliwe jest ich zarejestrowanie bez wprowadzania kontrahenta. W takim przypadku, jeżeli dla danego dokumentu została utworzona faktura (spinacz/korekta spinacza), kontrahent ustalany jest na podstawie kontrahenta z tej faktury. Jeżeli zaś dla ww. dokumentu nie istnieje faktura, wówczas jako nazwa Odbiorcy wysyłana jest fraza Sprzedaż detaliczna.

RW

Schemat RW nie przewiduje pól obligatoryjnych, które nie byłyby już obligatoryjne w systemie.

MM

Schemat MM nie przewiduje pól obligatoryjnych, które nie byłyby już obligatoryjne w systemie.

JPK_WB

Numer rachunku

JPK_WB obowiązuje tylko dla rachunków, których numer spełnia warunki formatu IBAN. Spełnione jest to dla wszystkich rachunków prowadzonych w polskich bankach oraz prowadzonych w krajach Unii Europejskiej. Format IBAN składa się z dwóch liter stanowiących kod kraju, dwóch cyfr kontrolnych oraz właściwego numeru rachunku (od 10 do 30 znaków).

Wszystkie banki z ustawionym czekiem NRB spełniają warunek rachunku IBAN.

W przypadku banków zagranicznych należy poprawnie ustawić kod kraju na karcie banku powiązanego z danym rejestrem bankowym. W przypadku pozostawienia nieuzupełnionego kodu kraju, system domyślnie przyjmie wartość PL.

Saldo początkowe i końcowe

Aby saldo początkowe i końcowe odpowiadało rzeczywistej wartości rachunku, należy na pierwszym raporcie w danym rejestrze bankowym ustawić odpowiedni Stan początkowy. W kolejnych raportach stan ten jest już odpowiednio modyfikowany o wartość zapisów bankowych.

Wiersze wyciągu

W schemacie JPK_WB polami obligatoryjnymi jest Nazwa podmiotu będącego stroną operacji, opis operacji oraz jej kwota.

W systemie Comarch ERP XL wszystkie te pola są polami obligatoryjnymi, czyli należy uzupełnić wszystkie pola bezpośrednio związane z plikiem JPK_WB. Pewnym wyjątkiem może być podmiot ***INNY***, którego można wybrać na oknie zapisu bankowego. Taki podmiot nieokreślony jest przesyłany do pliku JPK_WB jako kontrahent INNY. Nie powoduje to błędu podczas walidacji schemy, ale może zostać zakwestionowane przez organ kontrolujący, jako nieprawidłowa nazwa kontrahenta.

W praktyce gospodarczej często rejestrowane są operacje przekazania środków pieniężnych między różnymi rachunkami bankowymi. W takim przypadku często celowo ustawiany jest kontrahent ***INNY***, aby nie generować niepotrzebnych rozliczeń.

Aby zachować pełną poprawność pliku JPK_WB na zapisie bankowym można utworzyć Atrybut o nazwie JPK_WB_INNY i typie Kontrahent.

Podczas generacji pliku JPK_WB, dla każdego zapisu bankowego, w którym nie zdefiniowano podmiotu zapisu, system sprawdza czy taki atrybut został ustawiony. Jeśli tak, to wartość tego atrybutu (nazwa kontrahenta) jest pobierana do wiersza operacji JPK.

Uwaga

W trzeciej części odpowiedzi na pytania dotyczące JPK Ministerstwo Finansów potwierdziło, że chociaż obowiązek dostarczenie tej struktury spoczywa na podatniku, będzie on realizowany we współpracy z bankiem. W praktyce organ podatkowy będzie mógł zwrócić się do banku za zgodą podatnika o wydanie wyciągów bankowych w formie JPK, wskazując podstawę żądania, nr rachunku bankowego i okres, którego wyciąg będzie dotyczył.

Schematy plików JPK

W poniższym rozdziale zaprezentowany jest przegląd najważniejszych pól poszczególnych struktur Jednolitego Pliku Kontrolnego, wraz z poglądową obsługą tego pola w Comarch ERP XL. Pełny wykaz schematów JPK znajduje się na stronie Ministerstwa Finansów pod adresem:

http://www.mf.gov.pl/kontrola-skarbowa/dzialalnosc/jednolity-plik-kontrolny

w dziale Struktury JPK.

JPK_FA

Faktury – schemat

Dane zawarte na tej liście odzwierciedlają informacje z nagłówków faktur zarówno dla dokumentów sprzedaży, jak i zakupu. Zgodnie ze schematem powinny się tam znaleźć następujące informacje:

 

Kolumna	Ograniczenia pola	Uwagi
Data wystawienia	Data	Numeracja automatyczna
Numer faktury	Tekst (1-256 znaków)	Patrz punkt 4.1.2
Nabywca	Tekst (1-256 znaków)	Patrz punkt 4.1.1. Pole opcjonalne dla przypadku określonego w art. 106e ust. 5 pkt 3 ustawy
Adres nabywcy	Tekst (1-30 znaków)	Patrz punkt 4.1.1. Pole opcjonalne dla przypadku określonego w art. 106e ust. 5 pkt 3 ustawy
Sprzedawca	Tekst (1-256 znaków)	Patrz punkt 4.1.1.
Adres sprzedawcy	Tekst (1-256 znaków)	Patrz punkt 4.1.1.
Prefiks sprzedawcy	Tekst (2 znaki)	Pole nieobowiązkowe. Kod (prefiks) podatnika VAT UE dla przypadków określonych w art. 97 ust. 10 ustawy
NIP sprzedawcy	Polski NIP bez myślników	Patrz punkt 4.1.1.
Prefiks nabywcy	Tekst (2 znaki)	Pola nieobowiązkowe. Kod (prefiks) podatnika VAT UE dla przypadków określonych w art. 97 ust. 10 ustawy
NIP nabywcy	Polski NIP bez myślników	Patrz punkt 4.1.1.
Data sprzedaży	Data	Pole nieobowiązkowe. Wypełniane jeśli data sprzedaży jest różna od daty wystawienia dokumentu.
Netto 23%	Liczba	Pole uzupełniane automatycznie
VAT 23%	Liczba	Pole uzupełniane automatycznie
Netto 7,8%	Liczba	Pole uzupełniane automatycznie
VAT 7,8%	Liczba	Pole uzupełniane automatycznie
Netto 5%	Liczba	Pole uzupełniane automatycznie
VAT 5%	Liczba	Pole uzupełniane automatycznie
Netto NP-OO	Liczba	Pole uzupełniane automatycznie
VAT NP-OO	Liczba	Pole uzupełniane automatycznie
Netto NP	Liczba	Pole uzupełniane automatycznie
VAT NP	Liczba	Pole uzupełniane automatycznie
Netto 0%	Liczba	Pole uzupełniane automatycznie
Netto zw.	Liczba	Pole uzupełniane automatycznie
Należność	Liczba	Pole uzupełniane automatycznie
Metoda kasowa	true/false	Atrybut. Patrz punkt 4.3.6
Samofakturowanie	true/false	Atrybut. Patrz punkt 4.3.6
Odwrotne obciążenie	true/false	Ustawiane automatycznie dla dokumentów z odwrotnym obciążeniem
Zwolnienie z VAT	true/false	Ustawiane automatycznie dla dokumentów, na których istnieje stawka ‘zw’
Przepis ustawy	Tekst (1-256 znaków)	Pole nagłówka. Patrz punkt 4.3.4
Przepis dyrektywy	Tekst (1-256 znaków)	Pole nagłówka. Patrz punkt 4.3.4
Inna podstawa	Tekst (1-256 znaków)	Pole nagłówka. Patrz punkt 4.3.4
Faktura komornika	true/false	Atrybut. Patrz punkt 4.3.6
Nazwa komornika	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Adres komornika	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Przedstawiciel podatkowy	true/false	Atrybut. Patrz punkt 4.3.6
Nazwa przedstawiciela	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Adres przedstawiciela	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Numer przedstawiciela	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Śr. transportu – data dopuszcz.	Data	Atrybut. Patrz punkt 4.3.6
Śr. transportu – przebieg	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Nowy statek – liczba godzin	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
WTT – drugi podatnik	true/false	Atrybut. Patrz punkt 4.3.6
FV marża biur podróży	true/false	Atrybut. Patrz punkt 4.3.6
FV marża	true/false	Atrybut. Patrz punkt 4.3.6
Procedura marży	Tekst (1-256 znaków)	Atrybut. Patrz punkt 4.3.6
Rodzaj faktury	Tekst (1-256 znaków)	Dopuszczalne wartości = VAT, KOREKTA, ZAL, POZ. Pole uzupełniane automatycznie.
Przyczyna korekty	Tekst (1-256 znaków)	Patrz punkt 4.3.3
Numer faktury pierwotnej	Tekst (1-256 znaków)	Patrz punkt 4.3.3
Okres korekty	Tekst (1-256 znaków)	Patrz punkt 4.3.3
Otrzymana zaliczka	Liczba	Pole uzupełniane automatycznie
VAT od zaliczki	Liczba	Pole uzupełniane automatycznie

Wiersze faktury – schemat

Dane zawarte na tej liście odzwierciedlają informacje z pozycji poszczególnych faktur. Zgodnie ze schematem powinny się tam znaleźć następujące informacje:

Kolumna	Ograniczenia pola	Uwagi
Numer faktury	Tekst (1-256 znaków)	Zgodny z nagłówkiem dokumentu
Nazwa towaru	Tekst (1-256 znaków)
J.m.	Tekst (1-256 znaków)
Ilość	Liczba
Cena jedn.	Liczba
Cena brutto	Liczba
Kwota rabatu	Liczba	W przypadku gdy nie wpływa na cenę netto
Wartość netto	Liczba
Wartość brutto	Liczba
Stawka VAT	Tekst (1-2 znaków)

Wszystkie te pola są pobierane bezpośrednio z pozycji towarowych dla faktur sprzedaży/zakupu.

JPK_MAG

PZWartość – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer PZ	Tekst (1-256 znaków)
Data dok.	Data
Wartość	Liczba
Data otrzymania	Data
Dostawca	Tekst (1-256 znaków)
Numer faktury	Tekst (1-256 znaków)
Data faktury	Data

PZWiersz – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer PZ	Tekst (1-256 znaków)	Zgodny z nagłówkiem dokumentu
Kod towaru	Tekst (1-256 znaków)
Nazwa towaru	Tekst (1-256 znaków)
Ilość	Liczba (22,6)	Ilość pokazywana z precyzją 6 znaków po przecinku
J.m.	Tekst (1-256 znaków)
Cena jednostkowa	Liczba
Wartość	Liczba

WZWartość – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer WZ	Tekst (1-256 znaków)
Data dok.	Data
Wartość	Liczba
Data wydania	Data
Odbiorca	Tekst (1-256 znaków)
Numer faktury	Tekst (1-256 znaków)
Data faktury	Data

WZWiersz – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer WZ	Tekst (1-256 znaków)	Zgodny z nagłówkiem dokumentu
Kod towaru	Tekst (1-256 znaków)
Nazwa towaru	Tekst (1-256 znaków)
Ilość	Liczba (22,6)	Ilość pokazywana z precyzją 6 znaków po przecinku
J.m.	Tekst (1-256 znaków)
Cena jednostkowa	Liczba
Wartość	Liczba

RWWartość – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer RW	Tekst (1-256 znaków)
Data dok.	Data
Wartość	Liczba
Data wydania	Data
Skąd	Tekst (1-256 znaków)	Pole opcjonalne – nieuzupełniane
Dokąd	Tekst (1-256 znaków)	Pole opcjonalne – nieuzupełniane

RWWiersz – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer RW	Tekst (1-256 znaków)	Zgodny z nagłówkiem dokumentu
Kod towaru	Tekst (1-256 znaków)
Nazwa towaru	Tekst (1-256 znaków)
Ilość	Liczba (22,6)	Ilość pokazywana z precyzją 6 znaków po przecinku
J.m.	Tekst (1-256 znaków)
Cena jednostkowa	Liczba
Wartość	Liczba

MMWartość – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer MM	Tekst (1-256 znaków)
Data dok.	Data
Wartość	Liczba
Data wydania	Data
Skąd	Tekst (1-256 znaków)	Pole opcjonalne
Dokąd	Tekst (1-256 znaków)	Pole opcjonalne

MMWiersz – schemat

Kolumna	Ograniczenia pola	Uwagi
Numer MM	Tekst (1-256 znaków)	Zgodny z nagłówkiem dokumentu
Kod towaru	Tekst (1-256 znaków)
Nazwa towaru	Tekst (1-256 znaków)
Ilość	Liczba (22,6)	Ilość pokazywana z precyzją 6 znaków po przecinku
J.m.	Tekst (1-256 znaków)
Cena jednostkowa	Liczba
Wartość	Liczba

JPK_KR

ZOiS – schemat

Kolumna	Ograniczenia pola	Uwagi
Nr konta	Tekst (1-256 znaków)
Nazwa konta	Tekst (1-256 znaków)
Typ konta	Tekst (1-256 znaków)	Bilansowe, rozliczeniowe, wynikowe
Kod zespołu	Tekst (1-256 znaków)	Pierwszy znak nr konta
Opis zespołu	Tekst (1-256 znaków)	Pierwszy znak nr konta
Kod kategorii	Tekst (1-256 znaków)	Pierwsze 2 znaki nr konta
Opis kategorii	Tekst (1-256 znaków)	Pierwsze 2 znaki nr konta
Kod kategorii	Tekst (1-256 znaków)	Numer konta syntetycznego
Opis kategorii	Tekst (1-256 znaków)	Nazwa konta syntetycznego
BO debet	Liczba
BO credit	Liczba
Obroty debet	Liczba
Obroty credit	Liczba
Obroty narast debet	Liczba
Obroty narast credit	Liczba
Saldo debet	Liczba
Saldo credit	Liczba

Dziennik – schemat

Kolumna	Ograniczenia pola	Uwagi
Lp.	Liczba całkowita
Nr zapisu	Tekst (1-256 znaków)
Opis dziennika	Tekst (1-256 znaków)
Nr dowodu	Tekst (1-256 znaków)
Rodzaj dowodu	Tekst (1-256 znaków)	Np. faktura, wyciąg bankowy
Data operacji	Data
Data dowodu	Data
Data księgowania	Data
Operator	Tekst (1-256 znaków)
Opis	Tekst (1-256 znaków)	Opis operacji w dzienniku
Kwota	Liczba	Wartość dekretu

KontoZapis – schemat

Kolumna	Ograniczenia pola	Uwagi
Lp.	Liczba całkowita
Nr zapisu	Tekst (1-256 znaków)
Konto Wn	Tekst (1-256 znaków)
Kwota Wn	Liczba
Kwota Wn waluta	Liczba	Uzupełniane tylko dla kont pozabilansowych
Kod waluty winien	Tekst (3 znaki)	Uzupełniane tylko dla kont pozabilansowych
Opis Wn	Tekst (1-256 znaków)
Konto Ma	Tekst (1-256 znaków)
Kwota Ma	Liczba
Kwota Ma waluta	Liczba	Uzupełniane tylko dla kont pozabilansowych
Kod waluty Ma	Tekst (3 znaki)	Uzupełniane tylko dla kont pozabilansowych
Opis Ma	Tekst (1-256 znaków)

JPK_WB

WyciagWiersz – schemat

Kolumna	Ograniczenia pola	Uwagi
Lp.	Liczba całkowita
Data	Data
Podmiot	Tekst (1-256 znaków)
Opis	Tekst (1-256 znaków)
Kwota	Liczba
Saldo	Liczba	Wyliczane po każdej operacji

Nowa wersja pliku JPK

JPK_FA

Struktura JPK_FA(2) zaczęła obowiązywać od 1 lipca 2019 r.

Zostały wprowadzone zmiany dotyczące sposobu prezentacji:

Zgodnie z broszurą dotyczącego JPK_FA faktury walutowe w sekcji Faktura w polach od P_13 do P_15 należy ujmować w PLN. Na tej podstawie został zmieniony sposób prezentacji kwot w polach od P_13 do P_15 dla faktur walutowych.

W systemie Comarch ERP XL została udostępniona możliwość generowania Jednolitego Pliku Kontrolnego dla faktur VAT wg struktury JPK_FA(3).

Struktura JPK_FA(3) została opublikowana w związku z nowymi regulacjami, dotyczącymi faktur VAT w zakresie mechanizmu podzielonej płatności, które zostały wprowadzone ustawą z dnia 9 sierpnia 2019 r. o zmianie ustawy o podatku od towarów i usług oraz niektórych innych ustaw (Dz. U. z 13 września 2019 r. poz. 1751). Dodatkowo w nowej wersji struktury wprowadzono zmiany dotyczące raportowania faktur w walutach obcych i faktur zaliczkowych oraz szereg zmian o charakterze porządkowym.

Zmiany w zakresie JPK_FA(3) dotyczą zagadnień:

Na udostępnionym w Systemie JPK_FA(3), oprócz stosownych zmian, adoptujących powyższe założenia nowej struktury, dokonano również poniższych zmian:

Rejestrowanie JPK_FA(3)

Na liście plików JPK_FA filtr Wersja został wzbogacony o wartość 3. Po jej wyborze lista plików jest ograniczana do plików sporządzonych wg struktury JPK_FA(3). Użycie opcji Dodaj przy takim ustawieniu ww. filtra pozwala na dodanie nowego formularza JPK_FA(3).

JPK_FA(3) – Waluta

Zgodnie z nowym schematem przewidzianym dla JPK_FA(3) waluta nie jest już wysyłana w części nagłówkowej pliku, lecz dla każdej faktury w nim ujętej. Oznacza to, że odtąd w jednym JPK_FA mogą być ujęte transakcje dokonywane w różnych walutach. W Systemie Comarch ERP XL nadal można generować JPK_FA dla konkretnej waluty (chociażby na wewnętrzne potrzeby firmy), natomiast wskazanie waluty nie jest już konieczne. W przypadku jej niewskazania System generuje JPK_FA(3) dla transakcji bez względu na użytą na nich walutę. Takie też jest domyślne ustawienie filtra Waluta.

JPK_FA(3) – Podmiot

Zgodnie ze strukturą JPK_FA(3) dla podmiotu sporządzającego JPK należy podać alternatywnie albo adres polski albo zagraniczny. Różnica polega na innym zestawie danych adresowych dla adresu polskiego i innym dla adresu zagranicznego. W przypadku adresu polskiego zmiana w stosunku do dotychczasowych danych sprowadza się do rezygnacji z pola Poczta. Dla adresu zagranicznego przewidziano mniejszy zakres danych: Kod kraju, Kod pocztowy, Miejscowość, Ulica, Nr domu, Nr lokalu, przy czym wymagane są tylko: Kod kraju i Miejscowość. O tym, czy System wyśle adres krajowy, czy też zagraniczny decyduje symbol kraju w kontrolce Kod kraju. Jeżeli ustalony zostanie tutaj kod PL, wówczas wysłany zostanie adres polski, w innych przypadkach (brak kodu lub kod inny niż PL), wysłany zostanie adres zagraniczny. Domyślnie System identyfikuje kod kraju na podstawie nazwy kraju wprowadzonej na zakładce Deklaracje c.d. pieczątki firmy. Aby jednak System prawidłowo zidentyfikował dany kraj konieczne jest, aby ww. nazwa kraju była zgodna z nazwą kraju w tabeli KrajeCelne (KPC_NazwaPL).

Ww. kod kraju może zostać wprowadzony/zmieniony przez Użytkownika samodzielnie, bezpośrednio na formularzu JPK. W takim wypadku Użytkownik powinien zadbać o jego poprawność, tj. wprowadzić stosowny dwuliterowy symbol kraju. Wygląd formularza JPK_FA(3) w zakresie danych adresowych pozostaje niezmienny bez względu na kod kraju tj. prezentowane są wszystkie elementy adresu, w tym województwo, gmina itp., bez względu na to, czy adres jest polski, czy zagraniczny. To na etapie generowania pliku .xml System wysyła tylko te dane, które są przewidziane dla danego rodzaju adresu.

Uwaga

Po wprowadzeniu/zmianie kraju, czy też po zmianie innego elementu adresu (ulica, miasto itp.) należy dokonać operacji „przelicz” na formularzu, w przeciwnym razie w pliku .xml wysłane zostaną dotychczasowe dane adresowe.

JPK_FA(3) – Faktury

Dotychczasowa nazwa zakładki Listy JPK została zmieniona na Faktury. Dokonano na niej poniższych zmian:

W wierszach podsumowujących faktury dane grupowane są jak dotąd wg daty dokumentu. Oprócz daty prezentowana jest łączna liczba faktur z danego dnia oraz łączna wartość netto tychże faktur. Wartość netto prezentowana jest wyłącznie, jeżeli na formularzy JPK_FA(3) wskazano konkretną walutę.

Zakres informacji prezentowanych dla poszczególnych faktur został zmieniony stosownie do zmian w strukturze JPK_FA(3):

Usunięte zostały kolumny odpowiadające tym polom, które zostały usunięte ze struktury (VAT DOPTK, Otrzymana zaliczka, VAT od zaliczki)

W dotychczasowych kolumnach z wartością netto, wartością podatku oraz wartością należności prezentowane są obecnie wartości w walucie dokumentu.

Dodane zostały nowe kolumny, odpowiadające nowym informacjom przekazywanym w pliku: waluta dokumentu, kwota podatku w PLN, znacznik Mechanizmu Podzielonej Płatności (MPP), znacznik Środek transportu, Faktury zaliczkowe

Zakres prezentowanych danych dla poszczególnych elementów faktury nie uległa zmianie. Elementów nie ma już natomiast dla faktur zaliczkowych oraz ich korekt.

Nowa struktura JPK_FA(3) wprowadziła nowe informacje przekazywane dla poszczególnych faktur. W objaśnieniach doprecyzowano również kwestię ujmowania w JPK_FA faktur walutowych. Poniżej opisano zmiany w tym zakresie.

Dla dokumentów eksportowych FSE, (s)FSE, (S)FSE, FKE, (s)FKE, (S)FKE, (Z)FKE, FEL, KEL wysyłana jest waluta dokumentu, dla pozostałych zaś, waluta Systemowa PLN,

Wartości netto dla poszczególnych typów transakcji i stawek VAT danej faktury oraz wielkości podatku VAT wykazywane są w walucie dokumentu. W nowododanych do struktury JPK_FA(3) polach zaś wykazywane są kwoty podatku w PLN. Wielkość należności z tytułu faktury wykazywana jest w walucie dokumentu. Podczas ustalania ww. wielkości przyjęto zasadę, zgodnie z którą te wielkości, które są wprost zapisywane w bazie Systemu są z niej wprost „przenoszone” do JPK_FA (wartość netto w walucie, VAT w PLN), natomiast wielkości, które w bazie nie są zapisywane (w szczególności VAT w walucie obcej) jest stosownie obliczany na potrzeby JPK. Zachowując zasadę, zgodnie z którą informacje przekazywane w JPK_FA powinny być zgodne z informacjami prezentowanymi w Systemie wartość należności w walucie obcej ustalana jest w identyczny sposób, jak na formatce dokumentu walutowego w Systemie tj.:

Na dokumentach rejestrowanych metodą od brutto : TrN_WartoscWal

Na dokumentach rejestrowanych metodą od netto: suma wartości netto w walucie i kwoty VAT w PLN przeliczonej na walutę dokumentu po kursie z nagłówka dokumentu

Co za tym idzie kwota VAT-u w walucie obcej jest ustalana w oparciu o Vat w PLN i kurs na dokumencie (przeliczenie VAT-u w PLN na VAT w walucie).

Ww. znacznik w pliku JPK_FA(3) ustalany jest na podstawie parametru Podzielona płatność (MPP) na poszczególnych dokumentach. Jeżeli parametr jest włączony, wówczas w polu P_18A wysyłana jest wartość: true, w przeciwnym razie wartość: false.

JPK_FA(3) – Zamówienia

W pliku JPK_FA(3) przekazywana jest informacja o zamówieniach, z których zostały wygenerowane faktury zaliczkowe ujęte w danym JPK_FA. W dedykowanym do tego nowym węźle w pliku przekazywana jest informacja o numerze faktury zaliczkowej, wartości brutto zamówienia, z którym jest ona związana oraz informacja o poszczególnych elementach tego zamówienia (nazwa towaru, jednostka miary, ilość, cena netto, wartość netto, kwota podatku VAT oraz stawka VAT). Ww. informacje prezentowane są na zakładce [Zamówienia] formularza JPK_FA(3).

W sekcji Zamówienia prezentowane są nagłówki zamówień, a dla każdego z nich informacja o numerze faktury zaliczkowej, na podstawie której nastąpiła identyfikacja zamówienia, wartość brutto zamówienia w walucie faktury zaliczkowej oraz numer zamówienia. Numer ten nie jest co prawda wysyłany w pliku JPK_FA, ale prezentowany jest tutaj celem łatwiejszej identyfikacji zamówienia przez Użytkownika. W sekcji Wiersze zamówień prezentowane są elementy zamówienia, na które wskazuje ustawienie kursora w sekcji Zamówienia. Wartość brutto zamówienia oraz cena, wartość oraz kwota VAT elementów zamówienia wykazywane są w walucie, w jakiej zarejestrowano fakturę zaliczkową. W przypadku Systemu Comarch ERP XL oznacza to, że zamówienia związane z fakturami zaliczkowych FSL są wykazywane w PLN, natomiast zamówienia związane z fakturami zaliczkowymi FEL w walucie danego FEL. Sumy kontrolne dla ww. zamówień, obejmujące łączną ilość i wartość wykazanych jw. zamówień prezentowane są na zakładce [Sumy cltr] formularza. Z zakładki tej usunięta została cała sekcja Stawki podatku, która nie jest już wysyłana w JPK_FA.

Ujmowanie transakcji WSTO_EE w JPK_FA(4)

Obsługa nowej struktury JPK_FA(4), obowiązującej od 1 kwietnia 2022 roku została udostępniona w wersji 2022.0.2 Systemu. Główną zmianą w zakresie nowej struktury było ujęcie w niej transakcji rejestrowanych w ramach procedur szczególnych OSS (One Stop Shop) oraz IOSS (Import One Stop Shop).

Przed wersją 2022.1 System Comarch ERP XL nie obsługiwał transakcji  WSTO_EE ani też procedury OSS, stąd dla tych Użytkowników, którzy obsługiwali ww. transakcje we własnym zakresie umożliwiono ich ujmowanie w JPK_FA(4) poprzez oznaczenie takich faktur stosownymi atrybutami przypisywanymi do nagłówka dokumentu:

Przypisanie do dokumentu zarówno atrybutu JPK_P_13_5, jak i JPK_P_14_5 i ustalenie ich wartości na <TAK> oznaczało, że dokument należy w JPK_FA(4) potraktować jako transakcję WSTO w procedurze OSS, przypisanie wyłącznie atrybutu JPK_P_13_5 <TAK> zaś oznaczało transakcję WSTO ale bez procedury OSS.

W wersji 2022.1 ww. zasady zostały wzbogacone o obsłużone w tej wersji: transakcję WSTO_EE i procedurę OSS.

Transakcje WSTO_EE w procedurze OSS ujmowane są w JPK_FA(4) w sposób j.n.

Gdzie DOPTK oznacza dostawę opodatkowaną poza terytorium kraju.

Przez ww. transakcje rozumiane są zarówno dokumenty z transakcją WSTO_EE i włączonym parametrem Procedura OSS (dokumenty rejestrowane w wersji 2022.1) jak i dokumenty oznaczone atrybutami JPK_P_13_5 i JPK_P_13_5 (dokumenty rejestrowane przed wersją 2022.1).

Transakcje oznaczone jako WSTO, a nie podlegające procedurze OSS ujmowane są w JPK_FA(4) w sposób j.n.

Przez ww. transakcje rozumiane są zarówno dokumenty z transakcją WSTO_EE i wyłączonym parametrem Procedura OSS (dokumenty rejestrowane w wersji 2022.1) jak i dokumenty oznaczone atrybutem JPK_P_13_5 a nie oznaczone atrybutem JPK_P_13_5 (dokumenty rejestrowane przed wersją 2022.1).

Omówione wyżej zasady ujmowania transakcji WSTO_EE w JPK_FA(4) dotyczą zarówno faktur sprzedaży jak i faktur zaliczkowych. Takie faktury zaliczkowej ujmowane są w JPK_FA(4) wg wyżej opisanych zasad, z tym, że dla tego typu dokumentów jako elementy wykazywane są elementy zamówień, do których zarejestrowano fakturę zaliczkową. Dla elementów zamówień związanych z FSL/FEL z transakcją WSTO_EE stawka VAT prezentowana/wysyłana jest wg poniższych zasad:

Uwaga

Obsługa wprowadzonej w wersji 2022.1 transakcji WSTO_EE przewidziana jest wyłącznie dla faktury zaliczkowej FEL, tak więc dokument FSL może zostać ujęty jw. wyłącznie jeżeli Użytkownik oznaczył go w wersjach wcześniejszych ww. atrybutami.

Rozpoczęcie pracy w module: Księgowość systemu Comarch ERP XL w trakcie roku

Wdrożenie programu księgowego w trakcie roku musi być przeprowadzone ostrożnie ze względu na specyfikę rozrachunków i rozliczeń w systemie.

Powiązania pomiędzy płatnościami i rozrachunkami są bardzo istotne dla prawidłowości pracy z programem. Nie ma problemu z wprowadzeniem stanu początkowego na kontach zwykłych natomiast dla kont rozrachunkowych należy wydzielić kwoty związane z rozrachunkami rozliczonymi na dzień rozpoczęcia pracy w programie oraz z rozrachunkami nierozliczonymi na dzień rozpoczęcia pracy w programie.

Wprowadzenie stanów początkowych kont zwykłych

Wprowadzenie stanów początkowych na kontach zwykłych musi zostać podzielony na dwie części: na faktyczny BO na dzień 01/01 roku obrotowego oraz obroty za okres od 01/01 do dnia poprzedzającego dzień rozpoczęcia pracy w programie, czyli np. na dzień 31/03, jeżeli start w programie ma nastąpić od dnia 01/04

Faktyczny Bilans Otwarcia na dzień 1 stycznia roku obrotowego

Bilans otwarcia wprowadza się dokumentem BO z poziomu menu: Księgowość, Bilans Otwarcia. Jest to ręczny dokument BO, w którym rejestrowane są salda kont zwykłych.

Dokumentów Bilansu Otwarcia może być kilka, np. BO dla kont zwykłych i BO dla kont rozrachunkowych.

Obroty za okres na kontach zwykłych

Druga część stanu początkowego kont zwykłych, na dzień rozpoczęcia pracy w programie, np. na dzień 1 kwietnia, dotyczy obrotów za okres od początku roku, czyli od 01/01 bieżącego roku do dnia poprzedzającego dzień rozpoczęcia pracy w systemie, czyli w opisywanym przypadku 31/03 bieżącego roku. Obroty mogą zostać wprowadzone zapisami księgowymi na konto księgowe bezpośrednio w dziennikach księgowań.

Przy księgowaniu obrotów za dany okres za pomocą dokumentu PK, wymagane jest zawsze podanie kont przeciwstawnych. Dlatego należy wprowadzić konto techniczne, najlepiej wynikowe, dla zbilansowania PK i zatwierdzenia dokumentu. Konto będzie istnieć tylko w tym okresie, w którym rozpoczynamy pracę w systemie, więc po przeniesieniu planu kont do następnego okresu należy je wykasować, a status konta „wynikowe” uniemożliwi przeniesienie BO.

Wprowadzenie stanów początkowych kont rozrachunkowych

Wprowadzanie stanów kont rozrachunkowych jest nieco bardziej skomplikowane i wymaga nie tylko wprowadzenia stanu faktycznego BO i obrotów za okres, ale także wydzielenia płatności rozliczonych i nierozliczonych, dlatego powinno się odbywać etapami wymienionymi poniżej.

Faktyczny Bilans Otwarcia na dzień 1 stycznia roku obrotowego

Bilans Otwarcia na dzień 1 stycznia roku obrotowego powinien zostać podzielony na dwie części. Kwotę wynikającą z płatności nierozliczonych do dnia rozpoczęcia pracy w systemie, czyli do 31/03 oraz kwotę salda BO, wynikającą z płatności rozliczonych do dnia 31/03. Rozbicie kwot jest wskazane ze względu na strukturę i powiązanie pomiędzy płatnościami (rozliczeniami) a dekretami (rozrachunkami). W przypadku kwot nierozliczonych konieczne jest odtworzenie płatności, natomiast dla rozrachunków rozliczonych nie jest wymagane odtwarzanie płatności.

Wprowadzanie BO dla pozycji rozliczonych

Wartość salda z BO wynikającą z dokumentów rozliczonych na dzień poprzedzający rozpoczęcie pracy w systemie, czyli na 31/03, mogłaby zostać wprowadzona zbiorczą kwotą, na koncie każdego kontrahenta a płatność zaznaczona jako “nie rozliczaj”. Tym samym ta część nie podlegałaby rozliczeniom, nie byłaby widoczna na żadnej liście płatności i nie trzeba byłoby odtwarzać zapłat.

Wprowadzenie BO dla pozycji nierozliczonych

Część BO, która wynika z dokumentów nierozliczonych na dzień poprzedzający rozpoczęcie pracy w systemie, czyli np. na 31/03, musi zostać wprowadzona kwotami, które generują płatność i będą podlegały rozliczeniom w trakcie pracy z systemem.

Stan obrotów między Bilansem Otwarcia a dniem rozpoczęcia pracy w systemie

Obroty za okres od 01/01 do dnia rozpoczęcia pracy z programem, czyli, np.01/04 na kontach rozrachunkowych również muszą być podzielone na dwie części, na część rozliczoną, która rozrachunkom już nie będzie podlegać oraz część nierozliczoną, która będzie rozliczana.

Obroty wynikające z dokumentów rozliczonych

Tego typu obroty na kontach rozrachunkowych mogą być wprowadzone jako zapisy księgowe bezpośrednio w dziennikach, ponieważ nie będą one tworzyć rozliczeń.

Przy księgowaniu obrotów za dany okres, wymagane jest zawsze podanie kont przeciwstawnych, celem bilansowania się PK. Dlatego należy wprowadzić konto techniczne, najlepiej wynikowe, dla zbilansowania PK i zatwierdzenia dokumentu. Konto będzie istnieć tylko w tym okresie, w którym rozpoczynamy pracę w systemie, więc po przeniesieniu planu kont do następnego okresu należy je wykasować, a status konta „wynikowe” uniemożliwi przeniesienie BO.

Obroty wynikające z dokumentów nierozliczonych

To jest część kwoty wynikająca z dokumentów, które zostały wystawione, zaksięgowane i nierozliczone w okresie od 1 stycznia do 1 kwietnia. Tego typu obroty trzeba wprowadzić jako faktury a’vista zakupu w rejestrze vat zakupu (dla zobowiązań) lub sprzedaży (dla należności) oraz zaksięgować na odpowiednie konta rozrachunkowe. Dokumenty utworzą płatności, które pozwolą na przeprowadzenie pełnego rozrachunku na koncie. Obroty wynikające z nierozliczonych dokumentów można również wprowadzić używając dokumentu UNM (uproszczona nota memoriałowa).

Takie dzielenie rozrachunków jest konieczne z dwóch powodów:

Na kontach rozrachunkowych, kwoty wynikające ze stanów obrotów rozliczonych do okresu rozpoczęcia pracy w systemie będą pozostawać jako nierozrachowane.

Umożliwi to dokonanie rozrachunku, zarówno części BO wprowadzonego dla kwot rozliczonych, jak również obrotów za okres od 01/01 do dnia rozpoczęcia pracy w systemie dla części rozliczonej.

Zestawienie obrotów i sald

Zestawienie obrotów i sald będzie prawidłowo sporządzone w przypadku, kiedy stan bilansu otwarcia będzie wprowadzony dokumentem Bilans Otwarcia, a stany obrotów za okres od 01/01 do dnia poprzedzającego rozpoczęcie pracy w systemie będą wprowadzone zapisami księgowymi. Zapewni to prawidłową prezentację bilansu otwarcia strony Wn i Ma oraz prawidłową prezentację obrotów narastająco strony Wn i Ma.

Rozwiązanie to wymaga dosyć szczegółowego ustalenia struktury rozrachunków na kontach księgowych, oraz wyliczenia poszczególnych sum rozrachunków, które należy wprowadzić. Jest to jednak rozwiązanie stosowane w firmach rozpoczynających pracę w systemie Comarch ERP XL w trakcie roku.

 

Częściowa likwidacja środka trwałego

Częściowa likwidacja środka trwałego to inaczej zmniejszenie jego wartości. W celu przeprowadzenia częściowej likwidacji środka trwałego należy wystawić dla tego środka dokument MW (modyfikacja wartości) na kwotę, o którą ma ulec zmniejszeniu wartość środka trwałego. Na dokumencie odpowiednią kwotę należy wpisać ze znakiem minus. Na dokumencie MW należy wyprowadzić:

Zmniejszenie wartości środka trwałego

Wystawienie dokumentu MW

Dla częściowej likwidacji środka trwałego należy wystawić dla tego środka dokument MW (Modyfikacja Wartości). Wszystkie kwoty na dokumencie powinny być kwotami ujemnymi. Dla środka amortyzowanego dwutorowo, na dokumencie MW (Modyfikacja wartości) aktywne są obie kwoty: Podstawa BIL i Podstawa POD. Przy wystawianiu dokumentu MW dla takiego środka należy podać kwotę bilansową, o jaką ma być zmniejszona wartość inwentarzowa środka. Pozostałe kwoty zostaną automatycznie wyliczone przez system i wpisane we właściwe pola.

Po wystawieniu dla środka trwałego amortyzowanego dwutorowo dokumentu MW zmniejszającego jego wartość, automatycznie zostaną zaktualizowane kwoty i środek trwały będzie można dalej amortyzować generując prawidłowe dokumenty AM.

Korzyści wynikające z wykorzystania funkcjonalności Księgowania wsadowego

Księgowanie wsadowe zostało zaimplementowane, w celu poprawy ergonomii pracy oraz zwiększenia wydajności systemu Comarch ERP XL. Dzięki wprowadzeniu tej funkcjonalności, Użytkownicy uzyskali narzędzie umożliwiające automatyzację procesu księgowania. Przede wszystkim możliwe będzie księgowanie poza godzinami pracy z programem, w wyniku czego minimalizujemy obciążenie systemu i zwiększamy jego wydajność. Poza tym uzyskujemy dodatkowy czas na pracę w systemie, który dotychczas należało wykorzystać na czynności związane z księgowaniem.

Wykorzystanie funkcjonalności Procesy w ramach definiowania i parametryzowania funkcjonalności Księgowanie wsadowe

Księgowanie wsadowe wykorzystuje zaimplementowaną funkcjonalność modelowania procesów. Przy definiowaniu procesu księgowania wsadowego obowiązują reguły opisane w biuletynie: Definiowanie i obsługa procesów.

Nowością i cechą właściwą przy konstruowaniu procesu dla księgowania wsadowego w systemie są predefiniowane akcje kluczowe: Uruchomienie księgowania, Uruchomienie księgowania domyślnie, Księgowanie, Predekretacja.

Konsekwencje wyboru akcji kluczowych

Do zadania predefiniowanego START o nazwie: Status początkowy procesu, należy podpiąć akcję kluczową: Uruchomienie księgowania lub Uruchomienie księgowania domyślnie.

Rodzaj zdefiniowanej akcji kluczowej: Uruchomienie księgowania oraz Uruchomienie księgowania domyślnie będzie istotny w momencie rozpoczęcia księgowania wsadowego.

Księgowanie wsadowe, Użytkownik może uruchomić tylko i wyłącznie używając przycisku: , dostępnego na dokumencie, lub liście dokumentów.

Uruchomienie księgowania – Jeżeli w trakcie definiowania procesu księgowania wsadowego, jako akcję kluczową startującą cały proces wybierzemy: Uruchomienie księgowania, to po naciśnięciu przycisku: , w oknie: Księgowanie dokumentów handlowych, w części: Sposób księgowania należy wybrać opcję: Księguj za pomocą procesu. Dzięki temu odszarzony zostanie przycisk: Proces. Po jego uruchomieniu wyświetli się lista dostępnych procesów ze zdefiniowaną akcją startową Uruchomienie księgowania. Z listy dostępnych procesów księgowania wsadowego należy wybrać właściwy dla typu dokumentów i rozpocząć przyciskiem: , proces księgowania wsadowego.

Uruchomienie księgowania domyślnie – Jeżeli w trakcie definiowania procesu księgowania wsadowego, jako akcję kluczową startującą cały proces wybierzemy Uruchomienie księgowania domyślnie, to po wyborze książeczki, w oknie: Księgowanie dokumentów handlowych, w części Sposób księgowania, należy wybrać opcję: Księguj za pomocą domyślnego procesu. Kolejnym krokiem powinno być rozpoczęcie procesu księgowania wsadowego – po naciśnięciu przycisku: .

Bardzo istotną sprawą jest poprawne zdefiniowanie opiekuna czynności, która wykorzystuje akcje kluczowe: Uruchom księgowanie i Uruchom księgowanie domyślnie. Wymagane jest podanie opiekuna, który znajduje się w strukturze firmy. Związane jest to z koniecznością wydania polecenia rozpoczęcia księgowania przez konkretnego Użytkownika systemu.

Dla pozostałych akcji kluczowych wykorzystywanych na etapie budowy procesu księgowania wsadowego, zgodnie z ideą automatyzacji procesu księgowania, powinno się wybierać opiekuna automatycznego.

Konsekwencje definicji zadania startującego proces księgowania wsadowego dla działania czynności księgowania wsadowego

Funkcjonalność: Księgowanie wsadowe, współpracuje z XL Work Automat (więcej informacji w biuletynie: Definiowanie i obsługa procesów oraz w Dokumentacji Użytkownika), który jest odpowiedzialny za wykonanie automatycznego księgowania zgodnie z definicją, którą wprowadził Użytkownik, na zakładce: Ogólne, okna: Definicje zadania procesu.

Proces księgowania wsadowego wybranej grupy dokumentów uruchamiamy przyciskiem: i startujemy poprzez naciśnięcie przycisku: , z poziomu okna: Księgowanie dokumentów handlowych. Czynność ta powinna zostać poprzedzona wybraniem schematu księgowania dla dokumentu lub grupy dokumentów, dziennika oraz sposobu, w jaki ma być uruchomiony proces księgowania.

Konfiguracja Definicji zadania procesu w polach: Termin realizacji, Data realizacji, Czas realizacji zachowuje się zgodnie z opisem w biuletynie: Definiowanie i obsługa procesów oraz w Dokumentacji Użytkownika do modułu: Administrator. Jest to niezwykle ważne okno z punktu widzenia zarządzania czynnością związaną z księgowaniem dokumentu lub grupy dokumentów. Data realizacji zadania księgowania wsadowego jest liczona od momentu przypięcia procesu księgowania wsadowego i wyświetlana zgodnie z funkcją: data systemowa + data realizacji. Taką wartość daty otrzymamy w kolumnie: Data realizacji z poziomu Skrzynki Automatu XL.

Z datą otrzymaną w sposób opisany powyżej będą realizowane poszczególne akcje kluczowe, przy założeniu ciągłej pracy XL Work Automat.

Księgowanie automatyczne

Na definicji dokumentu jest możliwość wyboru domyślnego schematu i dziennika księgowań w ramach opcji „księgowanie automatyczne”.

Parametry “księgowania automatycznego” mają zastosowanie w stosunku do dokumentów, których księgowanie jest obsługiwane przez proces. Chodzi więc o taką sytuację, kiedy księgowanie wsadowe stanowi etap innego procesu.

Dzięki tym ustawieniom możliwa jest pełna automatyzacja procesu, wraz z księgowaniem dokumentu, ponieważ schemat księgowy i dziennik wybrany jest już na definicji dokumentu.

Dostępne możliwości konfiguracji kluczy podziałowych

Klucze podziałowe to listy współczynników. Z definicji sumują się do 100%. Dzięki kluczom można podzielić każdą kwotę na części proporcjonalnie do wartości poszczególnych współczynników wchodzących w skład klucza. Istnieje możliwość wykorzystania kluczy w księgowaniach okresowych (KO). Dzięki temu można rozliczać produkcję za pomocą KO.

System Comarch ERP XL umożliwia definiowanie nieskończonej liczby odrębnych kluczy podziałowych dostosowanych do charakteru działalności danego podmiotu gospodarczego. Użytkownik, w oknie klucz podziałowy,  ma możliwość konfiguracji odpowiedniego klucza podziałowego poprzez:

Należy dodać, iż przy próbie dodawania nowego Klucza podziałowego domyślnie proponowana jest opcja kreowania klucza w oparciu o zapytanie SQL. Elementy jak i zapytanie SQL są wzajemnie wykluczającymi się możliwościami definiowania. Wybór typu definiowania klucza wykonuje się z poziomu zakładki: Ogólne.

Definiowanie klucza w oparciu o stałe elementy

Do zasadniczych elementów klucza podziałowego zaliczamy:

Jeżeli na zakładce: Ogólne zostanie wybrana typ: Elementy, zakładka: SQL, zostanie wyszarzona. Na zakładce: Elementy, będzie dostępna lista elementów klucza z możliwością dodawania/kasowania/edycji każdego z elementów. Metoda stałych współczynników zakłada wprowadzenie na sztywno wartości współczynników. Może być wykorzystywana w przypadku gdy współczynniki są z góry ustalone, (przykładowo w przedsiębiorstwach w których koszty wydziałowe rozbijane są według stałych wartości procentowych) lub przyjęte na podstawie danych z poprzednich okresów. Wykorzystanie wymiarów Konto oraz Nazwa dodatkowa zostanie opisane przy omawianiu wykorzystania kluczy podziałowych w KO.

Uwaga

Współczynniki klucza nie są definiowane jako procenty, lecz jako dowolne liczby. Wartość współczynnika będzie ilorazem liczby wprowadzonej w polu współczynnik i sumy wszystkich wartości. Na przykład przy wprowadzeniu: 25, 35, 40, to wartości poszczególnych współczynników będą równe odpowiednio: 25/100, 35/100 i 40/100.

Przyklad

W systemie zdefiniowano klucz podziałowy z trzema elementami:

Każdy z elementów zawiera trzy kolumny: Współczynnik, Konto i Nazwę dodatkową.

Klucz został przypisany do księgowania okresowego. Przypisanie klucza do pozycji KO można wykonać poprzez naciśniecie przycisku: Klucz podziałowy, który znajduje się na formatce: Pozycja księgowanie okresowego. Pozostawienie pustego pola oznacza niewykorzystanie klucza w KO.

W księgowaniu okresowym do którego przypisano klucz podziałowy, do tych wartości możemy się odwoływać przez zmienne:

• WartośćKlucza – odwołuje się do danych z kolumny Współczynnik
• KontoKlucza – odwołuje się do danych z kolumny Konto
• NazwaKlucza– odwołuje się do danych z kolumny  Nazwa dodatkowa

Wygenerowany na podstawie powyżej zdefiniowanego księgowania okresowego dekret wygląda następująco:

• Współczynnik znormalizowany klucza – jest obliczany na podstawie pierwszej kolumny klucza podziałowego. Jest to wartość wiersza podzielona przez sumę całej pierwszej kolumny.

Elementy klucza podziałowego

Dla powyższego klucza podziałowego wartości poszczególnych współczynników wynoszą:

20/(20+30+50)=2/10
30/(20+30+50)=3/10
50/(20+30+50)=5/10

Jeżeli przeksięgowujemy wartość 1000 i pomnożymy ją przez współczynnik znormalizowany klucza (zmienną *Klucz) to otrzymamy na dekrecie wartości 200, 300,500.

Definiowanie klucza w oparciu o zapytanie SQL

Z poziomu zakładki SQL możliwe jest definiowanie klucza za pomocą odpowiedniego zapytania SQL, dostosowanego do planu kont i charakteru działalności poszczególnych przedsiębiorstw. Zapytanie powinno zwracać minimum jedną, maksimum trzy kolumny. Pierwsza z nich będzie określała wartość klucza, tym samym musi być numeryczna ( jest to odpowiednik kolumny Współczynnik). Druga i trzecia kolumna to symbole pozycji (Konto oraz Nazwa dodatkowa). SELECT powinien zapewnić, aby były one unikalne. Jeżeli SELECT zwróci tylko pierwszą kolumnę (współczynnik), symbole w kolumnie drugiej(Konto)  zostaną nadane automatycznie (np. 1,2,3…), w wyniku czego kolumna ta będzie zawsze niepusta. Natomiast trzecia kolumna (Nazwa), jeżeli nie zostanie zdefiniowana, pozostanie pusta. Dwie kolumny z symbolami mogą być wykorzystywane np. do określania konta i nazwy wymiaru.

Istnieje możliwość wprowadzenia odpowiednich parametrów, które będą determinowały SELECTA wprowadzonego na zakładce: SQL. Jest to dość wygodna funkcjonalność, gdyż umożliwia zmianę pewnych ograniczeń zapytania SQL bez zasadniczej jego przebudowy.

Zdefiniowana lista parametrów umożliwia uzależnienie wartości współczynników od np. daty, wydziału czy numeru zlecenia. Prawidłowe obliczenie poszczególnych współczynników klucza będzie wymagało podania wartości wszystkich parametrów wykorzystanych w zapytaniu SQL. Aby współczynniki były rzeczywiście zależne od wartości parametrów, zapytanie definiujące klucz powinno je wykorzystać.   Parametry można wprowadzić z poziomu zakładki: Parametry, jednak ich całkowite obliczenie za pomocą odpowiedniego wyrażenia realizowane jest z poziomu księgowania okresowego.

Uwaga

Współczynniki klucza nie będą definiowane jako procenty, lecz jako dowolne liczby. Wartość poszczególnego współczynnika znormalizowanego klucza będzie ilorazem liczby zwracanej przez SELECT i sumy wszystkich wartości. Na przykład jeżeli klucz podziałowy zwróci wartości: 10, 12, 3 w pierwszej kolumnie, to wartości poszczególnych współczynników będą równe odpowiednio: 10/25, 12/25 i 3/25.

Przy wprowadzaniu zapytania SQL należy pamiętać aby na początku SELECTA dodać „set nocount on” i zakończyć go „set nocount off”.

Przyklad

Zdefiniowano klucz podziałowy wykorzystując zapytanie SQL w którym użyte są dwa parametry @rok oraz @miesiac. Parametry te będą wyliczane dynamicznie w zależności od tego w którym miesiącu i roku będzie wykonywane księgowanie okresowe. Te dane możemy odczytać na podstawie daty generacji księgowania okresowego czyli pola ksn_datanast.

Pozycja księgowania okresowego wygląda analogicznie jak w przypadku klucza podziałowego zbudowanego w oparciu o elementy.

Przypisanie klucza do pozycji KO można wykonać poprzez naciśniecie przycisku: Klucz podziałowy, który znajduje się na formatce: Pozycja księgowanie okresowego. Pozostawienie pustego pola oznacza niewykorzystanie klucza w KO.

W chwili wyboru klucza zakładka: Parametry klucza zostanie odszarzona. Na zakładce tej znajduje się lista zawierająca ich nazwy i wyrażenia niezbędne do ich obliczenia, które należy właśnie w tym miejscu dodać. Nazwy parametrów są kopiowane z definicji klucza i nie ma możliwości ich dodania z poziomu zakładki: Parametry klucza, natomiast są one istotne przy wykorzystywaniu kluczy zdefiniowanych przy użyciu zapytania SQL.

Jeżeli SELECT zwracający współczynniki klucza wykorzystuje parametry, w chwili jego obliczania nazwy ich będą podmieniane na odpowiednie wartości, wygenerowane przez wyrażenia definiujące poszczególne Parametry. Zmiana klucza przypisanego do elementu KO powoduje skasowanie listy parametrów poprzedniego klucza i zastąpienie jej nową listą z niezdefiniowanymi wartościami Parametrów.

Poszczególna pozycja KO generuje jeden zapis księgowy (pozycje zapisu zbiorczego jeżeli jest kilka elementów KO). W przypadku podpięcia klucza podziałowego, zostanie wygenerowane tyle zapisów ile współczynników ma klucz (dokładnie tyle – ile pozycji liczbowych zwróci zapytanie SQL w pierwszej kolumnie SELECT. Może być to także ilość na sztywno wprowadzonych współczynników w definicji klucza).

Wykorzystanie kluczy podziałowych w księgowaniu okresowym

Przeksięgowanie w oparciu o klucz podziałowy dla danego konta

Pierwszym krokiem w konfiguracji KO z wykorzystaniem wcześniej zdefiniowanego klucza jest określenie kwoty, która zostanie rozksięgowana. Można to wykonać wprowadzając w polu: Kwota wyrażenie obliczające wymaganą wartość(przykładowo saldo DT konta (SDT(’580-01’)). Następnie należy użyć zmiennej: Klucz – która oznacza bieżącą wartość współczynnika klucza –  wpisując bezpośrednio *klucz lub klikając w przycisk: Wyrażenie i wybierając Współczynnik znormalizowany klucza. Konta, na które zostanie wykonane rozksięgowanie odpowiedniej kwoty mogą być wprowadzone ręcznie, a także mogą być założone w trakcie generacji KO. System umożliwia zakładanie kont z wykorzystaniem zmiennych: KontoKlucza oraz NazwaKlucza, które są ściśle powiązane z elementami definicji klucza.

Reasumując w wyniku wygenerowania KO nastąpi przeksięgowanie salda DT konta 580-01 w oparciu o odpowiednie współczynniki klucza na nowo założone konta 580-… (‘580-‘&KontoKlucza).

Uwaga

Dla kluczy podziałowych skonfigurowanych w oparciu o zapytanie SQL KontoKlucza to wartości zwrócone przez SELECT w drugiej kolumnie, natomiast  NazwaKlucza to wartości odpowiadające kolumnie trzeciej.

Dla kluczy podziałowych skonfigurowanych w oparciu o sztywne elementy KontoKlucza to wartość w polu: Konto na zakładce: Elementy klucza podziałowego , natomiast  NazwaKlucza to wartości odpowiadające polu: Nazwa dodatkowa.

Wobec powyższego w przypadku wykorzystania zmiennych do zakładania kont należy pamiętać, aby odpowiednie kolumny zwrócone przez SELECT były niepuste, oraz odpowiednie pola na zakładce Elementy klucza podziałowego były wypełnione.

Przeksięgowanie w oparciu o klucz podziałowy dla kilku kont

W polu: Oblicz dla, istnieje możliwość wprowadzenia odpowiedniego warunku, który rozszerzy zakres KO na konta spełniające go. W wyniku takiej operacji, czyli wypełnienia pola Oblicz dla i Klucz podziałowy, zostanie wygenerowanych tyle zapisów, ile współczynników posiada dany klucz pomnożone przez ilość kont spełniających warunek Oblicz dla. Reasumując dla KO  nastąpi przeksięgowanie sald DT kont spełniających warunek, czyli sald kont 401,402,403….itd. w oparciu o odpowiednie współczynniki klucza na nowo założone konta 580-…(580-NazwaKlucza).

Przyklad

Zdefiniowano klucz podziałowy wykorzystując zapytanie SQL. Podstawą do obliczenia współczynników klucza podziałowego stanowi SELECT:

set nocount on

declare @zasoby table

(Typ smallint, Numer int, Produkt int, Czynnosc int, Zasob int, Czas int)

insert into @zasoby

select PZA_TwrTyp, PZA_TwrNumer, PZA_Id, PCZ_Id, PZA_Id, PCZ_CzasRozliczeniowy from CDN.ProdZasoby

inner join CDN.TraSElem on TrS_ZlcTyp=14346 and TrS_ZlcNumer=PZA_Id

inner join CDN.TraNag on TrN_GIDNumer=TrS_GIDNumer

and TrN_Data2 between @DataOd and @DataDo

inner join CDN.ProdCzynnosci on PCZ_Id=PZA_Czynnosc

where PZA_TypZasobu=0

while 1=1

begin

insert into @zasoby

select Typ, Numer, Produkt, PCZ_Id, P.PZA_Id, PCZ_CzasRozliczeniowy

from @zasoby

inner join CDN.ProdZasoby S

on S.PZA_Czynnosc=Czynnosc and S.PZA_TypZasobu=1

inner join CDN.ProdZasoby P

on P.PZA_Id=S.PZA_Zasob

inner join CDN.ProdCzynnosci

on PCZ_Id=P.PZA_Czynnosc

where not exists(select * from @zasoby where Zasob=P.PZA_Id)

if @@rowcount=0 break

end

select  sum(Czas)*1.0, Twr_Konto1, Twr_Kod

from @zasoby

inner join CDN.TwrKarty on Twr_GIDTyp=Typ and Twr_GIDNumer=Numer

group by Typ, Numer, Twr_Kod, Twr_Konto1

having sum(czas) > 0

set nocount off

Powyższy SELECT zwraca sumę czasów wszystkich czynności zrealizowanych do wyprodukowania poszczególnych produktów, które zostały przyjęte na magazyn dokumentem PW, wystawionym w terminie określonym parametrami. Na kluczu wpisano  parametry:

• DataOD
• DataDO

Następnie do KO, którego pozycja przedstawiona jest na poniższym rysunku, podpięto odpowiedni klucz o nazwie Przeks. wg czynności.

W chwili skonfigurowania KO w oparciu o klucz podziałowy Przeks. wg czynności na zakładce: Parametry klucza pojawiły się parametry wprowadzone uprzednio podczas definiowania klucza. Następnie z poziomu tej zakładki wprowadzono odpowiednie wyrażenia, obliczające parametry klucza.

Parametr DataOd obliczony jest jako pierwszy dzień miesiąca, w którym występuje generowanie KO, natomiast parametr DataDo zwraca datę generacji KO. W analizowanym przykładzie datą generacji KO jest 2014-01-31. Wobec tego nastąpi zawężenie obliczeń SELECTA do okresu miedzy 2014-01-01 a 2014-01-31.

Zapytanie SQL zwróci następujące współczynniki klucza:

SELECT zwróci sumę czasu wszystkich zrealizowanych czynności odpowiednio dla towaru MAKA, CIASTO, ZBOZE. W drugiej kolumnie dodatkowo wystąpią konta magazynów podpięte do towarów, o które alternatywnie można oprzeć wyrażenie zakładające konto.

W wyniku wygenerowania KO nastąpi przeksięgowanie salda DT konta 502-431  na nowo założone konta 501-NazwaKlucza-431. Zakładając, iż saldo Dt 502-431 wynosi 1000 wygenerowanie KO spowoduje:

Zaksięgowanie kwoty 1000 po stronie Ct na konto 502-431

Zaksięgowanie kwoty 1000*0,020986 czyli 20,98 po stronie Dt na konto 501-MAKA-431

Zaksięgowanie kwoty 1000*0,630189 czyli 630,19 po stronie Dt na konto 501-CIASTO-431

Zaksięgowanie kwoty 1000*0,348826 czyli 348,83 po stronie Dt na konto 501-ZBOZE-431

Na poniższym rysunku przedstawiono zapis księgowy wygenerowany przez  KO.

Wstęp

Miejscem definiowania formatów przelewów w systemie Comarch ERP XL jest moduł Administrator. System umożliwia tworzenie formatów wymiany danych z bankiem (eksportu danych z listy płatności i importu wyciągów bankowych). Obsługiwane są następujące typy formatów:

Struktura linii, zarówno nagłówka, jak i rekordu, może być zdefiniowana poprzez zbudowanie listy pól, wybranych z predefiniowanej listy. Każdy z predefiniowanych parametrów jest powiązany z określonymi danymi lub funkcjami systemu. Dla każdego formatu można ponadto określić ogólne parametry, takie jak znak separatora linii, format daty itp.

Przy eksporcie i imporcie danych o operacjach bankowych możliwy jest wybór formatu danych.

Istnieje możliwość ustawienia domyślnego formatu exportu/importu dla rejestru bankowego (w momencie importu wyciągu do konkretnego rejestru, będzie się ustawiał domyślnie ten, który zostanie zapisany na karcie banku).

Poniżej miejsce, w którym dokonuje się ustawienia:

Otwierając do edycji kod banku, który przypisany jest do rejestru bankowego, dokonujemy zmian pożądanego formatu importu przelewów oraz eksportu przelewów.

Uwaga

W systemie Comarch ERP XL istnieje również możliwość zdefiniowania wymiany danych z bankami za pomocą usługi sieciowej. Opis tej funkcjonalności znajduje się w odrębnym biuletynie pt. Wymiana danych z bankami za pomocą usługi sieciowej

Lista formatów przelewów

Definiowanie formatów przelewów odbywa się z poziomu listy: Formaty przelewów.

Okno formatów przelewów umożliwia:

 

[Eksport formatu] – eksport formatu (plik xml), zdefiniowanego w oknie: Formaty przelewów, do wskazanego pliku

[Import formatu] – import formatu przelewów (plik xml) ze wskazanej lokalizacji

[Dodaj] – dodanie nowego formatu przelewów

[Zmień] – modyfikację danych istniejącego formatu przelewów

[Usuń] – skasowanie zaznaczonego formatu przelewów z listy

Edycja formatu pliku exportu na przykładzie Elixir zgodnego ze specyfikacją Alior, ING, PKO BP, Pekao SA

Dodanie nowej definicji formatu przelewów odbywa się za pośrednictwem okna: Edycja formatu pliku wymiany danych. Definiowanie składa się z następujących kroków:

Na zakładce: Ogólne, określa się następujące dane:

Nazwa formatu – nazwa formatu przelewu.
Rozszerzenie pliku – rodzaj rozszerzenia pliku.
Oddzielaj pola znakiem – opcję zaznacza się, jeżeli pola mają zostać rozdzielone separatorem.
Separator pól – pole służy wprowadzeniu znaku separatora pól.
Kodowanie – typ kodowania.
Format daty – wskazuje rodzaj formatu daty, czyli kolejność i sposób wpisania dnia, miesiąca, roku.
Znak dziesiętny – decyduje o tym, jaki będzie separator cyfr dziesiętnych.
Separator tysięcy – decyduje o tym, jaki będzie separator cyfr tysięcznych.
Podział pola na wiersze – decyduje o tym, jaki będzie separator podziału pola na wiersze.
Ograniczenie tekstu – służy zdefiniowaniu znaku ograniczającego tekst.
Zamieniaj znaki ograniczenia tekstu w treści na – zdefiniowany w tym polu znak służy zastąpieniu nim znaku ograniczenia tekstu, a tym samym wyeliminowaniu ograniczeń tekstu w treści, np. jeżeli znakiem ograniczającym tekst będzie cudzysłów, a w treści zostanie użyta nazwa ujęta w cudzysłów, wtedy system odczyta cudzysłów w treści, jako znak ograniczający tekst. Aby uniknąć tej sytuacji, należy zdefiniować zamiennik ograniczenia tekstu. Pole: Zamieniaj znaki ograniczenia testu w treści, uaktywni się po wprowadzeniu wartości w polu: Ograniczenie tekstu.
Stała szerokość pól – decyduje o tym, czy szerokość pól będzie stała.

Uwaga

Dla płatności z oznaczeniem MPP, do pliku w polu Tytułem, przekazywany jest tytuł operacji /VAT/…/IDC/../INV/…, tylko dla formatów przelewów z predefiniowaną nazwą formatu np. Elixir-O. Po zmianie nazwy, tytuł w takim formacie nie będzie przekazywany. Dla własnego formatu z nazwą Elixir-O, dla płatności MPP do pola Tytułem będzie też przekazywany tytuł operacji /VAT/…/IDC/../INV/… .

Na zakładce: Nagłówek, definiuje się informacje, jakie będą znajdowały się w nagłówku pliku wymiany. W przypadku formatu Elixir nie ma potrzeby definiowania tego typu wierszy.

Na zakładce: Pozycje, definiuje się pola, jakie znajdą się w pozycji (linii) pliku wymiany danych. Dostępne są tam takie same przyciski, jak na zakładce: Nagłówek. Informacje wyświetlone w kolumnach pochodzą od ustawień zdefiniowanych na zakładce: Ogólne oraz w oknie: Edycja formatu eksportu, za pośrednictwem którego wprowadza się odpowiednie pozycje formatu przelewów.

W oknie znajdują się pola:

Nazwa pola – w polu następuje wybór pozycji z predefiniowanej listy. Pozycja ta będzie stanowiła informację, która znajdzie się w pliku wymiany danych.
W przypadku wybrania Zapytania SQL, należy zwrócić uwagę na wykorzystanie parametrów {filtrSQL}, {Trp_GIDTyp}, {Trp_GIDFirma}, {Trp_GIDNumer}, {Trp_GIDLp} w zapytaniu SQL tworzącym pole formatu przelewu.
W zapytaniu można używać następujących ciągów znaków: {filtrSQL}, {Trp_GIDTyp}, {Trp_GIDFirma}, {Trp_GIDNumer}, {Trp_GIDLp}, które przed wykonaniem zapytania zostaną odpowiednio zastąpione:
W miejsce {filtrSQL} zostanie podstawione wyrażenie: TrP_GIDTyp=x and TrP_GIDNumer=y and TrP_GIDLp=z, gdzie x,y,z to wartości tych pól dla bieżącego (przetwarzanego) rekordu tabeli TraPlat. W miejsce {Trp_GIDTyp}, {Trp_GIDFirma}, {Trp_GIDNumer}, {Trp_GIDLp} zostaną podstawione wartości odpowiednich pól (x,y,z) dla bieżącego rekordu.
Typ pola – typ,w jakim zapisana zostanie pozycja. Możliwe jest zapisanie informacji w formie tekstu lub liczby (całkowitej, z dwoma miejscami po przecinku, z czterema miejscami po przecinku).
Wartość – pole to zostanie uaktywnione, jeśli zostanie wybrana nazwa pola: Stała wartość. W polu definiuje się stałą wartość jak umieszczona zostanie w pliku wymiany.
Szerokość – szerokość pola (w jakiej zostanie umieszczona pozycja).

Opcje pola:

Usuwaj znaki rozdzielające – parametr aktywny jest tylko dla pola typu tekstowego, jego zaznaczenie spowoduje usunięcie znaków rozdzielających z tekstu pola, przykładowo kreski z numeru rachunku.

Uzupełnij znakiem:

Nie uzupełniaj – zaznaczenie spowoduje, że pola będzie postaci jak zdefiniowano powyżej. Jeżeli opcja nie zostanie zaznaczona pola będzie dodatkowo uzupełnione znakiem wskazanym w polu Znak,

Z prawej – znak zostanie dopisany z prawej strony pola.

Z lewej – znak zostanie dopisany z lewej strony.

Na ostatniej zakładce: Stopka, definiuje się ostatnią linię pliku wymiany danych. Dostępne są tam takie same przyciski, jak na zakładce: Nagłówek i zakładce: Pozycje.

Przyklad

Przykład pliku przelewu wygenerowanego za pomocą formatu Elixir BPH:

110,20060131,151890,10601376,0,”18106013768856920012475533″,”37106013769999666633334444″,”PREZENTACJA S.A.||WROCŁAWSKA 44|30-415 KRAKÓW”,”KONTRAHENT S.A.||UL. BIAŁA 22|78-555 WARSZAWA”,0,10601376,”(A)FZ-6/04/KRAK|||”,””,””,”51″,”100000100019″

Pozycje formatu przelewów w definiowanym formacie przelewów odpowiadające poszczególnym liniom w generowanym pliku wymiany danych:

110 – pozycja: Stała wartość, to typ polecenia, 110 to polecenie przelewu oraz płatność do Urzędu Skarbowego,
20060131 – pozycja: Data operacji, to data płatności w formacie RRRRMMDD,
151890 – pozycja: Kwota płatności w groszach, kwota bez kropek tysięcznych i przecinka oddzielającego wartość dziesiętnych,
10601376 – pozycja: Numer kierunkowy banku własnego, to numer rozliczeniowy banku zleceniodawcy (zawsze 8 cyfr),
0 – pozycja: Stała wartość, pole zerowe (zawsze 0),
“18106013768856920012475533” – pozycja: Pełny numer rachunku własnego, numer rachunku zleceniodawcy w formacie NRB,
“37106013769999666633334444” – pozycja: Pełny numer rachunku kontrahenta, pełny numer rachunku kontrahenta wraz z numerem rozliczeniowym,
“PREZENTACJA S.A.||WROCŁAWSKA 44|30-415 KRAKÓW” – pozycje: Nazwa własna 1, Nazwa własna 2, Adres własny – ulica, Adres własny – kod i miasto, to dane zleceniodawcy, poszczególne wiersze są oddzielone od siebie znakiem: ׀
“KONTRAHENT S.A.||UL. BIAŁA 22|78-555 WARSZAWA” – pozycje: Nazwa kontrahenta 1, Nazwa kontrahenta 2, Adres kontrahenta – ulica, Adres kontrahenta – kod i miasto, to dane kontrahenta, poszczególne wiersze są oddzielone od siebie znakiem: ׀
0 – pozycja: Stała wartość, pole zerowe (zawsze 0),
10601376 – pozycja: Numer kierunkowy banku kontrahenta, to numer rozliczeniowy banku kontrahenta (zawsze 8 cyfr),
“(A)FZ-6/04/KRAK|||” – pozycja: Tytułem (numery dokumentów), to szczegóły płatności, cztery linie szczegółów płatności po 35 znaków, poszczególne wiersze są oddzielone od siebie znakiem: ׀
“”,”” – pozycje: Stała wartość, pole puste,
“51” – pozycja: Stała wartość, to klasyfikacja polecenia, 51 dla polecenia przelewu oraz płatności do Urzędu Skarbowego i płatności ZUS,
“1000000100019” – pozycja: Identyfikator operacji, to identyfikator nadawany każdemu poleceniu przelewu. Jeżeli ten sam identyfikator wystąpi w wyciągu bankowym (będzie nim oznaczone obciążenie), to podczas importu tego wyciągu odpowiednie płatności zostaną automatycznie rozliczone.

Istnieje możliwość zaimportowania i wyeksportowania formatu przelewu.

Import przelewów na przykładzie formatu SWIFT MT940

W systemie Comarch ERP XL są dostępne trzy predefiniowane formaty SWIFT MT940 do importu przelewów. Są to:

SWIFT MT940

Predefiniowany format Swift MT940, który dostępny jest w systemie obsługuje wyciągi pochodzące z banków:

BPH
Pekao SA
Alior
Millennium
ING Bank Śląski
Santander
Deutsche Bank (usługa db direct)

Ogólny opis formatu:

Rozmieszczenie informacji w pliku:

:20:data wyciągu
:25:numer rachunku 1
:28C:numer wyciągu
:NS:22 właściciel rachunku
:NS:23 typ rachunku
:60F:saldo początkowe
:61:transakcja 1
:NS:19 godz. księgowania transakcji 1
:86:szczególy transakcji 1
:61:transakcja 2
:NS:19 godz. księgowania transakcji 2
:86:szczególy transakcji 2
:61:transakcja 3
:NS:19 godz. księgowania transakcji 3
:86:szczegoly transakcji 3
:62F:saldo końcowe
:64:saldo dostępne
:86:Informacje dodatkowe

Prezentacja szczegółów operacji w pliku: (POLA :61: I :86:)
Szczegóły pojedynczej transakcji prezentowane są w liniach :61: , :NS:19 oraz :86:
Linia :61: zawiera dane dotyczące daty waluty , daty księgowania, kwoty oraz waluty operacji.
Linia :NS19: godzinę księgowania, natomiast linia :86: prezentuje tytuł operacji, dane kontrahenta oraz zawiera kody operacji.

:61:0203260326DN5312,00NTRF
:NS19:1259
:86:020<00Wyplata-(dysp/przel)<10numer transakcji
<20 linia 1 tytułu operacji
<21 linia 2 tytułu operacji
<22 linia 3 tytułu operacji
<23 linia 4 tytułu operacji
<24 linia 5 tytułu operacji
<25 linia 6 tytułu operacji
<27NAZWA KONTRAHENTA 1
<28NAZWA KONTRAHENTA 2
<29ADRES KONTRAHENTA 1
<30numer rozliczenowy banku kontrahenta<31numer rachunku kontrahenta
<32NAZWA KONTRAHENTA1<33NAZWA KONTRAHENTA 2 do 35 znaków
<38 IBAN lub NRB kontrahenta
<60ADRES KONTRAHENTA 2
<61ID TRANSAKCJI W FK KLIENTA do 35 zn.
<62ID KONTRAHENTA W FK KLIENTA do 35 zn.
<63REF5898327000090031789

Format SWIFT MT940 w systemie Comarch ERP XL jest obsługiwany jako predefiniowany.

Przyklad

Przykład pliku przelewu importowanego przez Comarch ERP XL przy pomocy formatu MT940:

:20:1602359
:25:PL72106000760000320000546101
:28C:237
:NS:22Zakady Wytwórcze Kineskopów
:60F:C200825PLN0,00
:61:0308250825CN142680,00NTRFNONREF//8327000090031789
Przelew przychodzący wewnętrzny
:NS:191259
:86:051<00Wpata na rach.<101000000001
<20F-RA 4762/2003 ZAPłATA ZA
<21DOSTAW¨ KINESKOPW
<22LIPIEC 2003
<27BLACKTRONIX FABRYKA TELEWIZOROW
<29GLOGOWSKA 248
<3010600076<310000320000584734
<32BLACKTRONIX FABRYKA TELEWIZ<33ORŕW
<3822106000760000320000584734
<6060-010 POZNAN
<63REF5983270000900317897
:61:2008250825CN20000,00NTRFSENDERS REF//8327000090031790
Przelew przychodzacy wewnetrzny
:NS:191307
:86:051<00Wpata na rach.<101000000002
<20FAKTURA 7/2020
<21DOSTAWA KINESKOPŕW
<22BLACK 17′ 25 SZT.
<23BLACK 21′ 30 SZT
<27MATRIX WYTWORNIA SPRZ¨TU TV I AGD
<29PULAWSKA 65
<3010600076<310000300000374405
<32MATRIX WYTWORNIA SPRZ¨TU TV<33 I AGD
<3867106000760000300000374405
<6000-950 WARSZAWA
<63REF598327000090031790
:61:2008250825DN8566,27NTRFREFERENCJE//8327000090031791
Przelew wychodzacy zewnetrzny
:NS:191312
:86:020<00Wyplata-(dysp/przel)<101000000003
<20FRA 7611/2003 TERMIN 030826
<21ZA REMONT ZAKLADOWYCH
<22POMIESZCZEă MAGAZYNOWYCH
<27USLUGI REMONTOWE SP. Z O.O.
<28JAN KOWALSKI
<29STR¤KOWA 3A
<3010501445<311000002252037854
<32USLUGI REMONTOWE SP. Z O.O.<33
<3802105014451000002252037854
<6031-345 KRAKOW
<61TRANS65348259
<62USLREMONT
<63REF598327000090031791
:61:2008250825DN19587,57NTRFREFERENCJE //8327000090031792
Przelew wychodzacy wewnetrzny
:NS:191312
:86:020<00Wyplata-(dysp/przel)<101000000004
<20FRA 324-2342-234/2003
<21ZA PREFABRYKATY DO TUB
<22PRŕ˝NIOWYCH
<27HUTA SZKLA TOPIK
<29PRZEMYSťOWA 67
<30110600076<310000320000119499
<32HUTA SZKLA TOPIK<33
<3861106000760000320000119499
<6050-505 WROCLAW
<61TRANS65348260
<62HUTASZKLA
<63REF598327000090031792
:62F:C200825PLN134526,16
:64:C200825PLN134526,16

Podczas importu zapisów bankowych do systemu Comarch ERP XL istnieje możliwość identyfikacji pracownika po jego wszystkich rachunkach bankowych, a kontrahenta także po tak zwanym wirtualnym numerze rachunku.

SWIFT MT940 BGŻ

Przyklad

Przykład pliku przelewu importowanego przez Comarch ERP XL przy pomocy formatu SWIFT MT940 BGŻ:

{1:SenderBankHeader}{2:ReceiverBankHeader}{4:
:20:MT940
:25:65000000000000000000000000
:28C:99
:60F:D090713PLN9235,71
:61:0907130713D178,19NOTREF
:86:?1???????PRZELEW WEWNĘTRZNY Z RACHUNKU NUMER 23 0000 0000 0000 0000 0000 0000?NOWAK JAN?AL. TESTOWA 5A M 28 00-000 WARSZAWA?za rachunek nr 1/2009
:61:0907130713D60NOTREF
:86:?2???????PRZELEW WEWNĘTRZNY Z RACHUNKU NUMER 60 0000 0000 0000 0000 0000 0000?TESTOWA HELENA MIECZYSŁAWA?TESTOWANA 46 M 6 11-111 RZESZÓW?oplata za fakture
:62F:D090713PLN9473,9
:64:D090714PLN9472,9
:86:6792956?65000000000000000000000000?R?090713?090713??0?Z?5?090713?0??0?1???
-}
{1:SenderBankHeader}{2:ReceiverBankHeader}{4:
:20:MT940
:25:65000000000000000000000000
:28C:100
:60F:D090714PLN9473,9
:61:0907140714D-2500NOTREF
:86:?1???????PRZELEW WEWNĘTRZNY NA RACHUNEK NUMER 03 0000 0000 0000 0000 0000 0000?ZAKŁAD PRODUKCYJNY TEST SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ?TESTOWA 1 55-200 GNIEZNO?Wypłata na lokatę zlecona przez Internet (bvt111111111).
:62F:D090714PLN6973,9
:64:D090715PLN6972,9
:86:6792956?65200000000000000000000000?R?090714?090714??0?Z?5?090714?0??0?1???
-}

SWIFT MT940 CitiDirect

Przyklad

Przykład pliku przelewu importowanego przez Comarch ERP XL przy pomocy formatu SWIFT MT940CitiDirect:

:20:FIRMA XXX
:25:86111111111111444411114444
:28C:42/1
:60F:C140228PLN0,
:61:1402280228C3668,67N066NONREF//1112224477
TEST-KNT1
:86:/PT/FT/BO/KNT1/AB/11400000
Warszawa 05111111115555444477778888/BI/010
2222111/ER/1,/OA/PLN3668,67/PY/fa 44777
:61:1402280228C3781,2N066NONREF//1112224444
TEST-KNT2
:86:/PT/FT/BO/KNT2/AB/12402076
Szczecin 18101012701111444411114444/BI/010
2222111/ER/1,/OA/PLN3781,2/PY/FV 12445
:61:1402280228C4140,33N066NONREF//1112224477
TEST-KNT3
:86:/PT/FT/BO/KNT3/AB/10600005
Kraków 62101012125555444411110000/BI/010
2222111/ER/1,/OA/PLN4140,33/PY/F.555555
:61:1402280228C4217,N066NONREF//1112224410
TEST-KNT4
:86:/PT/FT/BO/KNT4/AB/15000028
A C-inne Warszawa 75101012124444111177770000/BI/010
2222111/ER/1,/OA/PLN4217,/PY/FV-2014/22222
:61:1402280228C4756,2N066NONREF//1112224411
TEST-KNT5
:86:/PT/FT/BO/KNT5/AB/10204812
Szczecin 80101010101111222233334444/BI/010
2222111/ER/1,/OA/PLN4756,2/PY/FV-2014/11111
:62F:C140228PLN20563,4
:64:C140228PLN20563,4

Zalecenia nowej broszury JPK_KR

Ministerstwo Finansów opublikowało w październiku 2020 r. nową broszurę dotyczącą JPK dla ksiąg rachunkowych. Sama struktura JPK_KR(1) nie została zmodyfikowana, zostały natomiast wprowadzone dodatkowe opisy, które mają na celu doprecyzować znaczenie poszczególnych sekcji tego pliku oraz ich funkcjonowanie w kontekście Ustawy o Rachunkowości.

Nowa broszura JPK_KR będzie obowiązywać od 1 stycznia 2021, co ma dać spółkom czas na dostosowanie swojego systemu księgowania dokumentów do opublikowanych wyjaśnień.

Dziennik

Najważniejsze zmiany wprowadzone w broszurze dotyczą numeracji operacji w dzienniku. Zgodnie z wyjaśnieniami powinny one być zgodne z art. 14 UoR, czyli prowadzone w sposób chronologiczny, numerowane i bez pozostawiania miejsc na późniejsze dopiski lub zmiany.

Sama chronologia zapisów w dzienniku powinna być zachowana według dat zapisów księgowych, a nie według dat dokonania operacji gospodarczych.

W pliku JPK_KR znajduje się zarówno informacja o numerze zapisu w poszczególnym dzienniku (np. 1/Zak/01/2020, 280/Sprz/01/2020), jak i jego dacie księgowania. Niedopuszczalna jest zatem sytuacja, że zapis o wyższym numerze będzie miał wcześniejszą datę księgowania niż już istniejące.

Prowadzenie dziennika w XL

W systemie Comarch ERP XL firma może założyć dowolną ilość dzienników księgowań, w zależności od typu ujmowanych tam operacji. W ramach każdego z nich jest prowadzona odrębna numeracja.

Schemat księgowania

Najczęstszą formą wprowadzania do nich zapisów jest automatyczne księgowanie dokumentów z wykorzystaniem schematów księgowań. Aby zachować ciągłość numeracji zalecanym ustawieniem parametru Data księgowania jest opcja dzisiejsza. Powoduje to ujmowanie zapisów księgowych pod bieżącą datą systemową.

W przypadku konieczności ujęcia dokumentu w miesiącu poprzednim zalecana jest zatem zmiana daty systemowej na ostatni jego dzień.

 

Renumeracja bufora

W przypadku stosowania innego typu ustawienia daty księgowania może dojść do sytuacji gdy kolejny numer wpisu w dzienniku będzie niezgodny pod kątem chronologicznym (np. w przypadku ujmowania faktur, które wpłynęły później, ale dotyczą wcześniejszych operacji niż już zarejestrowane). Aby zapobiegać takim sytuacjom należy stosować księgowania do bufora. Podczas przenoszenia zapisów do Księgi Głównej zostają one poddane renumeracji. W takim przypadku numer zapisu jest przyporządkowany zgodnie z datą księgowania. Renumerację w buforze można również wykonać ręcznie.

 

W przypadku gdy część zapisów została już ujęta w księdze głównej, nie należy stosować dat zapisu wcześniejszych niż już ujęte w księgach.

 

Przeszacowanie walut

Transakcje walutowe z kontrahentami, bankami, pracownikami ujmowane są w księgach rachunkowych w walucie PLN. Stąd też kwota każdej operacji, która pierwotnie wyrażona jest w walucie obcej, przed jej wprowadzeniem do ksiąg rachunkowych wymaga przeliczenia na złotówki. Ustawa o rachunkowości mówi o kursach, jakie należy zastosować celem właściwego przeliczenia transakcji dokonanej w walucie obcej na wartość w walucie PLN. Zgodnie z art. 30 ustawy wyrażone w walutach obcych operacje gospodarcze w zależności od ich rodzaju ujmuje się w księgach rachunkowych na dzień ich przeprowadzenie po kursie:

Ten sam artykuł narzuca też obowiązek, nie rzadziej niż na dzień bilansowy, wyceny wyrażonych w walutach obcych:

Generacja przeszacowania walut

Przeszacowanie, ze względu na to, że jest to operacja związana z wyceną na dzień bilansowy aktywów i pasywów wyrażonych w walutach obcych, może być przeprowadzane tylko dla nierozliczonych zapisów, lub sald kont liczonych w oparciu o zapisy z Księgi Głównej/bufora.

Funkcjonalność przeszacowania walut dostępna jest w module Księgowość (menu: Księgowość >> Przeszacowanie walut). Przeszacowaniu podlegają wyłącznie konta walutowe. Przeliczenie może dotyczyć albo salda konta walutowego (dla kont zwykłych) albo zapisów na koncie walutowym (dla kont rozrachunkowych).

Na zakładce: Generacja, należy określić następujące parametry: walutę, dla której będzie wykonywane przeszacowanie, podać kurs, według którego salda, bądź poszczególne zapisy księgowe będą przeliczane oraz zaznaczyć, czy przeszacowanie ma dotyczyć salda konta czy też poszczególnych zapisów księgowych. W przypadku zapisów księgowych przeszacowane mogą być wszystkie zapisy, bądź zapisy z wskazanych kont. Tutaj należy też wskazać, za jaki okres wykonane ma być przeszacowanie.

 

Przeszacowanie wybranych sald bądź zapisów księgowych należy uruchomić poprzez użycie ikony
.

W przeszacowaniu walut ujęta jest historyczność rozliczeń dekretów. Oznacza to, że uwzględniane są w nim zapisy księgowe, które zostały rozliczone w kolejnym roku obrachunkowym/ przyszłym miesiącu, ale na koniec roku obrachunkowego (miesiąca), dla którego wykonywane jest przeszacowanie nie były jeszcze rozliczone.

Różnice kursowe wyliczane są globalnie dla danego konta podlegającego przeszacowaniu, lub indywidualnie dla każdego zapisu wówczas, gdy generacja dotyczy poszczególnych zapisów księgowych. Należy pamiętać, iż po wygenerowaniu przeszacowania dla salda konta nie ma możliwości powtórnej generacji przeszacowania dla tego samego konta nawet, jeśli zostały dodane w bazie nowe zapisy księgowe związane z tym kontem. W takiej sytuacji należałoby usunąć przeszacowanie i wygenerować je raz jeszcze.

Wartość różnicy kursowej powstałej z wyceny walut liczonej dla salda konta jest wyliczana według następującego schematu:

RK= SWK*K-SZK

Gdzie:

SWK- saldo konta w walucie obcej np. 905-01

K- kurs podany na przeszacowaniu walut

SZK- saldo konta złotówkowego np. 131-01

Wartość różnicy kursowej powstałej z wyceny liczonej dla konkretnego zapisu księgowego powstaje w następujący sposób:

RK= PN*(KD-KP)

Gdzie:

PN- płatność nierozliczona w walucie obcej pochodząca z dokumentu źródłowego

KD- kurs waluty z dokumentu źródłowego

KP- kurs podany na przeszacowaniu walut

Księgowanie przeszacowania walut

Na zakładce: Księgowanie, wyświetlana jest lista, na której widoczne są wszystkie wygenerowane dokumenty przeszacowań. Z tego poziomu należy zaksięgować te dokumenty na koniec bieżącego okresu i na początek kolejnego okresu (okresu obrachunkowego, miesiąca). Niezrealizowane różnice kursowe z dokumentów przeszacowania księgowane są na konta podane w konfiguracji systemu Comarch ERP XL (Konfiguracja>> Księgowość>> Księgowania>> Przeszacowanie walut). W tym samym obszarze należy zaznaczyć, czy dekret powstały z księgowania przeszacowania ma zostać zapisany w buforze, czy bezpośrednio w Księdze Głównej.

Należy pamiętać, iż na wygenerowane przeszacowanie można zaksięgować tylko i wyłącznie z datą ostatniego dnia okresu obrachunkowego lub ostatniego dnia miesiąca, natomiast wyksięgować tylko pod datą pierwszego dnia okresu obrachunkowego, miesiąca.

Ścieżka księgowania wygenerowanego przeszacowania jest następująca: w pierwszej kolejności należy zaksięgować przeszacowanie na koniec bieżącego okresu, a następnie, z tego samego poziomu, zmieniając ustawienie filtra na: niezaksięgowane na początku okresu, należy dokonać księgowania na początek kolejnego okresu.

Księgowanie w przyszłym okresie obrachunkowym/miesiącu polega na wystornowaniu dekretu związanego z wyceną, wprowadzonego w poprzednim okresie obrachunkowym. Dlatego też, nie wolno ręcznie nic zmieniać w wygenerowanym dokumencie przeszacowania i powstałym z jego księgowania dekrecie. Storno wprowadzane jest do zapisów księgowych zawsze z datą pierwszego dnia przyszłego okresu obrachunkowego/ datą pierwszego dnia kolejnego miesiąca i jest to storno czerwone. System Comarch ERP XL nie dysponuje na chwilę bieżącą funkcjonalnością pozwalającą na wykonanie storna w dniu faktycznego rozliczenia dokumentu.

Uwaga

Nie można zaksięgować przeszacowania na początku przyszłego okresu obrachunkowego/miesiąca, jeśli nie zostało ono zaksięgowane na koniec bieżącego okresu/miesiąca. Nie można również usunąć dekretu powstałego z przeszacowania zaksięgowanego na koniec okresu, jeśli istnieje dekret na początku okresu.

Dekrety powstałe po zaksięgowaniu przeszacowania walut

Z poziomu poprawnie zaksięgowanego przeszacowania można odwołać się do dwóch dekretów: dekretu powstałego na końcu okresu i dekretu powstałego na początku okresu.

Dekret powstały po zaksięgowaniu przeszacowania na koniec okresu będzie miał datę ostatniego dnia okresu obrachunkowego, a dekret zaksięgowany na początku okresu – pierwszego dnia nowego okresu.

Przy wyksięgowywaniu przeszacowania na początek okresu obrachunkowego dokonują się automatyczne rozrachunki z dekretem powstałym z księgowania przeszacowania na koniec roku.

 

Dokument różnic kursowych

Zgodnie przepisami podatkowymi niezbędne jest dualne ujmowanie różnic kursowych – bilansowo i podatkowo. W systemie Comarch ERP XL jest to możliwe dzięki wprowadzeniu dokumentu różnic kursowych. Dokument różnic kursowych (RK) jest generowany automatycznie w wyniku rozliczania lub kompensowania płatności, zapisów kasowych/bankowych, w tym zapisów kasowych/bankowych heterogenicznych o różnych kursach. Powstaje on również w wyniku powiązania raty umowy leasingowej z dokumentem. Nie generuje on płatności, a co za tym idzie nie podlega rozliczeniom.

Parametry w konfiguracji

W oknie: Konfiguracja, na zakładce: Księgowość/Księgowania w sekcji: Różnice kursowe znajduje się parametr: Dokument różnic kursowych. Zaznaczenie tego parametru skutkuje generacją dokumentu różnic kursowych (RK). Dokument RK jest tworzony tylko wtedy, gdy rozliczenie następuje z poziomu dokumentu. Jeżeli wygenerowany zostanie tylko rozrachunek na kontach księgowych, dokument RK nie zostanie utworzony. W takim przypadku powstanie wyłącznie dekret różnicy kursowej na kontach księgowych.

 

Po zaznaczeniu parametru: Dokument różnic kursowych udostępnione zostaną dwie opcje dla księgowania: Automatyczne i Schematem.

Po wybraniu opcji: Księgowanie automatyczne, dokument RK zostanie automatycznie zaksięgowany na konto rozrachunkowe pobrane z dokumentu źródłowego o niższym kursie i odpowiednio na konto przychodów/kosztów z tytułu różnic kursowych (konto należy wskazać na definicji waluty), w momencie księgowania ostatniego z dokumentów źródłowych RK. W konfiguracji należy określić, do jakiego dziennika będą księgowane dokumenty RK, z jaką datą będzie się odbywać księgowanie oraz czy powstałe zapisy księgowe będą trafiać do bufora czy do Księgi Głównej.

Po wybraniu opcji: Księgowanie schematem, dokument RK będzie księgowany jednym ze schematów księgowych utworzonych przez Użytkownika na liście schematów i podpiętych do obiektu: Różnice kursowe. Po wybraniu tego parametru nastąpi wyszarzenie parametrów: Dziennik i Data księgowania. Dostępny będzie jedynie parametr: Bufor decydujący o tym, czy zapis księgowy wygenerowany na podstawie dokumentu RK ma zostać ujęty w buforze czy też w Księdze Głównej.

Jeżeli parametr: Dokument różnic kursowych nie zostanie zaznaczony wówczas różnice kursowe będą generowane tylko w postaci dekretu księgowego, bezpośrednio na kontach księgowych.

 

Uwaga

Różnice kursowe, powstałe w wyniku wyceny wg kursu ustalonego rozchodowego zapisu kasowo/bankowego, zawsze wygenerują się jako dokument RK ze statusem Wycena, bez względu na ustawienia w konfiguracji.

 

Uwaga

Dokumenty RK ze statusem Wycena, powstałe w wyniku wyceny wg kursu ustalonego rozchodowego zapisu kasowo/bankowego, zawsze księgują się automatycznie podczas księgowania raportu, w którym są zapisy biorące udział w wycenie, bez względu na ustawienie parametrów w konfiguracji.

Dodatkowo dla dokumentów różnic kursowych można zdefiniować serię. Zdefiniowania serii dokonuje się w oknie: Konfiguracja, na zakładce: Księgowość/Słowniki.

Lista dokumentów różnic kursowych

Lista ta wyświetlana jest w module Księgowość, po wyborze z paska narzędzi pozycji: Rozliczenia/Rozrachunki opcji: Dokumenty różnic kursowych.

Na powyższej liście widoczne są wszystkie dokumenty różnic kursowych, daty ich wystawienia i rozliczenia oraz status dokumentu RK. Po zaznaczeniu parametru: Pokaż dokumenty – widoczne są też dokumenty źródłowe, z rozliczenia których powstała dana różnica kursowa. Dodatkowo, na liście dokumenty mogą być filtrowane. Zawężanie listy dokumentów jest możliwe poprzez:

Na liście dokumentów różnic kursowych jest również możliwość sumowania kwot dodatnich i ujemnych różnic kursowych. Równocześnie podczas sumowania wyliczane jest saldo, czyli różnica pomiędzy dodatnimi i ujemnymi różnicami kursowymi. Dzięki sumowaniu wartości dodatnich i ujemnych różnic kursowych ułatwiona jest analiza wartości z kwotami zaksięgowanymi na odpowiednich kontach.

Z poziomu listy dokumentów różnic kursowych zostało umożliwione również księgowanie dokumentów RK, eksport listy dokumentów RK do arkusza kalkulacyjnego oraz wydruk listy różnic kursowych.

Formatka dokumentu różnic kursowych

Dokument różnic kursowych (RK) jest generowany automatycznie w wyniku rozliczenia/kompensowania dokumentów lub powiązania raty umowy leasingowej z dokumentem o różnych kursach, stąd z poziomu listy dokumentów nie ma możliwości ręcznego wystawienia nowego dokumentu. Dokument RK składa się z czterech zakładek.

Zakładka: Ogólne

Na zakładce: Ogólne znajdują się podstawowe informacje dotyczące dokumentu:

Numer – w polu wpisywany jest numer automatycznie nadawany przez system.

Dokument obcy – w polu można wpisać numer zewnętrzny nadawany przez Użytkownika.

Dokumenty źródłowe – informacja o dokumentach źródłowych RK.

Status dokumentu RK – jest podpowiadany automatycznie w zależności od rodzaju płatności na dokumentach źródłowych. Status ten Użytkownik może zmieniać.

Różnica kursowa dodatnia/ujemna – w polu uzupełniana jest kwota wyliczonej różnicy kursowej w zależności od jej rodzaju.

Opis – pole pozostawione do ręcznego uzupełnienia przez operatora.

Na dokumencie RK znajdują się również dwie daty: Data dokumentu i Data rozliczenia. Data dokumentu jest ustawiona zgodnie z datą rozliczenia. Użytkownik ma możliwość zmiany tej daty i wykorzystania jej do księgowania schematem księgowym.

Ustawienie daty rozliczenia uzależnione jest od ustawień konfiguracyjnych:

W przypadku zaznaczenia w konfiguracji dla parametru: Księgowanie, opcji: Automatycznie data rozliczenia ustawiana jest wg:

Przyklad

Ustawienie daty systemowej: 30-06-20201

Data wystawienia zapisu K/B: 15-06-2021

Data wystawienia faktury: 19-06-2021

Data rozliczenia na RK: 19-06-2021

Przyklad

Ustawienie daty systemowej: 30-06-2021

Data wystawienia zapisu K/B: 15-06-2021

Data wystawienia faktury: 19-06-2021

Data rozliczenia na RK: 30-06-2021

W przypadku zaznaczenia w konfiguracji dla parametru: Księgowanie, opcji: Schematem oraz wybrana opcja: Data powstania dokumentu RK jako późniejszego dokumentu – data rozliczenia ustawiana jest zawsze jako data najpóźniej wystawionego dokumentu biorącego udział w rozliczeniu.

Jeśli została wskazana opcja: Data powstania dokumentu RK jako dzisiejsza – data rozliczenia ustawiana jest zgodnie z datą systemową. Warunek: data w systemie musi być równa lub późniejsza od daty wystawienia  najpóźniej wystawionego  dokumentu biorącego udział w rozliczeniu. W przeciwnym razie datą rozliczenia będzie data najpóźniej wystawionego  dokumentu.

W przypadku, gdy kompensata generowana jest za pośrednictwem dokumentu KMP, w ustawieniu daty rozliczenia na dokumencie RK jest uwzględniana data kompensaty.

 

Przyklad

W konfiguracji ustawiono: Księgowanie Automatyczne z datą późniejszego dokumentu.

Za pośrednictwem dokumentu KMP skojarzono ze sobą dwa dokumenty.

Data wystawienia pierwszego dokumentu: 15-06-2021

Drugiego: 20-06-2021

Data kompensaty na dokumencie KMP: 30-06-2021

Data rozliczenia na RK została ustawiona na 30-06-2021

Przyklad

W konfiguracji ustawiono: Księgowanie Automatyczne z datą “dzisiejszą”

Za pośrednictwem dokumentu KMP skojarzono ze sobą dwa dokumenty.

Data wystawienia pierwszego dokumentu: 15-06-2021

Drugiego: 20-06-2021

Data kompensaty na dokumencie KMP: 30-06-2021

Datę systemową ustawiono na 31-05-2021

Data rozliczenia na RK została ustawiona na 30-06-2021

Zakładka: Księgowość

Księgowanie dokumentu RK jest uzależnione od ustawień konfiguracyjnych (parametr: Księgowanie Automatycznie/Schematem).

Jeżeli w konfiguracji zostanie wybrana opcja: Księgowanie automatyczne, wówczas księgowanie dokumentu RK będzie się odbywało według następujących zasad:

Jeżeli w konfiguracji zostanie wybrana opcja: Księgowanie schematem, wówczas księgowanie dokumentu RK będzie się odbywało według następujących zasad:

Nie dojdzie do zaksięgowania dokumentu RK w sytuacji, gdy jeden z dekretów związanych z dokumentem źródłowym zostanie rozrachowany z innym dekretem wprowadzonym z ręki lub związanym z dokumentem niebiorącym udziału w rozliczeniach.

Na zakładce: Księgowość, dokumentu RK istnieje również możliwość wprowadzenia opisu analitycznego. Dostępne są na niej daty analityczne: Wystawienia i Rozliczenia oraz kategorie finansowe: Nie dotyczy i Wg dokumentu.

Zakładka: Atrybuty

Na zakładce: Atrybuty istnieje możliwość opisania dokumentu za pomocą atrybutów. Atrybuty dodawane są na ogólnych zasadach. Aby było możliwe przypisanie atrybutu do konkretnego dokumentu RK, należy najpierw przypisać klasę atrybutu do obiektu: [Księgowe].[Różnice kursowe].

Zakładka: Załączniki

Na zakładce: Załączniki istnieje możliwość dodania załączników do dokumentu. Załączniki dodawane są na ogólnych zasadach.

Ujęcie dokumentu różnic kursowych

Różnice kursowe mogą być ujmowane w dwojaki sposób: bilansowo i podatkowo.

Bilansowe ujęcie różnic kursowych

W ujęciu bilansowym dokumenty RK są dzielone na dodatnie i ujemne. W trakcie generowania dokumentu RK pod uwagę brane będą kursy na płatnościach rozliczanych/kompensowanych dokumentów i w zależności od różnicy w kursach różnica kursowa będzie klasyfikowana, jako dodatnia bądź ujemna.

Dodatnie różnice kursowe będą generowane w następujących przypadkach:

Ujemne różnice kursowe będą generowane w następujących przypadkach:

Podatkowe ujęcie różnic kursowych

Ze względu na różnice w podejściu bilansowym i podatkowym w sposobie ujmowania różnic kursowych dokumenty RK będą dodatkowo klasyfikowane pod kątem ujęcia podatkowego. Klasyfikacja ta będzie się odbywać przy pomocy statusu.

<

Przykładowe księgowania dokumentu RK

Przykładowe księgowanie automatyczne

Sposób księgowania automatycznego dokumentów RK będzie uzależniony od ich dokumentów źródłowych.

W przypadku dokumentu RK powstałego z rozliczenia dokumentu FS z zapisem KP, księgowanie dokumentu RK będzie wyglądało następująco:

W przypadku dokumentu RK powstałego z kompensowania dokumentu FS i FZ księgowanie dokumentu RK będzie wyglądało następująco:

Przykładowe księgowanie schematem

Aby dokument RK został zaksięgowany schematem należy taki schemat utworzyć. Schemat tworzy się w menu: Narzędzia/Schematy księgowe na zakładce: Różnice kursowe.

W schematach księgowych dotyczących dokumentu RK udostępnione zostały następujące kwoty:

Księgując dokument RK schematem możemy księgować różnice kursowe zarówno w ujęciu bilansowym i podatkowym. W momencie dualnego ujmowania dokumentów RK, dla ewidencji podatkowej należy założyć konta o statusie: pozabilansowe. Schemat w takim przypadku może wyglądać następująco:

Pozycja 1 – pozwala na zaksięgowanie dokumentów RK dodatnich

Pozycja 2 – pozwala na zaksięgowanie dokumentów RK ujemnych

 

Ewidencjonowanie środków trwałych

W momencie rozpoczynania pracy z modułem: Środki trwałe systemu Comarch ERP XL bardzo często zdarza się, że Użytkownik posiada środki trwałe ewidencjonowane wcześniej w innym systemie. W momencie wprowadzania takich środków do systemu bardzo ważne jest wprowadzenie ich w taki sposób, aby dane generowane później w programie były prawidłowe.

Wprowadzanie kart inwentarzowych

Pierwszym krokiem w trakcie rozpoczęcia pracy z modułem: Środki trwałe, jest wprowadzenie kart inwentarzowych dla środków trwałych. Dla każdego środka trwałego należy wprowadzić kartę inwentarzową i zapisać na niej prawidłowe dane dla danego środka: symbol klasyfikacji rodzajowej, akronim, stawki i współczynniki dla amortyzacji bilansowej i podatkowej lub własnego toru, metody dla amortyzacji podatkowej i bilansowej lub własnego toru. Na karcie należy również określić miesiąc rozpoczęcia naliczania amortyzacji bilansowej i podatkowej lub własnego toru.

Na wprowadzanej karcie środka trwałego należy wprowadzić datę faktycznego przyjęcie środka do użytkowania (np. 01.01.2009)

Wprowadzenie dokumentów

Po założeniu dla środków trwałych kart inwentarzowych należy wprowadzić dla nich odpowiednie dokumenty z zachowaniem historyczności.

Przyjęcie środka trwałego do użytkowania – dokument OT

Po zarejestrowaniu kart inwentarzowych środków trwałych należy każdy ze środków przyjąć do użytkowania za pomocą dokumentu OT. Bardzo ważne jest to, aby na dokumencie OT podać datę faktycznego przyjęcia do użytkowania środka trwałego, czyli datę, od której środek był użytkowany w poprzednim systemie (np. 01.01.2009).

Na dokumencie OT wprowadzamy pozycje. Na pozycji w polach: Podstawa BIL i Podstawa POD lub dla własnego toru amortyzacji podajemy faktyczną wartość początkową środka trwałego.

Zmiany wartości środka trwałego – dokument MW

W celu zachowania historyczności oraz prawidłowych odpisów amortyzacyjnych środków trwałych użytkowanych wcześniej w innych systemach, należy w momencie ich ewidencji w systemie Comarch ERP XL wprowadzić dla nich wszelkie wcześniej dokonane modyfikacje wartości. Modyfikacje te wprowadzamy z faktyczną datą ich wykonania (np. 01.03.2010) za pomocą dokumentu MW.

Na dokumencie MW wprowadzamy pozycje. Na pozycji w polach: Podstawa BIL i Podstawa POD lub dla własnego toru amortyzacji podajemy faktyczną wartość, o którą ma zostać zwiększona/zmniejszona wartość początkowa środka trwałego. W tym miejscu określamy również, czy dokument MW będzie obowiązywał od miesiąca jego wystawienia, czy od kolejnego miesiąca.

Uwaga

W przypadku środków trwałych amortyzowanych metodą degresywną dokument MW domyślnie obowiązuje od kolejnego roku użytkowania środka trwałego, chyba że zaznaczono w konfiguracji Środków trwałych parametr: Metoda degresywna – zmiana wartości w pierwszym roku od następnego miesiąca.

Dotychczasowa amortyzacja środka trwałego – dokument AM

Dla środków trwałych częściowo zamortyzowanych w innych systemach należy, oprócz podstawy amortyzacji bilansowej i podatkowej lub własnego toru amortyzacji, wprowadzić również wartości dotychczasowych odpisów bilansowych i podatkowych lub własnego toru amortyzacji. W tym celu należy wystawić odpowiednie dokumenty AM. Dokument taki należy wystawić w grudniu roku poprzedzającego rok rozpoczęcia pracy z systemem Comarch ERP XL (np. rozpoczęcie pracy 01.01.2012 – dokument AM 31.12.2011). Dokument taki należy wystawić z pozycji Tabeli amortyzacji, zakładka: Generacja. Ważne jest, aby w momencie generowania dokumentu AM, w oknie: Parametry generacji, zaznaczyć opcję: Uwzględniaj zaległe odpisy od daty rozpoczęcia amortyzacji.

W wyniku generacji zostanie utworzony dokument AM o wartości odpisów wyliczonych automatycznie według wprowadzonych wcześniej stawek i wartości na dzień 31.12.2011.

Jeżeli odpisy automatycznie wygenerowane w systemie nie są wartościowo zgodne z odpisami wcześniej poniesionymi, wówczas dokument AM można wystawić z pozycji listy dokumentów. Dokument ten również powinien być wystawiony z datą 31.12.2011.

Na pozycji dokumentu AM należy wybrać opcję generacji: od daty rozpoczęcia amortyzacji. Na pozycji dokumentu AM można dodatkowo modyfikować wartość odpisów.

Wprowadzone w ten sposób środki trwałe można prawidłowo amortyzować od stycznia 2012 roku. Wszystkie dokumenty wystawione w systemie od tej daty powinny być księgowane. Dokumenty wystawione z datami wcześniejszymi (wprowadzone historycznie dla celów prawidłowego naliczania amortyzacji) nie są księgowane.

Uwaga

Jeżeli praca z modułem: Środki trwałe, nie rozpoczyna się od początku danego roku, wówczas oprócz opisanego wcześniej dokumentu AM w grudniu roku poprzedzającego rozpoczęcie pracy z systemem należy wprowadzić dodatkowo dokument AM w miesiącu poprzedzającym rozpoczęcie pracy z systemem. Przykładowo, jeśli rozpoczęcie pracy następuje dnia 01.07.2012, należy wprowadzić dokumenty AM z następującymi datami: 31.12.2011 oraz 30.06.2012. W trakcie generacji drugiego dokumentu AM należy zaznaczyć opcję: Uwzględniaj zaległe odpisy od początku roku.