Wstęp

Począwszy od 16 sierpnia 2006 roku Ministerstwo Finansów wprowadziło możliwość składania deklaracji podatkowych drogą elektroniczną. Możliwość taką otrzymali początkowo jedynie niektórzy podatnicy, 1 stycznia 2008 roku możliwość składania deklaracji elektronicznych rozszerzono na wszystkie podmioty gospodarcze.

Funkcjonalność wysyłania deklaracji drogą elektroniczną bezpośrednio z systemu Comarch ERP XL udostępniona została w lipcu 2008 roku wraz z wersją 8.0 systemu. Model wysyłania deklaracji polega na wygenerowaniu w systemie pliku xml, który jest zgodny ze schematem XSD opublikowanym przez Ministerstwo Finansów.
Wygenerowany plik deklaracji podatkowej opatrywany jest podpisem elektronicznym i wysyłany do systemu e-Deklaracje Ministerstwa Finansów. Aby wysłanie deklaracji było możliwe konieczne jest posiadanie kwalifikowanego podpisu elektronicznego (wszelkie informacje na ten temat znajdują się na stronach WWW Ministerstwa, pod adresem http://www.e-deklaracje.gov.pl/).

Wysyłanie deklaracji drogą elektroniczną możliwe jest dla deklaracji VAT-7 (od wersji 11), VAT-7K (od wersji 5), VAT-7D (od wersji 2) i ich korekt, oraz deklaracji VAT-UE, VAT-UEK (wersja 2).

Do deklaracji VAT-7 w zależności od ustawień na deklaracji tworzone są w formie zakładek i razem z nią wysyłane załączniki:

Przygotowanie deklaracji podatkowej do wysłania

Deklarację w postaci pliku xml można wygenerować niezależnie od całego procesu wysyłania jej do portalu Ministerstwa Finansów. Jest to możliwe z poziomu listy: Deklaracje, w module: Księgowość systemu Comarch ERP XL, za pomocą przycisku 

Wygenerowany plik zostanie zapisany w miejscu wskazanym w Konfiguracji komputera, na zakładce: Wymiana danych, w sekcji: Zgłoszenia SAD, deklaracje:

Aby został wygenerowany prawidłowy plik, konieczne jest uzupełnienie na deklaracji następujących pól:

Dla deklaracji VAT-7:

Dla deklaracji VAT-UE i VAT-UEK:

Uwaga

Pole: Kraj na formatce deklaracji powinno być wybrane z listy rozwijanej

Ponieważ numer NIP jest przepisywany na deklarację VAT-7 z pieczątki firmy, przed przystąpieniem do wysyłania, należy zwrócić uwagę czy wprowadzony jest on w odpowiedniej postaci, to znaczy czy jest podzielony kreskami w następujący sposób: 111-222-33-44.

Wysyłanie deklaracji

System Comarch ERP XL umożliwia wysyłanie elektroniczne z poziomu modułu Księgowość z listy: Deklaracje, z obu jej zakładek: VAT-7 oraz VAT-UE. Proces elektronicznego wysyłania przebiega identycznie dla deklaracji VAT-7, VAT-7D i VAT-7K jak i dla deklaracji VAT– UE oraz ich korekt.

Proces wysyłania deklaracji należy rozpocząć naciskając przycisk , co spowoduje otwarcie formatki: Wysyłanie e-deklaracji. Na zakładce: Dane i certyfikaty tej formatki należy wybrać z rozwijanej listy certyfikat z aktywnym podpisem kwalifikowanym:

Następnym krokiem jest wygenerowanie deklaracji w postaci xml za pomocą przycisku . Na tym etapie system sprawdza, czy wypełnione są wymagane pola wysyłanej deklaracji. System wygeneruje plik xml tylko w przypadku, gdy wszystkie wymagane pola deklaracji będą wypełnione. W przeciwnym wypadku wskaże, które pola należy uzupełnić przed wysłaniem deklaracji:

Prawidłowe wygenerowanie deklaracji w pliku xml spowoduje uaktywnienie się zakładki: Podpisz i Wyślij.

Z poziomu zakładki Podpisz i Wyślij, należy wygenerowany plik xml opatrzyć elektronicznym podpisem kwalifikowanym. Służy do tego przycisk  , który powoduje powstanie formatki czytnika klucza, gdzie należy wprowadzić indywidualny kod PIN do certyfikatu. Wygląd tej formatki może różnić się od przedstawionego poniżej, w zależności od urzędu certyfikacji, który wydał klucz do podpisu kwalifikowanego.

Wprowadzenie PIN-u i zaakceptowanie spowoduje wygenerowanie w oknie formatki opatrzonego podpisem elektronicznym dokumentu. Tak przygotowany plik można wysłać do portalu Ministerstwa Finansów, za pomocą przycisku  :

Wysłanej deklaracji zostaje nadany numer referencyjny: RefId dokumentu. Określony zostaje też status wysłanego dokumentu.

Uwaga

Aby przyciski: Exportu deklaracji do pliku xml oraz Wysyłanie deklaracji do portalu MF były aktywne, wybrana z listy deklaracja musi być co najmniej „Zaakceptowana”.

Urzędowe Poświadczenie Odbioru

Urząd skarbowy po otrzymaniu e-deklaracji zobowiązany jest wydać petentowi Urzędowe Poświadczenie Odbioru (UPO), potwierdzające otrzymanie deklaracji przez urząd skarbowy. Funkcjonalność systemu Comarch ERP XL umożliwia pobranie UPO bezpośrednio z poziomu formatki wysłanej deklaracji. Służy do tego przycisk:  [Pobieranie UPO], który uaktywnia się na deklaracji, po jej prawidłowym wysłaniu:

UPO dla złożonego dokumentu jest wystawiane w ciągu kilku godzin – od 1 godziny do 24 godzin. Jest to uzależnione od polityki Centrum Certyfikacji, w którym wystawiony został używany do podpisu certyfikat. Dopóki system urzędu skarbowego nie zakończy weryfikacji deklaracji, dokument będzie otrzymywał status UPO serii 30x. Należy wtedy spróbować po kilku godzinach ponownie pobrać UPO.

Status e-deklaracji widoczny jest też na zakładce Ogólne. Pole to uaktualniane jest automatycznie w zależności od etapu przetwarzania deklaracji.
Statusy e-deklaracji:

Jeżeli wysłany dokument zostanie odrzucony przez system urzędu, informacja o tym będzie dostępna prawie natychmiast po złożeniu. Pobieranie UPO zakończy się otrzymaniem błędu o statusie serii 4xx.
Prawidłowo przetworzony przez urząd dokument deklaracji otrzyma potwierdzenie UPO o statusie 200:

Po potwierdzeniu, że przetwarzanie dokumentu zostało zakończone poprawnie i status e-deklaracji został zmieniony na: Wysłano/odebrano UPO można wydrukować dokument UPO. Wydruk dokumentu UPO uruchamiany w oknie deklaracji z menu kontekstowego drukarki.

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 2004-04-14, zamknięcie 2004-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 2004-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 2004-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 2004-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 2004-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 2004, 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 2006, 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 2004, 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-2006/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 2004-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 2004-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 2004-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 2004-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 2006-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 2006-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 2006-11-09, zamknięcie 2006-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 2004, 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 2005 – 2004, 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 2004, 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 2004-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 2008 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 2006, 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 2006, 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 2006, 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/2006/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-2006/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-2006/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-2006/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.

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ć:

• kwotę inwentarzową brutto
• umorzenie w wysokości proporcjonalnej do wartości wyprowadzanej kwoty inwentarzowej brutto
• podstawę amortyzacji netto.

Zmniejszenie wartości środka trwałego amortyzowanego jednotorowo

W celu zmniejszenia wartości środka trwałego amortyzowanego jednotorowo należy w pierwszej kolejności rozdzielić tory dla umorzenia i amortyzacji tego środka, aby było możliwe wprowadzenie na dokumencie MW różnych wartości dla podstawy amortyzacji i kwoty inwentarzowej. Dokument MW należy wystawić dopiero po rozdzieleniu torów dla tego środka trwałego.

Wystawienie dokumentu RT

Pierwszym krokiem zmierzającym do częściowej likwidacji środka trwałego amortyzowanego jednotorowo jest wystawienie dla tego środka dokumentu RT (Rozdzielenie torów).

Na dokumencie RT należy wybrać odpowiednią datę. Data na dokumencie RT musi poprzedzać datę wystawienia dokumentu MW. Dokument ten obowiązuje od następnego miesiąca w stosunku do daty podanej w polu: Data obowiązywania.

Wystawienie dokumentu MW

Kolejnym krokiem zmierzającym do częściowej likwidacji środka trwałego amortyzowanego jednotorowo jest wystawienie dla tego środka dokumentu MW (Modyfikacja Wartości). Wszystkie kwoty na dokumencie powinny być kwotami ujemnymi.

Po wystawieniu dokumentów RT i MW dla danego środka trwałego, automatycznie zostaną zaktualizowane kwoty i środek trwały będzie można dalej amortyzować oraz umarzać generując prawidłowe dokumenty AM.

Zmniejszenie wartości środka trwałego amortyzowano dwutorowo

Zmniejszenie wartości środka trwałego amortyzowanego dwutorowo przebiega w analogiczny sposób jak zmniejszenie wartości środka trwałego amortyzowanego jednotorowo. Jednak w takim przypadku nie ma potrzeby wystawiania dokumentu RT (Rozdzielenie torów). Dla środka amortyzowanego dwutorowo, na dokumencie MW (Modyfikacja wartości) aktywne są obie kwoty: Podstawa bilansowa i Podstawa podatkowa. 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.

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 biuletynie technicznym: XL114 – Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4.

 

 

Wstęp

Koszty wynagrodzeń są zazwyczaj wnikliwie analizowane w każdym przedsiębiorstwie ze względu na ich znaczący udział w kosztach zaklasyfikowanych do danego okresu.

Biuletyn poświęcony został analizie kosztów wynagrodzeń przeprowadzanej w systemie Comarch ERP XL. Obejmuje ona proces tworzenia opisu analitycznego na listach płac, w tym także wykorzystanie podzielnika dla potrzeb właściwej prezentacji kosztów.

Opis analityczny listy płac opiera się na wyliczeniu i możliwości ocechowania za pomocą wymiarów analitycznych pewnych agregatów wartości.

Wykonanie opisu analitycznego umożliwia uwzględnienie w Business Intelligence  właściwych kosztów płac. Możliwe jest również wykorzystanie dokonanego opisu analitycznego dla potrzeb zaksięgowania listy schematem zbudowanym w oparciu o opis analityczny.

Specyfikacja kwot na listach płac

Dokument LP „Lista płac” powstaje w wyniku wykonania importu danych przy udziale procedur składowanych z Comarch ERP Optima bądź wczytaniu danych za pomocą pliku tekstowego o określonej strukturze (PIK). Elementy wyliczonego wynagrodzenia zapisywane są w tabeli Cdn.PikKwoty.

Uwaga

Podczas wykonywania importu następuje przeniesienie danych dotyczących naliczonych składników wynagrodzenia (w tym narzutów) a nie ich wyliczanie.

Dla potrzeb tej analizy najbardziej interesować nas będą wartości następujących pól:

Dodatkowo należy pamiętać, iż składniki wynagrodzenia są zapisywane i mogą być analizowane na trzech poziomach szczegółowości:

Warianty opisu analitycznego

Opis analityczny może zostać utworzony w następujący sposób:

1. Przeniesienie opisu analitycznego z Comarch ERP Optima (uwarunkowane parametrem w konfiguracji transformacji DTS – „Przenoszenie opisu analitycznego”)
2. Wykorzystanie podzielnika wynagrodzeń – utworzenie opisu analitycznego na istniejącej liście płac przy udziale przygotowanego podzielnika
3. Uzupełnienie opisu analitycznego bezpośrednio przez Użytkownika

Najczęściej wykorzystywany jest wariant 1 i 2.

Sposoby ujęcia analitycznego kosztów wynagrodzeń

Opis analityczny list płac może odbywać się w oparciu o 3 warianty ujęcia kosztów:

1. Netto/Podatek/ZUS pracobiorcy/ZUS pracodawcy/zmniejszenia
2. Brutto/ZUS pracodawcy/Zmniejszenia
3. Koszt całkowity/Zmniejszenia

Są to 3 sposoby ujęcia tych samych kwot, Użytkownik decyduje, w którym wariancie będzie prowadzona analiza kosztów wynagrodzeń w jego jednostce.

W przypadku wykorzystania podzielnika wynagrodzeń, rozbicie kosztów (zgodnie z jednym z 3 wariantów) następuje w sposób określony w konfiguracji podzielnika.

Poniżej przedstawione zostało przyporządkowanie poszczególnych elementów wynagrodzeń do danej kategorii używanej podczas analizy:

ZUS pracodawcy: Emerytalne firmy + Rentowe firmy + Wypadkowe + Fundusz Pracy + FGŚP + FEP (identyfikacja na podstawie pik_symbol)

ZUS pracobiorcy: Emerytalne pracownika+ Rentowe pracownika + Chorobowe + Zdrowotne (identyfikacja na podstawie pik_symbol)

Brutto: Netto + Podatek + ZUS pracobiorcy (wyliczony tak jak powyżej)

Koszt całkowity: Brutto + ZUS pracodawcy

Uwaga

Zgodnie z powyższym rozbiciem, wartość „brutto” w opisie analitycznym nie jest tożsama z kwotą wynagrodzenia brutto (pik_symbol=1 ). Zmianie nie ulega wartość kosztu a tylko jego rozbicie w zależności od przyjętego wariantu.

Specyfikacja kwot związanych z opisem analitycznym

Kwoty poszczególnych elementów wynagrodzenia dla potrzeb opisu analitycznego kwalifikowane są do jednej z grup:

Przypisanie składnika do danej grupy odbywa się zgodnie z następującymi założeniami:

Uwaga

Podsumowując – podział polega na przyporządkowaniu ujemnych wartości (z uwzględnieniem dodatkowych warunków) do zmniejszeń, a dodatnich do zwiększeń.

Przykładowe zmniejszenia w opisie analitycznym

Na wypłacie pracownika naliczonej w Comarch ERP Optima (a na liście płac widocznej z poziomu XL) mogą się pojawić kwoty które są identyfikowane jako „Zmniejszenia”

Czego mogą dotyczyć  zmniejszenia? Poniżej przedstawione zostały przykłady:

Przykładowy opis analityczny listy płac

W tym punkcie przedstawione zostanie ujęcie kosztów wynagrodzenia danego pracownika
w poszczególnych wariantach analizy kosztów wynagrodzeń. Klasyfikacja następuje zgodnie
z założeniami opisanym we wcześniejszych częściach dokumentu.

Uwaga

Lista płac z pomniejszeniem wynikającym ze zdefiniowanego składnika. Pozycja listy płac powiązana z pracownikiem zawiera 2 elementy – wynagrodzenie brutto 2000 i pomniejszenie brutto w wysokości 100

Ujęcie kosztów w wariancie „Netto”

Pokazuje on wynagrodzenie w układzie: Netto, Podatek, ZUS pracobiorcy, ZUS pracodawcy, Zmniejszenia

W takim przypadku opis składników będzie wyglądał tak jak na poniższym zrzucie ekranowym.

Poniżej przedstawiono szczegółową specyfikację na poziomie wynagrodzenia danego pracownika:

Nazwa pozycji	Wartość	Uwagi
Netto	1.459,48	Wartość samego wynagrodzenia (kwoty>0)
Podatek	119
ZUS pracobiorcy	451	Narzuty od obu składników (kwoty >0): 163,09 + 204,96 + 31,50 + 51,45
ZUS pracodawcy	395.01	Narzuty od obu składników (kwoty >0): 204,96 + 136,50 + 51.45 + 2,10
Zmniejszenia	-29.48	Brutto lub netto<0

Ujęcie kosztów w wariancie „Brutto”

Pokazuje on wynagrodzenie w układzie: Brutto, ZUS pracodawcy, Zmniejszenia

W takim przypadku opis składników będzie wyglądał tak jak na poniższym zrzucie ekranowym:

Poniżej przedstawiono szczegółową specyfikację na poziomie wynagrodzenia danego pracownika:

Nazwa pozycji	Wartość	Uwagi
Brutto	2.029,48	Netto + Podatek + ZUS pracobiorcy 1.459,48 + 119,00 + ( 204,96 + 31,50 + 51,45 + 163,09)
ZUS pracodawcy	395.01	Narzuty od obu składników (kwoty >0), analogicznie jak wariancie netto: 204,96 + 136,50 + 51.45 + 2,10
Zmniejszenia	-29.48	Brutto lub netto<0

Ujęcie kosztów w wariancie „Koszt całkowity”

Pokazuje on wynagrodzenie w układzie: Koszt całkowity, Zmniejszenia

W takim przypadku opis składników będzie wyglądał tak jak na poniższym zrzucie ekranowym:

Poniżej przedstawiono szczegółową specyfikację na poziomie wynagrodzenia danego pracownika:

Nazwa pozycji	Wartość	Uwagi
Koszt całkowity	2.424,49	Brutto (Netto + Podatek + ZUS pracobiorcy) powiększone o ZUS pracodawcy. Czyli: (1459,48 + 119,00 + 451,00 ) [Brutto] + (204,96 + 136,50 + 51.45 + 2,10) [ZUS pracodawcy]
Zmniejszenia	-29.48	Brutto lub netto<0

Synchronizacja baz danych Comarch ERP XL- Comarch ERP XL HR

Współpraca Comarch ERP XL  i Comarch ERP XL  HR obejmuje dwa obszary, wymagające konfiguracji:

Konfiguracja parametrów synchronizacji w Comarch ERP XL

Uwaga

Od wersji  2017.0 Comarch ERP XL ustawienia synchronizacji z bazą danych Comarch ERP XL HR można dokonać jedynie w systemie Comarch ERP XL. Oznacza to, że możliwa jest wyłączania współpraca dwustronna pomiędzy obiema bazami.

W celu uruchomienia współpracy należy w  konfiguracji systemu Comarch ERP XL na zakładce: HR zaznaczyć check: Synchronizuj strukturę organizacyjną i dane kadrowe. Następnie w polach: Serwer i Baza należy wprowadzić nazwę serwera SQL, na którym znajduje się baza Comarch ERP XL HR i nazwę tej bazy.

W polach: Login i Hasło należy wprowadzić dane loginu, utworzonego w zgodnie z poniższym opisem:

Z poziomu narzędzia: Microsoft SQL Server Management Studio > Security > Logins należy dodać nowy login SQL (proponowana nazwa to CDNDTS). Ustawienia dla loginu:

Należy zaznaczyć role: public i sysadmin

Po prawidłowym wpisaniu tych danych, podczas zapisu okna konfiguracji automatycznie zostaną wykonane następujące czynności:

Uwaga

Aby możliwe było wykonanie tych operacji, podawany w konfiguracji login SQL musi mieć nadane uprawnienia ‘sysadmin’.

Jeżeli bazy Comarch ERP XL i Comarch ERP XL HR znajdują się na różnych serwerach, login powinien zostać założony na każdym z serwerów. 

Uwaga

Automatyczne tworzenie zlinkowanwgo serwera oraz jego mapowanie na bazy Comarch ERP XL oraz Comarch ERP XL HR zostało wprowadzone w wersji 2017.0 Comarch ERP XL. Do tej wersji konfigurację synchronizacji systemu należy przeprowadzać zgodnie z biuletynem XL114 – „Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4”.

Od wersji 2017.0 Comarch ERP XL jeśli współpraca zostanie ustawiona od strony bazy danych Comarch ERP XL, nie będzie możliwa dokonywanie zmian w tym obszarze konfiguracji Comarch ERP XL HR (System – Konfiguracja: Firma – Płace – Parametry współpracy z  XL). Zostanie wyświetlona informacja: „Baza danych Comarch ERP XL w wersji 2017.0 lub wyższej. Ustawienia synchronizacji z taką bazą danych można dokonać jedynie w systemie Comarch ERP XL”. Obszar konfiguracji  będzie nieaktywny.

Jeśli wprowadzone dane będą zawierały błędy (np. nie będzie takiego loginu SQL na serwerze), Użytkownik zostanie o tym poinformowany i synchronizacja nie będzie możliwa. W przypadku pozytywnej weryfikacji danych i utworzenia wszystkich niezbędnych powiązań, zostanie uruchomiona funkcja specjalna: Synchronizacja danych kadrowych.

Uwaga

Aby zagwarantować poprawność wykonania funkcji synchronizacji, w obu bazach nie powinny być wykonywane w tym czasie żadne operacje.

Wywołanie funkcji specjalnej: Synchronizacja struktury organizacyjnej może spowodować nieodwracalne zmiany w bazie danych. Przed jej uruchomieniem należy sprawdzić zgodność danych w obu synchronizowanych bazach (Comarch ERP XL HR oraz Comarch ERP XL) oraz bezwzględnie wykonać ich kopie zapasowe. Każdorazowe wykonanie synchronizacji powinno obejmować wszystkie etapy. Gwarantuje to poprawne skojarzenie obiektów.

Dodatkowe ustawienia w systemie Windows jeżeli bazy ERP XL i ERP XL HR znajdują się na różnych serwerach

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

Usługę: Koordynator transakcji rozproszonych należy uruchomić dla każdego synchronizowanego serwera.

Usługę należy skonfigurować jak poniżej:

Dodatkowo, należy skonfigurować zaporę sieciową, reguły przychodzące i wychodzące jak poniżej:

Konfiguracja parametrów synchronizacji w Comarch ERP XL HR

Uwaga

Od wersji  Comarch ERP XL 2017.0 ustawienia synchronizacji z bazą danych Comarch ERP XL można dokonać jedynie w systemie Comarch ERP XL. Oznacza to, że możliwa jest wyłączania współpraca dwustronna pomiędzy obiema bazami.

Do wersji 2016.3.4 Comarch ERP XL ustawienie parametrów synchronizacji wykonywane  w Comarch ERP XL HR z poziomu: System – Konfiguracja (CTRL+F9): Firma – Płace – Parametry współpracy z  XL. W tym miejscu należy zaznaczyć parametr współpracy podając:

Dodatkowo Użytkownik  ma możliwość wskazania Operatora dla zapisów z programu Comarch ERP XL.

Po ustawieniu parametrów synchronizacji  możliwe jest realizowanie współpracy w zakresie bieżącej aktualizacji danych kadrowych.  Synchronizacja uruchamiana jest podczas zapisywania zmian na kartach pracowników, wydziałów, lokalizacji i projektów.

Bieżąca aktualizacja danych kadrowych wprowadzanych w Comarch ERP XL HR/ Comarch ERP XL przy włączonej współpracy dwustronnej

Bieżąca praca w systemie Comarch ERP XL oraz Comarch ERP XL HR wymaga aktualizowania danych na bieżąco, w związku z czym:

Uwaga

Tylko atrybuty o typie: Okresowy podlegają synchronizacji.

Import list płac z Comarch ERP XL HR do Comarch ERP XL za pomocą procedur składowanych

Konfiguracja po stronie serwera SQL

Od wersji 2017.0 Comarch ERP XL część czynności po stronie serwera SQL wykonywanych jest automatycznie przez system w momencie zapisu konfiguracji synchronizacji w Comarch ERP XL ( zakładka HR). Konieczne jest jedynie dodanie loginu SQL z odpowiednimi uprawnieniami. Szczegółowy opis znajduje się w  rozdziale: Konfiguracja parametrów synchronizacji w Comarch ERP XL.

W wersjach wcześniejszych w  celu zaimportowania list płac za pośrednictwem procedur składowanych konieczne jest wykonanie pełnej konfiguracji po stronie serwera SQL. Wszystkie czynności jakie należy wykonać zostały opisane w biuletynie technicznym: XL 114 -Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4.

Konfiguracja zestawu transformacji DTS

Od wersji 2017.0 Comarch ERP XL z poziomu okna Konfiguracja/HR istnieje możliwość eksportu danych do zestawu DTS. Opcja pozwala na automatyzację uzupełnienia ustawień serwera i bazy danych dla mechanizmu importu list płac (tzw. transformacji DTS) na podstawie wartości wprowadzonych w konfiguracji systemu.

W oknie konfiguracji systemu znajduje się przycisk [Eksportuj dane do zestawu DTS]. Za jego pomocą zostaje utworzony nowy zestaw DTS oznaczony jako ‘Ustawienia konfiguracyjne’. W zestawie zostają automatycznie uzupełnione dane dotyczące serwerów i baz danych podlegających synchronizacji, wraz z właściwym loginem i hasłem SQL. Pozostałe parametry zestawu mają wartości domyślne.

Uwaga

W bazie danych będzie istniał tylko jeden zestaw z oznaczony jako „Ustawienia konfiguracyjne”. Dla poprawności danych o wynagrodzeniach pobranych z XL HR zaleca się korzystanie z tego zestawu lub z zestawu o identycznych parametrach. Dla zestawu pobranego z ustawień konfiguracyjnych, ustawienia dotyczące serwerów i baz danych nie będą możliwe do zmiany (ikona zapisu zmian będzie nieaktywna).

Do wersji 2016.3.4 Comarch ERP XL zdefiniowanie zestawu transformacji DTS odbywa się z poziomu modułu Administrator (menu: Narzędzia-> Transformacje DTS).  W otwartym oknie zestawu należy uzupełnić parametry automatycznych transformacji  DTS, takie jak: serwer i bazę źródłową (Comarch ERP XL HR), serwer i bazę docelową (Comarch ERP XL), użytkownika SQL i hasło w bazie źródłowej i docelowej.

Import list płac

Import list płac wykonywany jest z poziomu modułu: Księgowość, menu: Płace/Listy płac. W  dolnej części okna, dostępna jest opcja: Import z Optimy.

 

W oknie: Import list płac,  dostępny jest przycisk  , który  uruchamia  przeniesienie nie zaimportowanych list płac z Comarch ERP XL HR.

Z okna: Import list płac, przeniesione listy płac są importowane do okna: Listy płac, za pomocą przycisku .

Uwaga

Importowi  podlegają wyłącznie zamknięte listy płac. Lista płac może zostać zaimportowana z Comarch ERP XL HR do Comarch ERP XL tylko raz. Ponowne zaimportowanie istniejącej w XL-u listy płac jest możliwe tylko po uprzednim usunięciu jej z list płac.

Uwaga

Po zaimportowaniu listy płac do systemu Comarch ERP XL następuje automatyczne oznaczenie tej listy jako zaksięgowanej w systemie Comarch ERP XL HR. Usunięcie listy płac z systemu Comarch ERP XL spowoduje automatyczne usunięcie znacznika „zaksięgowana” na liście płac w systemie Comarch ERP XL HR

Import deklaracji PIT/DRA/PPK

Import deklaracji PIT/DRA/PPK wykonywany jest w sposób analogiczny do importu listy płac. Odbywa się on z poziomu modułu: Księgowość, menu: Płace /Kwoty z deklaracji od wynagrodzeń.

Uwaga

Importowane są tylko zamknięte deklaracje PIT/DRA/PPK.

Import deklaracji wykonywany jest niezależnie od importu listu płac i dotyczy tylko niektórych kwot z deklaracji. W przypadku deklaracji PIT-4 i PIT-8 przenoszone są  kwoty:

Uwaga

Do systemu Comarch ERP XL importowane są tylko niektóre kwoty z deklaracji PIT-4, PIT-8A oraz DRA.

Kwota podatku podlegającego wpłacie tworzy płatność dokumentu na podmiot Urząd Skarbowy wskazany w konfiguracji systemu ( System->Konfiguracja -> HR -> Urząd skarbowy). Płatność podlega rozliczaniu wg.  standardowych zasad rozliczeń.

W przypadku deklaracji DRA przenoszone są :

Na zakładce: Płatności deklaracji DRA, tworzone są płatności dla  urzędu ZUS wskazanego w konfiguracji systemu ( System->Konfiguracja->HR-> ZUS). Od wersji 5 formularza deklaracji DRA płatność nie ulga rozbiciu na ubezpieczenia społeczne, zdrowotne, FP i FGŚP i Fundusz Emerytur Pomostowych. Obecnie generowana jest jedna płatność z przypisaniem do nowego typu rachunku (pobierany z karty urzędu ZUS- tzw. Indywidualny rachunek płatnika).

Typy generowanych płatności:

Płatność podlega rozliczaniu wg.  standardowych zasad rozliczeń.

Na deklarację PPK przenoszona jest:

Na podstawie sumarycznej kwoty składek PPK do zapłaty tworzy się płatność do wybranej przez firmę instytucji finansowej.

Instytucję taką można wprowadzić na liście urzędów, na zakładce: Instytucje finansowe dla PPK, a następnie wskazać ją w konfiguracji firmy na zakładce: HR, w polu: PPK.

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.

Ustawienia ogólne

Dane firmy prezentowane na zakładce: Dane informacji podsumowującej VAT-UE, pobierane są z pieczątki firmy, zakładki: Deklaracje/Deklaracje cd. definiowanej w module: Administrator. Z pieczątki firmy na zakładkę: Podpis pobierane są też dane przedstawiciela.

Istotnym parametrem konfiguracyjnym dotyczącym informacji podsumowującej VAT-UE jest parametr: Nie zaokrąglaj kwot na deklaracjach VAT-7, VAT-UE (Konfiguracja systemu, Księgowość, Parametry 2). Jeżeli zostanie zaznaczony system będzie prezentował niezaokrąglone kwoty na deklaracjach VAT-7, VAT-UE. Bez zaznaczonego parametru system będzie zaokrąglał wykazywane kwoty zgodnie z zasadami matematycznymi.

Uwaga

Niniejszy biuletyn został napisany przy wyłączonym parametrze: Nie zaokrąglaj kwot na deklaracjach VAT-7, VAT-UE.

Formularz informacji podsumowującej VAT-UE

W związku z nowelizacją ustawy o VAT, podatnicy, którzy świadczą usługi wewnątrzwspólnotowe muszą od 1 stycznia 2010r wykazywać te transakcje w informacji podsumowującej.

Informacja podsumowująca VAT-UE jest więc zbiorczym zestawieniem dokonanych wewnątrzwspólnotowych dostaw i nabyć towarów oraz usług rozliczanych przez odbiorcę w danym okresie rozliczeniowym. Okresem tym dla informacji podsumowującej jest obecnie miesiąc.

Uwaga

Od 01.01.2017 r. informacje VAT-UE, VAT-UEK na formularzach w wersji 3 i 4 można składać tylko za okresy miesięczne.

W zależności od opcji wybranej na zakładce VAT-UE okna Deklaracje, program pozwala na wygenerowanie informacji podsumowującej miesięcznej lub kwartalnej. Uniemożliwione zostało natomiast wygenerowanie dwóch informacji za ten sam okres lub okresy nakładające się na siebie. Istnieje także możliwość wyboru odpowiedniego formularza informacji podsumowującej: VAT-UE(4) lub VAT-UE(3) lub VAT-UE(2) oraz VAT-UEK(4) lub VAT-UEK(3) lub VAT-UEK(2). Możliwość wystawienia formularzy VAT-UE(4), VAT-UEK(4) ograniczono tylko do okresów miesięcznych. W przypadku formularzy VAT-UE(3), VAT-UEK(3) również ograniczono ich wystawianie za okresy kwartalne, począwszy od 1 kw. 2017 r. Na formularzu, na którym zostanie wskazany kw. Należący do roku 2017 przycisk „Przelicz” jest nieaktywny.

Uwaga

Od 01.01.2017 r. wprowadzono obowiązek przesyłania formularzy VAT-UE(4), VAT-UEK(4) tylko drogą elektroniczną.

Na informacji podsumowującej VAT-UE kwoty wykazywane są w podziale na nabycia (zakładka: Nabycia), dostawy (zakładka: Dostawy) i usługi (zakładka: Usługi). Na zakładce: Usługi, prezentowane są wewnątrzwspólnotowe dostawy oraz dostawy opodatkowane poza terytorium kraju, jeżeli wskazany parametr rodzajowy to „usługi rozlicza odbiorca”. Grupowanie transakcji odbywa się na podstawie pozycji powiązanych z adresami o tym samym numerze NIP, zdefiniowanymi w ramach jednej lub wielu kart kontrahenta. Dla VAT-UE(2), VAT-UEK(2) oraz VAT-UE(3), VAT-UEK(3) w przypadku, gdy na informacji zabraknie miejsca na podanie informacji o kolejnych nabyciach/dostawach/usługach, system automatycznie tworzy załączniki: VAT-UE/A (dla dostaw), VAT-UE/B (dla nabyć) oraz VAT-UE/C (dla usług rozliczanych przez odbiorcę). Dla VAT-UE(4), VAT_UEK(4) zrezygnowano z załączników VAT-UE/A, VAT-UE/B, VAT-UE/C w miejsce, których wprowadzono rozwijaną liczby wierszy, a przy eksporcie danych do xml usunięto podział wierszy na załączniki.

W polu: Razem na zakładkach prezentowana jest suma wszystkich transakcji, z wyszczególnieniem dostaw/nabyć trójstronnych.

Uwaga

Wyjątek stanowi zakładka Usługi, na której w polu tym prezentowana jest suma transakcji wewnątrzwspólnotowych z wyjątkiem transakcji trójstronnych

Na poszczególnych zakładkach informacji podsumowującej VAT-UE dostępny jest parametr „Wg kontrahentów”. Po jego zaznaczeniu system udostępnia dodatkowy widok prezentujący sumaryczne wartości transakcji według kontrahentów. Na liście prezentowany jest także akronim kontrahenta.

Dodatkowy widok może być przydatny, w przypadku, gdy w danym okresie sprawozdawczym zawarto transakcje z różnymi podmiotami o tym samym numerze NIP, oraz w przypadku, gdy kontrahentom wchodzącym w skład danej grupy np. kapitałowej zmienił się NIP.

Na liście głównej zastosowano sposób prezentacji zgodny z wymaganiami stawianymi przez schemy narzucone odgórnie przez Ustawodawcę (widok główny, formalny). Na liście dodatkowej umieszczono widok uszczegóławiający, wg kontrahentów (widok nieformalny).

Dane w dodatkowym widoku widoczne są po najechaniu kursorem na dany wiesz w widoku głównym. W przypadku VAT-UEK, w widoku tym dopuszczamy do powielenia się numerów NIP w wierszach Było lub Jest, w obrębie kilku grup (na co nie pozwalają schemy).

Przyklad

W danym okresie wystąpiły transakcje z kontrahentem: K1 NIP 111-111-11-11, 5000,00 i K2 NIP 111-111-11-11, 2000,00. Po sporządzeniu informacji VAT-UE, pojawiła się transakcja z kontrahentem K2 o zmienionym NIP z 111-111-11-11, na 222-222-22-22 na kwotę 3000,00 oraz doszła nowa transakcja z K3 NIP 333-333-33-33 na kwotę 4000,00.

Poniżej prezentacja na VAT-UE

W widoku głównym kwoty transakcji z różnymi kontrahentami o tym samym NIP zostały zgrupowane. W widoku dodatkowym prezentację uszczegółowiono, nastąpiło zgrupowanie transakcji per Kontrahent.

Poniżej prezentacja kwot na informacji VAT-UEK

-Wiersz pierwszy:

W widoku formalnym prezentujemy:

Było: „nic”.

Jest: 3333333333 4000,00.

W widoku dodatkowym, prezentacja identyczna jak w widoku formalnym

– Wiersz drugi:

W widoku głównym prezentujemy:

Było: 1111111111 7000,00,

Jest: 1111111111 5000,00.

W widoku dodatkowym prezentacja została rozszerzone o wartość transakcji przypadająca na konkretnego kontrahenta.

Było: 1111111111 K1 5000,00,

Jest: 1111111111 K1 5000,00.

Było: 1111111111 K2 2000,00,

Jest: 2222222222 K2 5000,00.

– Wiersz trzeci:

W widoku formalnym prezentujemy:

Było: „nic”.

Jest: 2222222222 5000,00.

W widoku dodatkowym:

Było: 1111111111 K2 2000,00,

Jest: 2222222222 K2 5000,00.

W informacji podsumowującej VAT-UE ujmowane są tylko takie dokumenty, na których na zakładce: Ogólne ustawiono transakcję wewnątrzwspólnotową, a na zakładce: VAT odznaczono parametr: Nie uwzględniaj na inf. podsumowującej oraz wybrano właściwy typ transakcji:

Nie ma tu znaczenia wysokość stawki podatkowej, gdyż w informacji VAT-UE prezentowane są kwoty netto.

Warto zaznaczyć jeszcze, że transakcja automatycznie ustawia się jako wewnątrzwspólnotowa w przypadku, gdy na dokumencie zostanie wybrany kontrahent unijny. Ustawienia na karcie kontrahenta unijnego prezentuje poniższy rysunek.

Faktury można wystawić także na kontrahenta krajowego lub pozaunijnego. W takim przypadku rodzaj transakcji należy zmienić ręcznie oraz wybrać właściwy kraj przeznaczenia.

Zakładki: Dostawy, Nabycia oraz Usługi na informacji podsumowującej VAT-UE

Dostawy

Po stronie dostaw na informacji podsumowującej VAT-UE ujmowane są następujące dokumenty z ustawieniami:

Faktura sprzedaży eksportowa FSE

Zakładka: Ogólne:

Zakładka: VAT:

Faktura sprzedaży FS

Zakładka: Ogólne:

Zakładka: VAT:

Faktura sprzedaży a’vista (A)FS

Zakładka: Ogólne:

Zakładka: VAT:

Faktura wewnętrzna FW

Zakładka: Ogólne:

Zakładka: VAT:

Faktura wewnętrzna a’vista (A)FW

Zakładka: Ogólne:

Zakładka: VAT:

Faktura eksportowa zaliczkowa FEL

Zakładka : Ogólne:

Zakładka: VAT:

Nabycia

Po stronie nabyć uwzględniane są następujące dokumenty z ustawieniami:

Faktura zakupu FZ

Zakładka: Ogólne:

Zakładka: VAT:

Faktura zakupu – spinacz (S)FZ

Faktura zakupu typu: spinacz, dziedziczy ustawienia rodzaju transakcji ze spinanego dokumentu PZ, tak więc już w momencie wystawiania PZ należy zwrócić na to uwagę. Na PZ parametr: Nie uwzględniaj na inf. podsumowującej jest domyślnie zaznaczony i wyszarzony (podobnie jak inne ustawienia dotyczące VAT). Można nim sterować już po wygenerowaniu (S)FZ.

Zakładka: Ogólne:

Zakładka: VAT:

Faktura wewnętrzna FW

Zakładka: Ogólne:

Zakładka: VAT:

Faktura wewnętrzna a’vista (A)FW

Zakładka: Ogólne:

Zakładka: VAT:

Uwaga

Realizując ścieżkę wewnątrzwspólnotowego nabycia bez modułu: Import, wystawiany jest dokument FZ. W celu naliczenia podatku VAT po stronie sprzedaży, należy, zgodnie z tą ścieżką, wystawić dokument (A)FW jako wewnątrzwspólnotowe nabycie z parametrem: Nie uwzględniaj na inf. podsumowującej -zaznaczonym. Jeśli Użytkownik parametr ten odznaczy, kwota nabyć wynikająca z tej transakcji będzie na informacji podsumowującej VAT-UE zdublowana: najpierw zostanie wzięta z FZ, a następnie z (A)FW.

Faktura wewnętrzna zakupu FWZ

FWZ jest dokumentem wystawianym w ścieżce realizującej wewnątrzwspólnotowe nabycie w module: Import. Dokument ten jest generowany z faktury wewnętrznej sprzedaży FWS, i po niej dziedziczy ustawienia typu transakcji, a więc:

Zakładka: Ogólne:

Zakładka: VAT:

Faktura wewnętrzna FWS

Zakładka: Ogólne:

Zakładka: VAT:

Uwaga

 Realizując ścieżkę wewnątrzwspólnotowego nabycia w module: Import generowany jest dokument FWS, na którym parametr: Nie uwzględniaj na inf. podsumowującej jest domyślnie zaznaczony. Jeżeli Użytkownik parametr ten odznaczy, to kwota nabyć wynikająca z tej transakcji będzie na informacji podsumowującej VAT-UE zdublowana: najpierw zostanie wzięta z FWS, a następnie z FWZ.

Faktura zakupu zaliczkowa FZL

Zakładka: Ogólne:

Zakładka: VAT:

Usługi

Po stronie usług uwzględniane są następujące dokumenty z ustawieniami:

Faktura sprzedaży FS

Zakładka: Ogólne:

Zakładka: VAT:

Faktura sprzedaży eksportowa FSE

Zakładka: Ogólne:

Zakładka: VAT:

Faktura eksportowa zaliczkowa FEL

Zakładka: Ogólne:

Zakładka: VAT:

Uzgadnianie informacji podsumowującej VAT-UE z rejestrem VAT

Podczas uzgadniania informacji podsumowującej VAT-UE z rejestrem VAT należy pamiętać o tym, iż pewne rodzaje dokumentów ujmowane są zawsze w rejestrach sprzedaży, ale w informacji VAT-UE mogą być prezentowane albo po stronie nabyć, albo po stronie dostaw, w zależności od typu transakcji wybranego na zakładce VAT dokumentu. Są to:

Jest to szczególnie istotne przy weryfikacji wewnątrzwspólnotowych nabyć, o czym będzie mowa w rozdziale: Uzgodnienie nabyć.

Uzgadniając informację podsumowującą VAT-UE z rejestrem VAT należy posłużyć się wydrukiem: Raport pod VAT-UE, dostępnym z poziomu rejestru VAT, zakładka: Informacje podsumowujące. Kwoty wyliczone na informacji powinny być zgodne z kwotami prezentowanymi na wydrukach.

Uzgodnienie dostaw

W celu uzgodnienia dostaw należy wykonać wydruk przy następujących ustawieniach:

Uzgodnienie nabyć

W celu uzgodnienia nabyć należy wykonać dwa wydruki przy następujących ustawieniach:

1. Ustawienia rejestru: zakładka Informacje podsumowujące, rejestry zakupu
   Wykonywany wydruk: Raport pod VAT-UE (zakup)

   

2. Ustawienia rejestru: zakładka Informacje podsumowujące, rejestry sprzedaży.
   Wykonywany wydruk: Raport pod VAT-UE (sprzedaż), rodzaj transakcji: Nabycia.

   

Kwoty z obydwu wydruków należy zsumować, a otrzymany wynik powinien być zgodny z wielkością nabyć wyliczoną w informacji podsumowującej VAT-UE. Bardzo ważne jest wykonanie drugiego wydruku, gdyż uwzględnia on m.in. faktury wewnętrzne wystawione jako wewnątrzwspólnotowe nabycie – czyli na informacji VAT-UE wliczane do nabyć, ale w rejestrach prezentowane po stronie sprzedaży.

Uzgodnienie usług rozliczanych przez odbiorcę

W celu uzgodnienia usług rozliczanych przez odbiorcę należy wykonać wydruk przy następujących ustawieniach:

 

Wstęp

Z początkiem nowego roku w życie weszły przepisy tzw. ustawy antyzatorowej. W efekcie nieterminowi płatnicy muszą się liczyć się z nowymi karami. Pakiet wprowadził między innymi ulgę na złe długi w podatkach dochodowych PIT i CIT. Na największe podmioty nałożył także obowiązek raportowania praktyk płatniczych.

Firmy, które generują największe zatory, muszą liczyć się z możliwością interwencji ze strony UOKiK. Postępowania kontrolne będą prowadzone względem podmiotów, u których w ciągu trzech kolejnych miesięcy suma przeterminowanych należności przekroczy 5 mln zł, natomiast od 1 stycznia 2022 roku – 2 mln zł.

Przepisy dot. ulgi na złe długi, nałożyły na nabywcę obowiązek skorygowania, tj. zwiększenia podstawy opodatkowania/zmniejszenia straty za nieterminową zapłatę. Z kolei sprzedawcy dały prawo do pomniejszenia podstawy opodatkowania/zwiększenia straty. Poniżej, więcej informacji na ten temat.

Regulacje prawne po stronie wierzyciela

Regulacje prawne po stronie dłużnika

Ulga za złe długi w PIT/CIT a regulacje prawne w VAT

Dostępne narzędzia w systemie Comarch ERP XL wspierające korygowanie podstawy opodatkowania/straty w „uldze na złe długi”.

Nowe regulacje prawne nakładają na nabywcę obowiązek zwiększenia podstawy opodatkowania lub zmniejszenia straty, jeżeli zobowiązanie, które po stronie sprzedawcy jest źródłem powstania przychodu nie zostanie uregulowane w ciągu 90 dni od upływu terminu płatności. Nie ma znaczenia, czy nabywca ujął transakcję po stronie kosztów uzyskania przychodów.

Biorąc pod uwagę powyższe, istotnym elementem przeciwdziałania zwiększeniu podstawy opodatkowania jest analiza płatności pod kątem przeterminowania.

System Comarch ERP XL dysponuje narzędziami analitycznymi pozwalającymi na śledzenie płatności pod kątem okresu przeterminowania. Analizy można dokonać z poziomu:

Dostępne są także raporty pozwalające między innymi na „kubełkowanie” płatności wg okresów przeterminowania.

Analiza z poziomu listy rejestrów VAT

Na liście rejestrów VAT dostępne są filtry, pozwalające na analizę dokumentów pod kątem przeterminowania. Funkcjonalność została wprowadzona na potrzeby korygowania VAT z tyt. „ulgi za złe długi”.

Wspomniane filtry dostępne są z poziomu sekcji Płatności. Po jej uaktywnieniu, użytkownik ma możliwość:

W podatkach dochodowych, w przypadku czynnych podatników VAT do kosztów uzyskania przychodów na ogół zaliczana jest kwota netto. Nieodliczona kwota podatku VAT co do zasady nie jest ujmowana w KUP. Są jednak od tej zasady wyjątki. Przykładem jest np. zakup samochodu osobowego wykorzystywanego na cele przedsiębiorstwa i prywatne. 50% podatku podlega odliczeniu, 50% zwiększa wartość początkową, czyli podstawę amortyzacji. Jeżeli faktura nie zostanie uregulowana w ciągu 90 dni podstawę opodatkowania należy skorygować o kwotę netto. Wydaje się, że także o kwotę podatku nieodliczonego. W celu ustalenia kwoty korekty, na liście rejestrów VAT można skorzystać z filtra Odliczenie VAT, posiłkować się opcjami:

„Ulga za złe długi” dotyczy transakcji handlowych zawartych w ramach działalności wierzyciela oraz działalności dłużnika, z których dochody podlegają opodatkowaniu podatkiem dochodowym na terytorium Rzeczpospolitej Polskiej. Z poziomu listy rejestrów VAT dostępne są filtry, które pozwalają na zawężenie dokumentów wg rodzaju transakcji. W tym przypadku listę należy zawęzić do transakcji krajowych.

Wierzyciel może skorzystać z ulgi za złe długi, pod warunkiem, że dłużnik na ostatni dzień miesiąca poprzedzającego dzień złożenia zeznania podatkowego nie jest w trakcie postępowania restrukturyzacyjnego, postępowania upadłościowego lub w trakcie likwidacji. Z poziomu listy rejestrów VAT dostępny jest filtr pozwalający na ograniczenie dokumentów do tych, które są powiązane z kontrahentami, którzy nie są w stanie likwidacji/upadłości.

Przyklad

Zarejestrowano FZ-1/19: Netto: 10.000,00 VAT: 2.300,00 Brutto: 12.300,00

Tabela VAT

Pozycja 1: Netto: 5.000,00 VAT: 1.150,00 Brutto: 6.150,00 odliczenie TAK

Pozycja 2: Netto: 5.000,00 VAT: 1.150,00 Brutto: 6.150,00 odliczenie NIE

Płatności:

Termin pł.: 30.10.19 12.300,00

Rozliczenie: 30.12.19  4.000,00

Pozostaje: 8.300,00

Pozostaje: 20.02.20 8.300,00

Ujęcie w kosztach kwoty netto + nieodliczonej kwoty VAT, która przypada na kwotę płatności pozostającej do rozliczenia.

Wsp. Udział kwoty pozostającej do rozliczenia w sumie płatności:
8.300 x 100 / 12.300 = 67,4796747967%

Kwota Netto przypadająca na kwotę nierozliczoną: 10.000 x wsp. = 6.747,97

Kwota VAT nieodliczona przypadająca na kwotę nierozliczoną: 1.150 x wsp = 776,02

Razem kwota korekty: 7.523,99

Poniżej zrzuty z systemu Comarch ERP XL operujące na ww. kwotach

Preliminarz płatności

Z poziomu listy rejestrów VAT analiza ogranicza się do płatności powiązanych z fakturami VAT. Wg ustawy o ograniczeniu zatorów płatniczych korekta może dot. transakcji udokumentowanych nie tylko fakturami VAT ale także rachunkami, czy też umowami.

W analizie warto zatem posiłkować się także narzędziami udostępnionymi z poziomu preliminarza płatności, które pozwalają na wylistowanie należności/zobowiązań nierozliczonych, o okresach przeterminowania zbliżających się do 90 dni, lub wynoszących więcej niż 90 dni i rodzących konieczność dokonania korekty podstawy opodatkowania.

„Struktura wiekowa” należności i zobowiązań

Z poziomu listy kontrahentów, zakładki Wg akronimu udostępniono raporty pozwalające na analizę nierozliczonych lub rozliczonych płatności (należności, zobowiązań) wg przedziałów przeterminowania.

Raporty dostępne są z poziomu menu wydruków Archiwalne należności i zobowiązania.

Użytkownik ma możliwość zdefiniowania własnych przedziałów przeterminowania, choć domyślne, pozwalają na sprawdzenie, czy w przedziale od 91 dni istnieją przeterminowane płatności.

Zapisy korygujące podstawę opodatkowania/stratę

W „uldze na złe długi” w podatku VAT oraz w przepisach dot. przeciwdziałania zatorom płatniczym w podatkach dochodowych okres przeterminowania, po którym należy dokonać korekty jest identyczny, wynosi 90 dni licząc od pierwszego dnia po upływie terminu płatności. Można zatem przyjąć, że korekcie podatku VAT na ogół będzie towarzyszyła korekta podatku dochodowego.

Korekty można dokonać:

Dokumenty (ZD)FS i (ZD)FZ podlegają księgowaniu. W księgach rachunkowych korekcie podatku VAT naliczonego może towarzyszyć zapis na koncie pozabilansowym, który będzie korygował podstawę opodatkowania w podatku dochodowym.

W przypadku zapisów korygujących po stronie kosztów zalecamy księgowanie na kontach pozabilansowych po stronie DT, ze znakiem ujemnym.

W przypadku zapisów korygujących po stronie przychodów zalecamy księgowanie na kontach pozabilansowych po stronie CT, ze znakiem ujemnym.

Powyższe zalecenia wynikają ze zmian wprowadzonych na formularzu CIT-2 w wersji 2020.0, o których mowa w kolejnym punkcie.

Przyklad

Zarejestrowano FZ-1/19, kwota Netto: 10.000, VAT: 2.300

Termin pł. 30.10.2019 r.

FZ zawiera dwie pozycje w tabeli VAT:

Poz. 1. 5.000 1.150 Odliczenie Tak

Poz. 2. 5.000 1.150 Odliczenie Nie

Kwota do rozliczenia na dzień 20.02.2020: 8.300,00

Wygenerowano (ZD)FZ z pozycjami:

Poz. 1. -3.373,98 -776,02 Odliczenie Tak

Poz. 2. -3.373,98 -776,02 Odliczenie Nie

Księgowanie

Korekta podatku VAT naliczonego (zwiększenie po stronie podatku należnego)

776,02 22-1 VAT należny / 24 Pozostałe rozrachunki

Korekta po stronie podatku dochodowego – dekret, który zwiększy podstawę opodatkowania, przy założeniu, że VAT nieodliczony także koryguje podstawę opodatkowania

-7.523,98 99-0 Konto pozabilansowe/—

Korekta po stronie kosztów: (-6.747,96 )+ (-776,02) = -7.523,98

Poniżej zrzuty z systemu:

Wyliczenie zaliczki na podatek dochodowy

Wyliczenie zaliczki w wersji Comarch ERP XL 2019.3.2 oraz w wersjach wcześniejszych

W wersji 2019.3.2 oraz w wersjach wcześniejszych, formularz CIT-2 nie jest dostosowany do wyliczenia zaliczki na podatek dochodowy z uwzględnieniem korekt z tyt. przeciwdziałania zatorom płatniczym. W tej sytuacji użytkownik może posiłkować się zestawieniami księgowymi.

Zmiany na formularzu w CIT-2 w wersji Comarch ERP XL 2020.0

Zmiany na formularzu CIT-2 opisane poniżej, wprowadzone w wersji Comarch ERP XL 2020.0 zostaną uwzględnione także w wersji 2019.3.3.

Na formularzu CIT-2, pod polami 35 (Podstawa opodatkowania) i 36 (Strata) dodano sześć nowych pól, pozwalających na wprowadzenia korekt na podstawie przepisów dot. przeciwdziałania zatorom płatniczym. Celem nowych pól jest umożliwienie skorygowania podstawy opodatkowania lub straty na podstawie nieuregulowanych wierzytelności bądź zobowiązań.

Pod polem 36 ‘Strata’ dodano trzy pola (od 37 do 39) poprzedzone informację o treści: KOREKTA Z TYT. „ULGI ZA ZŁE DŁUGI”

Pole 37 o nazwie ‘Korekta przychodu’

Pole 38 o nazwie Korekta kosztu

Pole 39 o nazwie Korekta – pole także definiowalne. Domyślnie prezentowana jest różnica pól 37 i 38. Można zrezygnować z ujmowania korekt w osobnych polach 37 i 38. i wprowadzić własną definicję w polu 39.

Pod polem 39 dodano pola:

Pole 40. Podstawa opodatkowania po korekcie

Przyklad

Przykład 1

Pole	Opis	Kwota
35	Podstawa opodatkowania	15.000,00
37	Korekta po stronie przychodu	-10.000,52
38	Korekta po stronie kosztu	-2.111,86
39	Korekta	(-10.000,52-(-2.111,86)= -7.888,66
40	Podst.opodatk. po korekcie	15.000+(-7.888,66) = 7.111,34 ≈ 7.111

Przykład 2

Pole	Opis	Kwota
35	Podstawa opodatkowania	15.000,00
37	Korekta po stronie przychodu	-20.000,52
38	Korekta po stronie kosztu	-2.111,86
39	Korekta	-20.000,52 - (- 2.111,86) = -17.888,66
40	Podst.opodatk. po korekcie	15.000 + (-17.888,66) = 0
42	Nierozliczona „Ulga za złe długi”	15.000 +(-17.888,66) = -2.888,66

Przykład 3

Pole	Opis	Kwota
35	Podstawa opodatkowania	15.000,00
37	Korekta po stronie przychodu	-10.000,52
38	Korekta po stronie kosztu	-12.111,86
39	Korekta	-10.000,52 - (-) 12.111,86 = 2.111,34
40	Podst.opodatk. po korekcie	15.000 + 2.111,34 = 17.111,34 ≈ 17.111

Pole 41. Strata po korekcie

Przyklad

Przykład 4

Pole	Opis	Kwota
36	Strata	15.000,00
37	Korekta po stronie przychodu	-10.000,52
38	Korekta po stronie kosztu	-12.111,86
39	Korekta	-10.000,52 - (-) 12.111,86 = 2.111,34
41	Strata po korekcie	15.000 - 2.111,34 = 13.111,34 ≈ 13.111

Przykład 5

Pole	Opis	Kwota
36	Strata	15.000,00
37	Korekta po stronie przychodu	-10.000,52
38	Korekta po stronie kosztu	-2.111,86
39	Korekta	-10.000,52 –(-2.111,86) =- 7.888,66
41	Strata po korekcie	15.000 – (-7.888,66) = 22.888,66 ≈ 22.889

Przykład 6

Pole	Opis	Kwota
36	Strata	15.000,00
37	Korekta po stronie przychodu	-10.000,52
38	Korekta po stronie kosztu	-32.111,86
39	Korekta	-10.000,52 –(- 32.111,86) = 22.111,34
41	Strata po korekcie Wykazujemy 0,00, ponieważ strata nie może być ujemna. Różnicę ze znakiem przeciwnym ujmujemy w polu 40	15.000 – (22.111,34) = -7.111.34 < 0
40	Podst. opodatk. po korekcie	7.111

Pole 42. Nierozliczona „Ulga za złe długi” – pole o charakterze czysto informacyjnym. W polu tym prezentowana jest nierozliczona wartość korekty, w przypadku, gdy wartość w polu 35 Podstawa opodatkowania będzie większa od zera, ale kwota korekty zmniejszającej podstawę opodatkowania będzie większa od kwoty wykazanej w polu 35.

Rachunek walutowy – zasady funkcjonowania w świetle przepisów prawa bilansowego i prawa podatkowego

Jednostki gospodarcze, zgodnie z obowiązującymi przepisami prawa dewizowego, mogą przechowywać środki pieniężne w walutach obcych na własnym rachunku walutowym w banku, z którego usług korzystają.

Wycena operacji wyrażonych w walutach obcych wg przepisów UoR

Kwestie związane z wyceną operacji wyrażonych w walutach obcych reguluje art. 30 ust 1 i 2 UoR. Ustawa określa zasady wyceny na dzień bilansowy oraz zasady wyceny operacji następujących w trakcie roku obrotowego.

Wyrażone w walutach obcych operacje gospodarcze ujmuje się w księgach rachunkowych na dzień ich przeprowadzenia – o ile odrębne przepisy dotyczące środków pochodzących z budżetu Unii Europejskiej i innych krajów Europejskiego Obszaru Gospodarczego oraz środków niepodlegających zwrotowi, pochodzących ze źródeł zagranicznych nie stanowią inaczej – odpowiednio po kursie:

Z punktu widzenia przepisów Ustawy o rachunkowości, wycena obrotów z tytułu transakcji w dewizach jest przeprowadzona wg przytoczonego powyżej artykułu Ustawy o rachunkowości. Rozchód waluty z rachunku powinien następować według metod wskazanych w art. 34 ust. 4, pkt 1-3 UoR (nie powstaną wówczas RK na rachunku walutowym, powstaną natomiast na kontach rozrachunkowych). Nie jest również sprzeczne z UoR wycenianie rozchodu według kursu sprzedaży banku przy jednoczesnym ustalaniu różnic kursowych od własnych środków pieniężnych.

Wycena operacji wyrażonych w walutach obcych wg przepisów ustawy o podatku dochodowym

Zgodnie z art. 9b ust.1 ustawy o CIT podatnicy ustalają różnice kursowe wg dwóch zasad:

W kontekście tych uregulowań podatnicy, którzy wybiorą opcję drugą, rozliczają różnice kursowe wg zasad UoR i mają one charakter zarówno bilansowy jak i podatkowy. Zatem konto walutowe może funkcjonować według zasad wynikających z Ustawy o rachunkowości i wszystkie związane z tym różnice kursowe będą uznane również za element wyniku podatkowego. Jednostka może dokonywać wyceny wpływu dewiz wg kursu faktycznego wynikającego z charakteru operacji, rozchodu wg metody FIFO (czyli bez ustalania RK od własnych środków pieniężnych) oraz przyjąć zasadę dokonywania wyceny środków pieniężnych tylko na dzień bilansowy.

Podatnicy, którzy wybiorą opcję pierwszą w myśl art. 15 a ust. 8 CIT – także powinni wyznaczać kolejność wyceny środków lub wartości pieniężnych w walucie obcej, o której mowa w ust. 2 pkt 3 i ust. 3 pkt 3, według przyjętej metody stosowanej w rachunkowości, której nie mogą zmieniać trakcie roku podatkowego.

Metody wyceny środków pieniężnych wyrażonych w walucie obcej

Zgodnie z obowiązującymi ustawami możliwe są następujące sposoby przeprowadzania wyceny:

Założenia wyceny rozchodu środków pieniężnych wyrażonych w walutach obcych

W Comarch ERP XL istnieje możliwość prowadzenia wyceny rozchodu środków pieniężnych wyrażonych w walutach obcych na poziomie rejestru kasowo/bankowego, potocznie zwana magazynem walut. Z funkcjonalnością wprowadzonego sposobu dokonywania wyceny związane są dwa aspekty: kolejność kojarzenia KP z KW (rozliczenie wg FIFO, LIFO) oraz wycena wg kursu pobieranego z KP wg kolejności kojarzenia (LIFO, FIFO) bądź kursu wprowadzanego z ręki.

Definicje FIFO, LIFO

Pod pojęciami FIFO, LIFO należy rozumieć:

Rozliczenie wg. FIFO, LIFO

W systemie Comarch ERP XL została wprowadzona możliwość rozliczenia (skojarzenia) KP z KW wg metod FIFO, LIFO (parametr: Wycena na definicji rejestru kasowo/bankowego). Wybranie opcji: FIFO lub LIFO będzie wpływało na sposób kojarzenia zapisów rozchodowych z zapisami przychodowymi. Zapis rozchodowy zostanie rozliczony (skojarzony) z zapisami przychodowymi wg wskazanej metody kojarzenia FIFO lub LIFO. Istnieje również możliwość rezygnacji z takiego skojarzenia dokumentów KP z KW, poprzez wybór ustawienia: Brak na definicji rejestru walutowego (dotychczasowe działanie systemu). W tym ostatnim przypadku rozliczanie KP z KW będzie możliwe tylko na poziomie dekretów. Kurs, który będzie podpowiadany na zapisach rozchodowych będzie zgodny z dotychczasowym działaniem programu, a więc będzie pobierany zgodnie z ustawieniami na definicji wykorzystywanej operacji. Opis dotychczasowego sposobu dokonywania wyceny (do wersji 8.0) został opisany w biuletynie technicznym pt. Wycena rozchodu środków pieniężnych wyrażonych w walutach obcych.

W rejestrze z określonym typem wyceny: FIFO lub LIFO na poziomie całego rejestru istnieje możliwość wprowadzania jedynie zapisów rozchodowych zgodnych z tym typem. Sposobu skojarzenia zapisów KW z zapisami KP nie można zmienić na wprowadzanych zapisach rozchodowych, musi on być zgodny, z tym który został wybrany dla całego rejestru. A więc w rejestrze z metodą wyceny określoną jako FIFO rozliczenie będzie następowało wg FIFO, w rejestrze z metodą określoną jako LIFO – jako LIFO.

Wycena wg. FIFO, LIFO.

Podczas wprowadzania zapisów kasowo/bankowych w ramach rejestru z określonym sposobem skojarzenia wyceny, na wprowadzonych zapisach istnieje możliwość wybrania kursu po jakim ma następować wycena, zgodnego z typem skojarzenia określonym na całym rejestrze. Kurs zgodny z metodą skojarzenia podpowiada się jako domyślny. A więc w rejestrze z typem określonym jako FIFO, podczas wprowadzania zapisu rozchodowego domyślnie podpowiadany jest kurs zgodny z tą metodą, a więc kurs wg FIFO. Analogicznie w rejestrze z typem określonym jako LIFO, na zapisach rozchodowych domyślnie podpowiadany jest kurs LIFO. Nie istnieje natomiast możliwość wskazania kursu zgodnego z drugim sposobem wyceny, a więc w ramach rejestru o typie FIFO, nie można określić kursu jako LIFO, i na odwrót.

Warto zauważyć, że pomimo stosowania metod FIFO, LIFO, w programie Comarch ERP XL na wprowadzanych zapisach kasowo/bankowych rozchodowych umożliwiono także wycenę wg innego kursu, wprowadzonego z ręki. Taki kurs możliwy jest do wprowadzenia, jeśli na rozchodowym zapisie kasowo/bankowym zostanie wybrana opcja: Kurs: Ustalony. Wówczas zapis zostanie przeliczony po kursie wprowadzonym przez Użytkownika, a nie kursie wynikającym z zastosowanej metody wyceny. Taka funkcjonalność może mieć zastosowanie w kilku sytuacjach, np: – odsprzedaży waluty do banku po kursie ustalonym przez bank, podczas korzystania z kredytu w rachunku bieżącym walutowym. W sytuacji odsprzedaży waluty do banku rozliczenie (kojarzenie) będzie wg FIFO, lub LIFO, natomiast wycena wg kursu kupna banku, któremu jednostka sprzedaje dewizy.

Wycena rozchodu środków pieniężnych wyrażonych w walutach obcych

Zakładka Kurs/Wycena

W związku z wprowadzeniem funkcjonalności magazynu walut zmianie uległ wygląd zakładki Kurs/Wycena na zapisie kasowo/bankowym. Zakładka ta została uzupełniona o informacje: o sposobie dokonywanego skojarzenia dokumentów przychodowych z rozchodowymi (parametr: Rozliczenie wg: ), o typie pobranego kursu (parametr Kurs wg: – jeśli kurs zostanie określony jako Ustalony na zapisie istnieje możliwość podania wartości kursu), o kwocie jaka pozostaje do wyceny (pole: Pozostaje do wyceny: ), o kwocie różnic kursowych z wyceny (pole: Kwota RK: ).

Na zakładce Kurs/wycena pojawiła się również tabelka, w której prezentowane są dokumenty, które biorą udział w wycenie. Dokumenty te prezentowane są w kolorze zielonym, jeśli program proponuje je do wyceny lub na czarno, jeśli wycena została już dokonana i dokumenty biorą w niej udział. W sytuacji kiedy do wyceny proponowany jest zapis KP późniejszy niż wyceniane KW, oznaczony on będzie dodatkowo żółtym tłem.

Dokonanie wyceny i ustalanie wartości zapisu rozchodowego

Wycena rozchodu środków pieniężnych wyrażonych w walutach obcych dokonywana jest na zakładce Kurs/Wycena rozchodowego zapisu kasowo/bankowego. Podczas wprowadzania zapisu rozchodowego, jeśli w danym rejestrze znajdują się odpowiednie zasoby środków pieniężnych, program proponuje, które zapisy mogą zostać skojarzone z wprowadzanym zapisem rozchodowym. Zapisy proponowane są przez program wg wybranej dla danego rejestru metody. Proponowane zapisy prezentowane są w kolorze zielonym. Dokonanie wyceny następuje poprzez naciśnięcie przycisku: [Wyceń]. Wybór tego przycisku powoduje zaakceptowanie zaproponowanej przez program propozycji wyceny i powiązanie przedstawionych zapisów przychodowych z wprowadzanym zapisem rozchodowym. Dodanie wyceny możliwe jest tylko z poziomu zapisu rozchodowego, na zapisie przychodnym wykonanie wyceny nie jest dostępne. Jeśli na zapisie rozchodowym kurs ma być pobierany wg metody LIFO lub LIFO, wartość i kwota pozostająca do rozliczenia w PLN takiego zapisu jest nieznana do momentu dokonania wyceny. Kwoty te prezentowane są w wysokości 0 PLN, jeśli zapis nie jest wyceniony.

Po dokonaniu wyceny, zostaje ustalona wartość w PLN wprowadzanego rozchodowego zapisu kasowo/bankowego na podstawienie wartości skojarzonych z nim zapisów przychodowych. Warto zauważyć, że w takiej sytuacji dokonaniu wyceny nie towarzyszy naliczenie różnic kursowych od własnych środków pieniężnych.

Jeśli natomiast kurs określony jest jako Ustalony, wartość, kwota pozostaje do rozliczenia i kwota pozostaje do wyceny wprowadzanego zapisu od razu przeliczane są również na walutę systemową. W takiej sytuacji od razu znana jest wartość w PLN dodawanego zapisu, mimo że nie został on jeszcze wyceniony.

Tak jak to już zostało przedstawione powyżej wycena dokonywana jest zgodnie z propozycją przedstawioną przez program wg przyjętej metody. Jeśli okaże się, że w danym rejestrze brak jest wystarczających zasobów pieniężnych do dokonania wyceny przy kursie określonym jako FIFO lub LIFO, program poinformuje o tym w momencie dokonywania wyceny. Po wybraniu przycisku: Wyceń pojawi się komunikat, informujący o tym, że zapis został wyceniony tylko częściowo. Identyczna informacja pojawi się, gdy zapis nie zostanie w ogóle wyceniony, np. z powodu braku zapisów przychodowych w rejestrze.

W efekcie częściowej wyceny na zakładce Kurs/Wycena wartość zapisu ustalona jest tylko częściowo na podstawie skojarzonego zapisu przychodowego. W polu: Pozostaje do wyceny zawarta jest informacja, jaka kwota z tego zapisu będzie jeszcze podlegała wycenie. Kwota ta podawana jest tylko w walucie obcej, gdyż jej wartość w walucie systemowej nie jest znana do momentu dokonania wyceny.

Natomiast w przypadku częściowej wyceny (z powodu braku odpowiednich zapisów przychodowych) zapisu rozchodowego wprowadzanego z kursem Ustalonym, program ustala pełną wartość zapisu w PLN oraz informuje o braku możliwości dokonywania całkowitej wyceny. Po wybraniu przycisku: Wyceń pojawia się komunikat, informujący o braku zapisów przychodowych koniecznych do rozliczenia wyceny. Wycena dokona się w takiej sytuacji tylko częściowo. Identyczna informacja pojawi się, gdy zapis nie zostanie w ogóle wyceniony, np. z powodu braku zapisów przychodowych w rejestrze.

W efekcie częściowej wyceny zapisu rozchodowego z kursem Ustalonym na zakładce Kurs/Wycena w polu: Pozostaje do wyceny zawarta jest informacja, jaka kwota z tego zapisu będzie jeszcze podlegała wycenie. Wartość pozostająca do wyceny podana w takim przypadku jest w walucie systemowej oraz w walucie obcej, gdyż znana jest wartość kursu (kurs: Ustalony) po jakim ta kwota ma zostać przeliczona.

Przedstawiony powyżej sposób dokonywania wyceny dotyczy wyceny dokonywanej świadomie przez Użytkownika programu w momencie dodawania zapisu rozchodowego. Wycena rozchodu środków pieniężnych jest również automatycznie wykonywana przez program zgodnie z przyjętą na rejestrze metodą w sytuacjach opisanych poniżej. Wycena taka następuje zgodnie z uwagami podanymi powyżej, i co jest w tym związane, przytoczone komunikaty podczas dokonywania tej wyceny również mogą się pojawić. Wycena automatyczna następuje w poniższych sytuacjach:

 

 

 

W logu pojawiającym się w momencie dokonywania wyceny, znajduje się informacja o wycenionych, w ramach każdego ze wskazanych raportów, zapisach rozchodowych.

Wycena przez wskazanie

Od wersji 11.0 wprowadzona została funkcjonalność wyceny przez wskazanie.

Na formatce zapisu kasowo/bankowego, w oknie raportu oraz w na zakładce: Raporty rejestru kasowo/bankowego dodany został przycisk: [Wycena przez wskazanie].

Analogicznie, jak w przypadku opisywanej powyżej opcji – Wyceń, podczas wprowadzania zapisu rozchodowego, jeśli w danym rejestrze znajdują się odpowiednie zasoby środków pieniężnych, program proponuje, które zapisy mogą zostać skojarzone z wprowadzanym zapisem rozchodowym. Zapisy proponowane są przez program wg wybranej dla danego rejestru metody. Opcja – wycena przez wskazanie umożliwia operatorowi wybór zapisów, które mają brać udział w wycenie. Po naciśnięciu ikony [Wycena przez wskazanie] zostanie otwarte okno: Lista zapisów do wyceny, w którym system do wskazania udostępni zapisy przychodowe, których timestamp jest wcześniejszy od timestamp zapisu wycenianego. W przypadku zaznaczenia kilku zapisów o różnych datach, system wyceni/rozliczy zapisy w kolejności wybranej na rejestrze (FIFO/LIFO), bądź w kolejności zaznaczenia, w zależności od wybranej opcji w sekcji: Kolejność wyceny.

Usuwanie wyceny

Usuwanie dokonanej wyceny możliwe jest na zapisie kasowo/bankowym na zakładce Kurs/Wycena. Usunięcie wyceny dostępne jest pod przyciskiem: [Skasuj wycenę]. Skasowanie wyceny powoduje powrót do sytuacji, gdy program przedstawia propozycję dotyczącą skojarzenia tego zapisu z zapisami przychodowymi znajdującymi się w tym rejestrze. Skasowanie wyceny możliwe jest tylko z poziomu zapisu rozchodowego, na zapisie przychodnym usunięcie wyceny nie jest dostępne. Wycenę można usunąć do momentu zaksięgowania zapisu rozchodowego.

Jeśli na zapisie kasowo/bankowym rozchodowym kurs jest określony jako FIFO lub LIFO, usunięcie wyceny powoduje cofnięcie ustalenia wartości tego zapisu w walucie systemowej. W takiej sytuacji wartość tego zapisu w walucie systemowej ponownie wynosi 0 PLN. Usunięcie wyceny w takim przypadku możliwe jest, jeśli zapis kasowo/bankowy nie jest rozliczony. Jeśli taki zapis rozchodowy został rozliczony/skompensowany usunięcie skojarzenia wyceny nie będzie możliwe, gdyż na postawie wyceny została ustalona wartość tego zapisu.

Jeśli na zapisie rozchodowym zostanie wskazany kurs Ustalony, usunięcie wyceny z poziomu zakładki Kurs/Wycena również powoduje powrót do przedstawienia przez program propozycji wyceny. Wartość zapisu w walucie systemowej nie ulega jednak wyzerowaniu, gdyż wliczona jest ona na podstawie kursu Ustalonego. Usunięcie wyceny z poziomu zapisu możliwe jest do momentu dokonania rozliczenia/skompensowania tego zapisu.

Przedstawiony powyżej sposób usuwania wyceny dotyczy usuwania dokonywanego świadomie przez Użytkownika programu w poziomu zapisu rozchodowego. Usunięcia wyceny rozchodu środków pieniężnych można również dokonać w sytuacjach opisanych poniżej. Takie usunięcie następuje zgodnie z uwagami podanymi powyżej. Usunięcie wyceny możliwe jest również w poniższych sytuacjach:

Uwaga

Jeśli zachodzi potrzeba usunięcia skojarzenia wyceny zaksięgowanych zapisów, aby móc to uczynić należy odksięgować raport, w którym znajdują się wycenione zapisy. Po odksięgowaniu raportu usunięcie wyceny możliwe jest do przeprowadzenia zgodnie z informacjami podanymi powyżej.

Różnice kursowe związane z wyceną

Wycenie wg FIFO, LIFO nie towarzyszy naliczenie różnic kursowych, chyba że Użytkownik zrezygnuje z kursu podpowiadanego wg jednej z w/w metod i wprowadzi kurs z ręki, jako tzw. kurs Ustalony. Po dokonaniu skojarzenia takiego dokumentu KW (wprowadzonego po kursie Ustalonym) z KP, zostaje utworzony dokument różnicy kursowej, który otrzymuje status: Wycena. Dokument ten jest automatycznie księgowany, jeśli księgowany jest ostatni z dokumentów biorących udział w wycenie. Księgowanie to następuje automatycznie bez względu na ustawienia w konfiguracji systemu dotyczące sposobu księgowania dokumentów różnicy kursowej. Dokument różnicy kursowej księgowany jest na konto rachunku walutowego, które przypięte jest do rejestru, w którym dokonywana jest wycena oraz odpowiednio na konto ujemnych lub dodatnich różnic kursowych. Warunkiem koniecznym prawidłowego zaksięgowania takiego dokumentu różnicy kursowej, jest określenie konta przypisanego do rejestru kasowo/bankowego walutowego jako konta rozrachunkowego. W przypadku określenia kursu na KW jako Ustalonego z dokumentem mogą być związane dwa typy różnic kursowych: wynikające z wyceny (KP <-> KW) oraz ze standardowego rozliczenia (KW <-> Faktura).

Różnice kursowe z wyceny podpinane są na zakładce Kurs/Wycena zapisu kasowo/bankowego o wyższym kursie bez względu na to czy jest to zapis rozchodowy czy przychodowy. Na drugim zapisie biorący udział w wycenie, kwota wynikająca z różnicy kursowej prezentowana jest natomiast w polu: Kwota RK.

Różnice kursowe z wyceny prezentowane są również na zakładce: Stan raportu, w którym wycena ta została dokonana.

Uwaga

Różnica kursowa dotycząca wyceny zawsze powstaje w formie dokumentu różnicy kursowej o statusie: Wycena. Taki dokument tworzony jest nawet w sytuacji, gdy w konfiguracji systemu Comarch CDN XL zaznaczone jest, aby różnice tworzone były w formie dekretu różnicy kursowej

Księgowanie raportu z wycenionymi zapisami

Księgowanie wycenionego rozchodowego zapisu kasowo/bankowego następuje zgodnie z ogólnymi zasadami księgowania raportów kasowo/bankowych. W związku z tym, że wartość zapisu rozchodowego ustalana jest na podstawie kursów skojarzonych z nim zapisów przychodowych, jeśli na zapisie rozchodowym kurs zostanie wskazany jako określony wg metody FIFO lub LIFO, zapis rozchodowy księgowany jest po kursie wynikającym z tego skojarzenia.

Jeśli na zapisie rozchodowym kurs zostanie wskazany jako określony wg metody FIFO lub LIFO i zapis ten zostanie skojarzony z więcej niż jednym zapisem przychodowym, wartość zapisu rozchodowego zostanie ustalona na podstawie wszystkich skojarzonych z nim zapisów przychodowych. W takiej sytuacji po zaksięgowaniu raportu, z danym zapisem rozchodowym będzie powiązanych tyle dekretów wynikowych, ile zostało z tym zapisem skojarzonych zapisów przychodowych. Każdemu skojarzeniu odpowiada w takiej sytuacji osobny dekret. Takie księgowanie zapisu rozchodowego wynika z faktu, iż wartość tego zapisu została ustalona na podstawie kilku zapisów przychodowych, z których każdy był wprowadzony po innym kursie. Aby różnice kursowe związane z rozliczeniem transakcji wyliczały się w przyszłości prawidłowo, takie księgowanie zapisu, w podziale na zastosowane kursy, jest konieczne.

Jeśli zapis rozchodowy zostanie wprowadzony po kursie określonym jako Ustalony, a następnie zostanie skojarzony z więcej niż jednym zapisem przychodowym, to w wyniku jego zaksięgowania zostanie utworzony tylko jeden dekret wynikowy, gdyż wartość tego zapisu i kurs po jakim został wprowadzony jest ustalona, a nie wyliczana na podstawie zapisów skojarzonych.

Rozrachunek dekretów związanych z wyceną

Rozrachunek związany z wyceną rozchodu środków pieniężnych wyrażonych w walutach obcych dokonywany jest na koncie rozrachunkowym przypisanym do rejestru, w którym dokonywana jest wycena. Rozrachunek taki powstaje automatycznie w momencie zaksięgowania ostatniego raportu biorącego udział w wycenie. Dekrety zapisów przychodowych i rozchodowych zostają ze sobą rozrachowane w taki sam sposób, w jaki zostały ze sobą skojarzone zapisy.

Jeśli wykorzystywana jest funkcjonalność wyceny rozchodu środków pieniężnych wyrażonych w walutach obcych, to zaksięgowaniu skojarzonych zapisów musi towarzyszyć powstanie rozrachunku związanego z wyceną na koncie przypisanym do rejestru. W programie nie może mieć miejsca sytuacja, gdy mimo istnienia wyceny na zaksięgowanych zapisach kasowo/bankowych, na dekretach rozrachunek nie został utworzony. Rozrachunek dekretów zawsze w takim przypadku tworzony jest automatycznie przez program.

Warto podkreślić, że w systemie nie ma możliwości usunięcia wyceny poprzez skasowanie rozrachunków, które są z nią związane, powstałych na koncie rozrachunkowym rejestru. Podczas próby usunięcia takich rozrachunków pojawia się poniższy komunikat.

Usunięcie wyceny jest możliwe tylko sposób przedstawiony w podrozdziale: Wycena przez wskazanie.

Zmiana sposobu wyceny

W związku z tym, że sposób wyceny ustalany jest na poziomie całego rejestru, możliwy jest do ustalenia tylko raz podczas wprowadzania rejestru, bez możliwości zmiany. Po wprowadzeniu w rejestrze pierwszego raportu, opcja dotycząca wyceny na definicji tego rejestru ulega wyszarzeniu. Jeśli w kolejnym roku obrachunkowym zostaje podjęta decyzja o zmianie sposobu dokonywania wyceny należy założyć nowy rejestr kasowo/bankowym z nowym typem wyceny.

Uwaga

W momencie dokonywania konwersji bazy z wersji 8.0 na istniejących rejestrach kasowo/bankowych walutowych opcja: Wycena automatycznie ustawiana jest na Brak. Ustawienia tego parametru w takim przypadku nie można zmienić. Aby korzystać z funkcjonalności tzw. magazynu walut należy założyć nowy rejestr z odpowiednim sposobem wyceny

Raport o typie: Bilans Otwarcia

W raportach kasowo/bankowych walutowych istnieje możliwość wprowadzenia raportu: Bilans Otwarcia. Raport wprowadzony jako raport bilansu otwarcia oznaczony jest znacznikiem: RBO. W ramach tego raportu mogą być wprowadzane niewycenione zapisy z rejestru, w którym wycena była dokonywana tylko na kontach księgowych, np. w poprzedniej wersji programu, albo niewycenione zapisy pochodzące z rejestru o innym typie wyceny. Raport Bilansu Otwarcia może zostać wprowadzony mimo iż w rejestrze już istnieją raporty bieżące. Domyślnie raport ten otwierany jest z datą i godziną o dwie sekundy wcześniejszą niż pierwszy raport w tym rejestrze.

Uwaga

Jeżeli raport RBO zostanie wprowadzony po wprowadzeniu jakiegokolwiek raportu bieżącego, należy usunąć wycenę z wszystkich wprowadzonych raportów i wycenić je ponownie.

Na raporcie dostępne są parametry:

Odksięgowanie takiego raportu RBO możliwe jest jedynie z poziomu tego raportu, za pomocą opcji: Usuń dekret dostępnej spod prawego przycisku myszy.

Obsługa magazynu walut z zaznaczonym parametrem: Wycena rozchodu środków pieniężnych zapisami późniejszymi.

Do wersji 10.5 włącznie, w przypadku wyboru wyceny wg FIFO/LIFO, rozchód wyceniany jest na podstawie dokumentów przychodu, których data wystawienia (timestamp) jest wcześniejsza od daty dokumentu rozchodu. Nie ma możliwości wyceny rozchodu zapisami wystawionymi w terminie późniejszym. Z uwagi na sytuację, w której saldo na rachunku walutowym może mieć wartość ujemną np.: w związku z zaciągniętym kredytem a’konto spłaty bieżących zobowiązań, w wersji 11.0 wprowadzono możliwość wyceny zapisów rozchodowych z zapisami przychodowymi, których data wystawienia (timestamp) jest późniejsza od daty dokumentu rozchodu.

W takim przypadku wycena (ustalenie kursu) będzie możliwa wg:

Dodatkowo, pomimo kursu ustalonego (wprowadzonego ręcznie) rozliczenie (kojarzenie zapisów rozchodowych z przychodowymi) będzie możliwe wg zasad:

Parametr „Wycena rozchodu środków pieniężnych zapisami późniejszymi” wprowadzony został w wersji 11.0 i znajduje się na zakładce: Ogólne rejestru kasowo/bankowego.

Aktywacja parametru umożliwia wycenę/rozliczenie zapisów rozchodowych z zapisami przychodowymi, których data wystawienia (timestamp) jest późniejsza od daty dokumentu rozchodu.

Po zaznaczeniu parametru „Wycena rozchodu śr. pieniężnych zapisami późniejszymi możliwa jest:

Po zaznaczeniu parametru „Wycena rozchodu śr. pieniężnych zapisami późniejszymi” i wykorzystaniu opcji: Wycena przez wskazanie, możliwa jest:

Wycena rozchodu środków pieniężnych wyrażonych w walucie obcej – przykłady

Poniższe przykłady zaprezentują ogólnie rozumiane rozrachunki od strony dokumentów oraz dekretów i pozwolą lepiej zrozumieć sposób wyceny walutowych środków pieniężnych w systemie Comarch ERP XL.

Przykład 1 – wycena wg kursu FIFO lub LIFO

W poniższym przykładzie założono, że sposób wyceny na definicji rejestru został określony jako FIFO, a na zapisach rozchodowych kurs również został określony jako FIFO. Wszystkie poniższe operacje zostały wprowadzone w kwocie 100 EUR.

Zapisy zostały wprowadzone do rejestru kasowo – bankowego wg następującej kolejności:

Operacje biorące udział w rozliczeniach:

Ewidencja i rozrachunek dekretów związanych z w/w operacjami

Podczas wprowadzania zapisów rozchodowych, kurs na nich zostaje ustalony wg kursu pobranego ze skojarzonych z nimi zapisów przychodowych zgodnie z metodą FIFO. Skojarzenie zapisów nie powoduje w takim przypadku powstania różnic kursowych. Skojarzenie zapisów rozchodowych z zapisami przychodowymi nie powoduje ich wzajemnego rozliczenia, wobec czego dokumenty te mogą zostać rozliczone/skompensowane z innymi dokumentami. Dopiero w wyniku takiego rozliczenia/skompensowania powstają różnice kursowe. Po zaksięgowaniu wszystkich zapisów biorących udział w wycenie (po zaksięgowaniu raportów z tymi zapisami) na koncie rozrachunkowym „133 – Rachunek dewizowy” utworzony zostaje automatycznie rozrachunek pomiędzy dekretami skojarzonych ze sobą zapisów przychodowych i rozchodowych. W związku z tym nie ma potrzeby wykonywania dodatkowego rozrachunku ręcznie na dekretach pochodzących z zaksięgowania zapisów kasowo – bankowych.

Reasumując:

W powyższym przykładzie na koncie „133 Rachunek dewizowy” rozrachunek związany z wyceną rozchodu środków pieniężnych wyrażonych w walutach obcych został wykonany automatycznie w momencie zaksięgowania raportów, w których znajdują się zapisy biorące udział w skojarzeniu wyceny. W takiej sytuacji nie ma potrzeby ręcznego dokonywania rozrachunków. W tym przypadku nie zostały utworzone różnice kursowe związane z wyceną, gdyż kurs na zapisach rozchodowych był ustalany na podstawie kursów skojarzonych z nim zapisów przychodowych.

Przykład 2 – wycena wg kursu Ustalonego

W poniższym przykładzie założono, że sposób wyceny na definicji rejestru został określony jako FIFO, a na zapisach rozchodowych kurs został określony jako Ustalony. Wszystkie poniższe operacje zostały wprowadzone w kwocie 100 EUR, a kurs podany na zapisach rozchodowych był różny od kursu na zapisach przychodowych.

Zapisy zostały wprowadzone do rejestru kasowo – bankowego wg następującej kolejności:

Operacje biorące udział w rozliczeniach:

Ewidencja i rozrachunek dekretów związanych z w/w operacjami

Podczas wprowadzania zapisów rozchodowych, kurs na nich jest określony jako Ustalony. Zapisy te są kojarzone z niewycenionymi zapisami przychodowymi wg przyjętej na definicji rejestru metody kojarzenia, która w tym przypadku jest metodą FIFO. Skojarzenie zapisów powoduje w takim przypadku powstanie różnic kursowych z wyceny. Skojarzenie zapisów rozchodowych z zapisami przychodowymi nie powoduje ich wzajemnego rozliczenia, wobec czego dokumenty te mogą zostać rozliczone\skompensowane z innymi dokumentami. W wyniku takiego rozliczenia\skompensowania również powstają różnice kursowe. W tym przypadku są to różnice kursowe związane z realizacją transakcji. Po zaksięgowaniu wszystkich zapisów biorących udział w wycenie (po zaksięgowaniu raportów z tymi zapisami) na koncie rozrachunkowym „133 – Rachunek dewizowy” utworzony zostaje automatycznie rozrachunek pomiędzy dekretami skojarzonych ze sobą zapisów przychodowych i rozchodowych. Podczas księgowania raportów automatycznie księgowane są również różnice kursowe związane z wyceną rozchodu środków pieniężnych. Księgowanie przebiega na konto przypisane do definicji rejestru i odpowiednio konto dodatnich lub ujemnych różnic kursowych. Takie różnice kursowe są integralną częścią rozrachunku. W związku z tym, że różnice kursowe księgowane są automatycznie i rozrachunek na kontach powstaje również automatycznie nie ma potrzeby wykonywania dodatkowego rozrachunku ręcznie na dekretach pochodzących z zaksięgowania zapisów kasowo – bankowych.

Reasumując:

W powyższych przykładach na koncie „133 Rachunek dewizowy” rozrachunek związany z wyceną rozchodu środków pieniężnych wyrażonych w walutach obcych został wykonany automatycznie w momencie zaksięgowania raportów, w których znajdują się zapisy biorące udział w skojarzeniu wyceny. W takiej sytuacji nie ma potrzeby ręcznego dokonywania rozrachunków. W tym przypadku zostały utworzone różnice kursowe związane z wyceną, gdyż kurs na zapisach rozchodowych był podany jako kurs Ustalony.

Problem wyceny walutowych środków pieniężnych prześledzimy teraz na konkretnych danych liczbowych w następnym przykładzie.

Przykład 3 – wycena wg kursu FIFO, przez wskazanie na rejestrze z zaznaczonym parametrem: Wycena rozchodu środków pieniężnych zapisami późniejszymi.

W poniższym przykładzie założono, że sposób wyceny na definicji rejestru został określony jako FIFO, a na zapisach rozchodowych kurs również został określony jako FIFO. Wszystkie poniższe operacje zostały wprowadzone w kwocie 100 EUR.

Zapisy zostały wprowadzone do rejestru kasowo – bankowego wg następującej kolejności:

Operacje biorące udział w rozliczeniach:

Ewidencja i rozrachunek dekretów związanych z w/w operacjami

Podczas wprowadzania zapisów rozchodowych, kurs na nich zostaje ustalony wg kursu pobranego ze skojarzonych z nimi zapisów przychodowych zgodnie z metodą FIFO. Skojarzenie zapisów nie powoduje w takim przypadku powstania różnic kursowych. Skojarzenie zapisów rozchodowych z zapisami przychodowymi nie powoduje ich wzajemnego rozliczenia, wobec czego dokumenty te mogą zostać rozliczone/skompensowane z innymi dokumentami. Dopiero w wyniku takiego rozliczenia/skompensowania powstają różnice kursowe. Po zaksięgowaniu wszystkich zapisów biorących udział w wycenie (po zaksięgowaniu raportów z tymi zapisami) na koncie rozrachunkowym „133 – Rachunek dewizowy” utworzony zostaje automatycznie rozrachunek pomiędzy dekretami skojarzonych ze sobą zapisów przychodowych i rozchodowych. W związku z tym nie ma potrzeby wykonywania dodatkowego rozrachunku ręcznie na dekretach pochodzących z zaksięgowania zapisów kasowo – bankowych.

Przykład 4 – liczbowy

Przedsiębiorstwo prowadzi rachunek dewizowy w Euro.

W celu rejestracji na koncie księgowym wpływów, wydatków środków pieniężnych w walucie obcej założono następujące konta:

„133 Rachunek dewizowy” (konto bilansowe, rozrachunkowe, waluta konta – PLN)

„933 Rachunek dewizowy” (konto pozabilansowe, rozrachunkowe, waluta konta – EUR)

Powiązano ze sobą konta 133 i 933

Założono rejestr kasowy o nazwie „MW”, któremu przypisano walutę EUR oraz konto pozabilansowe, walutowe, rozrachunkowe, „933”, powiązane z kontem bilansowym, złotówkowym, rozrachunkowym, „133 Rachunek dewizowy”. Metoda wyceny została określona jako FIFO.

W miesiącu październiku miały miejsce następujące operacje:

W ramach rejestru wprowadzamy następujące dokumenty KP, KW:

Poniżej lista walutowych operacji kasowych/bankowych zarejestrowanych w systemie Comarch ERP XL.

Podczas wprowadzania zapisów rozchodowych dokonywana jest wycena wprowadzonych zapisów zgodnie z przyjętym na zapisie kursem: FIFO lub Ustalonym, oraz dokonywane jest skojarzenia zapisów przychodowych z rozchodowymi zgodnie z przyjęta metodą kojarzenia określoną na definicji rejestru, w tym przypadku metodą FIFO.

Wycena rozchodu środków pieniężnych w rejestrze EURO:

Jak widać z prezentowanego przykładu, wartość rozchodowanych środków pieniężnych w walucie PLN, po uwzględnieniu różnic kursowych wynosi 127.440,00 PLN.

Poniżej prezentacja zapisów księgowych w PLN na koncie 133 „Rachunek dewizowy” oraz w walucie obcej 933 „Rachunek dewizowy” w systemie Comarch ERP XL – po zaksięgowaniu wyciągu bankowego, czyli po uwzględnieniu wyceny również na poziomie konta rozrachunkowego przypisanego do rejestru, w którym następuje kojarzenie operacji rozchodowych z przychodowymi.