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.

Częściowa likwidacja środka trwałego

Częściowa likwidacja środka trwałego to inaczej zmniejszenie jego wartości. W celu przeprowadzenia częściowej likwidacji środka trwałego należy wystawić dla tego środka dokument MW (modyfikacja wartości) na kwotę, o którą ma ulec zmniejszeniu wartość środka trwałego. Na dokumencie odpowiednią kwotę należy wpisać ze znakiem minus. Na dokumencie MW należy wyprowadzić:

Zmniejszenie wartości środka trwałego

Wystawienie dokumentu MW

Dla częściowej likwidacji środka trwałego należy wystawić dla tego środka dokument MW (Modyfikacja Wartości). Wszystkie kwoty na dokumencie powinny być kwotami ujemnymi. Dla środka amortyzowanego dwutorowo, na dokumencie MW (Modyfikacja wartości) aktywne są obie kwoty: Podstawa BIL i Podstawa POD. Przy wystawianiu dokumentu MW dla takiego środka należy podać kwotę bilansową, o jaką ma być zmniejszona wartość inwentarzowa środka. Pozostałe kwoty zostaną automatycznie wyliczone przez system i wpisane we właściwe pola.

Po wystawieniu dla środka trwałego amortyzowanego dwutorowo dokumentu MW zmniejszającego jego wartość, automatycznie zostaną zaktualizowane kwoty i środek trwały będzie można dalej amortyzować generując prawidłowe dokumenty AM.

Wstęp

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

Poza wymienionymi, istnieje również możliwość definiowania odpowiednich testów, w zależności od potrzeb Użytkownika, przy wykorzystaniu wyrażenia SQL (zakładka Testy definiowane). Ponadto, można określić zakres czasowy, dla którego będzie wykonywany test i tym samym otrzymania wyników odnoszących się właśnie dla tego przedziału czasowego. Takich ustawień, jak również parametryzacji zapuszczanych testów integralności związanych np. z poziomem szczegółowości loga, dokonuje się na zakładce: Ogólne, okna: Testy integralności.

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

Ogólne zasady analizy komunikatów

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

Przyklad

Niepoprawny typ rejestru kasowego 26, nazwa Bank BPH S.A., KAR_GID (752:1:2:0). Przedrostek KAR_GID wskazuje na tabelę Rejestry (patrz dokumentacja tabel), cyfry w nawiasach to: 752 – pole KAR_GIDTyp 1 – pole KAR_GIDFirma 2 – pole KAR_GIDNumer 0 – pole KAR_GIDLp

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

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

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

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

Proponowane rozwiązanie: ponowne wystawienie upomnienia.

Test: Zgodność kasy

Poprawność stanów kasowych

Porównywane są raporty kasowe/bankowe z zapisami. Sprawdzana jest zgodność pól KRP_PrzychodyWal (oraz KRP_RozchodyWal) z sumą pól KAZ_Kwota. Jeżeli waluta systemowa jest różna od waluty raportu, test sprawdza zgodność pól KRP_Przychody (oraz KRP_Rozchody) z sumą KAZ_Kwota (przeliczoną po odpowiednim kursie na walutę systemową). W przypadku wystąpienia niezgodności pojawia się następujący komunikat:

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

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

Poprawność rejestrów i operacji kasowych

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

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

Rozwiązanie: Należy wykonać odpowiedni update na pole KAR_Typ. (Patrz dokumentacja tabel). Następnie sprawdzana jest poprawność operacji kasowych. Pole KAO_Typ przyjmuje wartości: Jeżeli jedna operacja przyjmuje kilka typów to wartość w tym polu wyliczana jest jako suma poszczególnych typów (przykładowo Kasa+Karta w polu KAO_TYP przyjmuje wartość 5). Błąd opisany jest komunikatem:

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

Rozwiązanie: Należy ustawić odpowiedni typ na definicji operacji kasowej/bankowej. (Narzędzia / operacje kasowo/bankowe) W ostatnim etapie kontrolowana jest poprawność operacji kasowych/bankowych względem poszczególnych rejestrów. Komunikat błędu wygląda następująco:

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

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

Test: Zgodność rozrachunków

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

Zgodność rozrachunków z dekretami

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

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

Tego typu błąd zgłaszany jest w następujących przypadkach (problem przedstawiony w zależności od tabeli, której dotyczy): W ujęciu technicznym warunek generujący błąd wygląda następująco: DT_Kwota – DT_Pozostaje jest różne od sumy ROZ_Kwota (w przypadku gdy waluta dekretu nie jest walutą systemową) lub ROZ_KwotaSys (gdy waluta dekretu = waluta systemowa) Rozwiązanie: Naprawy powyższych zaburzeń trzeba dokonać poprzez wybranie z menu modułu: Administrator, funkcji specjalnej: Uzgadnianie rozliczeń/rozrachunków. Funkcja powoduje m.in. uaktualnienie kwoty: Pozostaje na dekretach księgowych, zapisach kasowych/bankowych, płatnościach dokumentów – tak, aby stanowiła ona równowartość różnicy kwoty, na którą wprowadzony jest dekret, zapis, płatność oraz sumy rozliczeń.

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

Rekord zgłasza błąd o niezgodności parametrów zapisu księgowego: w tabeli Dekrety dekret posiada parametr nierozliczony (pole DT_Nierozliczony=1), natomiast analizując ten sam dekret w programie zauważamy, że kwota Pozostaje na Rozrachunkach jest równa 0 (zatem DT_Pozostaje=0, DT_Rozliczony=1). Remedium stanowi uruchomienie funkcji specjalnej: Uzgadnianie rozliczeń i rozrachunków, w wyniku czego nastąpi uzgodnienie parametrów: DT_Nierozliczony, DT_Pozostaje. Może również wystąpić sytuacja odwrotna, tzn. dekret posiada parametr: DT_Nierozliczony=0 oraz DT_Pozostaje różne od 0, co zgłaszane jest w logu następująco:

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

W celu naprawy, należy uruchomić funkcję specjalną: Uzgadnianie rozliczeń i rozrachunków. Również  uruchamiamy tę funkcję w przypadku błędu typu:

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

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

Zgodność rozrachunków z rozliczeniami

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

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

Rozliczenie, zaksięgowanie dokumentów na konto rozrachunkowe (rozrachunkowe specjalne) w oparciu o tabelę płatności nie zostało poprawnie obsłużone, w kontekście spójności rozliczeń z rozrachunkami. Naprawy tego typu błędów można wykonać w następujący sposób: Jeśli przyczyną był niepoprawnie skonstruowany schemat księgowy trzeba odksięgować rozliczone ze sobą dokumenty i następnie wykonać ponowne księgowanie tych dokumentów zmodyfikowanym poprawnie ułożonym schematem księgowań, jeżeli z kolei problem był efektem błędu oprogramowania należy ponownie zaksięgować dokumenty wersją programu uwzględniającą poprawkę błędu (uaktualnienie HR).

Rozrachunki dokonane bez wykorzystania dekretu kompensacyjnego

Test zgłasza błąd:

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

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

Test: Zgodność rozliczeń

Zgodność rozliczeń z zapisami kasowymi

W pierwszym etapie test sprawdza następujace warunki: -dla KAZ_Waluta=KAZ_WalutaRoz sprawdzane jest zgodność różnicy KAZ_Kwota - KAZ_Pozostaje z sumą kwot ROZ_Kwota. W przypadku niezgodności pojawia się komunikat:

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

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

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

Kwota “Pozostaje do rozliczenia” na zapisie bankowym/kasowym jest różna od kwoty “Pozostaje do rozrachowania” na dekrecie wynikowym, na konto rozrachunkowe pochodzącym z zaksięgowania tego zapisu bankowego/kasowego. Rozwiązanie: Należy uruchomić funkcję z apteczki uzgadniającą kwoty Pozostaje: Uzgadnianie rozliczeń/rozrachunków. W drugim etapie test weryfikuje poprawność flag (rozliczony/nierozliczony) na poszczególnych zapisach. Błąd zwracany jest w następujących sytuacjach: Komunikat o błędzie w w/w przypadkach wygląda następująco:

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

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

Zgodność rozliczeń z płatnościami

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

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

W dalszej części test dokonuje kontroli następującego warunku: TrP_Kwota – TrP_Pozostaje = suma Roz_Kwota W przypadku, gdy powyższe równanie nie jest spełnione test generuje komunikat:

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

Rozwiązanie: Należy uruchomić funkcję specjalną: Uzupełnienie rozliczeń/rozrachunku (tabela TraPlat). Kolejna część testu porównuje flagi płatności z kwotą pozostałą do rozliczenia. Można wyróżnić dwie nieprawidłowe sytuacje: Jeśli jeden z powyższych warunków został spełniony, system zwraca komunikat:

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

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

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

W pierwszym etapie kontrolowana jest zgodność dokumentów zawartych na różnicy kursowej z wpisami w tabeli rozliczenia. Test dokonuje porównania następujących pól: z tabeli RożniceKursowe: RKN_Dok1Typ, RKN_Dok1Numer, RKN_Dok1Lp, RKN_Dok2Typ,  RKN_Dok2Numer, RKN_Dok2Lp z polami z tabeli Rozliczenia: r2_Dok1Typ, r2_Dok1Numer, r2_Dok1Lp, r2_Dok2Typ, r2_Dok2Numer, r2_Dok2Lp W razie wykrycia niezgodności test zwraca komunikat:

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

Rozwiązanie Należy dokonać ponownego rozliczenia dokumentów.

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

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

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

Rozwiązanie: Dokonać ponownego rozrachunku.

Test: Sprawdzenie kompletności księgowań

Sprawdzenie istnienia dekretów wynikowych

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

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

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

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

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

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

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

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

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

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

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

Sprawdzenie istnienia nagłówka dekretu wynikowego

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

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

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

Sprawdzenie ilości księgowań dokumentów

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

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

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

Sprawdzenie kompletności księgowania raportów

Test sprawdza czy dany raport kasowy/bankowy został zaksięgowany i porównuje jego status z przypisanymi mu zapisami kasowymi/bankowymi. Błąd generowany jest w dwóch sytuacjach: Komunikat zwracany w przypadku wystąpienia nieprawidłowości wygląda następująco:

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

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

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

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

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

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

W kolejnym etapie kontrolowana jest zgodność pomiędzy rekordami dekretu i dziennika. Test sprawdza poniższe warunki: DT_Rok <> DZK_Rok DT_Miesiac <> DZK_Miesiac DT_Dzien <> DZK_Dzien DT_Dziennik <> DZK_Dziennik DT_Bufor <> DZK_Bufor W przypadku, gdy jeden z powyższych warunków zostanie spełniony, system zgłasza komunikat o błędzie. Jego tekst został zaprezentowany ponizej:

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

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

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

Test dokonuje kontroli poprawności dekretów poprzez sprawdzenie następującego warunku: DZK_SumaDt-DZK_SumaCt=0 W przypadku niezgodności pojawia się komunikat:

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

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

Sprawdzenie czy konta na dekretach istnieją w tabeli Konta

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

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

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

Sprawdzenie czy dekrety mają wypełnione pole DT_Dziennik

W przypadku nieprawidłowości test zwraca komunikat:

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

Rozwiązanie W większości zgłaszanych przypadków, należy dokonać poprawy poprzez usunięcie dekretu wynikowego dokumentu i następnie ponowne jego zaksięgowanie. Jeżeli istnieją w bazie problemy związane ze sklejonymi dekretami (dekrety pochodzące z różnych dokumentów mają identyczne gidnumery DT_GidNumer) można posłużyć się poniższym selectem dla ich namierzenia: select a.dzk_gidnumer, case a.dzk_bufor when '' then '' else '(' + a.dzk_bufor + ')' end +a.dzk_dziennik + '/' + cast(a.dzk_rok%100 as char(2)) + '/' + cast(a.dzk_miesiac as char(2))+ '/' + cast(a.dzk_rmnumer as varchar(5)) 'Numer pk',case b.dzk_bufor when '' then '' else '(' + b.dzk_bufor + ')' end + b.dzk_dziennik + '/' + cast(b.dzk_rok%100 as char(2)) + '/' + cast(b.dzk_miesiac as char(2))+ '/' + cast(b.dzk_rmnumer as varchar(5)) 'NumeR pojedynczego' from cdn.dziennik a join cdn.dziennik b on a.dzk_gidnumer=b.dzk_gidnumer where a.dzk_gidlp=0 and b.dzk_gidlp<0 order by a.dzk_gidnumer W przypadku istnienia tego typu błędów, naprawy należy dokonać usuwając dekret wynikowy z błędnym DT_GidNumer i dokonać ponownego zaksięgowania dokumentu bądź ponownie wprowadzić dekret, jeśli nie miał on powiązań z tabelą cdn.Zrodla.

Sprawdzenie poprawności dekretów w okresie obrachunkowym

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

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

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

Test: Poprawność kont i ich stanów

Sprawdzenie poprawności numerów kont

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

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

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

Zgodność stanów kont

Test sprawdza dla każdego okresu zgodność stanów kont analitycznych. Test oparty został o następujące warunki: DTS_ObrotyDebetBuf=suma(Dt_Kwota) dla DT_DC=1 DTS_ObrotyCreditBuf=suma(Ct_Kwota) dla DT_DC=2 DTS_ObrotyDebet=suma(Dt_Kwota) dla DT_DC=1 DTS_ObrotyCredit=suma(Ct_Kwota) dla DT_DC=2 W przypadku nieprawidłowości test zwraca poniższy komunikat:

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

Rozwiązanie Uruchomić funkcję specjalną – odbudowa stanów kont. Test sprawdza dla każdego okresu zgodność kont syntetycznych z ich analityką. Test został oparty o poniższe warunki: DTS_ObrotyDebet = suma (DTS_ObrotyDebet z analityki) DTS_ObrotyCredit = suma (DTS_ObrotyCredit z analityki) DTS_ObrotyDebetBuf = suma (DTS_ObrotyDebetBuf z analityki) DTS_ObrotyCreditBuf = suma (DTS_ObrotyCreditBuf z analityki) Jeśli powyższe warunki nie zostaną spełnione system zwraca komunikat:

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

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

Sprawdzenie istnienia kont w okresach obrachunkowych, ustawienia waluty

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

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

Rozwiązanie Wykonać update na pole KKS_Waluta. W dalszym etapie waluta pobrana z konta porównana jest z walutami zdefiniowanymi w systemie. W przypadku gdy waluta na koncie nie ma swojego odpowiednika w systemie generowany jest komunikat:

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

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

Sprawdzenie konta zapisu

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

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

Rozwiązanie Nie istnieje uniwersalne rozwiązanie problemu. Należy dokonać analizy zastanej sytuacji i odpowiedzieć na następujące pytania: Czy konto powinno mieć podpięta analitykę (system dopuszcza księgowanie na konto syntetyczne jeśli nie ma ono podpietej analityki – należy zaznaczyć odpowiednie ustawienie w konfiguracji)? Czy dekrety zostały wprowdzone na odpowiednie konto? W zależności od uzyskanych odpowiedzi modyfikacje dotyczyć będą dekretów księgowych bądź kont.

Test: Noty memoriałowe

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

Test dokonuje kontroli następujących warunków: W przypadku błędu pojawia się komunikat:

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

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

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

W pierwszym etapie test sprawdza miejsce określenia podmiotu na definicji noty memoriałowej. Dla not ,którym: kontrolowana jest tabela MemNag pod względem prawidłowości wpisów. Pola dotyczące kontrahentów dla tak zdfiniowanych not powinny przyjmować wartość 0. Jeśli jest inaczej test zwraca poniższy komunikat:

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

Rozwiązanie Należy podnieść notę do edycji i ponownie zapisać. W następnej kolejności test kontroluje czy podmiot określony na nocie memoriałowej ma swój odpowiednik w tabelach KntKarty (dla kontrahentów) lub PrcKarty (dla pracowników). W przypadku stwierdzenia niezgodności generowany jest komunikat jak poniżej:

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

Rozwiązanie Należy podnieść notę do edycji i wybrać ponownie kontrahenta/pracownika. W kolejnym etapie kontrolowana jest zgodność typu noty memoriałowej wg poniższych warunków: W przypadku gdy jeden z powyższych warunków nie został spełniony, system generuje komunikat:

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

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

Test: Bilans otwarcia

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

Test sprawdza prawidłowość powiązań pomiędzy bilansem otwarcia a jego płatnościami. Błędy zgłaszane przez program mogą dotyczyć dwóch sytuacji: Rozwiązanie Nie istnieje uniwersalne rozwiązanie w/w problemów. Należy przeanalizować każdy ze zwróconych rekordów z osobna opierając się na poniższych warunkach łączenia płatności z dokumentem BO. BOs_trpTyp=TrP_GIDTyp and BOs_trpFirma=TrP_GIDFirma and BOs_trpNumer=TrP_GIDNumer and BOs_trplp=TrP_GIDlp

Zakończenie

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

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

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.

Uwaga

W opisie analitycznym listy płac zaimportowanej do systemu Comarch ERP XL uwzględniane są wyłącznie składniki, które stanowią koszt pracodawcy, a więc na definicji składnika w systemie Comarch ERP XL  HR mają zaznaczony parametr: Stanowi koszt pracodawcy

.

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 HR 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 HR (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. Koszt całkowity/Zmniejszenia
2. Brutto/ZUS pracodawcy/PPK pracodawcy/Zmniejszenia
3. Netto/Podatek/ZUS pracobiorcy/ZUS pracodawcy/PPK pracobiorcy/PPK pracodawcy/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) + PPK pracobiorcy Koszt całkowity: Brutto + ZUS pracodawcy (wyliczony tak jak powyżej) + PPK 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: Wartości poszczególnych składników opisu analitycznego wyliczane są pomocą funkcji  [CDN].[PobierzKwotyPIK] , która przyjmuje poniższe parametry:

Przyklad

Przykład użycia funkcji [CDN].[PobierzKwotyPIK] Użycie funkcji [CDN].[PobierzKwotyPIK]

Przykładowe zmniejszenia w opisie analitycznym

Na wypłacie pracownika naliczonej w Comarch ERP XL HR (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 opisanymi 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 3 elementy – wynagrodzenie brutto 6000, pomniejszenie brutto w wysokości 100 oraz przychód z tytułu PPK 63,44

Uwaga

W związku z opodatkowaniem składki PPK pracodawcy, na liście płac w Comarch ERP XL prezentowany jest element wypłaty: Przychód z tytułu PPK, dla którego naliczany jest podatek należny od części składki finansowanej przez pracodawcę. Ponieważ sama składka naliczana jest osobno i to ona stanowi koszt pracodawcy, ten dodatkowy element wypłaty, nie ma ustawionego parametru 'Stanowi koszt pracodawcy' na definicji w Comarch ERP XL HR. Zgodnie z funkcjonalnością systemu Comarch ERP XL nie  jest on uwzględniany w opisie analitycznym. Naliczony dla tego elementu podatek oraz pomniejszenie wartości netto również nie są widoczne na opisie analitycznym. W kolejnych wersjach systemu będą wprowadzane zmiany w tym obszarze.

Ujęcie kosztów w wariancie „Netto”

Pokazuje on wynagrodzenie w układzie: Netto/Podatek/ZUS pracobiorcy/ZUS pracodawcy/PPK pracobiorcy/PPK 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ę wynagrodzenia na poziomie pracownika.

Nazwa pozycji	Wartość	Uwagi
Netto	4.198,44	Wartość samego wynagrodzenia (kwoty>0)
Podatek	401,00
ZUS pracobiorcy	1.310,04	Narzuty od obu składników (kwoty >0): 595,36+ 91.50+ 149.45+473.73
ZUS pracodawcy	1.147,41	Narzuty od obu składników (kwoty >0): 595,36 + 396,50 + 149,45 + 6,10
PPK pracobiorcy	122,00
PPK pracodawcy	91,50
Zmniejszenia	-31.48	Brutto lub netto<0

Ujęcie kosztów w wariancie „Brutto”

Pokazuje on wynagrodzenie w układzie: Brutto, ZUS pracodawcy, PPK 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	6.031,48	Netto + Podatek + ZUS pracobiorcy + PPK pracobiorcy: 4198,44 + 401,00 + ( 595,36+ 91.50+ 149.45+473.73)+ 122
ZUS pracodawcy	1.147,41	Narzuty od obu składników (kwoty >0): 595,36 + 396,50 + 149,45 + 6,10
PPK pracodawcy	91,50
Zmniejszenia	-31.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	7270,39	Brutto (Netto + Podatek + ZUS pracobiorcy + PPK pracobiorcy) powiększone o ZUS pracodawcy i + PPK pracodawcy. Czyli: (4198,44 + 401,00 + 1310,04 + 122,00 ) [Brutto] + (595,36 + 396,50 + 149.45 + 6,10) [ZUS pracodawcy] +91.50 [PPK Pracodawcy]
Zmniejszenia	-31.48	Brutto lub netto<0

       

Wstęp

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

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

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

Jeżeli podczas importu wyświetlony zostanie powyższy komunikat, oznacza to, że Operator importujący jest zwykłym Użytkownikiem, bez odpowiednich uprawnień i lista płac nie zostanie zaimportowana do Comarch ERP XL. Aby Operator mógł zaimportować listę płac, musi posiadać uprawnienia:

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

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

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

Jeżeli podczas importu pojawia się powyższy komunikat, oznacza to, że w systemie Comarch ERP XL brak jest pracownika i centrum kosztowego ( wydziału), którym opisana jest lista płac w systemie Comarch ERP XL HR. W takim przypadku należy uaktualnić wydział w systemie Comarch ERP XL HR. Uaktualnienie wydziału polega na ponownym zapisaniu formularza danych wydziału, przy włączonym parametrze: Współpraca z systemem Comarch ERP XL. W systemie Comarch ERP XL dopisany zostanie wydział, jako centrum w strukturze kosztowej. Listę płac będzie można zaimportować prawidłowo po ponownym uruchomieniu modułu: Księgowość, ponieważ struktura kosztowa odczytywana jest przy starcie tego modułu.

Uwaga

Rozbieżności pomiędzy strukturą kosztową Comarch ERP XL i wydziałami Comarch ERP XL HR mogą być spowodowane : -  usunięciem lub dodaniem w Comarch ERP XL centrum kosztowego przy wyłączonej synchronizacji z systemem Comarch ERP XL HR, - usunięciem lub dodaniem w Comarch ERP XL HR nowego wydziału przy wyłączeniu parametru konfiguracyjnego: Współpraca z systemem Comarch ERP XL.

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

Jeżeli podczas importu pojawia się powyższy komunikat, oznacza to, że w systemie Comarch ERP XL brak jest pracownika, dla którego została naliczona wypłata w systemie Comarch ERP XL HR lub do pracownika nie zostało przypisane centrum kosztów w systemie Comarch ERP XL. Aby prawidłowo zaimportować listę płac, należy uaktualnić kartę pracownika wraz z wydziałem w systemie Comarch ERP XL HR. Uaktualnienie polega na ponownym wybraniu wydziału na karcie pracownika i  zapisaniu karty przy włączonym parametrze: Współpraca z systemem Comarch ERP XL. W Comarch ERP XL, dopisany zostanie zarówno pracownik na liście pracowników oraz jego wydział jako centrum w strukturze kosztowej. Po ponownym uruchomieniu modułu: Księgowość, listę płac będzie można poprawnie zaimportować. W niektórych przypadkach zachodzi konieczność ponownego naliczenia listy płac w Comarch ERP XL HR i ponowny import do Comarch ERP XL.

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

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

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

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

Uwaga

Rozbieżności pomiędzy listą pracowników, listą projektów oraz listą lokalizacji w Comarch ERP XL HR i Comarch ERP XL mogą być spowodowane: - usunięciem lub dodaniem w Comarch ERP XL pracownika, po dokonaniu exportu lub synchronizacji z Comarch ERP XL HR, - dodaniem w Comarch ERP XL HR nowego pracownika po wyłączeniu parametru konfiguracyjnego: Współpraca z systemem Comarch ERP XL, -  usunięciem lub dodaniem w Comarch ERP XL lokalizacji, projektu przy wyłączonej synchronizacji z systemem Comarch ERP XL HR, - usunięciem lub dodaniem w Comarch ERP XL HR  lokalizacji, projektu przy wyłączeniu parametru konfiguracyjnego: Współpraca z systemem Comarch ERP XL.

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

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

Uwaga

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

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

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

Uwaga

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

W celu uzyskania bardziej szczegółowych informacji o przyczynie braku importu danych, należy  z poziomu narzędzia Microsoft SQL Server Management Studio wykonać procedurę: exec cdn.ImportListPlacOptima ID_Zestawu,1 W miejsce pierwszego parametru funkcji należy wstawić ID zestawu transformacji DTS, za pomocą którego wykonywany jest import ( jest to wartość pola:  DZE_ID z tabeli CDN.DTSZestawy). Drugi parametr procedery przyjmuje zawsze wartość 1. Zwracane wyniki procedury:

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

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że nie został utworzony zlinkowany serwer lub podczas jego dodawania, wskazana została nieprawidłowa nazwa serwera, na którym znajdują się bazy Comarch ERP XL HR i Comarch ERP XL lub utworzony został zlinkowany serwer bez końcówki: '_Place'. Konieczne jest dodanie zlinkowanego serwera lub usunięcie już istniejącego i dodanie go ponownie ( za pomocą skryptu dostępnego w biuletynie technicznym: XL114 - Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4). W wersji 2017.0 Comarch ERP XL wprowadzono automatyczne tworzenie zlinkowanwgo serwera oraz jego mapowanie na bazy Comarch ERP XL oraz Comarch ERP XL HR . W celu uruchomienia współpracy oraz utworzenia zlinkowanego serwera należy w  konfiguracji systemu Comarch ERP XL na zakładce: HR zaznaczyć check: Synchronizuj strukturę organizacyjną i dane kadrowe oraz uzupełnić pozostałe dane zgodnie z biuletynem: XL064 - Współpraca Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR.

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

Uwaga

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

W celu uzyskania informacji o przyczynie braku importu danych, należy  z poziomu narzędzia Microsoft SQL Server Management Studio wykonać procedurę: exec cdn.ImportListPlacOptima ID_Zestawu,1 W miejsce pierwszego parametru funkcji należy wstawić ID zestawu transformacji DTS, za pomocą którego wykonywany jest import ( jest to wartość pola:  DZE_ID z tabeli CDN.DTSZestawy). Drugi parametr procedery przyjmuje zawsze wartość 1. Zwracane wyniki procedury:

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

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że login SQL po którym następuje linkowanie serwerów ( zazwyczaj CDNDTS) nie został zmapowany na bazę konfiguracyjną Comarch ERP XL HR. W celu zmapowania loginu należy, we właściwościach loginu,  na zakładce: User Mapping, wskazać bazę konfiguracyjną Comarch ERP XL HR, a  w obszarze Database role membership for: zaznaczyć role:  CDNRaport, public.

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

Jeżeli wynikiem wywołania procedury jest powyższy komunikat, oznacza to, że login SQL po którym następuje linkowanie serwerów ( zazwyczaj CDNDTS) nie został zmapowany na bazę firmową Comarch ERP XL HR. W celu zmapowania loginu należy, we właściwościach loginu,  na zakładce: User Mapping, wskazać bazę firmową Comarch ERP XL HR, a  w obszarze Database role membership for: zaznaczyć role:  CDN, CDNRaport, public, db_owner. Komunikat ten pojawi się również jeżeli w zestawie transformacji DTS wskazano nieprawidłowo nazwę serwera, na którym znajdują się bazy Comarch ERP XL HR i Comarch ERP XL.

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

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

Login failed for user 'CDNDTS'

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

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

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

Uwaga

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

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

Jeżeli synchronizacja wykonywana jest między serwerami w różnych fizycznych lokalizacjach, konieczne jest uruchomienie i skonfigurowanie usługi systemowej MSDTC, czyli koordynatora transakcji rozproszonych. Ustawienia usługi zostały opisane w biuletynach technicznych: XL064 – Współpraca Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR oraz XL114 - Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4.    

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, 4 i 5 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. 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(3) lub VAT-UE(4) lub VAT-UE(5) oraz VAT-UEK(3) lub VAT-UEK(4) lub VAT-UEK(5). Możliwość wystawienia formularzy VAT-UE(5), VAT-UEK(5) ograniczono tylko do okresów miesięcznych. Jednocześnie z menu usunięto opcje udostępniające formularze VAT-UE(2) i VAT-UEK(2), które obowiązywały przed 2015 r.

Uwaga

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

Nowy formularz VAT-UE(5), na zakładce Dane, w wierszu 8 usunięto pole REGON z uwagi na zniesienie wymogu jego podawania.

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(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) i VAT-UE(5), VAT_UEK(5) 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:

Call–off stock

System Comarch ERP XL nie obsługuje przesunięcia towarów do magazynu typu call-off stock na terytorium państwa członkowskiego innego niż Polska. W związku z brakiem obsługi procedury, na zakładce Call-off stock dane nie są generowane automatycznie, można je wprowadzić ręcznie.

 

Na zakładce Call-off stock dodano następujące kolumny:

Numer identyfikacji VAT klienta zastąpionego – NIP kontrahenta pobrany z adresu kontrahenta „zastąpionego”, tj. dla którego towary były pierwotnie przemieszczone do magazynu typu call-off stock, ale w wyniku umowy nastąpiła zmiana odbiorcy na innego.

Powrotne przemieszczenie – prezentacja ustawienia parametru do zaznaczenia o nazwie „Powrotne przemieszczenie”.

Dodawanie, modyfikowanie, usuwania pozycji.

Na zakładce Call-off stock dodano trzy nowe przyciski: Dodaj, Zmień, Usuń. Zgodnie z przyjętym standardem, akcje dodawania, modyfikowania, usuwania pozycji są możliwe na formularzu o statusie „Bufor”.

Uwaga

Na formularzu VAT-UE(5), na zakładce Call-off stock przycisk  [Piorun] “Przelicz deklarację” automatycznie nie zwraca żadnych wierszy. Dane użytkownik może wprowadzić tylko ręcznie, z uwagi na brak obsługi w systemie Comarch ERP XL przesunięcia towarów z terytorium Polski na terytorium innego państwa członkowskiego w procedurze call-off stock.

Dodawanie pozycji

Dodanie pozycji jest możliwe na formularzu o statusie Bufor, po wybraniu przycisku Dodaj. Z przyciskiem Dodaj powiązano rozwijane menu, w ramach, którego udostępniono następujące opcje:

Modyfikacja pozycji

Modyfikacja pozycji jest możliwa na formularzu o statusie Bufor, po wybraniu przycisku Zmień. Z przyciskiem Zmień powiązano rozwijane menu. W ramach menu dodano następujące opcje:

Usunięcie pozycji

Usunięcie pozycji jest możliwe na formularzu o statusie Bufor, po wybraniu przycisku Usuń.

Formularz pozycji VAT-UE

Na formularzu pozycji VAT-UE udostępniono następujące pola:

Zapisanie formularza pozycji jest możliwe po wybrania kontrahenta „głównego”. System kontroluje zgodność krajów nadania Numerów Identyfikacji Podatkowej dla kontrahenta głównego i zastąpionego.

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

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:

• Wg zasad podatkowych
• Według przepisów Ustawy o rachunkowości, pod warunkiem, że w okresie nie krótszym niż trzy lata podatkowe (licząc od początku roku podatkowego, w którym zastosowano tę metodę), sprawozdania podatników będą badane przez podmioty uprawnione do badania sprawozdań finansowych.

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

• Wycena wg FIFO: to kojarzenie KW z KP, zaczynając od KP najwcześniej wystawionego (najstarszego) nie skojarzonego lub skojarzonego częściowo z KW. To także wycena rozchodu środków pieniężnych wg kursów pobranych z KP, z którymi KW jest kojarzone.
• Wycena wg LIFO: to kojarzenie KW z KP, zaczynając od KP najpóźniej wystawionego, nie skojarzonego lub skojarzonego częściowo z KW. To także wycena rozchodu środków pieniężnych wg kursów pobranych z KP, z którymi KW jest kojarzone.

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:

 

 

• Wycena dokonywana jest również w momencie zamykania raportu – skojarzeniu podlegają wtedy wszystkie niewycenione zapisy zgodnie z przyjętą zasadą kojarzenia zapisów dla całego rejestru: FIFO lub LIFO. Logu pojawiającym się w momencie zamykania raportu znajduje się informacja o wycenionych w trakcie zamykania zapisach rozchodowych.

 

• Wycena może również zostać wykonana dla wskazanych raportów znajdujących jest w danym rejestrze – skojarzeniu podlegają wtedy niewycenione zapisy znajdujące się we wskazanych raportach. Wycena następuje zgodnie z kolejnością wynikającą z wybranej na rejestrze metody kojarzenia: FIFO lub LIFO. Wycenie dokonywanej w ten sposób mogą podlegać zarówno zamknięte, jak i otwarte raporty.

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

• Jeśli zapis kasowo/bankowy rozchodowy zostanie wprowadzony automatycznie do systemu, np. poprzez dokonanie zapłaty ‘łapką’ za faktury generujące płatność w walucie obcej o typie zobowiązanie, to kurs na takim zapisie ustalany jest zgodnie z metodą wyceny przyjętą na definicji rejestru (FIFO lub LIFO), w którym zapis powstaje, oczywiście przy założeniu, że w tym rejestrze znajduje się odpowiednia wartość zasobów pieniężnych. Taki zapis zostaje od razu skojarzony z zapisami przychodowych znajdującymi się w rejestrze w wyniku, czego zostaje ustalona jego wartość w walucie systemowej.
• Jeśli podczas dodawania zapłaty okaże się, że wartość środków pieniężnych nie jest wystarczająca do dokonania skojarzenia wyceny, zapis kasowo/bankowy zostanie wprowadzony po kursie Ustalonym. Program w takiej sytuacji poprosi o podanie kursu, po jakim ma zostać wprowadzony zapis rozchodowy. Wartość takiego zapisu zostanie określona zgodnie z podanym kursem, natomiast zapis zostanie częściowo skojarzony z niewycenionym zapisami przychodowymi znajdującymi się w tym rejestrze.

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:

• Usunięcie wyceny możliwe jest z poziomu listy zapisów kasowo/bankowych znajdujących się w danym raporcie. Usunięcie wyceny następuje dla zaznaczonych na liście zapisów rozchodowych. Usunięcie wyceny w ten sposób możliwe jest dla zapisów, na których kurs został określony jako FIFO lub LIFO, pod warunkiem że zapis nie został rozliczony/ skompensowany. W przypadku zapisów o kursie Ustalonym usunięcie takiej wyceny jest możliwe również dla zapisów, które zostały rozliczone/skompensowane. Usunięcie wyceny jest możliwe nawet na zapisach znajdujących się zamkniętym raporcie. Wycenę można usunąć w ten sposób, jeśli raport nie jest zaksięgowany.

• Usunięcie wyceny możliwe jest również z poziomu całego rejestru dla zaznaczonych na liście raportów. Usunięcie skojarzenia wyceny w ten sposób możliwe jest dla zapisów, na których kurs został określony jako FIFO lub LIFO, pod warunkiem że zapis nie został rozliczony/ skompensowany. W wypadku zapisów o kursie Ustalonym usunięcie takiej wyceny jest możliwe również dla zapisów, które zostały rozliczone/skompensowane. Usunięcie wyceny jest możliwe nawet na zapisach znajdujących się zamkniętym raporcie. Wycenę można usunąć w ten sposób, jeśli raport nie jest zaksięgowany.

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:

• Nie księguj
• Księguj jako BO – jeżeli raport bilansu otwarcia zostanie zaksięgowany z zaznaczonym parametrem, dekret z tego raportu ujmowany będzie zawsze na kontach na pierwszy dzień bieżącego okresu obrachunkowego jako dekret bilansu otwarcia. Trafi on zawsze do dziennika *BO* i uwzględniany będzie na kontach jako bilans otwarcia na ten dzień, mimo że data zamknięcia raportu może być inna.

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

• Księguj w obrotach bieżących – raport zaksięgowany z zaznaczonym parametrem zostanie ujęty w księgach pod datą zamknięcia raportu, w dzienniku wskazanym na rejestrze bankowym, a więc w analogiczny sposób jak pozostałe wyciągi bankowe.
• Nie rozliczaj – parametr decyduje o tym, czy zapisy z danego raportu mają podlegać rozliczaniu/skompensowaniu Jeśli raport Bilansu Otwarcia zostanie zaksięgowany, dekret z tego raportu ujmowany na kontach jest zawsze na pierwszy dzień bieżącego okresu obrachunkowego jako dekret bilansu otwarcia. Trafia on zawsze do dziennika *BO* i uwzględniany jest na kontach jako bilans otwarcia na ten dzień, mimo że data zamknięcia raportu może być inna.

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:

• FIFO
• LIFO
• Wg kursu ustalonego
• Przez wskazanie (Jeżeli ich ilość będzie większa od 1, do wyceny będą brane zapisy w kolejności ustawionej na rejestrze – FIFO lub LIFO)

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

• FIFO
• LIFO
• Przez wskazanie (w ramach zapisów wskazanych, wg kolejności FIFO/LIFO)

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:

• Wycena i rozliczenie wg FIFO, LIFO z uwzględnieniem zapisów przychodowych, których timestamp jest wcześniejszy lub późniejszy od timestamp zapisu wycenianego
• Wycena wg kursu ustalonego i rozliczenie wg metod wybranych na rejestrze (FIFO/LIFO) z uwzględnieniem zapisów przychodowych, których timestamp jest wcześniejszy lub późniejszy od timestamp zapisu wycenianego. Tego rodzaju rozliczeniu musi towarzyszyć wygenerowanie RK zgodnie z przyjętymi zasadami.

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

• Wycena i rozliczenie w ramach puli wskazanej przez użytkownika. System do wskazania udostępni zapisy przychodowe, których timestamp jest wcześniejszy lub późniejszy od timestamp zapisu wycenianego. W przypadku zaznaczenia kilku zapisów o różnych datach, system wyceni/rozliczy zapis 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.
• Wycena wg kursu ustalonego i rozliczenie w ramach puli wskazanej przez użytkownika. System do wskazania udostępni zapisy przychodowe, których timestamp jest wcześniejszy lub późniejszy od timestamp zapisu wycenianego. W przypadku zaznaczenia kilku zapisów, o różnych datach, system rozliczy zapis 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. Tego rodzaju wycenie/rozliczeniu będzie towarzyszyło wygenerowanie RK, zgodnie z przyjętymi dla wyceny zasadami.

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:

• KP1
• KP2
• KW1 – kurs na KW1 został ustalony wg kursu z KP1, z którym KW1 został skojarzony.
• KW2 – kurs na KW2 został ustalony wg kursu z KP2, z którym KW2 został skojarzony.
• KP3
• KW3 – kurs na KW3 został ustalony wg kursu z KP3, z którym KW3 został skojarzony.

Operacje biorące udział w rozliczeniach:

• Rozliczenie KP1 z FS1 – zapis kasowy (przychód) rozlicza płatność (należność).
• Rozliczenie KW1 z FZ1 – zapis kasowy (rozchód) rozlicza płatność (zobowiązanie).
• Kompensata KP2 z KW2 – zapis kasowy (przychód) kompensuje zapis kasowy (rozchód).
• KP3 – dokument nierozliczony. Dokumentuje zaliczkę a’ konto przyszłej dostawy, która zostanie zrealizowana w kolejnym miesiącu. (W przyszłości zapis zostanie rozliczony z płatnością, natomiast w miesiącu, w którym przyjęto zaliczkę zostanie on ujęty w wycenie rozchodu środków pieniężnych).
• KW3 – dokument nierozliczony. Dokumentuje zaliczkę a’ konto przyszłej dostawy po stronie zakupu, która zostanie zrealizowana w kolejnym miesiącu. (W przyszłości zapis zostanie rozliczony z płatnością, natomiast w miesiącu, w którym wypłacono zaliczkę zostanie on ujęty w wycenie rozchodu środków pieniężnych).

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

• Operacja 1.a. Rozliczone ze sobą dokumenty FS1 oraz KP1 zaksięgowano na koncie rozrachunkowym 203-X, FS1 po stronie „Wn”, KP1 po stronie „Ma”. Na tym koncie powstał rozrachunek, któremu towarzyszyło naliczenie różnicy kursowej – nastąpiła zatem ostateczna wycena należności.
• Operacja 1.b. Dokument KP1 został także zaksięgowany po stronie „Wn” na koncie rozrachunkowym rejestru – „133 Rachunek dewizowy”, na którym ewidencjonowane są dekrety związane z wpływem i wydatkowaniem środków pieniężnych. Konto to powiązane jest z kontem pozabilansowym walutowym, dzięki temu ma miejsce dualna rejestracja operacji w PLN oraz w walucie obcej.
• Operacja 2.a. Rozliczone ze sobą dokumenty KW1 oraz FZ1 zaksięgowano na koncie rozrachunkowym 203-X, KW1 po stronie „Wn”, FZ1 po stronie „Ma”. Na tym koncie powstał rozrachunek, któremu towarzyszyło naliczenie różnicy kursowej – nastąpiła wycena zobowiązania.
• Operacja 2.b. Dokument KW1 zaksięgowano po stronie „Ma” na koncie rozrachunkowym – „133 Rachunek dewizowy”.

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:

• KP1
• KP2
• KW1 – kurs na KW1 został wprowadzony jako kurs Ustalony, a KW1 zostało skojarzone w KP1.
• KW2 – kurs na KW2 został wprowadzony jako kurs Ustalony, a KW2 zostało skojarzone w KP2.
• KP3
• KW3 – kurs na KW3 został wprowadzony jako kurs Ustalony, a KW3 zostało skojarzone w KP3.

Operacje biorące udział w rozliczeniach:

• Rozliczenie KP1 z FS1 – zapis kasowy (przychód) rozlicza płatność (należność).
• Rozliczenie KW1 z FZ1 – zapis kasowy (rozchód) rozlicza płatność (zobowiązanie).
• Kompensata KP2 z KW2 – zapis kasowy (przychód) kompensuje zapis kasowy (rozchód).
• KP3 – dokument nierozliczony. Dokumentuje zaliczkę a’ konto przyszłej dostawy, która zostanie zrealizowana w kolejnym miesiącu. (W przyszłości zapis zostanie rozliczony z płatnością, natomiast w miesiącu, w którym przyjęto zaliczkę zostanie on ujęty w wycenie rozchodu środków pieniężnych).
• KW3 – dokument nierozliczony. Dokumentuje zaliczkę a’ konto przyszłej dostawy po stronie zakupu, która zostanie zrealizowana w kolejnym miesiącu. (W przyszłości zapis zostanie rozliczony z płatnością, natomiast w miesiącu, w którym wypłacono zaliczkę zostanie on ujęty w wycenie rozchodu środków pieniężnych).

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

• Operacja 1.a. Rozliczone ze sobą dokumenty FS1 oraz KP1 zaksięgowano na koncie rozrachunkowym 203-X, FS1 po stronie „Wn”, KP1 po stronie „Ma”. Na tym koncie powstał rozrachunek, któremu towarzyszyło naliczenie różnicy kursowej – nastąpiła zatem ostateczna wycena należności.
• Operacja 1.b. Dokument KP1 został także zaksięgowany po stronie „Wn” na koncie rozrachunkowym – „133 Rachunek dewizowy”, na którym ewidencjonowane są dekrety związane z wpływem i wydatkowaniem środków pieniężnych. Konto to powiązane jest z kontem pozabilansowym walutowym, dzięki temu ma miejsce dualna rejestracja operacji w PLN oraz w walucie obcej.
• Operacja 2.a. Rozliczone ze sobą dokumenty KW1 oraz FZ1 zaksięgowano na koncie rozrachunkowym 203-X, KW1 po stronie „Wn”, FZ1 po stronie „Ma”. Na tym koncie powstał rozrachunek, któremu towarzyszyło naliczenie różnicy kursowej – nastąpiła wycena zobowiązania.
• Operacja 2.b. Dokument KW1 zaksięgowano po stronie „Ma” na koncie rozrachunkowym – „133 Rachunek dewizowy”.

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:

• KP1
• KP2
• KW1 – kurs na KW1 został ustalony wg kursu z KP1, z którym KW1 został skojarzony.
• KW2 – kurs na KW2 został ustalony wg kursu z KP2, z którym KW2 został skojarzony.
• KW3 – kurs na KW3 został ustalony wg kursu z KP3, z którym KW3 został skojarzony przez wskazanie.
• KP3

Operacje biorące udział w rozliczeniach:

• Rozliczenie KP1 z FS1 – zapis kasowy (przychód) rozlicza płatność (należność).
• Rozliczenie KW1 z FZ1 – zapis kasowy (rozchód) rozlicza płatność (zobowiązanie).
• Kompensata KP2 z KW2 – zapis kasowy (przychód) kompensuje zapis kasowy (rozchód).
• KW3 – dokument nierozliczony. Dokumentuje zaliczkę a’ konto przyszłej dostawy po stronie zakupu, która zostanie zrealizowana w kolejnym miesiącu. (W przyszłości zapis zostanie rozliczony z płatnością, natomiast w miesiącu, w którym wypłacono zaliczkę zostanie on ujęty w wycenie rozchodu środków pieniężnych).
• KP3 – dokument nierozliczony. Dokumentuje zaliczkę a’ konto przyszłej dostawy, która zostanie zrealizowana w kolejnym miesiącu. (W przyszłości zapis zostanie rozliczony z płatnością, natomiast w miesiącu, w którym przyjęto zaliczkę zostanie on ujęty w wycenie rozchodu środków pieniężnych).

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

• Operacja 1.a Rozliczone ze sobą dokumenty FS1 oraz KP1 zaksięgowano na koncie rozrachunkowym 203-X, FS1 po stronie „Wn”, KP1 po stronie „Ma”. Na tym koncie powstał rozrachunek, któremu towarzyszyło naliczenie różnicy kursowej – nastąpiła zatem ostateczna wycena należności.
• Operacja 1.b Dokument KP1 został także zaksięgowany po stronie „Wn” na koncie rozrachunkowym – „133 Rachunek dewizowy”, na którym ewidencjonowane są dekrety związane z wpływem i wydatkowaniem środków pieniężnych. Konto to powiązane jest z kontem pozabilansowym walutowym, dzięki temu ma miejsce dualna rejestracja operacji w PLN oraz w walucie obcej.
• Operacja 2.a Rozliczone ze sobą dokumenty KW1 oraz FZ1 zaksięgowano na koncie rozrachunkowym 203-X, KW1 po stronie „Wn”, FZ1 po stronie „Ma”. Na tym koncie powstał rozrachunek, któremu towarzyszyło naliczenie różnicy kursowej – nastąpiła wycena zobowiązania.
• Operacja 2.b Dokument KW1 zaksięgowano po stronie „Ma” na koncie rozrachunkowym – „133 Rachunek dewizowy”.
• Operacja 4 W momencie wprowadzania zapisu KW3 brak jest na rachunku środków do wyceny tego zapisu. Zapis ten pozostaje niewyceniony.
• Operacja 5 W momencie przyjęcia środków KP3 dokonana może zostać wycena zapisu KW3 z późniejszym zapisem KP3

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:

• 01.10.17 – wystawiono FS1 kontrahentowi „X” na kwotę 3.000,00 Euro. Średni kurs NBP z poprzedniego dnia roboczego wynosił 100 Euro = 385,00 PLN
• 04.10.17 – KP1- zarejestrowano zapłatę na kwotę 3.000,00 Euro za FS1. Kurs : 100 Euro = 390,00 PLN
• 05.10.17 – KP2 zarejestrowano wpływ zaliczki na kwotę 10.000 Euro na poczet dostawy, która będzie realizowana w przyszłym miesiącu. Kurs :100 Euro = 375,00 PLN
• 06.10.17 – KW1 – sprzedano do banku 5.000,00 Euro, celem zasilenia rachunku bieżącego. Kurs : 100 Euro = 385,00 PLN
• 07.10.17 – wpłynęła FZ1 od kontrahenta unijnego na kwotę 3.000 Euro. Średni kurs NBP z poprzedniego dnia roboczego wynosił 100 Euro = 387,00 PLN
• 08.10.17 – KW2 – dokonano zapłaty za FZ1 na kwotę 3.000 Euro.
• 10.10.17 – wystawiono FS2 kontrahentowi „X” na kwotę 20.000 Euro. Średni kurs NBP poprzedniego dnia roboczego wynosił 100 Euro = 401,00 PLN
• 12.10.17 – KP3 – zarejestrowano zapłatę 12.000 Euro. Kurs : 100 Euro = 389,00 PLN
• 15.10.17 – KP4 – od banku zakupiono 8.000 Euro. Kurs : 100 Euro = 392,00 PLN
• 22.10.17 – KW3 – dokonano zapłaty w wysokości 25.000 Euro na poczet przyszłej dostawy.

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.

Rozrachunki krzyżowe przy użyciu not memoriałowych w przykładach

Rozrachunki krzyżowe powstają w sytuacji, gdy mamy do czynienia z dwoma dokumentami w różnych walutach obcych. System Comarch ERP XL nie umożliwia rozliczenia i rozrachowania dokumentów w różnych walutach. Konieczne jest przewalutowanie jednego z dokumentów. Do tego celu należy wykorzystać dokumenty uproszczonej noty memoriałowej.

Przykłady opracowane są przy założeniu, że w konfiguracji zaznaczono parametr: Dokument różnicy kursowej.

Przykład FZ w USD, KW w EUR

Celem jest rozliczenie dwóch dokumentów, FZ w USD oraz zapłatę KW w EUR

W systemie wprowadzone są dwa dokumenty:

1. FZ  w USD (generuje zobowiązanie) na wartość 40 USD po kursie 3,50 PLN=140 PLN 2. Zapłata KW w EURO (generuje należność) na wartość 50 EUR po kursie 4,30=215 PLN

Aby je rozliczyć należy wprowadzić dwie uproszczone noty memoriałowe:

1. Notę generującą zobowiązanie w walucie EURO na wartość 50 EUR po kursie 4,30=215 PLN. Nota ta będzie posiadała płatność 50 EURO i zostanie rozliczona z dokumentem bankowym KW w EURO, dlatego wartość jej powinna być identyczna jak wartość zapłaty, ponieważ różnice kursowe powstaną przy rozliczeniu FZ.

Zamiast noty memoriałowej wykorzystać można dokument noty uproszczonej. Jego główną zaletą jest fakt, iż na zakładce: Pozycje podajemy konta oraz kwoty. Wskazując odpowiedni dziennik księgowań możemy dokument zaksięgować. Do uproszczonej noty memoriałowej nie ma konieczności podpinania schematu księgowań, księgowanie odbywa się na konta wskazane na zakładce: Pozycje. Płatność generowana jest na kontrahenta wskazanego na koncie rozrachunkowym wprowadzonym na zakładce: Pozycje.

2. Notę generującą należność w walucie USD odzwierciedlającą płatność za fakturę - na wartość 40 USD po kursie 5,375 = 215 PLN. Kurs wyliczamy dzieląc wartość zapłaty w PLN przez wartość w USD  (215 PLN/40 USD), jeżeli jest to zapłata całkowita. Jeżeli zapłata jest częściowa, należy przeliczyć kursy poprzez porównanie kursów EUR i USD.

Nota zostanie rozliczona z FZ poprzez funkcję: Dodaj kompensatę. W tym przypadku po dokonaniu rozliczenia dokumentów powinien powstać dokument różnicy kursowej.

Ponieważ uproszczone noty memoriałowe będą pełnić funkcję dokumentów pośrednich, na których nastąpi "przewalutowanie", należy utworzyć konto pośrednie (w przykładzie 281-01), na które noty te będą zaksięgowane. Konto musi istnieć ze względu na konieczność bilansowania się dekretów księgowych, a ponieważ nie można tego zrobić na jednej nocie memoriałowej, w związku z tym nie ma możliwości zaksięgowania tych dokumentów bez konta pośredniego.

Należy pamiętać, aby konto pośrednie nie było kontem rozrachunkowym, lecz np. kontem kosztowym. Nie powinno być ono uwzględniane w liczeniu Rachunku wyników oraz w przeksięgowaniach na wynik finansowy.

Konto kontrahenta powinno być kontem rozrachunkowym powiązanym z kontem pozabilansowym rozrachunkowym wyrażonym w walucie

Przykład FS w USD, KP w EUR

Celem jest rozliczenie dwóch dokumentów: FS w USD oraz zapłaty KP w EUR. W systemie są wprowadzone dwa dokumenty: FS w USD - (generuje należność w dolarach) na wartość 100 USD po kursie 2,40=240 PLN Zapłata KP w EURO na wartość 70 EUR po kursie 3.60=252 PLN Aby je rozliczyć należy wprowadzić dwie uproszczone noty memoriałowe:

1. Notę przychodową (generującą należność) w walucie EURO na wartość 70 EUR po kursie 3.60=252 PLN. Nota ta zostanie rozliczona z dokumentem bankowym (KP) w EURO, dlatego wartość jej powinna być identyczna jak wartość zapłaty, ponieważ różnice kursowe powstaną przy rozliczeniu FS.

2. Notę rozchodową (generującą zobowiązanie) w walucie USD na wartość 100 USD po kursie 2.52 = 252. Kurs wyliczamy dzieląc wartość zapłaty w PLN przez wartość w USD (252/100), jeżeli jest to zapłata całkowita. Jeżeli zapłata jest częściowa, trzeba przeliczyć kursy poprzez porównanie kursów EUR i USD. Nota zostanie rozliczona z FS poprzez funkcję Dodaj kompensatę. W tym przypadku po rozliczeniu dokumentów powinien powstać dokument Różnicy Kursowej.

Uwaga

Jeśli w konfiguracji nie zostanie zaznaczony parametr: Dokument różnicy kursowej, to po zaksięgowaniu dokumentów i rozliczeniu noty z FS/FZ powstanie dekret różnicy kursowej.

Przeszacowanie walut

Transakcje walutowe z kontrahentami, bankami, pracownikami ujmowane są w księgach rachunkowych w walucie PLN. Stąd też kwota każdej operacji, która pierwotnie wyrażona jest w walucie obcej, przed jej wprowadzeniem do ksiąg rachunkowych wymaga przeliczenia na złotówki. Ustawa o rachunkowości mówi o kursach, jakie należy zastosować celem właściwego przeliczenia transakcji dokonanej w walucie obcej na wartość w walucie PLN. Zgodnie z art. 30 ustawy wyrażone w walutach obcych operacje gospodarcze w zależności od ich rodzaju ujmuje się w księgach rachunkowych na dzień ich przeprowadzenie po kursie:

Ten sam artykuł narzuca też obowiązek, nie rzadziej niż na dzień bilansowy, wyceny wyrażonych w walutach obcych:

Generacja przeszacowania walut

Przeszacowanie, ze względu na to, że jest to operacja związana z wyceną na dzień bilansowy aktywów i pasywów wyrażonych w walutach obcych, może być przeprowadzane tylko dla nierozliczonych zapisów, lub sald kont liczonych w oparciu o zapisy z Księgi Głównej/bufora.

Funkcjonalność przeszacowania walut dostępna jest w module Księgowość (menu: Księgowość >> Przeszacowanie walut). Przeszacowaniu podlegają wyłącznie konta walutowe. Przeliczenie może dotyczyć albo salda konta walutowego (dla kont zwykłych) albo zapisów na koncie walutowym (dla kont rozrachunkowych).

Na zakładce: Generacja, należy określić następujące parametry: walutę, dla której będzie wykonywane przeszacowanie, podać kurs, według którego salda, bądź poszczególne zapisy księgowe będą przeliczane oraz zaznaczyć, czy przeszacowanie ma dotyczyć salda konta czy też poszczególnych zapisów księgowych. W przypadku zapisów księgowych przeszacowane mogą być wszystkie zapisy, bądź zapisy z wskazanych kont. Tutaj należy też wskazać, za jaki okres wykonane ma być przeszacowanie.

 

Przeszacowanie wybranych sald bądź zapisów księgowych należy uruchomić poprzez użycie ikony .

W przeszacowaniu walut ujęta jest historyczność rozliczeń dekretów. Oznacza to, że uwzględniane są w nim zapisy księgowe, które zostały rozliczone w kolejnym roku obrachunkowym/ przyszłym miesiącu, ale na koniec roku obrachunkowego (miesiąca), dla którego wykonywane jest przeszacowanie nie były jeszcze rozliczone.

Różnice kursowe wyliczane są globalnie dla danego konta podlegającego przeszacowaniu, lub indywidualnie dla każdego zapisu wówczas, gdy generacja dotyczy poszczególnych zapisów księgowych. Należy pamiętać, iż po wygenerowaniu przeszacowania dla salda konta nie ma możliwości powtórnej generacji przeszacowania dla tego samego konta nawet, jeśli zostały dodane w bazie nowe zapisy księgowe związane z tym kontem. W takiej sytuacji należałoby usunąć przeszacowanie i wygenerować je raz jeszcze.

Wartość różnicy kursowej powstałej z wyceny walut liczonej dla salda konta jest wyliczana według następującego schematu:

RK= SWK*K-SZK

Gdzie:

SWK- saldo konta w walucie obcej np. 905-01

K- kurs podany na przeszacowaniu walut

SZK- saldo konta złotówkowego np. 131-01

Wartość różnicy kursowej powstałej z wyceny liczonej dla konkretnego zapisu księgowego powstaje w następujący sposób:

RK= PN*(KD-KP)

Gdzie:

PN- płatność nierozliczona w walucie obcej pochodząca z dokumentu źródłowego

KD- kurs waluty z dokumentu źródłowego

KP- kurs podany na przeszacowaniu walut

Księgowanie przeszacowania walut

Na zakładce: Księgowanie, wyświetlana jest lista, na której widoczne są wszystkie wygenerowane dokumenty przeszacowań. Z tego poziomu należy zaksięgować te dokumenty na koniec bieżącego okresu i na początek kolejnego okresu (okresu obrachunkowego, miesiąca). Niezrealizowane różnice kursowe z dokumentów przeszacowania księgowane są na konta podane w konfiguracji systemu Comarch ERP XL (Konfiguracja>> Księgowość>> Księgowania>> Przeszacowanie walut). W tym samym obszarze należy zaznaczyć, czy dekret powstały z księgowania przeszacowania ma zostać zapisany w buforze, czy bezpośrednio w Księdze Głównej.

Należy pamiętać, iż na wygenerowane przeszacowanie można zaksięgować tylko i wyłącznie z datą ostatniego dnia okresu obrachunkowego lub ostatniego dnia miesiąca, natomiast wyksięgować tylko pod datą pierwszego dnia okresu obrachunkowego, miesiąca.

Ścieżka księgowania wygenerowanego przeszacowania jest następująca: w pierwszej kolejności należy zaksięgować przeszacowanie na koniec bieżącego okresu, a następnie, z tego samego poziomu, zmieniając ustawienie filtra na: niezaksięgowane na początku okresu, należy dokonać księgowania na początek kolejnego okresu.

Księgowanie w przyszłym okresie obrachunkowym/miesiącu polega na wystornowaniu dekretu związanego z wyceną, wprowadzonego w poprzednim okresie obrachunkowym. Dlatego też, nie wolno ręcznie nic zmieniać w wygenerowanym dokumencie przeszacowania i powstałym z jego księgowania dekrecie. Storno wprowadzane jest do zapisów księgowych zawsze z datą pierwszego dnia przyszłego okresu obrachunkowego/ datą pierwszego dnia kolejnego miesiąca i jest to storno czerwone. System Comarch ERP XL nie dysponuje na chwilę bieżącą funkcjonalnością pozwalającą na wykonanie storna w dniu faktycznego rozliczenia dokumentu.

Uwaga

Nie można zaksięgować przeszacowania na początku przyszłego okresu obrachunkowego/miesiąca, jeśli nie zostało ono zaksięgowane na koniec bieżącego okresu/miesiąca. Nie można również usunąć dekretu powstałego z przeszacowania zaksięgowanego na koniec okresu, jeśli istnieje dekret na początku okresu.

Dekrety powstałe po zaksięgowaniu przeszacowania walut

Z poziomu poprawnie zaksięgowanego przeszacowania można odwołać się do dwóch dekretów: dekretu powstałego na końcu okresu i dekretu powstałego na początku okresu.

Dekret powstały po zaksięgowaniu przeszacowania na koniec okresu będzie miał datę ostatniego dnia okresu obrachunkowego, a dekret zaksięgowany na początku okresu – pierwszego dnia nowego okresu.

Przy wyksięgowywaniu przeszacowania na początek okresu obrachunkowego dokonują się automatyczne rozrachunki z dekretem powstałym z księgowania przeszacowania na koniec roku.

 

Wstęp

Niniejszy biuletyn ma na celu przedstawienie przykładowych zaawansowanych filtrów stosowanych w module Księgowość w obszarze schematów księgowych oraz na listach: rejestrów VAT i zapisów księgowych. Korzystanie z filtrów w warunkach schematów księgowych daje użytkownikowi szerokie możliwości tworzenia uniwersalnych schematów księgowych, obsługujących różne typy transakcji. W biuletynie zaprezentowano filtry bardziej zaawansowane, a więc tych których nie można uzyskać „wprost”, tzn. posługując się tylko bezpośrednio wybranymi polami dostępnymi z Konstruktora filtra. W biuletynie zaprezentowano również zaawansowane filtry stosowane na listach rejestru VAT i zapisów księgowych. Filtry budowane na tych listach dają użytkownikowi możliwość uzyskania konkretnych dokumentów, zgodnych z wymaganiami użytkowników.

Przykładowe filtry budowane w warunkach pozycji schematów księgowych

Pozycje schematów księgowych tworzone w oparciu o tabelę Oblicz dla: Płatności

trp_kntnumer in (select knt_gidnumer from cdn.kntkarty where knt_powiazany = 1 and knt_expokraj = 1)

exists (Select * from Cdn.Atrybuty where Atr_Obityp=trn_gidTyp and Atr_ObiNumer=trn_gidNumer and (Atr_AtkID=2 and Atr_Wartosc='UM125'))

Atr_AtkID - unikalne ID klasy atrybutu zapisane w tabeli  cdn.atrybutyklasy (AtK_ID=Atr_AtkId)

Pozycje schematów księgowych tworzone w oparciu o tabelę Oblicz dla: Nagłówka

substring(trn_trnseria,3,3) like 'KWR'

Pozycje schematów księgowych tworzone w oparciu o tabelę Oblicz dla: Elementów

trn_gidnumer in (select tno_trnnumer from cdn.trnopisy join cdn.tranag on TRN_GIDTyp=TNO_TrNTyp and TRN_GIDNumer=TNO_TrNNumer where TnO_Opis LIKE '%' + 'KRA' + '%' )

trs_magnumer in (5, 14) and tre_gidnumer in (select trn_gidnumer from cdn.tranag join cdn.kntkarty on trn_kntnumer = knt_gidnumer and trn_knttyp = knt_gidtyp where knt_powiazany = 1)

Pozycje schematów księgowych tworzone w oparciu o tabelę Oblicz dla: Tabeli VAT

TRV_DeklMiesiac=month(dateadd(day,Trn_data2,convert(datetime,'1800-12-28',120)))

Pozycje schematów księgowych tworzone w oparciu o tabelę Oblicz dla: Opisu analitycznego

ows_wmrid in (select frs_id from cdn.frmstruktura where (frs_konto like '505%' or frs_konto like '506%')) and ows_typwymiaru=1

(select left(prj_kod,1) from cdn.prjstruktura where prj_id=ows_wmrid)='P' and ows_typwymiaru=5

exists (select 1 from cdn.traelem where TrN_GIDTyp=TrE_GIDTyp and TrN_GIDFirma=TrE_GIDFirma and TrN_GIDNumer=TrE_GIDNumer and Tre_TypTwr=6)

Przykładowe filtry budowane na listach rejestru VAT, zapisów księgowych

Przykładowe filtry tworzone na liście rejestru VAT

@PAR ?@LS20(CDN_KNT.DLL|CALLLOOKUPKNTLISTAGRUP())|Kontrahent|&Kontrahent:REG= @? PAR@ kna.KnA_KntNumer=??Kontrahent

@PAR ?@R(SELECT sch_gidnumer, sch_nazwa from cdn.schematy)|Schemat|&Schemat:REG= @? PAR@ trn_gidnumer in (select trn_gidnumer from cdn.tranag join cdn.schematy on TrN_SchTyp=Sch_GidTyp and TrN_SchNumer=Sch_GidNumer and Sch_GiDNumer=??Schemat)

@PAR ?@D17|Data_wystawienia_od|&Data_wystawienia_od:REG={DateClwFirstDay('m')} @? PAR@ @PAR ?@D17|Data_wystawienia_do|&Data_wystawienia_do:REG={DateClwLastDay('m')} @? PAR@ @PAR ?@D17|Termin_płatności_od|&Termin_płatności_od:REG={DateClwFirstDay('m')} @? PAR@ @PAR ?@D17|Termin_płatności_do|&Termin_płatności_do:REG={DateClwLastDay('m')} @? PAR@

TrN_TrNSeria=?@S100|seria:'' AND TrN_Data2>=??Data_wystawienia_od AND TrN_Data2<=??Data_wystawienia_do and trn_gidnumer in (select trp_gidnumer from cdn.traplat join cdn.tranag on TrN_GIDTyp=TRP_GIDTyp AND TrN_GIDNumer=TRP_GIDNumer where trp_termin>=??Termin_płatności_od and trp_termin<=??Termin_płatności_do)

(ltrim(trn_trnnumer) + '/' + rtrim(trn_trnseria)) like '%' + ?@S100|Numer syst. faktury:'' + '%'

trn_gidnumer in (select trn_gidnumer from cdn.tranag inner join cdn.opekarty on trn_openumerw=ope_gidnumer where Ope_Ident=?@S100|KTO (podaj swój login):'' ) or trn_gidnumer in (select trn_gidnumer from cdn.tranag inner join cdn.opekarty on trn_openumerm=ope_gidnumer where Ope_Ident=?@S100|KTO (podaj swój login):'' ) or trn_gidnumer in (select trn_gidnumer from cdn.tranag inner join cdn.opekarty on trn_openumerz=ope_gidnumer where Ope_Ident=?@S100|KTO (podaj swój login):'' )

trn_gidnumer in (select trn_gidnumer from cdn.tranag inner join cdn.kntkarty on Knt_GIDNumer=TrN_KntNumer where Knt_ExpoKraj=1)

@PAR ?@LS20(CDN_TWR.DLL|CALLLOOKUPTWRLISTAGRUP())|Towar|&Towar:REG= @? PAR@

TrN_GIDNumer in (select tre_gidnumer from cdn.traelem where tre_twrnumer=??Towar)

@PAR ?@LS30(CDN_KKS.DLL|CALLLOOKUPKKSLISTA())|kontoksiegowe|Konto:REG= @? PAR@

exists(select 1 from cdn.zrodla join cdn.dekrety on zro_dtnumer=dt_gidnumer and zro_dttyp=dt_gidtyp where trv_gidnumer=zro_trnNumer and trv_gidTyp=zro_trnTyp and DT_KKSNumer=??kontoksiegowe)

Przykładowe filtry tworzone na liście zapisów księgowych

dzk_gidnumer in (select dt_gidnumer from cdn.dekrety join cdn.zrodla on zro_dttyp = dt_gidtyp and zro_dtnumer = dt_gidnumer and zro_dtlp = dt_gidlp join cdn.tranag on trn_gidnumer = zro_trnnumer and zro_trntyp = trn_gidtyp where TrN_VatRejestr=?@S100|VAT Rejestr:'')

dzk_gidnumer in (select dt_gidnumer from cdn.dekrety join cdn.zrodla on zro_dttyp = dt_gidtyp and zro_dtnumer = dt_gidnumer and zro_dtlp = dt_gidlp join cdn.tranag on trn_gidnumer = zro_trnnumer and zro_trntyp = trn_gidtyp where TrN_gidtyp = 1489)

dzk_gidnumer not in (select dt_gidnumer from cdn.dekrety join cdn.zrodla on zro_dttyp = dt_gidtyp and zro_dtnumer = dt_gidnumer and zro_dtlp = dt_gidlp join cdn.tranag on trn_gidnumer = zro_trnnumer and zro_trntyp = trn_gidtyp)

DZK_OPEWNumer in (select DZK_OPEWNumer from cdn.opekarty join cdn.dziennik on DZK_OPEWNumer=Ope_GIDNumer where Ope_Ident='Admin')

Wstęp

Opis analityczny w module Księgowość systemu Comarch ERP XL stwarza szybką i prostą możliwość księgowania dokumentu na różne konta kosztowe układu rodzajowego i kalkulacyjnego oraz konta przychodowe. W platformie Business Intelligence jest narzędziem, za pomocą którego można budować dowolne raporty controllingowe i wykonywać różnorodne analizy.

Niniejszy dokument ma na celu zaprezentowanie opisu analitycznego w kontekście jego zastosowania w księgowaniu kosztowym i przychodowym dokumentów. Przedstawiony zostanie proces księgowania dokumentu opisanego analitycznie przy pomocy zakładki: Opis analityczny, od momentu skonfigurowania wymiarów analitycznych, poprzez zdefiniowanie schematu korzystającego z opisu analitycznego, aż po opisanie analityczne dokumentu i zaksięgowanie dokumentu zdefiniowanym schematem.

Zakładka: Opis analityczny

Dokumenty, które mogą być opisywane analitycznie posiadają zakładkę: Opis analityczny (formatka dokumentu, zakładka: Księgowość, podzakładka: Opis analityczny). Opis analityczny posiadają na swoich kartotekach również obiekty typu towary, pracownicy, środki trwałe, itp. Dzięki temu jest możliwość wprowadzenia na tych kartotekach wzorca opisu analitycznego wykorzystywanego później do automatycznego opisu analitycznego dokumentów.

Zakładka: ‘Opis analityczny’ na dokumentach jest aktywna zawsze w przypadku zatwierdzonych dokumentów.

Możliwe jest również opisanie analityczne dokumentów pozostających w buforze handlowym. Funkcjonalność udostępniono dla dokumentów:

oraz na Zamówieniach.

Opisu analitycznego dokumentu w buforze może dokonać tylko Operator posiadający uprawnienie: Opis analityczny dokumentów w buforze pod warunkiem, że taki opis umożliwiony został dla danego typu dokumentu. Oznacza to, że na definicji dokumentu zaznaczono opcję: ‘Dozwolony opis dokumentu w buforze’.

Wygląd zakładki: opis analityczny na dokumencie w buforze jest analogiczny do dokumentu zatwierdzonego. Opisu analitycznego dokumentu w buforze nie można jednak zatwierdzić.

Istotne obszary na zakładce: Opis analityczny w ujęciu ich znaczenia w module Księgowość to:

Razem - łączna kwota z dokumentu. Dokumenty mogą być opisywane na kwotę netto lub brutto. Kwota brutto pojawi się na dokumentach kosztowych (fakturach zakupu), dla których flaga: Odliczenia VAT ustawiona jest na: Nie.

Wg Wzorca - ta część kwoty dokumentu, która zostanie opisana wg wzorca dokument (pozycje: <dokument>).

Wg elementów - ta część kwoty dokumentu, która zostanie opisana wg szczegółowej specyfikacji dla poszczególnych elementów dokumentu.

Zatwierdził - akronim Operatora, który zatwierdził opis analityczny. Odtwierdzanie opisu analitycznego uzależnione jest od ustawień konfiguracyjnych (System/Konfiguracja/BI/Parametry) oraz ustawień na karcie Operatora (Zakładka: Parametry, podzakładka: Ogólne, sekcja: Modyfikacja opisu analitycznego).

Wzorzec – umożliwia wybór zdefiniowanego zestawu wartości opisu analitycznego

[Wypełnij] – automatyczne wypełnienie opisu analitycznego. Funkcjonalność umożliwia przepisywanie opisu analitycznego z elementu dokumentu na zakładkę opis analityczny dokumentu. Przykładowo jeżeli na kartach towarów będących elementami danego dokumentu został uzupełniony szablon opisu analitycznego to naciśnięcie tego przycisku spowoduje wypełnienie opisu zgodnie z tym szablonem. Dodatkowo pod przycisk można podpiąć funkcję serwerową, która będzie uzupełniała opis. Rysunki poniżej przedstawiają przykładowy szablon opisu analitycznego na karcie towarowej oraz dokument, w którym opis analityczny został według niego wypełniony.

Tabela na zakładce: Opis analityczny zawiera linie opisu analitycznego podzielone na kolumny:

Pozycja – w tej kolumnie określone jest, jakiego elementu dokumentu (lub całego dokumentu, jeśli jest to wzorzec <dokument>) dotyczy linia opisu.

Procent – zawiera informację o tym, jakiej części wartości elementu lub dokumentu dotyczy linia opisu (wyrażona w procentach)

Wartość - zawiera informację o tym, jakiej wartości elementu lub dokumentu dotyczy linia opisu.

Liczba i rodzaj pozostałych kolumn zależna jest od liczby zdefiniowanych w systemie wymiarów analitycznych i ustawień na definicji danego dokumentu. Każda z tych kolumn odpowiada jednemu z wymiarów i można ją uzupełniać tylko wartościami danego wymiaru.

Dodatkowo na zakładce: Opis analityczny definicji dokumentu można wprowadzić dopuszczalne wartości wymiarów, tzw. „krotki”. Przykładowo: na dokumencie wybrane jest centrum, kategoria finansowa oraz wymiar PIĄTKI. Dla Centrum są zdefiniowane następujące elementy: dział administracji, dział handlowy. Dla Kategorii: 411-01, 411-02, 411-03, 425-01, 425-02. Dla wymiaru PIĄTKI: produkcja podstawowa, koszty wydziałowe, koszty zarządu i administracji. Na poziomie zakładki: Opis analityczny definicji dokumentu można stworzyć odpowiednie kombinacje elementów. Przykładowo istnieje możliwość wykonania konfiguracji, aby wybierając na dokumencie centrum typu dział administracji istniała możliwość wybrania dla wymiaru PIĄTKI tylko elementu: koszty wydziałowe i dowolnego elementu z wymiaru Kategoria (pozostawienie pustego miejsca w kolumnie danego wymiaru oznacza możliwość wyboru na dokumencie każdego elementu tego wymiaru).

Opis analityczny z poziomu listy dokumentów

W programie Comarch ERP XL umożliwiono wykonywanie opisu analitycznego jednocześnie dla wielu dokumentów. Opcja ta dostępna jest z poziomu: Listy dokumentów handlowych, dla następujących grup:

oraz z poziomu listy zamówień.

Opisu analitycznego z listy dokumentów można dokonać:

Podczas dokonywania opisu analitycznego według wzorca, w oknie parametrów opisu należy wskazać: jakie typy dokumentów spośród zaznaczonych na liście powinny zostać opisane oraz z użyciem jakiego wzorca. Domyślnie opisowi analitycznemu z listy podlegają dokumenty nieopisane, ale za pomocą opcji: Zastosuj dla dokumentów, umożliwiono podmianę już istniejącego na dokumentach opisu, pod warunkiem, że nie jest on zatwierdzony.

Analogicznie w przypadku wybrania opcji ‘Opisz anal. Zaznaczone’ . Użytkownik wykorzystując parametry: Wypełnij opis dla dokumentów ma możliwość zadecydowania, czy uzupełnić opis na dokumentach nieopisanych, czy dodatkowo podmienić go na dokumentach, na których opis analityczny już istnieje.

Dodatkowo w systemie dostępny jest zakaz dla Operatora: Opisz analitycznie listę dokumentów handlowych, który blokuje użytkownikowi możliwość dokonywania seryjnego opisu analitycznego z listy dokumentów.

Wzorce opisu analitycznego

Opis analityczny dokonywany na dokumencie może być wprowadzony „ręcznie” bądź z wykorzystaniem procedury, która generuje wartości opisu analitycznego na podstawie wartości domyślnych, wprowadzonych na kartach obiektów (np. kartotekach towarowych lub środków trwałych). W niektórych sytuacjach dokumenty mogą być opisywane zgodnie ze stałym zestawem wartości, tzw. wzorcem opisu analitycznego (np. cyklicznie otrzymywane dokumenty kosztowe).

Definiowanie wzorca opisu analitycznego możliwe jest z poziomu:

Lista: Wzorce opisu analitycznego

Lista wzorców wyświetlana jest w układzie:

Wzorce opisu analitycznego posortowane są według kodu.

Na liście istnieje możliwość filtrowania wzorców według zbudowanego filtra (pole Filtr). Lista umożliwia także wyświetlenie wzorców nieaktywnych (parametr: Archiwalne).

Czynności możliwe do wykonania z poziomu listy:

Formularz wzorca opisu analitycznego

Formularz wzorca opisu zawiera parametry opisane w poniższej w tabeli.

Parametry	Uwagi
Kod	Kod wzorca
Nazwa	Nazwa wzorca
Obiekt	Typ dokumentu lub słownik (Pracownicy, Towary, Środki trwałe), dla którego tworzony jest wzorzec opisu
Rodzaj wzorca	Proponowany lub Obowiązkowy
Archiwalny	Wzorzec archiwalny nie jest możliwy do wybrania na obiekcie
Element opisu	Szablon linii opisu analitycznego
Wprowadził	Identyfikator operatora
Modyfikował	Identyfikator operatora

Elementy opisu analitycznego prezentowane są w układzie:

W zależności od rodzaju kwoty wskazanej w definicji wzorca, na dokumentach prezentowane będą następujące wartości:

Zbudowany wzorzec opisu analitycznego jest gotowy do wybrania na dokumencie/obiekcie na zakładce: Opis analityczny w polu: Wzorzec z rozwijaną listą dostępnych dla danego obiektu wzorców. Wybór wzorca skutkuje automatycznym wypełnieniem opisu analitycznego na dokumencie/obiekcie.

Obsługa wzorców na kartach obiektów i dokumentów

Na kartach obiektów (pracownik, towar, środek trwały) lub dokumentów można wykorzystać zdefiniowany wcześniej wzorzec bądź utworzyć na podstawie wprowadzonych wartości nową definicję.

Użycie wzorca polega na wyborze wartości z listy wzorców przyporządkowanych do danego typu obiektu/dokumentu - po wskazaniu danego wzorca wygenerowane zostaną linie opisu analitycznego zgodnie z zestawieniem podanym we wskazanej definicji.

Jeżeli wzorzec został zdefiniowany jako obowiązkowy, nie będzie możliwości modyfikacji wygenerowanego opisu analitycznego. W przypadku wzorca proponowanego opcje służące do dodania/edycji/usunięcia pozycji opisu analitycznego będą aktywne.

Przyklad

Dla dokumentu FZ zdefiniowano wzorzec o nazwie „Energia”, w którym zdefiniowano dwie linie: Rodzaj kwoty [Dowolna] Centrum [Dział Administracji] Kategoria [Zużycie energii] Procent [60%] Rodzaj kwoty [Dowolna] Centrum [Dział Handlowy] Kategoria [Zużycie energii] Procent [40%] Rejestrowany jest dokument (A) FZ na kwotę 4000,00 netto (rodzaj zakupu – koszty), na którym VAT w wysokości 920,00 nie podlega odliczeniu. Po przypięciu wzorca powinny zostać wygenerowane cztery linie: 1) Pozycja [dokument_koszty] Centrum [Dział Administracji] Kategoria [Zużycie energii] Procent [60%] Wartość [2 400,00] 2) Pozycja [dokument_koszty] Centrum [Dział Handlowy] Kategoria [Zużycie energii] Procent [40%] Wartość [1 600,00] 3) Pozycja [dokument_VAT_koszt] Centrum [Dział Administracji] Kategoria [Zużycie energii] Procent [60%] Wartość [552,00] 4) Pozycja [dokument_VAT_koszt] Centrum [Dział Handlowy] Kategoria [Zużycie energii] Procent [40%] Wartość [368,00]

Tym samym, Użytkownik nie musi samodzielnie uzupełniać każdej linii opisu analitycznego – co wymaga podania wartości procentowych oraz wyboru odpowiednich elementów wymiarów dla każdej pozycji – wskazuje tylko zdefiniowany wcześniej Wzorzec, uzyskując ten sam efekt w krótszym czasie.

Istniejący już wzorzec opisu analitycznego może zostać skopiowany przy pomocy standardowej opcji „Ctrl” + „Ins” wykonywanej z poziomu listy: Wzorce opisu analitycznego. Można także posłużyć się funkcjonalnością kopiowania wzorca z definicji innego dokumentu/obiektu. Po wyborze przycisku opisanego jako „Kopiuj z definicji innego dokumentu” pojawia się dostępna lista wzorców opisu analitycznego.

Po wyborze parametru „Dopisać do istniejących” do edytowanej definicji dokumentu zostaną dodane wskazane wzorce. Jeżeli natomiast zostanie wybrana opcja „Zastąpić nimi istniejące” na edytowanej definicji dokumentu zostaną usunięte dotychczasowe wzorce, a dodane te, które zostały wybrane przez Użytkownika.

Uwaga

Opcja kopiowania ma największe zastosowanie w sytuacji gdy na obu dokumentach/obiektach zdefiniowano takie same wymiary (kolumny).

Definiowanie wymiarów analitycznych

W systemie dostępne są predefiniowane wymiary analityczne typu: Centrum, Kategoria, Projekt, Lokalizacja. Dodatkowo użytkownik ma możliwość dodawania wymiarów według własnych potrzeb.

Kategorie finansowe

Kategorie finansowe są wymiarem systemowym, na podstawie którego wykonywane są raporty controllingowe przychodów i kosztów. Predefiniowane są cztery kategorie główne:

Koszt – dokumenty kosztowe Przychód – dokumenty stanowiące przychód Nie-Koszt – wydatki nie będące kosztem Nie-Przychód – wpływy nie stanowiące przychodu

W module Księgowość, na kategorii finansowej typu Koszt, użytkownik ma możliwość odzwierciedlenia na przykład struktury kosztów układu rodzajowego, do której następnie może odwołać się z poziomu zakładki: Opis analityczny dokumentów, wybierając odpowiednie elementy (przykładowo konta zespołu 4 z planu kont) w kolumnie o nazwie Kategoria.

Każda z czterech głównych kategorii finansowych może mieć wielopoziomową strukturę (zawierać dowolnie wiele podkategorii). Na końcu takiego łańcucha znajdują się elementy kategorii. Elementy kategorii mogą przybrać jedną z trzech postaci:

Typu słownikowego (element wymiaru) – element zdefiniowany jest „na sztywno” jako element wymiaru.

Typu „Z planu kont” – elementem jest konto wybrane z planu kont. Przykładowo jeżeli na formatce elementu wymiaru wskazane jest konto syntetyczne 425, wybranie tego elementu na zakładce: Opis analityczny dokumentu spowoduje wyświetlenie listy ze strukturą planu kont konta 425, tj. konto syntetyczne plus konta analityczne. Przy takiej konfiguracji dodanie lub usunięcie konta księgowego w planie kont w ramach struktury konta wskazanego w wymiarze powoduje automatyczną aktualizację jej elementów.

Wybranie na formatce elementu wymiaru obok opcji: z planu kont, dodatkowo również opcji: Materializuj wymiar spowoduje skopiowanie na wymiar struktury planu kont konta wskazanego na wymiarze, czyli nastąpi przypięcie na wymiar kont analitycznych tego konta jako elementów wymiaru analitycznego. Przy takiej konfiguracji dodanie nowego konta analitycznego w planie kont pod konto syntetyczne wskazane na wymiarze, wymaga dodatkowo wykonania przez użytkownika, czynności aktualizacji wymiaru poprzez ponowne wybranie opcji Materializuj wymiar. Wtedy nowe konto analityczne zostanie dodane do wymiaru jako element wymiaru.

Typu SQL - służy do zaawansowanego projektowania kategorii finansowej. Przy pomocy składni SQL można określić warunki (składnią klauzuli WHERE), na podstawie których zwrócony zostanie słownik wskazanych wartości. Kategoria typu SQL jest kategorią dynamiczną – oznacza to, że lista jej elementów jest aktualizowana w chwili jej wyświetlania. Przykładowo: select kks_konto as 'Numer konta', kks_nazwa as 'Nazwa konta' from cdn.konta where kks_konto like '4%' and kks_analityka=1 and kks_rok=2020, wyświetli listę wszystkich kont analitycznych układu 4 w roku obrachunkowym 2020.

Lista wymiarów i warunków

W analogiczny sposób do wymiaru Kategorie finansowe tworzone są wymiary analityczne definiowane przez użytkownika. Możliwość dodawania wymiarów dostępna jest z poziomu Listy wymiarów i warunków. Lista ta w odróżnieniu od listy Kategorie finansowe, posiada zakładkę Procedury, na której istnieje możliwość ustalenia warunków, na jakich będą opisywane analitycznie poszczególne grupy dokumentów za pomocą przycisku na zakładce: Opis analityczny opisywanego dokumentu.

Centrum

Kolumna Centrum na zakładce Opis analityczny dokumentu jest odpowiednikiem Struktury kosztowej – drugiej zakładki Struktury firmy zlokalizowanej w module Administrator. Centrum jest wymiarem predefiniowanym przez system. Elementy struktury kosztowej definiowane są w formie drzewiastej i stanowią miejsce powstawania kosztów. W polu: Konto na elemencie istnieje możliwość wskazania konta księgowego, którego będzie wykorzystane podczas księgowania w oparciu o opis analityczny. Istnieje również możliwość wprowadzenia dowolnego ciągu alfanumerycznego, który następnie może być wykorzystany do stworzenia nowego konta księgowego za pośrednictwem schematu księgowego.

Projekty

Projekty to również wymiar systemowy, za pomocą którego można opisywać analitycznie dokumenty. Podobnie jak w przypadku Centrum, pole Konto na elemencie wymiaru wypełniane jest konkretnym kontem z planu kont lub dowolnym ciągiem alfanumerycznym. Elementy wymiaru Projekt wybierane są przez Użytkownika na opisie analitycznym dokumentu w kolumnie Projekt.

Lokalizacja

Wymiar Lokalizacja dostępny jest z poziomu listy słowników kategorii. Podobnie jak wymiary: Kategorie finansowe, Centrum, Projekt, jest również wymiarem predefiniowanym przez system, budowanym w sposób analogiczny do pozostałych wymiarów analitycznych. Pole: Konto na elemencie wymiaru może być wypełnione konkretnym kontem z planu kont lub dowolnym ciągiem alfanumerycznym. Elementy wymiaru Lokalizacja wybierane są przez Użytkownika na opisie analitycznym dokumentu w kolumnie Lokalizacja.

Tworzenie schematu księgowego w oparciu o Oblicz dla: Opisu analitycznego

W celu zaksięgowania dokumentu w oparciu o opis analityczny, należy odpowiednio zdefiniować schemat księgowy. Pozycje schematu księgowego odnoszące się do zakładki Opis analityczny dokumentu należy zdefiniować w oparciu o Oblicz dla: Opisu analitycznego. W polu Kwota należy wybrać Wartość - jest to kwota w danej linii opisu analitycznego. W polu Konto księgowe można odwołać się do jednego z dostępnych, pod przyciskiem Konto księgowe, wymiarów analitycznych (np. @KATEGORIA), co oznacza księgowanie bezpośrednio na konto przypięte do wybranego na dokumencie elementu wymiaru. Inną możliwością, jeśli chodzi o Konto księgowe, jest zaznaczenie opcji: Wyrażenie, Załóż konto, co pozwoli na stworzenie nowego konta księgowego w oparciu o odpowiednie elementy wymiarów analitycznych. Rysunek przedstawiony poniżej prezentuje pozycję schematu księgowego zbudowaną w oparciu o opis analityczny, zawierającą wyrażenie zakładające konta zespołu 5 w oparciu o oznaczenia alfanumeryczne wprowadzone w polu Konto na elementach wymiarów analitycznych. Kolejne poziomy konta zespołu 5 zbudowane są z następujących wymiarów:

PIĄTKI - Centrum - Kategoria

Elementy wymiaru PIĄTKI mają przypięte konta syntetyczne: 527-produkcja podstawowa, 502- koszty wydziałowe, 503-koszty zarządu i administracji. Na wymiar Centrum przypięte są elementy odpowiadające miejscom powstawania kosztów. Przykładowo: dział administracji z oznaczeniem w polu Konto 01, dział handlowy z oznaczeniem 02, dział księgowy z oznaczeniem 03, dział produkcji z oznaczeniem 04 itp. Wymiar Kategoria odzwierciedla strukturę planu kont dotyczącą kosztów układu rodzajowego. W przypadku konta Kategorii została zastosowana funkcja sub, co umożliwia wycięcie z konta Kategorii określonej liczby znaków.

Księgowanie dokumentu w oparciu o Opis analityczny

Po zdefiniowaniu schematu księgowego w oparciu o opis analityczny, kolejnym etapem w księgowaniu kosztowym lub przychodowym dokumentu, jest opisanie analityczne dokumentu. Poniższy rysunek prezentuje zakładkę: Opis analityczny dokumentu, na której rozbito analitycznie koszty na odpowiednie elementy wymiarów analitycznych.

Po uzupełnieniu zakładki Opis analityczny na dokumencie, można przystąpić do księgowania dokumentu schematem księgowym zbudowanym w oparciu o Oblicz dla: Opisu analitycznego. Poniższy rysunek prezentuje rozksięgowanie kosztowe dokumentu na konta zespołu 4 i konta zespołu 5. Konta zespołu 5 są zakładane w planie kont w momencie księgowania dokumentu (wyświetlane są w kolorze zielonym na zakładce Dekretacja dokumentu).

Ewidencja korekty podatku odliczonego

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

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

Ustawienia konfiguracyjne

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

Ustalenie korekty podatku naliczonego od zakupu towarów

Załóżmy, że: Rok poprzedni np.: 2015

Jak zarejestrować korektę w systemie Comarch ERP XL

Sposób 1

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

Sposób 2

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

Reasumując:

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

Struktura sprzedaży z roku 2016 = 97%.

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

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

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

W przypadku Środków Trwałych, okres korekty do tyczy 5 lat (nieruchomości - 10 lat). Załóżmy, że:

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

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

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

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

Jak zarejestrować korektę w systemie ERP XL

Sposób 1

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

Sposób 2

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

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

Pozycja 1 Netto: 0,00 VAT: 1.869,92 ( 1/5 kwoty 9.349,59) Odliczenie podatku VAT – „Warunkowo” (kwota podatku będzie korygowana przez strukturę sprzedaży) Miesiąc ujęcia na deklaracji VAT-7 – 2017/01. Pozycja 2 Netto: 0,00 VAT: (-1608,13), (1/5 kwoty 8.040,65, która faktycznie została odliczona – Wsp. proporcji jest nam znany) Odliczenie podatku VAT – „TAK” Miesiąc ujęcia na deklaracji VAT-7 – 2017/01.

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

Uwaga

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

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

Reasumując:

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

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

Pomocne wydruki

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

Weryfikacja wysokości podatku naliczonego niepodlegającego odliczeniu

Załóżmy, że:

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

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

 

Wstęp

Uwaga

Biuletyn dotyczy wersji 2016.3.4 Comarch ERP XL i starszych. Od wersji 2017.0  Comarch ERP XL konfiguracja powinna zostać przeprowadzona zgodnie z biuletynem technicznym " XL 064 -Współpraca Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR".  W tej wersji wprowadzono automatyczne tworzenie zlinkowanego serwera oraz jego mapowanie na bazy Comarch ERP XL oraz Comarch ERP XL HR.

Od wersji 2013.6 systemu Comarch ERP XL ( i wersji 2013.7.1 systemu Comarch ERP XL HR) został wprowadzony mechanizm pozwalający na synchronizację dwustronną obiektów struktury firmy tzn. wydziałów, lokalizacji i projektów. Pozwoli to odzwierciedlać w obu bazach wszystkie dane, niezależnie od systemu, w którym zostały wprowadzone. Poza dodawaniem i aktualizacją tych obiektów, umożliwiamy również ich jednoczesne usuwanie z obu baz.

Uwaga

W wersji Comarch ERP XL 2015.0 oraz Comarch ERP XL HR 2014.6.1 wprowadzono pełną obustronną synchronizację pracowników i obiektów z nimi powiązanych, takich jak: banki i formy płatności, atrybuty oraz karty RCP.

Konfiguracja po stronie serwera SQL

Bazy systemu Comarch ERP XL i Comarch ERP XL HR znajdują się na jednym serwerze

Aby zsynchronizować ze sobą bazy systemu Comarch ERP XL i Comarch ERP XL HR, które znajdują się na tym samym serwerze, należy dodać login SQL oraz zlinkowany serwer zgodnie z opisem poniżej.

Dodanie loginu

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 wpisać nazwę loginu i jego hasło.

Należy zaznaczyć rolę: public i sysadmin.

Login CDNDTS należy zmapować na bazę:

W obszarze Database role membership for: należy zaznaczyć role: CDN, CDNRaport, public, db_owner.

W obszarze Database role membership for: zaznaczyć role: CDNRaport, public.

W obszarze Database role membership for: zaznaczyć role: CDNRaport, public, db_owner.

Dodanie zlinkowanego serwera

Pomimo tego, że obie bazy znajdują się na jednym serwerze, konieczne jest dodanie zlinkowanego serwera. Nowy zlinkowany serwer powinien mieć nazwę: 'Nazwa serwera'+'_Place'. Podczas jego tworzenia zalecane jest użycie poniższego skryptu:

DECLARE @nazwa_serwera nvarchar(128)

DECLARE @sciezka nvarchar(4000)

DECLARE @uzytkownik_zdalny nvarchar(128)

DECLARE @haslo nvarchar(128)

set @nazwa_serwera = 'nazwa serwera'+'_Place'

set @sciezka= 'ścieżka serwera'

set @uzytkownik_zdalny = 'login do serwera'

set @haslo = 'hasło loginu'

if exists (select srvname from master..sysservers where srvname =@nazwa_serwera)

BEGIN

EXEC sp_dropserver @nazwa_serwera,'droplogins'

END

EXEC sp_addlinkedserver @nazwa_serwera, @srvproduct='', @provider=N'SQLOLEDB', @datasrc = @sciezka

EXEC sp_addlinkedsrvlogin @nazwa_serwera, 'false', NULL, @uzytkownik_zdalny , @haslo

EXEC master.dbo.sp_serveroption @server=@nazwa_serwera, @optname=N'rpc', @optvalue=N'true'

EXEC master.dbo.sp_serveroption @server=@nazwa_serwera, @optname=N'rpc out', @optvalue=N'true'

gdzie parametry:

@uzytkownik_zdalny i @haslo - odnoszą się do loginu założonego w pkt. Dodanie loginu, @nazwa_serwera – nazwa serwera ( wraz z instancją, jeżeli istnieje), gdzie znajdują się bazy Comarch ERP XL HR i Comarch ERP XL @sciezka - odpowiada fizycznej nazwie serwera SQL, na którym znajduje się baza Comarch ERP XL HR i Comarch ERP XL

Uwaga

Użytkownicy, którzy korzystali wcześniej z funkcjonalności „Import list płac za pomocą procedur składowanych” i mieli już utworzony zlinkowany serwer, nie muszą wykonywać linkowania po raz drugi. Wystarczy, że we właściwościach zlinkowanego serwera na zakładce: Server Options zweryfikują parametry RPC i RPC Out i przestawią ich wartość na TRUE.

Bazy systemu Comarch ERP XL i Comarch ERP XL HR znajdują się na różnych serwerach

Dodanie loginu

Jeśli bazy Comarch ERP XL i Comarch ERP XL HR zlokalizowane są na różnych serwerach, wtedy na obu tych serwerach SQL należy dodać ten sam nowy login z hasłem, jak opisano pkt. Dodanie loginu.

Uwaga

Na serwerze z bazą Comarch ERP XL należy zmapować login na bazę Comarch ERP XL, a na serwerze z bazą Comarch ERP XL HR należy zmapować login na bazę Comarch ERP XL HR oraz bazę konfiguracyjną Comarch ERP XL HR . Mapowanie loginów zgodnie z opisem w punkcie Dodanie loginu.

Dodanie zlinkowanych serwerów

Łącznie wymagane jest dodanie trzech zlinkowanych serwerów:

Serwery należy dodać zgodnie z opisem poniżej.

Na każdym serwerze SQL (zarówno na tym, gdzie znajduje się baza systemu Comarch ERP XL jak i tym, gdzie znajduje się baza Comarch ERP XL HR) należy dodać zlinkowany serwer o nazwie 'Nazwa serwera XL HR'+'_Place'.

Uwaga

Na obu serwerach, zlinkowany serwer musi mieć taką samą nazwę, czyli 'Nazwa serwera XL HR'+'_Place'.

Tworząc taki serwer zalecane jest skorzystanie ze skryptu umieszczonego w pkt. Dodanie zlinkowanego serwera , gdzie jako nazwę serwera przekazujemy nazwę serwera, gdzie znajduje się baza Comarch ERP XL HR, a jako użytkownika zdalnego, dane loginu dodanego w pkt. Dodanie loginu.

Trzeci zlinkowany serwer należy dodać, po stronie serwera, gdzie znajduje się baza Comarch ERP XL HR. Z poziomu narzędzia: Microsoft SQL Server Management Studio > Server Objects > Linked Servers, należy wybrać opcję: New Linked Server…

Ustawienia zlinkowanego serwera:

Jako nazwę zlinkowanego serwera należy podać nazwę serwera SQL, na którym znajduje się baza Comarch ERP XL, a jako 'Server Type' należy wybrać opcję: SQL Server.

W polach: 'Local Login' i 'Remote User' należy podać nazwę użytkownika z pkt. Dodanie loginu, a w polu 'Remote Password' należy wpisać dla niego hasło. Zaznaczyć opcję: 'Be made using the login’s current security context'.

Należy przestawić parametry RPC i RPC Out na wartość TRUE.

Ustawienia w systemie Windows

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ę należy uruchomić dla każdego synchronizowanego serwera.

Należy uruchomić usługę lokalną o nazwie: Koordynator transakcji rozproszonych.

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 w systemie Comarch ERP XL

Konfiguracja synchronizacji struktury organizacyjnej

W konfiguracji systemu Comarch ERP XL na zakładce: HR należy 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 punkcie Dodanie loginu.

Konfiguracja importu list płac

Aby możliwy był import list płac z systemu Comarch ERP XL HR, należy prawidłowo uzupełnić dane zestawu DTS w module: Administrator (Narzędzia>Transformacje DTS).

Uwaga

Aby import list płac z systemu Comarch ERP XL HR do systemu Comarch ERP XL był możliwy, oprócz ustawienia zestawu DTS należy wcześniej wykonać kroki opisanych w punkcie Konfiguracja po stronie serwera SQL.

Konfiguracja w systemie Comarch ERP XL HR

W konfiguracji systemu Comarch ERP XL HR, zakładka: Płace, podzakładka: Parametry współpracy z XL, należy zaznaczyć check: Współpraca z systemem Comarch ERP XL i w polach: Serwer bazy danych systemu XL i Baza danych systemu XL, wprowadzić kolejno nazwę serwera SQL, gdzie znajduje się baza systemu Comarch ERP XL i nazwę tej bazy.

   

Wstęp

W związku ze zmianami wprowadzonymi do ustaw o podatku dochodowym w zakresie przeliczania transakcji wyrażonych w walutach obcych na polskie złote, konieczne jest stosowanie różnych kursów wymiany walut dla celów podatku dochodowego i dla celów rozliczeń podatku VAT.

Na potrzeby podwójnego przeliczania wartości transakcji walutowych, dostępny jest dodatkowy moduł systemu Comarch ERP XL – CDNAVAT. Jest on dostępny w katalogu, w którym znajdują się pliki systemu Comarch ERP XL.

Zgodnie z funkcjonalnością systemu, na dokumenty handlowe, rejestrowane po stronie modułu: Sprzedaż, kurs podpowiadany jest:

Funkcjonalność modułu CDNAVAT pozwala na automatyczne generowanie do walutowych dokumentów handlowych, dodatkowych dokumentów, w formie tzw. faktur a-vista. Faktury a-vista ewidencjonowane są po stronie rejestrów VAT. Nie wpływają one na stany magazynowe i nie posiadają elementów transakcji. Zawierają natomiast dane przepisane z dokumentu źródłowego pozwalające na identyfikację przeprowadzonej transakcji i jej prawidłową rejestrację w rejestrach VAT. Na wygenerowanych fakturach a-vista, podstawa opodatkowania oraz podatek VAT przeliczane są domyślnie na PLN:

Użytkownikom systemu umożliwiono także „ręczne” wskazanie kursu, po którym ma zostać przeliczone zobowiązanie z tyt. VAT.

Moduł CDNAVAT

Po uruchomieniu modułu CDNAVAT, w toolbarze dostępne są dwie ikony: Dokumenty, Lista kursów walut. Generację faktur a-vista udostępniono z poziomu listy: Dokumenty.

Przy pierwszym uruchomieniu listy dokumentów pojawi się komunikat o treści:

W celu automatycznego dodania atrybutów oraz uruchomienia skryptów zapewniających prawidłowe działanie programu należy wybrać opcję: Tak.

Efektem będzie utworzenie trzech poniższych atrybutów.

Nazwa klasy atrybutu	Typ atrybutu	Przypisanie do dokumentu
a-vista	dokument handlowy	dokument źródłowy
KorektaVat_dokument_źródłowy	dokument handlowy	automatycznie wygenerowana faktura a-vista
Kurs z dokumentu źródłowego	Tekst	automatycznie wygenerowana faktura a-vista

Wykonane skrypty będą odpowiadać między innymi za:

Uwaga

W/w predefiniowanym atrybutom nie wolno zmieniać nazwy oraz ich deaktywować. Deaktywacja spowoduje utratę powiązań pomiędzy fakturami źródłowymi, a wygenerowanymi do nich fakturami a-vista. W konsekwencji dokument źródłowy, do którego wygenerowano a-vistę, będzie uważany za „niezwiązany”. Będzie można do niego wygenerować kolejną fakturę a-vista.

Okno: Dokumenty

Okno: Dokumenty, zawiera trzy zakładki: FSE/FEL, FS/FSK, FZ/FZK.

Z poziomu zakładki:

Na dwóch pierwszych zakładkach prezentujących faktury sprzedaży, dokumenty posortowane są wg daty wystawienia. Na trzeciej, wyświetlającej faktury zakupu - wg daty wpływu.

Dane prezentowane w poszczególnych kolumnach pozwalają na identyfikację dokumentów. Są to:

Na każdej z zakładek dostępne są dwie grupy parametrów: parametry o charakterze filtrującym oraz parametry wykorzystywane do generacji faktur a-vista. W grupie parametrów filtrujących, dostępne są:

Dodatkowo Użytkownik ma możliwość zawężenia listy do danego typu dokumentu:

Na zakładce „FSE/FEL” do: Na zakładce „FS/FSK” do: Na zakładce „FZ/FZK” do: W grupie parametrów wpływających na dane generowanej faktury a-vista znajdują się:

– pozwala na wygenerowanie a-visty o numerze, w ramach zadeklarowanej serii. Jeżeli seria nie zostanie wskazana, faktura a-vista otrzyma numer w ramach serii wybranej na dokumencie „źródłowym”.

– pozwala na wygenerowanie faktury a-vista we wskazanym podczas generacji rejestrze. Jeżeli rejestr nie zostanie wybrany, faktura a-vista zostanie utworzona w tym samym rejestrze VAT, w którym znajduje się dokument źródłowy.

 – dostępny pod warunkiem zawężenia listy dokumentów do konkretnej waluty. Pozwala na ręczne wpisanie kursu, po którym zostaną przeliczone wartości tabeli VAT. Wartości przeliczane są na podstawie wartości netto w walucie obcej pobranych z faktury źródłowej. Jeżeli kurs nie zostanie wybrany, wartości na fakturze a-vista zostaną przeliczone po kursie z dnia poprzedzającego datę wystawienia dokumentu źródłowego.

Przyciski na liście dokumentów:

[Wygeneruj dokument a-vista]– pozwala na wygenerowanie faktur a-vista do dokumentów źródłowych,

[Podgląd] - pozwala na podgląd formatki dokumentu. Dokument można także wyświetlić wykonując dwuklik lewym klawiszem myszy na wybranym dokumencie,

[Usuń] – pozwala na usunięcie wygenerowanej faktury a-vista,

[Anuluj] – zamyka listę dokumentów.

Pod prawym klawiszem myszy udostępniono opcje pozwalające na zaznaczanie i odznaczanie wszystkich dokumentów.

Automatycznie wygenerowana faktura a-vista

Uwaga

Po wygenerowaniu faktury a-vista, Użytkownik powinien sprawdzić ustawienie tych parametrów i ewentualnie ustawić je ręcznie.

Uwaga

Po wygenerowaniu faktury a-vista, Użytkownik powinien skontrolować ustawienie tego parametru i ewentualnie zaznaczyć go ręcznie.

Wydruki faktur eksportowych (FSE, FKE)

Z poziomu automatycznie wygenerowanej faktury a-vista oprócz wydruków związanych stricte z fakturą a-vista udostępniono wydruk faktury eksportowej powiązanej z fakturą a-vista. W przypadku opodatkowania transakcji stawkami krajowymi (parametr VAT eksportowy odznaczony), wartości w tabelce VAT prezentowane są w walucie systemowej, przeliczone po kursie wskazanym na fakturze a-vista.

O czym należy pamiętać

Regulacje prawne dotyczące tzw. „złych długów” w podatku VAT

Ustawa deregulacyjna z dnia 16.11.2012 r., art. 89a wprowadziła regulacje prawne dotyczące korygowania podstawy opodatkowania oraz podatku należnego i naliczonego z tytułu transakcji krajowych nieuregulowanych, lub częściowo nieuregulowanych. Zmiana w zakresie skrócenia terminu umożliwiającego skorzystanie z ulgi na złe długi została wprowadzona ustawą z dnia 9 listopada 2018 r. o zmianie niektórych ustaw w celu wprowadzenia uproszczeń dla przedsiębiorców w prawie podatkowym i gospodarczym.

Po stronie wierzyciela

Po stronie dłużnika

Do wierzytelności powstałych przed dniem 1 stycznia 2019 r., których nieściągalność została uprawdopodobniona zgodnie z „nowym” brzmieniem art. 89a ust. 1a, tj. dla których 90 dzień od dnia upływu terminu płatności przypada po dniu 31 grudnia 2018 r., stosuje się przepis w brzmieniu zmienionym (tj. 90 dni).

W przypadku wierzytelności, co do których 90 dzień od upływu terminu płatności przypada przed dniem 1 stycznia 2019 r. stosuje się przepis w brzmieniu dotychczasowym (tj. 150 dni od dnia upływu terminu płatności).

W module księgowym systemu Comarch ERP XL wprowadzone zostały mechanizmy umożliwiające weryfikację dokumentów, które powinny zostać uwzględnione w rozliczeniu złych długów.

Okno: Rejestr VAT

Z poziomu rejestru Vat wprowadzone zostały dodatkowe predefiniowane filtry:

Rodzaj transakcji

Dla opcji: Kraj dodana została rozwijana lista z parametrami do wyboru:

Sekcja Płatności

Dotyczy zakładek: Wg numeru, VAT.

W sekcji Płatności dodana została opcja „Prezentacja wg”, która dostępna jest po wybraniu płatności:

W polu prezentacja wg, do wyboru są dwie opcje:

Od ustawienia tego parametru będzie uzależniony sposób prezentacji danych na liście.

Zestawienie możliwych ustawień ww. filtrów i zależności między nimi.

Płatności	Prezentacja wg:	Stan na dzień	Przeterminowane	Dni zwłoki
Wszystkie	Nieaktywne	Nieaktywne	Nieaktywne	Nieaktywne
Nierozliczone	Aktywne, domyślne ustawienie Płatności	Aktywne	Aktywne	Nieaktywne
Nierozliczone	j.w.	Aktywne	Aktywne Opcja: Tak	Aktywne
Nierozliczone	j.w.	AKtywne	Aktywne Opcja: Nie	Nieaktywne
Rozliczone	Aktywne, domyślne ustawienie Płatności	Aktywne	Aktywne Opcja: Nie	Nieaktywne
Rozliczone	j.w.	Aktywne	Aktywne Opcja: Nie	Aktywne
Rozliczone	j.w.	Aktywne	Aktywne Opcja: Nie	Nieaktywne
Nie podlegające rozliczeniu	Nieaktywne	Nieaktywne	Nieaktywne	Nieaktywne

Jeżeli zostanie wybrana prezentacja wg płatności, to na liście pojawi się dodatkowa kolumna Termin płatności.

Na listach rejestrów VAT typu sprzedaż i zakup znajdują się też parametry pozwalające na wyfiltrowanie płatności, dla których termin płatności plus:

Sekcja: Typ kontrahenta

Filtr ten związany jest z wymogiem, iż Wierzyciel i Dłużnik na dzień poprzedzający dzień złożenia deklaracji, w której dokonuje się korekty muszą być czynnymi podatnikami VAT, ponadto Dłużnik nie może być w trakcie postępowania restrukturyzacyjnego, postępowania upadłościowego lub w trakcie likwidacji.

Analogiczne filtry dotyczące oznaczenia czynnego płatnika VAT i podmiotu w stanie likwidacji/upadłości dodane zostały na karcie kontrahenta (zakładka księgowe) oraz na adresie (zakładka księgowe).

W sekcji tej umieszczony jest też parametr dotyczący statusu vat kontrahenta.

Filtry związane z ujęciem dokumentu na VAT-ZD.

Jeżeli wybrana zostanie opcja Prezentacja wg Płatności, to pod parametrem Informacja podsumowująca pojawia się parametr: Zgłoszenie VAT-ZD, w postaci listy rozwijanej z następującymi opcjami do wyboru:

Jeżeli w polu: Zgłoszenie VAT-ZD zostanie wybrane Tak, automatycznie uaktywni się parametr: Data VAT-ZD, który znajduje się w sekcji: Zakwalifikowano do deklaracji w okresie. W polu tym można wybrać rok i miesiąc deklaracji VAT-ZD.

Deklaracja VAT 7 (VAT 7K, VAT 7D)

W związku z przepisami dotyczącymi ewidencji złych długów na deklaracjach VAT pojawiły się nowe pola.

Od strony wierzyciela pojawiło się pole: Zawiadomienie VAT-ZD z opcjami do wyboru: tak, nie. Po zaznaczeniu opcji Tak, do danej deklaracji uaktywni się załącznik VAT-ZD, zakładka wierzyciel. Natomiast zakładka Dłużnik załącznika VAT-ZD jest aktywna zawsze.

Uwaga

Uwaga: Załącznik VAT –ZD wymagany jest tylko w sytuacji, kiedy użytkownik zaznaczy parametr: tak w polu Zawiadomienie VAT-ZD, czyli w sytuacji, kiedy to wierzyciel pomniejsza podatek. W systemie Comarch ERP XL załącznik VAT- ZD generowany jest pomocniczo również w sytuacji, kiedy dłużnik dokonuje zwiększenia podatku naliczonego

.

Zgłoszenie VAT -ZD

W ramach formularza VAT-ZD zostały dodane dwie podzakładki: Wierzyciel, Dłużnik. Aktywność podzakładki: wierzyciel jest uzależniona od ustawienia parametrów na deklaracji VAT-7, natomiast podzakładka : dłużnik aktywna jest zawsze.

Uwaga

W przypadku deklaracji VAT-7, VAT-7K, o okresach rozliczeniowych do 12/2018 r., faktury do ujęcia na VAT-ZD będą filtrowane na dotychczasowych warunkach, tj. wg parametru „Termin pł. + 150 dni…” W przypadku deklaracji VAT-7, VAT-7K rozliczających podatek VAT od stycznia do marca 2019 r. faktury będą filtrowane na postawie nowego parametru „90 lub 150 dni”, z możliwością zmiany np. na parametr filtrujący faktury na podstawie termin płatności +90 dni W przypadku deklaracji rozliczających podatek VAT począwszy od kwietnia 2019 r. dokumenty do ujęcia na VAT-ZD po stronie sprzedaży i zakupu będą filtrowane wg „Termin płatności + 90 dni…”

Zakładka VAT-ZD, podzakładka Wierzyciel

Na tej zakładce umieszczona została lista, na której będą prezentowane nierozliczone lub rozliczone częściowo płatności typu należność powiązane z dokumentami sprzedaży o okresie przeterminowania powyżej 90 lub 150 dni. Płatności będą prezentowane na dzień wskazany na formularzu (przycisk: Na dzień udostępniony w prawym dolnym rogu okna).

Uwaga

Kontrahent główny na dokumencie sprzedaży, na dzień sporządzenia zgłoszenia musi być czynnym podatnikiem VAT (na karcie kontrahenta głównego zaznaczony musi być parametr: Płatnik VAT) oraz nie może być w trakcie postępowania restrukturyzacyjnego, postępowania upadłościowego lub w trakcie likwidacji (na karcie kontrahenta głównego nie zaznaczony parametr: W likwidacji/upadłości).

Lista zawiera następujące kolumny:

1. Lp. – liczba porządkowa automatycznie nadawana pozycjom – kolumna w trybie multiselect, który może być wykorzystywany do seryjnego usuwania dokumentów;
2. Podatnik z podziałem na dwie podkolumny Akronim, Miasto. Prezentacja Akronimu i Miasta kontrahenta głównego, na którego wystawiono dokument sprzedaży;
3. NIP – numer identyfikacji podatkowej kontrahenta głównego, na którego wystawiono dokument sprzedaży;
4. Nr faktury – numer przepisywany z pola Faktura FS, jeżeli numer ten nie zostanie wypełniony, to numer systemowy faktury sprzedaży;
5. Data wystawienia – data wystawienia faktury sprzedaży;
6. Termin – termin płatności pobrany z nierozliczonej lub rozliczonej częściowo należności powiązanej z fakturą sprzedaży;
7. Kwota korekty podstawy opodatkowania – kwota netto wyliczona dla nierozliczonej płatności;
8. Kwota korekty podatku – kwota vat wyliczona dla nierozliczonej płatności;
9. Kwoty netto, vat w poszczególnych stawkach: 23%, 8%, 7%, 5% oraz netto w stawce 0%, ZW, NP;

W oknie udostępnione zostały następujące ikony:

[Włącz/wyłącz sumowanie]

[Kosz] – możliwość usunięcia poszczególnych pozycji lub pozycji w trybie multiselect

[Podgląd płatności]- pogląd płatności dokumentu

[Podgląd dokumentu]– podgląd dokumentu

[Dodaj pozycje]– możliwość dodania pozycji poprzez wskazanie w rejestrze Vat

[Generuj pozycje] – automatyczne uzupełnianie listy

W górnej części okna, po prawej stronie został udostępniony parametr: Status:

Zmiana statusu Deklaracji VAT-7 z Zaakceptowana na Bufor nie będzie skutkowała zmianą statusu na załączniku VAT-ZD (pozostanie status Zaakceptowana z możliwością zmiany statusu na Bufor, o ile nie wygenerowano korekty w rejestrze VAT do VAT-ZD – (ZD)FS lub (ZD)FZ ).

Jeżeli na VAT-ZD pozostanie status Zaakceptowana, nie będzie możliwości usunięcia deklaracji VAT-7 – próba usunięcia zakończy się komunikatem informującym o istnieniu załącznika VAT-ZD o statusie Zaakceptowana.

Zestawienie statusów VAT-7 i VAT-ZD z akcjami możliwymi do wykonania:

Status VAT-7	Status VAT-ZD	Akcja
		Zmiana statusu VAT-7	Zmiana statusu VAT-ZD	Generacja korekty VAT (ZD)FS lub (ZD)FZ	Usunięcie korekty VAT (ZD)FS lub (ZD)FZ	Księgowa-nie VAT-7	Usunięcie VAT-7
Bufor	Bufor	Tak - na zaakceptowana lub zatwierdzona. Wywołanie tej akcji będzie skutkowało automatycznym zaakceptowaniem VAT-ZD oraz pytaniem o wygenerowanie korekty VAT.	Tak – ręczna zmiana na zaakceptowana	Nie	Nie	Nie	Tak
Bufor	Zaakceptowana	Tak - na zaakceptowana lub zatwierdzona Wywołanie tej akcji będzie skutkowało automatycznym zaakceptowaniem VAT-ZD oraz pytaniem o wygenerowanie korekty VAT.	Tak, na Bufor. Warunek - nie może być wygenerowana korekta VAT do VAT-ZD	Tak	Tak	Nie	Nie
Zaakceptowana	Zaakceptowana	Tak, na Bufor	Nie	Tak	Tak	Tak	Nie
Zaakceptowana	Zaakceptowana	Tak, na Anuluj, pod warunkiem, że nie wygenerowano korekty VAT, w przeciwnym wypadku – Nie	Nie	Tak	Tak	Tak	Nie

Po wybraniu przycisku: Dodaj pozycje zostanie otwarta lista rejestru VAT sprzedaż (wszystkie rejestry), na zakładce: Wg numeru. Otwierana lista jest automatycznie filtrowana zgodnie z ustawieniami predefiniowanych filtrów:

Opcja: Generuj pozycje, powiązana jest z przyciskiem: Na dzień – gdzie domyślnie podpowiadana jest data bieżąca z możliwością zmiany.

Po użyciu opcji: Generuj pozycje, zostają automatycznie wylistowane należności w transakcjach krajowych (rodzaj transakcji Kraj), w kwocie do rozliczenia, powiązanych z dokumentami sprzedaży o okresie przeterminowania wskazanym w filtrze, na wskazany dzień.

Kontrahent główny na dokumencie sprzedaży, na dzień sporządzenia zgłoszenia musi być czynnym podatnikiem VAT (na karcie kontrahenta głównego zaznaczony parametr: Płatnik VAT) oraz nie może być w trakcie postępowania restrukturyzacyjnego, postępowania upadłościowego lub w trakcie likwidacji (na karcie kontrahenta głównego nie zaznaczony parametr: W likwidacji/upadł.). Każdorazowe wybranie przycisku: Generuj pozycje powoduje odświeżenie listy, tj. usunięcie pozycji, które zostały dodane za pomocą tej opcji.

Po lewej stronie znajduje się sekcja: Korekta VAT z parametrami pozwalającymi na wskazanie daty oraz rejestru, w którym ma zostać wygenerowana korekta oraz z przyciskiem uruchamiającym akcję generowania korekty. Ze względu na konieczność ujmowania tego typu dokumentów w plikach jpk_vat jest możliwość generowania tylko korekt pojedynczych. Generowanie korekt zbiorczych zostało zablokowane.

Zakładka VAT-ZD, podzakładka Dłużnik

Na liście prezentowane są niezapłacone w terminie 90 lub 150 dni płatności z faktur zakupu, które będą korygowały podatek VAT naliczony. Dokumenty są prezentowane na wskazany dzień.

Okno zawiera identyczne kolumny oraz ikony jak w podzakładce: Wierzyciel.

Analogicznie jak na podzakładce Wierzyciel działają też przyciski Dodaj pozycje i Generuj pozycje.

Po wybraniu przycisku: Dodaj pozycje zostanie otwarta lista rejestru VAT zakupu (wszystkie rejestry), na zakładce Wg numeru. Otwierana lista jest automatycznie filtrowana zgodnie z ustawieniami predefiniowanych filtrów:

Rys. Rejestr Vat zakupów, ustawienia filtrów predefiniowanych

Po wybraniu ikony: Generuj pozycje w oknie zostaną wylistowane automatycznie dokumenty zakupu na zgłoszenie VAT-ZD. Dokumenty będą wyfiltrowane na wskazany dzień, zgodnie z opisanymi powyżej kryteriami filtrowania.

Wydruk zgłoszenia VAT-ZD

Do wydruku pierwszej strony załącznika VAT-ZD pobierane są dane z deklaracji VAT-7. Wyjątek stanowi numer załącznika, który jest wyliczany. Jeden załącznik VAT-ZD może zawierać maksymalnie 8 pozycji, tak więc, jeżeli na liście VAT-ZD/Wierzyciel będzie powyżej 8 pozycji, to na wydruk będą się one przenosić w kolejnych załącznikach VAT-ZD. Dopiero po zaakceptowaniu zgłoszenia VAT-ZD, na deklarację VAT-7, do pola 48 będzie wprowadzana informacja o liczbie załączników. Jeżeli generowany jest więcej niż 1 załącznik VAT-ZD, to podsumowanie w polach 10, 11 wykazywane jest na ostatnim załączniku.

Powiązanie pozycji na VAT-ZD z płatnościami i dokumentami

Ujęcie dokumentów, a ściślej mówiąc ich płatności na VAT-ZD spowoduje odpowiednie oznakowanie obiektów na dokumencie.

Na płatnościach ujętych dokumentów zostaną dodane następujące kontrolki:

VAT-ZD: Rok, miesiąc, nr pozycji na VAT-ZD , kwota korekty podstawy opodatkowania, kwota korekty VAT. Kontrolki te są automatycznie wypełniane w momencie ujęcia płatności na VAT-ZD. Nie ma możliwości edycji tych pozycji.

Jeżeli Płatność zostanie ujęta na VAT-ZD, wówczas system zablokuje możliwość dokonywania na tej płatności :

Ponadto nie będzie możliwości anulowania dokumentu, którego płatność uwzględniona została na VAT-ZD – próba anulowania zakończy się stosownym komunikatem. Aby anulować dokument będzie trzeba usunąć pozycję z VAT-ZD .

Uwzględnienie płatności na załączniku VAT-ZD nie blokuje natomiast możliwości:

Korekty (ZD)FS, (ZD)FZ

Załącznik VAT-ZD nie podlega księgowaniu. Aby ująć wartości korygowanego podatku na kontach księgowych należy zaksięgować dokumenty a’vista, które należy wygenerować z poziomu załącznika VAT-ZD.

Dokumenty (ZD)FS, (ZD)FZ są nowymi typami dokumentów i generowane są z datą i w rejestrze wskazanym na VAT-ZD. Dla tego typu dokumentów przewidziana jest też oddzielna numeracja.

Dokumenty te generowane są pojedynczo, dla każdej pozycji oddzielnie – w związku z tym powstaje tyle dokumentów a’vista, ile jest pozycji na VAT-ZD.

Dokument wygenerowany ma podstawie VAT-ZD/Wierzyciel jest fakturą sprzedaży a-vista, oznaczoną jako: (ZD)FS, natomiast dokument wygenerowany na podstawie danych zawartych na formularzu VAT-ZD/Dłużnik jest fakturą zakupu a-vista, oznaczoną jako (ZD)FZ.

Nie ma możliwości dodawania dokumentów o typie (ZD)FS, (ZD)FZ ręcznie.

Do wygenerowanych dokumentów jest możliwość wystawienia korekty, tzw. korekty powrotnej. Kwoty na dokumencie korygującym odpowiadające kwocie zapłaty użytkownik musi jednak wprowadzić ręcznie – na chwilę obecną nie ma mechanizmu, który pozwoliłby na generowanie korekt powrotnych z wyliczonymi na podstawie zapłat kwotami.

Z poziomu załącznika VAT-ZD z zakładki Wierzyciel lub Dłużnik, poprzez ikonę: Korekty w rejestrze VAT, dostępną na wstążce, istnieje możliwość odwołania się do wygenerowanych dokumentów. Otwiera się wówczas okno: Lista korekt VAT-ZD, z poziomu której dokumenty można podglądnąć, zaksięgować, w razie potrzeby usunąć.

Korekta sprzedaży (ZD)FS wygenerowana do konkretnej pozycji zgłoszenia VAT-ZD

Dane na dokumencie

Elementy

Tabelka VAT

Płatności

Usuwanie

Dokument będzie można usunąć pod warunkiem, że:

Korekty ZD(FS) ujmowane są na deklaracji VAT w polach, w których ujmowana jest Dostawa owarów oraz świadczenie usług na terytorium kraju w odpowiednich stawkach:

Korekta zakupu (ZD)FZ wygenerowana do konkretnej pozycji zgłoszenia VAT-ZD

Dane na dokumencie 

Elementy

Tabelka VAT

Płatności

Usuwanie

Dokument będzie można usunąć pod warunkiem, że:

Dokumenty ZD(FZ) ujęte są na deklaracji VAT w polu: Korekta podatku naliczonego, o której mowa w art.89b ust.1ustawy

Korekty (ZD)FS i (ZD)FZ – historia związanych

Z poziomu rejestru VAT istnieje możliwość podglądu dokumentów związanych z daną korektą (ZD)FS lub (ZD)FZ. Dokumenty te można wyświetlić w oknie: Historia związanych.

W oknie tym została dodana nowa zakładka VAT-ZD, która prezentuje dokumenty bezpośrednio lub pośrednio powiązane ze zgłoszeniem VAT-ZD, tj.:

Zmiany w wydrukach uruchamianych z poziomu rejestru VAT

Większość wydruków udostępnionych z poziomu listy rejestrów VAT reaguje na nowe filtry dodane w związku z ułatwieniem obsługi ulgi za złe długi, między innymi:

Odwrócenie korekty VAT-ZD

W miesiącu, w którym korygowane w załączniku VAT-ZD dokumenty zostały zapłacone należy wykonać tzw. korektę powrotną. Z poziomu dokumentów ZD(FS), ZD(FZ) należy wygenerować korektę. Kwoty na dokumencie korygującym odpowiadające kwocie zapłaty użytkownik musi jednak wprowadzić ręcznie – na chwilę obecną nie ma mechanizmu, który pozwoliłby na generowanie korekt powrotnych z wyliczonymi na podstawie zapłat kwotami.

Korekty powrotne ZD(FSK) ujmowane są w deklaracji VAT analogicznie jak dokumenty których dotyczą, czyli ZD(FS).

Korekty powrotne ZD(FZK) ujmowane są na deklaracji VAT w polu: Korekta podatku naliczonego, o której mowa w art. 89b ust. 4 ustawy:

Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie na nośniku filmowym, magnetycznym lub innym, powoduje naruszenie praw autorskich niniejszej publikacji.

Prezentacja możliwości definiowania pozycji księgowania okresowego

Wstęp

W module: Księgowość systemu Comarch ERP XL Użytkownik ma możliwość definiowania księgowań okresowych. Funkcjonalność pozwala na automatyzację procesu rozliczania kosztów działalności w czasie. Rozwiązanie takie jest pożądane, gdy w jednostce wystąpią koszty dotyczące innego okresu sprawozdawczego lub kilku okresów sprawozdawczych. Raz zaewidencjonowane w systemie, dzięki użyciu funkcjonalności Księgowanie okresowe, mogą zostać comiesięcznie automatycznie rozksięgowane, co pozwala na znaczną poprawę ergonomii pracy w komórkach księgowych.

Poniższe opracowanie ma charakter komplementarny w relacji z dokumentacją oraz biuletynami technicznymi. Zostaną w nim omówione poszczególne elementy Pozycji księgowania okresowego pod kątem możliwości stosowania w nich właściwych wyrażeń.

Księgowanie wg harmonogramu nagłówka

Pole: Oblicz dla

W polu: Oblicz dla, istnieje możliwość wprowadzenia maski konta o maksymalnej długości 30 znaków, w oparciu o którą będzie generowane księgowanie. Maska konta może zawierać dwa rodzaje znaków:

„*” – zastępuje dowolną ilość znaków, „?” – zastępuje jeden znak.

Maska konta pozwala na dokonanie przeksięgowań z wielu kont na jedno lub na wiele kont (na koncie docelowym podaje się wtedy wyrażenie obliczające konto zawierające zmienną: Konto, odwołującą się do bieżącego konta zgodnego z maską wprowadzoną w polu: Oblicz dla).

W polu: Oblicz dla, można też stosować filtry SQL. Przykładowa wartość tego pola z włączonym parametrem: Filtr SQL, ma postać: kks_konto like '532%' and kks_poziom=1

Pole: Oblicz dla, określa źródło danych branych pod uwagę w księgowaniu okresowym. W zaprezentowanym przykładzie bazą do księgowania okresowego są zapisy na kontach analitycznych konta syntetycznego o numerze zaczynającym się od cyfr: 532.

Po zaznaczeniu na pozycji Księgowania okresowego pola Filtr SQL system automatycznie zaproponuje składnię: KKS_Konto LIKE, którą Użytkownik ma możliwość uzupełnić według potrzeb. W polu: Oblicz dla, bez włączonego parametru Filtr SQL, Użytkownik ma możliwość podać konkretny numer konta księgowego z możliwością używania symboli:

„*” – zastępuje dowolną ilość znaków, „?” – zastępuje jeden znak.

Dzięki wskazaniu na pozycji księgowania okresowego źródła Użytkownik ma możliwość stosowania odwołania do zakresu kont z pola Oblicz dla: używając polecenia KONTO, na pozostałych elementach księgowania okresowego:

W Wyrażeniu Kwoty księgowania okresowego, wybierając opcję: Funkcje bieżącego konta

W polu: Konta księgowe, wpisując „z ręki” słowo: Konto.

Pole: Kwota

W polu: Kwota pozycji księgowania okresowego, Użytkownik definiuje kwotę, która będzie brana pod uwagę przy księgowaniu na konta księgowe.

Użytkownik decyduje o tym, czy do księgowania okresowego mają być brane kwoty z zapisów będących w buforze, czy tylko zapisy na koncie księgowym, które znajdują się w Księdze Głównej.

W oknie: Kwota, Użytkownik może zdefiniować wartość kwoty za pomocą Wyrażenia lub Zmiennej. Nie ma możliwości stosowania kombinacji Wyrażenia i Zmiennej w celu wyliczenia kwoty do zaksięgowania.

W polu: Wyrażenie Kwoty pozycji księgowania okresowego istnieje możliwość stosowania funkcji CHOOSE, w celu warunkowego określenia Kwoty do zaksięgowania.

Kwota, która w wyniku zastosowania powyższego przykładu zostanie pobrana do zaksięgowania jest uzależniona od połowy wartości Salda debetowego konta 640, która jest porównywana z wartością 130. Jeżeli warunek: SDT(640)/2)>=130 jest spełniony, to system pobierze do zaksięgowania lub rozksięgowania wartość Salda debetowego konta 640. W przeciwnym wypadku pole Kwota pozycji księgowania okresowego uzyska wartość 130.

Pole: Konta księgowe

Funkcjonalność pola Konta księgowe na pozycji Księgowania okresowego zachowuje się i powinna być stosowana, jak na pozycjach schematów księgowych.

Pola: Opis i Opis dekretu

W polu: Opis, Użytkownik ma możliwość wpisania czterdziestoznakowego opisu księgowania okresowego. Przycisk o nazwie Opis dekretu pozwala na zdefiniowanie opisu na podstawie makr, który zostanie przeniesiony do pola Opis w nagłówku zapisu księgowego. Poniżej zestawienie udostępnionych makr:

Nazwa opcji	Wyrażenie	Informacja przekazywana do nagłówka zapisu księgowego, do pola opis
Nazwa	@NAZWA	Nazwa księgowania okresowego (pole Nazwa w nagłówku KO)
Numer dokumentu	@NUM	Numer dokumentu (pole Numer dokumentu w nagłówku KO)
Opis dokumentu	@OPISD	Opis księgowania okresowego (pole Opis w nagłówku KO)
Zapytanie SQL

W przypadku kiedy dekret księgowy generowany w wyniku jednopozycyjnego księgowania okresowego (relacja: 1 do wiele) jest wielopozycyjny, każda pozycja generowanego dekretu, jak i sam zapis księgowy, będzie miała wartość pola: Opis dekretu.

Księgowanie wg harmonogramu pozycji

Aby możliwe było generowanie księgowań okresowych wg harmonogramu określonego na pozycjach, konieczne jest zaznaczenie parametru „Wg harmonogramu pozycji” na zakładce: Ogólne księgowania okresowego.

Pole: Oblicz dla

Działanie analogiczne do opisanego w rozdziale: Pole: Oblicz dla.

Pole:Kwota

Określenie kwoty, która będzie podlegała automatycznemu podziałowi wg harmonogramu, jest możliwe na trzy sposoby:

Uwaga

Zaznaczenie opcji „Kwota do zaksięgowania” i „Dekret” jest możliwa tylko wtedy, gdy na nagłówku definicji księgowania okresowego wybrano parametr „Wg harmonogramu pozycji”.

Po wyborze jednej z opcji: „Kwota do zaksięgowania” lub „Dekret”, prezentowane są dodatkowe informacje na pozycji księgowania okresowego tj.: „Kwota do zaksięgowania”; „Kwota zaksięgowana” i „Pozostaje do zaksięgowania”.

Pole:Częstotliwość

W celu ustalenia kolejnych dat księgowania należy uzupełnić parametry: „Okres ważności: Od Do”, „Generuj co” oraz datę „Następnej generacji”.

W polu Częstotliwość dostępny jest parametr Proporcjonalnie do liczby. Parametr udostępnia trzy opcje:

Wybranie opcji proporcjonalnie do liczby okresów generacji jest równoznaczne z dotychczasowym mechanizmem generacji rat w harmonogramie.

W metodzie proporcjonalnie do liczby dni w okresie generacji, raty wyliczane są proporcjonalnie do liczby dni przypadających na dany okres generacji do całkowitej liczby dni przypadających na wszystkie okresy.

Przyklad

Generacja harmonogramu wg metody: Proporcjonalnie do liczby dni w okresie generacji. • Kwota do zaksięgowania: 1260,00 • Częstotliwość, co: 1 miesiąc • Następna generacja: 31.08.2016 r. • Okres ważności: od 26.08.2016 r. do 30.04.2017 r. Raty: • Łączna ilość dni w okresie generacji: 248 • I rata: (6 dni /248 dni) x 1260,00 = 30,48 • II rata: (30 dni/248 dni) x 1260,00 = 152,42 Itd.

W metodzie proporcjonalnie do liczby dni w pierwszy i ostatnim okresie generacji, jeżeli okres wyznaczony przez datę rozpoczynającą bieg ważności oraz datę rozpoczęcia generacji, nie będzie obejmował pełnego miesiąca, dla pierwszego i ostatniego miesiąca wysokość rat zostanie wyliczona proporcjonalnie. Dla pozostałych okresów raty będą generowane w równej wysokości.

Harmonogram

Po ustaleniu częstotliwości generowania księgowania oraz po wskazaniu kwoty do zaksięgowania przez wybór jednej z opcji: „Kwota do zaksięgowania” lub „Dekret”, można wygenerować harmonogram używając przycisku: [Generuj harmonogram] . Na zakładce: Harmonogram zostanie utworzony plan kolejnych księgowań.

Przyklad

Jeżeli na pozycji księgowania okresowego w sekcji: Częstotliwość parametry zostaną ustawione jak poniżej: Okres ważności: od 01.01.2017 do 30.06.2017 Generuj co: 1 miesięcy Następna generacja: 31.01.2017 to daty kolejnych księgowań będą następujące:

Kwoty do zaksięgowania w poszczególnych miesiącach są wyliczane jako iloraz „Kwoty do zaksięgowania” (lub „Kwoty dekretu”) przez ilość okresów (księgowań). Wykonując takie dzielenie może się zdarzyć, że wartości kolejnych kwot zostaną zaokrąglone. Wówczas wartość ostatniej raty zostanie zmodyfikowana w taki sposób, aby dopełnić wartość kwoty, która podlegała rozksięgowaniu. Pozostałe raty będą w jednakowej wysokości.

Kwoty do zaksięgowania w poszczególnych miesiącach są wyliczane jako iloraz „Kwoty do zaksięgowania” (lub „Kwoty dekretu”) przez ilość okresów (księgowań). Wykonując takie dzielenie może się zdarzyć, że wartości kolejnych kwot zostaną zaokrąglone. Wówczas wartość ostatniej raty zostanie zmodyfikowana w taki sposób, aby dopełnić wartość kwoty, która podlegała rozksięgowaniu. Pozostałe raty będą w jednakowej wysokości.

Przyklad

Jeżeli rozksięgowaniu podlega kwota 100 zł w ciągu trzech miesięcy, to kwota do zaksięgowania zostanie podzielona następująco: 1 miesiąc: 33.33 zł 2 miesiąc: 33.33 zł 3 miesiąc: 33.34 zł

Ostatnia rata została zwiększona o 1 gr, aby suma wszystkich księgowań dała wartość 100 zł.

Po zaksięgowaniu raty, na zakładce: Harmonogram jest prezentowana informacja o numerze i kwocie powstałego dekretu:

Kwota do zaksięgowania jest możliwa do modyfikacji także wtedy, gdy wygenerowanych zostało już kilka z zaplanowanych księgowań. Jeżeli to nastąpi, to konieczne jest ponowne przeliczenie harmonogramu. Taka modyfikacja harmonogramu nie powoduje zmian w istniejących dekretach. Będzie miała wpływ tylko na pozostałe księgowania.

Przyklad

Kwota do rozksięgowania wynosi 100zł i została podzielona na 3 raty. Jedno z księgowań zostało już wykonane.

Po zmodyfikowaniu kwoty do zaksięgowaniu na 90 zł i przeliczeniu harmonogramu, pozostałe dwie raty w planie zostaną przeliczone ponownie, uwzględniając już zaksięgowaną kwotę.

Uwaga

Z poziomu księgowania okresowego jest możliwe bezpośrednie odwołanie do dekretu za pomocą przycisku: Dekret wynikowy.

Pole:Konta księgowe

Działanie analogiczne do opisanego w rozdziale: Pole: Konta księgowe.

Pola:Opis i Opis dekretu

Działanie analogiczne do opisanego w rozdziale: Pola: Opis i Opis dekretu.

Atrybuty na księgowaniu okresowym

Jest możliwe dodawanie atrybutów na nagłówku księgowania okresowego oraz jego pozycjach, a także ich automatyczne kopiowanie na generowane dekrety księgowe. Możliwe jest również zdefiniowanie kopiowania atrybutów z nagłówka księgowania okresowego na jego pozycje.

Kopiowanie atrybutów z nagłówka księgowania okresowego na nagłówek dekretu

Kopiowanie atrybutów z nagłówka księgowania okresowego na nagłówek dekretu będzie możliwe, jeżeli:

Kopiowanie atrybutów z pozycji księgowania okresowego na pozycje dekretów

W celu konfiguracji kopiowania atrybutów z pozycji księgowania okresowego na pozycję dekretów należy:

Uwaga

Firmy na koniec okresu/okresów musza wykonać tzw. przeksięgowanie na wynik finansowy. W wyniku takiej operacji stany kont ulegają wyzerowaniu lub zmianie. Dzięki możliwości kopiowania atrybutów z definicji księgowania okresowego i jego pozycji na powstające dekrety księgowe, możliwe jest automatyczne oznaczanie dekretów pochodzących z takiego przeksięgowania. W połączeniu z funkcjonalnością filtrowania zapisów księgowych w oparciu o atrybuty, jest możliwe uzyskanie stanu obrotów i sald sprzed wykonania przeksięgowania na wynik.

Przykłady zastosowań księgowań okresowych

Księgowanie na Wynik Finansowy podczas zamykania okresu obrachunkowego

Funkcjonalność Księgowań Okresowych może zostać wykorzystana do zamykania ksiąg rachunkowych na koniec okresu obrachunkowego. Przykładem takiego wykorzystania mogą być księgowania związane z wynikiem finansowym.

Zakładając, że plan kont zawiera koszty ewidencjonowane w zespole 4, można zdefiniować takie księgowanie okresowe, które dokona przeniesienia kosztów z kont analitycznych zespołu 4 oraz przeniesienia kosztów i przychodów z kont zespołu 7, na konto wyniku finansowego.

W tym celu pole: Oblicz dla, definiujemy albo poprzez wprowadzenie maski konta 4??-*, albo poprzez zaznaczenie parametru: Filtr SQL. Efekt będzie taki sam, tzn. pod uwagę zostaną wzięte wszystkie konta analityczne zespołu 4.

W polu: Kwota definiujemy wartości podlegające wyksięgowaniu, czyli obroty lub salda debet kont wskazanych w filtrze , czyli ODT(KONTO) lub SDT(KONTO).

W polu: Konto DT, wskazujemy konkretne konto wyniku finansowego , np. 860-01.

W polu: Konto CT, wprowadzamy odwołanie do zakresu kont wskazanych w polu: Oblicz dla, wpisując wyrażenie KONTO.

Tak zdefiniowaną pozycją księgowania okresowego można przeksięgować salda wszystkich kont kosztowych z zakres zespołu 4.

Pozycja dotycząca księgowania przychodów i kosztów z kont zespołu 7 będzie zdefiniowana analogicznie.

Opisany wyżej przykład obrazują poniższe rysunki.

Efektem wykorzystania takiego schematu księgowego będzie wygenerowany zapis księgowy, zawierający dekrety na wszystkie konta objęte filtrem w zdefiniowanych pozycjach.

W zaprezentowanym przykładzie nie ma księgowań dotyczących pozostałych kosztów i przychodów operacyjnych i finansowych, ale takie pozycje również mogą zostać zdefiniowane w tym samym księgowaniu okresowym.

Wyksięgowanie kosztów rozliczeń międzyokresowych w koszty okresu

Innym przykładem wykorzystania księgowań okresowych mogą być księgowania związane z księgowaniem kosztów rozliczanych w czasie, czyli biernymi lub czynnymi księgowaniami międzyokresowymi kosztów.

Zautomatyzowanie procesu księgowania rozliczeń międzyokresowych jest łatwiejsze do przeprowadzenia wówczas, kiedy każdy tytuł podlegający rozliczeniu w czasie będzie ewidencjonowany na odrębnym koncie analitycznym. Wówczas łatwo jest podzielić wartość na liczbę miesięcy, na które koszt jest rozliczony, oraz łatwo jest kontrolować, czy wartość została całkowicie rozliczona.

W tym celu w polu: Oblicz dla, należy podać konkretne konto syntetyczne dotyczące rozliczeń międzyokresowych kosztów: np. 640-???

W polu: Kwota, należy użyć wyrażenia: Konto, oznaczającego zakres kont z pola: Oblicz dla. Ważnie jest, aby definicja zawierała wyrażenie sprawdzające, czy suma rozksięgowanych kosztów czy przychodów nie przekroczyła wartości podlegającej rozliczeniu. Chodzi o to, by nie została wyksięgowana większa wartość niż wynika to z kosztów.

W tym celu można zastosować wyrażenie:

choose (ODT(Konto)-OCT(Konto)<1,ODT(Konto)-OCT(Konto), ODT(Konto)/12).

W pozycji: Konto DT, wskazujemy konto kosztów okresu, na które mają zostać zaksięgowane koszty rozliczane w czasie. Nie można tutaj podać konta bezpośredniego z planu kont, lecz zastosować schemat powiązań pomiędzy numerami analityk konta 640, a numerami analityk kont kosztów okresu. Schemat ten będzie polegał na zgodności numerów kont analityczny obu kont kosztowych. Mogłoby to wyglądać jak na Rysunek 26.

Numery kont analitycznych dla konta 640 są identyczne jak numery konta kosztów, na które następuje przeksięgowanie.

W pozycji: Konto CT należy wpisać wyrażenie: Konto, które pobierze konto zgodnie z filtrem wskazanym w polu: Oblicz dla.

Opisany wyżej przykład zobrazowany jest na poniższych rysunkach.

W pozycji: Konto DT zastosowano wyrażenie, które wycina fragmenty numerów kont podanych w filtrze, w polu: Oblicz dla. W tym konkretnym przypadku wybierany jest numer konta jako dziewięć znaków począwszy od piątego znaku konta. W efekcie uzyskujemy zapis księgowy zawierający następujące dekrety.

Szablony dekretów księgowych

Księgowania okresowe mogą zostać wykorzystane do skonstruowania pewnych szablonów dekretów księgowych, które są powtarzalne w okresach rozliczeniowych w zakresie kont biorących udział w księgowaniu. Zmienia się tylko wartość takich zapisów księgowych, a trudno jest zdefiniować wartość, która będzie podlegać rozliczeniu.

Taki szablon wymaga określenia tak naprawdę tylko kont księgowych po stronie DT i CT. W pozycji: Kwota takiego szablonu należy wpisać wartość 1, ponieważ nie jest możliwe wprowadzenie dekretu księgowego z wartością 0. Po wygenerowaniu takiego księgowania, kwoty zostaną uzupełnione na właściwe. Przykładem takiego dekretu może być np. rozliczenie podatku VAT naliczonego i należnego.

Pole: Oblicz dla, należy pozostawić puste.

W polu: Kwota, należy wpisać wartość 1.

W pola: Konto DT oraz Konto CT, należy wprowadzić konkretne numery kont z planu kont.

W polu: Opis, należy podać treść opisującą pozycje księgowania.

Wstęp

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

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

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

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

Warunki w nagłówku schematu księgowego

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

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

Warunek dla dziennika

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

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

Warunek daty księgowania

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

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

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

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

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

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

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

Przyklad

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

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

Tworząc wyrażenie można odwołać się do dostępnych pól z tabel. W zależności czy odwołujemy się w pozycji schematu księgowego do Płatności, Nagłówka, Elementów, VAT-u czy opisu analitycznego dostępne są różne tabele: Pola z innych tabel, pozostających w relacjach z dostępnymi tabelami, również można wykorzystywać przy użyciu odpowiednio skonstruowanych zapytań SQL-owych. Kilka wyrażeń można łączyć ze sobą za pomocą znaków &. Dodatkowo, gdy już w polu konto mamy wprowadzone jakieś wyrażenie np. ‘700-‘&Tre_typTwr i teraz chcę dodać kolejną część związaną z kontem magazynowym zapisanym na karcie towaru, wystarczy jak ustawię kursor na końcu wprowadzonego wyrażenia i prawym klikiem myszy wybiorę z dostępnej listy opcję: Towaru-magazyn wówczas doklejone zostanie: TWR_Konto1. Przykłady odwoływania się do dostępnych pól w wyrażeniu konta księgowego:

Funkcje sub, choose w schematach księgowych

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

Przyklad

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

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

Funkcja choose

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

Przyklad

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

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

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

Opis analityczny

W przypadku opisu analitycznego mamy możliwość odwoływania się do wymiarów standardowych typu: centrum, lokalizacja, kategoria, projekt, a także do wymiarów zdefiniowanych we własnym zakresie. Księgowanie w oparciu o opis analityczny najczęściej wykorzystywane jest do rozksięgowania wartości netto dokumentu na odpowiednie wymiary kosztowe, przychodowe. Wartości dokumentów, w zależności od zdefiniowanych wymiarów, można rozbić na właściwe centra, lokalizacje, projekty według obranego klucza.

Przyklad

Firma posiada 3 centra kosztowe: dział produkcji, dział logistyczny, dział administracji. Dodatkowo posiada lokalizację w Krakowie i Wrocławiu, w których to znajdują się przedstawiciele każdego centrum. Dokumenty kosztowe oraz przychodowe są opisywane analitycznie tak, aby właściwe rozłożyć koszty i przychody na określone centra. Dodatkowo plan kont ma dostosowaną strukturę kont zespołu 5 i 7 do podziału zgodnego z centrami oraz lokalizacją.

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

Syntetyka- centrum- lokalizacja- kategoria

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

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

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

produkcja: 503

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

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

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

Zapytanie SQL w polu Kwota, Konto, Opis

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

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

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

Uwaga

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

Uwaga

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

Przyklad

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

SQL('select ''a''')&' '& @KON

Wyksięgowanie różnic groszowych

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

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

Przykładowo, jeśli na nagłówku dokumentu wystąpiła kwota wyższa o jeden grosz niż na elementach, to należy dodać następujące dwie pozycje: 1. Oblicz dla: Nagłówka, kwota: Netto 2. Oblicz dla: Elementów, kwota: -Netto (minus netto) Obydwie pozycje należy zaksięgować na techniczne konto po stronie, na której schemat proponuje kwotę niższą o ten jeden grosz. Przy zaznaczonym parametrze: Sumuj kwoty o tych samych kontach, obydwie pozycje dadzą w sumie brakujący grosz. Analogicznie można postąpić przy różnicy groszowej występującej między innymi tabelami. Istnieje również możliwość wyksięgowania takich różnic poprzez dodanie w schemacie księgowym pozycji opartej o zapytanie sql, które będzie wyliczać takie różnice groszowe.

Przyklad

Aby wyeliminować różnice groszowe na spinaczu (S)FS należy zdefiniować dodatkową pozycję schematu: Oblicz dla: Nagłówka i w polu: Kwota, wpisać następujące wyrażenie: TRN_NettoR - SQL('SELECT SUM(TRE_KsiegowaNetto) FROM CDN.TraElem JOIN CDN.TraNag ON TRE_GIDTyp=TRN_GIDTyp AND TRE_GIDFirma=TRN_GIDFirma AND TRE_GIDNumer=TRN_GIDNumer WHERE TRN_SpiTyp=' & TRN_GIDTyp & ' AND TRN_SPIFirma=' & TRN_GIDFirma & ' AND TRN_SPINumer=' & TRN_GIDNumer) Dla dokumentu niebędącego spinaczem np. paragonu należy wprowadzić następujące wyrażenie: TRN_NettoR -SQL(' SELECT SUM(TRE_KsiegowaNetto) FROM CDN.TraElem WHERE TRE_GIDTyp=' & TRN_GIDTyp & ' AND TRE_GIDNumer=' & TRN_GIDnumer )

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

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

Kwota netto zaliczki

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

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

Po stronie sprzedaży:

Po stronie zakupu:

Pole warunek na pozycji schematu księgowego

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

Uwaga

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

Kwoty VAT-u

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

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

Przyklad

Na konto 221-01 księgujemy wartości VAT-u z faktur zakupu w przypadku gdy miesiąc ujęcia na deklaracji VAT-7 jest równy miesiącowi wpływu dokumentu oraz gdy odliczenia VAT-7 są ustawiona na tak lub warunkowo. Taką pozycję w schemacie księgowym można zapisać następująco, wykorzystując pole warunek:

Kwoty netto

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

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

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

Przyklad

Definiuję na liście atrybutów atrybut o nazwie kontrahent obcy, wartościami, jakie będzie mógł przyjmować, będą: tak, nie. Następnie, w schemacie zakładam konta, w zależności od określonych wartości, jakie przyjmuje atrybut przypisany do kontrahenta: 212-01 kontrahenci krajowi (czyli atrybut ustawiony na NIE) , 212-02 kontrahenci obcy (czyli atrybut ustawiony na TAK): Schemat: W polu konto wprowadzamy wyrażenie: '212-01-'&FORMAT(KNT_GIDNUMER,@N06) W polu warunek wprowadzamy zapytanie, które pozwoli na join pomiędzy tabelą KntKarty, a tabelą Atrybuty: exists (Select * from Cdn.Atrybuty With (NOLOCK) Where Atr_Obityp=knt_gidTyp and Atr_ObiFirma=knt_gidFirma and Atr_ObiNumer=knt_gidNumer and (Atr_AtkID=1 and Atr_Wartosc='nie')) Pozycja na konto '212-02-'&FORMAT(KNT_GIDNUMER,@N06) będzie wyglądała analogicznie tyle tylko, że wartość atrybutu w warunku będzie określona na: tak.

Zapytanie SQL w polu warunek

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

Przyklad

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

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

 

Uwaga

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

Uwaga

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

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

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

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

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

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

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

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

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

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

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

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

Księgowanie dokumentów RW

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

Przyklad

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

Legenda: 312 – materiały w przerobie *MAGKONTO – magazyn surowców na stanie 411 – koszty zużycia materiałów Kwota Netto: - w przypadku surowców – cena zakupu - w przypadku półproduktów – koszt wg surowców, lub koszt ewidencyjny (wyliczany lub z góry ustalony)

Przyklad

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

Przyklad

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

Księgowanie dokumentu PW

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

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

Przyklad

Pozycja 1 - zaksięgowanie wyrobów w cenie ewidencyjnej na konto Magazyn Wyrobów (601) Pozycja 2 – zaksięgowanie wyrobów w wartości zużytych surowców na konto Produkcji podstawowej Pozycja 3 – zaksięgowanie wyrobów w wartości zużytych surowców na konto Rozliczenie produkcji (580) i wyksięgowanie z konta produkcji podstawowej.

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

Przyklad

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

Księgowanie dokumentu ZP

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

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

1. Kwoty odchyleń

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

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

Odchylenia kosztu surowca

Odchylenia kosztu ewidencyjnego

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

2. Pozostałe kwoty

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

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

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

Kwoty dla opcji „Oblicz dla: Surowców”

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

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

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

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

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

Przyklad

Pozycja 1 - zaksięgowanie kosztu surowców zużytych do realizacji danego zlecenia (411) Pozycja 2 – zaksięgowanie kosztu surowców zużytych do produkcji poszczególnych wyrobów na konto produkcji podstawowej (z podziałem na poszczególne produkty) Pozycja 3 – zaksięgowanie kosztu surowców zużytych do produkcji poszczególnych wyrobów na konto Rozliczenie produkcji (580) i wyksięgowanie z konta produkcji podstawowej

Sposoby dokumentowania operacji produkcyjnych oraz ich ujęcie na kontach

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

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

Scenariusz 1

Surowce wydawane do produkcji nie pod konkretne zlecenia.

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

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

Scenariusz 2

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

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

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

Dokument różnic kursowych

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

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

Księgowanie automatyczne

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

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

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

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

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

Księgowanie schematem

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

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

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

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

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

Przyklad

Definicja schematu księgującego dokument RK

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

Pozycja 1. Ujęcie bilansowe - pozwalające na zaksięgowanie RK dodatniej Kwota: Dodatnia Konto Debet: Konto dokumentu Konto Credit: Konto plus Opis: @Numer, @Opis Warunek: brak Pozycja 2. Ujęcie bilansowe - pozwalające na zaksięgowanie RK ujemnej Kwota: Ujemna Konto Debet: Konto minus Konto Credit: Konto dokumentu Opis: @Numer, @Opis Warunek: brak Pozycja 3. Ujęcie podatkowe - pozwalająca na zaksięgowanie RK dodatniej o charakterze „przychodowym” Kwota: Dodatnia Konto Debet: Konto Credit: 901-01 Konto pozabilansowe Opis: @ Numer, @Opis Warunek: wartość flagi status = „przychody” Pozycja 4. Ujęcie podatkowe - pozwalająca na zaksięgowanie RK ujemnej o charakterze „przychodowym” Kwota: (-) Ujemna Konto Debet: Konto Credit: 901-01 Konto pozabilansowe Opis: @ Numer, @Opis Warunek: wartość flagi status = „przychody” Pozycja 5. Ujęcie podatkowe - pozwalająca na zaksięgowanie RK dodatniej o charakterze „kosztowym” Kwota: (-)Dodatnia Konto Debet: 901-02 Różnice kosztowe - Konto pozabilansowe Konto Credit: - Opis: @ Numer, @Opis Warunek: wartość flagi status = „koszty” Pozycja 6. Ujęcie podatkowe - pozwalająca na zaksięgowanie RK ujemnej o charakterze „kosztowym” Kwota: Ujemna Konto Debet: 901-02 Różnice kosztowe - Konto pozabilansowe Konto Credit: - Opis: @ Numer, @Opis Warunek: wartość flagi status = „koszty” Jak widać z powyższego przykładu różnice dla transakcji przychodowych będą księgowane po stronie Ma – dodatnie ze znakiem plus, ujemne ze znakiem minus. Różnice kursowe dla transakcji kosztowych będą księgowane zawsze po stronie Wn – dodatnie ze znakiem minus, ujemne ze znakiem plus. Różnice kursowe, którym wybrano flagę „Kompensaty” oraz „Inne” będą księgowane wyłącznie w ujęciu bilansowym.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Księgowanie dokumentów RS

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

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

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

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

Przyklad

Zastosowanie wirtualnego pola PoziomTRN w warunku schematu księgowego: Pozycja schematu księgowego ma dotyczyć tylko tych płatności, dla których nagłówki dokumentów, z których pochodzą te płatności mają: - dla spinacza spiętego do RS serię ‘AAA’ - dla dokumentu spiętego do spinacza spiętego do RS serię ‘CCC’ Warunek w schemacie będzie wyglądał następująco: ((PoziomTRN=1 and TRN_TrnSeria=’AAA’) or (PoziomTRN=2 and TRN_TrnSeria=’CCC’))

Księgowanie po poziomach

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

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

Dla Nagłówka:

Dla Elementów:

Dla Płatności:

Uwaga

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

Poziomy dostępne dla Nagłówka

Dokumentu księgowanego:

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

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

Dokumentu początkowego:

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

Poziom 1:

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

Poziom 2:

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

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

Dokumentu początkowego:

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

Poziom 1:

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

Poziom 2:

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

Księgowanie dokumentów RS

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

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

Poziomy dostępne dla Elementów

Wszystkie:

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

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

Dokumentu księgowanego:

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

Poziom 1:

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

Poziom 2:

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

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

Dokumentu księgowanego:

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

Poziom 1:

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

Poziom 2:

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

Księgowanie dokumentów RS

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

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

Poziomy dostępne dla Płatności

Wszystkie:

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

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

Dokumentu księgowanego:

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

Poziom 1:

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

Poziom 2:

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

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

Dokumentu księgowanego:

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

Poziom 1:

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

Poziom 2:

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

Księgowanie dokumentów RS

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

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

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

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

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

Tworzenie sum na poziomie dokumentów spinanych

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

Przyklad

Księgowanie spinacza (S)FZ spinającego kilka dokumentów PZ: Użytkownik systemu księgując w oparciu o elementy wartość zakupu na jedno konto, np. rozliczenie zakupu, chciałby uzyskać na dekrecie osobne pozycje związane z poszczególnymi dokumentami PZ. Ponieważ dokumenty PZ są w tym przypadku zarówno poziomem pierwszym w stosunku do spinacza (S)FZ, jak i dokumentami bezpośrednio związanymi z elementami transakcji, zamierzony efekt można osiągnąć poprzez zastosowanie na pozycji schematu jednego z dwóch poniższych ustawień: Pozycja schematu księgowego – tworzenie sum na poziomie dokumentów PZ

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

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

Przyklad

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

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

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

Sumowanie dla pozycji schematu podczas księgowania po poziomach

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

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

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

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

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

Przyklad

Sumowanie pozycji po poziomie innym niż wybrany poziom księgowania. Sumowanie danej pozycji schematu księgowego możliwe jest po wybranym w polu: Poziom poziomie księgowania, lub każdym innym wyższym poziomie. Zastosowanie na pozycji schematu księgowego opcji: - Oblicz dla: Elementów Poziomu 2 - Sumuj kwoty o tych samych kontach dla danej pozycji dla Poziomu 1,podczas księgowania dokumentu RS przedstawionego w poprzednim przykładzie, da następujący efekt:

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

Uwaga

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

Korzyści wynikające z wykorzystania funkcjonalności Księgowania wsadowego

Księgowanie wsadowe zostało zaimplementowane, w celu poprawy ergonomii pracy oraz zwiększenia wydajności systemu Comarch ERP XL. Dzięki wprowadzeniu tej funkcjonalności, Użytkownicy uzyskali narzędzie umożliwiające automatyzację procesu księgowania. Przede wszystkim możliwe będzie księgowanie poza godzinami pracy z programem, w wyniku czego minimalizujemy obciążenie systemu i zwiększamy jego wydajność. Poza tym uzyskujemy dodatkowy czas na pracę w systemie, który dotychczas należało wykorzystać na czynności związane z księgowaniem.

Wykorzystanie funkcjonalności Procesy w ramach definiowania i parametryzowania funkcjonalności Księgowanie wsadowe

Księgowanie wsadowe wykorzystuje zaimplementowaną funkcjonalność modelowania procesów. Przy definiowaniu procesu księgowania wsadowego obowiązują reguły opisane w biuletynie: Definiowanie i obsługa procesów.

Nowością i cechą właściwą przy konstruowaniu procesu dla księgowania wsadowego w systemie są predefiniowane akcje kluczowe: Uruchomienie księgowania, Uruchomienie księgowania domyślnie, Księgowanie, Predekretacja.

Konsekwencje wyboru akcji kluczowych

Do zadania predefiniowanego START o nazwie: Status początkowy procesu, należy podpiąć akcję kluczową: Uruchomienie księgowania lub Uruchomienie księgowania domyślnie.

Rodzaj zdefiniowanej akcji kluczowej: Uruchomienie księgowania oraz Uruchomienie księgowania domyślnie będzie istotny w momencie rozpoczęcia księgowania wsadowego.

Księgowanie wsadowe, Użytkownik może uruchomić tylko i wyłącznie używając przycisku: , dostępnego na dokumencie, lub liście dokumentów.

Uruchomienie księgowania - Jeżeli w trakcie definiowania procesu księgowania wsadowego, jako akcję kluczową startującą cały proces wybierzemy: Uruchomienie księgowania, to po naciśnięciu przycisku: , w oknie: Księgowanie dokumentów handlowych, w części: Sposób księgowania należy wybrać opcję: Księguj za pomocą procesu. Dzięki temu odszarzony zostanie przycisk: Proces. Po jego uruchomieniu wyświetli się lista dostępnych procesów ze zdefiniowaną akcją startową Uruchomienie księgowania. Z listy dostępnych procesów księgowania wsadowego należy wybrać właściwy dla typu dokumentów i rozpocząć przyciskiem: , proces księgowania wsadowego.

Uruchomienie księgowania domyślnie - Jeżeli w trakcie definiowania procesu księgowania wsadowego, jako akcję kluczową startującą cały proces wybierzemy Uruchomienie księgowania domyślnie, to po wyborze książeczki, w oknie: Księgowanie dokumentów handlowych, w części Sposób księgowania, należy wybrać opcję: Księguj za pomocą domyślnego procesu. Kolejnym krokiem powinno być rozpoczęcie procesu księgowania wsadowego – po naciśnięciu przycisku: .

Bardzo istotną sprawą jest poprawne zdefiniowanie opiekuna czynności, która wykorzystuje akcje kluczowe: Uruchom księgowanie i Uruchom księgowanie domyślnie. Wymagane jest podanie opiekuna, który znajduje się w strukturze firmy. Związane jest to z koniecznością wydania polecenia rozpoczęcia księgowania przez konkretnego Użytkownika systemu.

Dla pozostałych akcji kluczowych wykorzystywanych na etapie budowy procesu księgowania wsadowego, zgodnie z ideą automatyzacji procesu księgowania, powinno się wybierać opiekuna automatycznego.

Konsekwencje definicji zadania startującego proces księgowania wsadowego dla działania czynności księgowania wsadowego

Funkcjonalność: Księgowanie wsadowe, współpracuje z XL Work Automat (więcej informacji w biuletynie: Definiowanie i obsługa procesów oraz w Dokumentacji Użytkownika), który jest odpowiedzialny za wykonanie automatycznego księgowania zgodnie z definicją, którą wprowadził Użytkownik, na zakładce: Ogólne, okna: Definicje zadania procesu.

Proces księgowania wsadowego wybranej grupy dokumentów uruchamiamy przyciskiem: i startujemy poprzez naciśnięcie przycisku: , z poziomu okna: Księgowanie dokumentów handlowych. Czynność ta powinna zostać poprzedzona wybraniem schematu księgowania dla dokumentu lub grupy dokumentów, dziennika oraz sposobu, w jaki ma być uruchomiony proces księgowania.

Konfiguracja Definicji zadania procesu w polach: Termin realizacji, Data realizacji, Czas realizacji zachowuje się zgodnie z opisem w biuletynie: Definiowanie i obsługa procesów oraz w Dokumentacji Użytkownika do modułu: Administrator. Jest to niezwykle ważne okno z punktu widzenia zarządzania czynnością związaną z księgowaniem dokumentu lub grupy dokumentów. Data realizacji zadania księgowania wsadowego jest liczona od momentu przypięcia procesu księgowania wsadowego i wyświetlana zgodnie z funkcją: data systemowa + data realizacji. Taką wartość daty otrzymamy w kolumnie: Data realizacji z poziomu Skrzynki Automatu XL.

Z datą otrzymaną w sposób opisany powyżej będą realizowane poszczególne akcje kluczowe, przy założeniu ciągłej pracy XL Work Automat.

Księgowanie automatyczne

Na definicji dokumentu jest możliwość wyboru domyślnego schematu i dziennika księgowań w ramach opcji „księgowanie automatyczne”.

Parametry "księgowania automatycznego" mają zastosowanie w stosunku do dokumentów, których księgowanie jest obsługiwane przez proces. Chodzi więc o taką sytuację, kiedy księgowanie wsadowe stanowi etap innego procesu.

Dzięki tym ustawieniom możliwa jest pełna automatyzacja procesu, wraz z księgowaniem dokumentu, ponieważ schemat księgowy i dziennik wybrany jest już na definicji dokumentu.

Ewidencja dotowanych środków trwałych według przepisów prawnych

W wielu publikacjach, w tym w piśmie Izby Skarbowej w Gdańsku, z dnia 30 lipca 2004 r. (sygn. nr BI/005-0595/04) funkcjonuje opinia, że fakt otrzymania refundacji wydatków na zakup środka trwałego nie wpływa na wielkość wartości początkowej, ani na wielkość odpisów amortyzacyjnych wykazywanych w ewidencji środków trwałych. Podatnik powinien jednak wydzielić z odpisów amortyzacyjnych taką ich część, która będzie równa kwotowo otrzymanej refundacji. Ta wydzielona część odpisów nie będzie mogła zostać zaliczona do kosztów uzyskania przychodów.

Stanowisko w podobnej sprawie zajęło również Ministerstwo Finansów, które w piśmie z 17 września 1996 r. (sygn. PO 3-MD-722-618/96) stwierdziło, iż „do odpisów amortyzacyjnych od nabytych lub wytworzonych środków trwałych, sfinansowanych otrzymaną dotacją, ma zastosowanie art. 16 ust. 1 pkt 48 ustawy z 15 lutego 1992 r. o podatku dochodowym od osób prawnych, który stanowi, że nie uważa się za koszty uzyskania przychodów odpisów z tytułu zużycia środków trwałych dokonywanych według zasad określonych w odrębnych przepisach, od tej części ich wartości, która odpowiada poniesionym wydatkom na nabycie lub wytworzenie tych środków we własnym zakresie, zwróconym podatnikowi w jakiejkolwiek formie. Podatnik nie może zatem zaliczyć do kosztów uzyskania przychodów odpisów amortyzacyjnych od tej części wartości wydatkowanej na zakup środka trwałego, która została mu zwrócona w jakiejkolwiek formie, w tym przypadku w postaci przyznanej przedsiębiorstwu dotacji”.

Podstawa prawna:

Art. 16 ust. 1 pkt 48 ustawy z 15 lutego 1992 r. o podatku dochodowym od osób prawnych (Dz.U. z 2000 r. nr 54, poz. 654 z późn. zm.)

Księgowanie dotacji

Z chwilą wpływu dotacji należy ją zarachować po stronie Ma konta Rozliczeń Międzyokresowych Przychodów. Stopniowo ją rozchodowywać, proporcjonalnie do dokonywanych od nabytego środka trwałego odpisów amortyzacyjnych, na konto Pozostałe Przychody Operacyjne.

Ewidencja dotowanych środków trwałych w systemie Comarch ERP XL

Rejestracja dotacji dla środków trwałych nowo wprowadzonych do systemu

Na karcie środka trwałego zaleca się dodanie dwóch torów amortyzacji środka trwałego.

Dla toru "bilansowego" należy wprowadzić kwotę będącą wartością początkową środka trwałego (nie pomniejszoną o dotację). Od tej wartości będą naliczane odpisy amortyzacyjne ujmowane na koncie Amortyzacji (401).

Dla toru "podatkowego" należy wprowadzić kwotę refundacji. Odpisy liczone od kwoty refundacji będą rozliczały kwotę dotacji. Księgowanie: Rozliczenia międzyokresowe przychodów / Pozostałe Przychody Operacyjne.

Wartość KUP będzie wynikała z różnicy kwot ujętych na koncie 401 Amortyzacja / 7 Pozostałe Przychody Operacyjne

Dodatkowo na karcie środka trwałego, na dokumentach AM  można wprowadzić atrybut "Dotacja", który pozwoli między innymi na łatwiejsze wyszukanie środków trwałych, których wartość jest refundowana z dotacji.

Poniżej przedstawiono przykład sposobu zaewidencjonowania środka trwałego w systemie Comarch ERP XL o wartości początkowej 10.000 PLN i kwocie refundacji 6.000 PLN (stawka amortyzacji 20%) spełniającego wymogi, o których mowa w przytoczonych wyżej interpretacjach. Zaprezentowany sposób pozwala na równoległe zaewidencjonowanie wartości początkowej środka trwałego, od której będą naliczane odpisy amortyzacyjne ujmowane na koncie 401 oraz kwoty refundacji, od której będą naliczane odpisy rozliczające dotacje RMP / Pozost.Przych.Oper.

Rejestracja dotacji dla środków trwałych już amortyzowanych wcześniej w systemie

Jeżeli dotacja na środek trwały przychodzi w momencie, kiedy środek trwały jest już amortyzowany w systemie, wówczas zachodzi konieczność wprowadzenia dokumentu MW modyfikującego wartość początkową środka trwałego w ujęciu podatkowym. Kwota zmniejszenia podstawy amortyzacji podatkowej powinna być zgodna z kwotą dotacji, jaka przysługuje na dany środek trwały.

Dotychczasowe odpisy amortyzacyjne (czyli koszt już poniesiony) można skorygować na dwa sposoby:

Poniżej przedstawiono przykład sposobu rejestracji dokumentów dla środka trwałego, dla którego otrzymano dotację w momencie, kiedy już wcześniej dokonywano odpisów amortyzacyjnych tego środka trwałego.

Możliwości dynamicznego raportowania

Zestawienie: Dynamiczne raportowanie zostało wprowadzone do systemu Comarch ERP XL ze względu na oczekiwania Użytkowników. Oczekiwali oni bardziej elastycznego dostępu do informacji związanych z wartością środków trwałych dla potrzeb bilansowych oraz sprawozdawczości finansowej. Informacje takie miały być dostępne nie tylko w formie wydruku ale również jako zestawienie wyświetlane bezpośrednio na ekranie z zachowaniem historyczności analiz.

Zestawienie: Dynamiczne raportowanie jest dostępne z poziomu Księgi inwentarzowej, z zakładek: Grupy, Wg Numeru inwentarzowego, Wg akronimu, Wg nazwy, Wg KŚT. W zależności od tego, z której zakładki wykonywany jest wydruk układ środków na wydruku jest inny. Są one porządkowane w analogiczny sposób jak na danej zakładce.

Dane na zestawieniu Dynamiczne raportowanie

Zestawienie: Dynamiczne raportowanie jest to rozbudowany wydruk. Głównym celem raportu jest dostęp do informacji o bieżącym stanie Majątku Trwałego oraz WNiP. Pod pojęciem stan rozumiemy możliwość ustalenia na dowolny dzień roku podatkowego wszystkich poniższych wartości.

Początkowa wartość inwentarzowa

Kwota początkowej wartości inwentarzowej dla środków trwałych jest liczona w oparciu o kwoty z dokumentów OT, OTK, MW, MWK, LT, LTK, PK, z pola: Podstawa bilansowa. Wartość ta jest zależna od daty dla której wykonywane jest zestawienie. Do początkowej wartości inwentarzowej są wliczane wielkości ze wszystkich wskazanych wcześniej dokumentów wystawionych od momentu przyjęcia danego środka do użytkowania do końca roku poprzedzającego rok, w którym znajduje się data wykonania raportu.

Przyklad

Środek trwały został przyjęty do użytkowania w lipcu 2004 roku, w styczniu 2005 zwiększono jego wartość po raz pierwszy a w marcu 2007 roku zwiększono jego wartość po raz drugi. Dla środka wystawiono w związku z tym następujące dokumenty (wartości po stronie bilansowej):

OT (07.2004) – 30000 PLN MW (01.2005) – 20000 PLN MW (03.2007) – 10000 PLN Na zestawieniu wykonanym na dzień 31.05.2007 w polu: Początkowa wartość inwentarzowa zostanie wyświetlona kwota 50 000 PLN.

Początkowa wartość podstawy amortyzacji

Kwota początkowej wartości podstawy amortyzacji dla środków trwałych jest liczona w oparciu o kwoty z dokumentów OT, OTK, MW, MWK, LT, LTK, PK, z pola: Podstawa podatkowa. Wartość ta jest zależna od daty dla której wykonywane jest zestawienie. Do początkowej wartości podstawy amortyzacji są wliczane wielkości ze wszystkich wskazanych wcześniej dokumentów wystawionym od momentu przyjęcia danego środka do użytkowania do końca roku poprzedzającego rok, w którym znajduje się data wykonania raportu.

Kwota zwiększeń wartości inwentarzowej

Wartość kwoty zwiększeń wartości inwentarzowej dla środka trwałego jest liczona w oparciu o kwoty z dokumentów MW (+), MWK (+), z pola: Podstawa bilansowa. Wartość ta jest zależna od daty dla której wykonywane jest zestawienie. Do kwoty zwiększeń wartości inwentarzowej są wliczane wielkości ze wszystkich wskazanych wcześniej dokumentów wystawionych w roku, w którym znajduje się data wykonania raportu.

Przyklad

Środek trwały został przyjęty do użytkowania w lipcu 2004 roku, w styczniu 2005 zwiększono jego wartość po raz pierwszy a w marcu 2007 roku zwiększono jego wartość po raz drugi. Dla środka wystawiono w związku z tym następujące dokumenty (wartości po stronie bilansowej): OT (07.2004) – 30 000 PLN MW (01.2005) – 20 000 PLN MW (03.2007) – 10 000 PLN Na zestawieniu wykonanym na dzień 31.05.2007 w polu: Zwiększenia wartości inwentarzowej zostanie wyświetlona kwota 10 000 PLN.

Kwota zwiększeń podstawy amortyzacji

Wartość kwoty zwiększeń wartości podstawy amortyzacji dla środka trwałego jest liczona w oparciu o kwoty z dokumentów MW (+), MWK (+), z pola: Podstawa podatkowa. Wartość ta jest zależna od daty dla której wykonywane jest zestawienie. Do kwoty zwiększeń podstawy amortyzacji są wliczane wielkości ze wszystkich wskazanych wcześniej dokumentów wystawionych w roku, w którym znajduje się data wykonania raportu.

Kwota zmniejszeń wartości inwentarzowej

Wartość kwoty zmniejszeń wartości inwentarzowej dla środka trwałego jest liczona w oparciu o kwoty z dokumentów MW (-), MWK (-), LT, z pola: Podstawa bilansowa. Wartość ta jest zależna od daty dla której wykonywane jest zestawienie. Do kwoty zmniejszeń wartości inwentarzowej są wliczane wielkości ze wszystkich wskazanych wcześniej dokumentów wystawionych w roku, w którym znajduje się data wykonania raportu.

Przyklad

Środek trwały został przyjęty do użytkowania w lipcu 2004 roku, w styczniu 2005 zmniejszono jego wartość po raz pierwszy, a w marcu 2007 roku zmniejszono jego wartość po raz drugi. Dla środka wystawiono w związku z tym następujące dokumenty (wartości po stronie bilansowej): OT (07.2004) – 70 000 PLN MW (01.2005) – (-20 000) PLN MW (03.2007) – (-30 000) PLN Na zestawieniu wykonanym na dzień 31.05.2007 w polu: Zmniejszenia wartości inwentarzowej zostanie wyświetlona kwota 30 000 PLN.

Kwota zmniejszeń podstawy amortyzacji

Wartość kwoty zmniejszeń podstawy amortyzacji dla środka trwałego jest liczona w oparciu o kwoty z dokumentów MW (-), MWK (-), LT, z pola: Podstawa podatkowa. Wartość ta jest zależna od daty, dla której wykonywane jest zestawienie. Do kwoty zmniejszeń podstawy amortyzacji są wliczane wielkości ze wszystkich wskazanych wcześniej dokumentów wystawionych w roku, w którym znajduje się data wykonania raportu.

Umorzenie

Wartość umorzenia dla środka trwałego jest liczona w oparciu o kwoty z dokumentów AM, AMK, MW (-), MWK (-), LT, PK z pola: Kwota Am. Bilansowej. Do wartości tej są wliczane tylko kwoty z dokumentów wystawionych w roku podatkowym, na którego dzień sporządzany jest raport.

Amortyzacja

Wartość amortyzacji dla środka trwałego jest liczona w oparciu o kwoty z dokumentów AM, AMK, MW(-), MWK (-), LT, PK z pola: Kwota Am. Podatkowej. Do wartości tej są wliczane tylko kwoty z dokumentów wystawionych w roku podatkowym, na którego dzień sporządzany jest raport.

Dotychczasowe umorzenie

Wartość dotychczasowego umorzenia dla środka trwałego jest liczona w oparciu o kwoty z dokumentów AM, AMK, MW (-), MWK (-), LT, PK z pola: Kwota Am. Bilansowej. Do wartości tej są wliczane tylko kwoty z dokumentów wystawionych w latach poprzedzających rok podatkowy, na którego dzień sporządzany jest raport.

Dotychczasowa amortyzacja

Wartość dotychczasowej amortyzacji dla środka trwałego jest liczona w oparciu o kwoty z dokumentów AM, AMK, MW (-), MWK (-), LT, PK z pola: Kwota Am. Podatkowej. Do wartości tej są wliczane tylko kwoty z dokumentów wystawionych w latach poprzedzających rok podatkowy, na którego dzień sporządzany jest raport.

Odpis aktualizacyjny

Wartość odpisu aktualizacyjnego dla środka trwałego jest liczona w oparciu o kwoty z dokumentów AK. Do wartości tej są wliczane tylko kwoty z dokumentów wystawionych w roku podatkowym, na którego dzień sporządzany jest raport.

Dotychczasowe odpisy aktualizacyjne

Wartość odpisu aktualizacyjnego dla środka trwałego jest liczona w oparciu o kwoty z dokumentów AK. Do wartości tej są wliczane tylko kwoty z dokumentów wystawionych w latach poprzedzających rok podatkowy, na którego dzień sporządzany jest raport.

Wartość inwentarzowa netto

Wartość inwentarzową netto otrzymujemy poprzez sumowanie odpowiednich wartości z wcześniejszych kolumn, a dokładnie: Początkowa wartość inwentarzowa + Kwota zwiększeń wartości inwentarzowej - Kwota zmniejszeń wartości inwentarzowej - Umorzenie - Dotychczasowe umorzenie - Odpis aktualizacyjny - Dotychczasowe odpisy aktualizacyjne.

Podstawa amortyzacji netto

Wartość tą otrzymujemy poprzez sumowanie odpowiednich wartości z wcześniejszych kolumn, a dokładnie: Początkowa wartość podstawy amortyzacji + Kwota zwiększeń podstawy amortyzacji - Kwota zmniejszeń podstawy amortyzacji - Amortyzacja - Dotychczasowa amortyzacja.

Parametry dynamicznego raportowania

Zestawienie: Dynamiczne raportowanie jest wydrukiem sparametryzowanym. Dzięki temu daje ono możliwość wykonywania raportu w różnym układzie środków trwałych, w zawężeniu do określonych grup środków, statusów, zakresów dat.

Zestawienie to można wykonać z każdej zakładki okna: Księgą inwentarzowa. W zależności od zakładki, na raporcie składniki majątku trwałego sortowane są wg:

Dodatkowo w trakcie wykonywania zestawienia w oknie: Wprowadzanie wartości, możliwe jest dodatkowe zawężenie środków trwałych poprze wybór określonych parametrów.

Parametr: Typ Wydruku

Parametr: Typ Wydruku, pozwala użytkownikowi na zawężenie danych tylko do wartości bilansowych lub podatkowych dla wskazanych środków trwałych.

W ramach zestawienia dynamicznego raportowania możliwe jest wykonanie wydruk stanów w ujęciu:

Parametr: Stan na dzień

Parametr: Stan na dzień, pozwala określić dzień oraz godzinę, na który wykonywany jest wydruk. Dane zawarte w wydruku będą danymi historycznymi i będą zawierały wykaz stanu środków trwałych na wskazany przez użytkownika dzień.

Parametry: Data przyjęcia ŚT od i Data przyjęcia ŚT do

Parametry: Data przyjęcia ŚT od i Data przyjęcia ŚT do pozwalają na określenie ram czasowych dla wydruku. Dzięki tym parametrom można określić zakres dat, w ramach których przyjęto składniki majątku trwałego do użytkowania.

Parametr: Data przyjęcia ŚT od jest z góry ustalona w systemie, a w momencie wykonywania wydruku można tą datę modyfikować.

Parametr: Data przyjęcia ŚT do należy analogicznie do parametru Stan na dzień

Parametr: Data dokumentu do

Parametr: Data dokumentu do pozwala określić graniczną datę dla dokumentów, które mają być brane pod uwagę przy ustalaniu wartości dla poszczególnych środków trwałych.

Parametr: Grupa

Parametr: Grupa pozwala na zawężenie listy środków trwałych na zestawieniu do jednej grupy. W tym celu należy w puste pole wpisać akronim odpowiedniej grupy.

Parametr: Akronim

Parametr: Akronim pozwala na zawężenie listy środków trwałych na zestawieniu do jednego, wybranego środka. W tym celu należy w puste pole wpisać akronim wybranego środka trwałego.

Parametr: Księga inwentarzowa

Parametr: Księga inwentarzowa pozwala na zawężenie listy środków trwałych na zestawieniu do jednej, wybranej księgi inwentarzowej. W tym celu należy w puste pole wpisać nazwę wybranej księgi inwentarzowej ze zdefiniowanej wcześniej w konfiguracji listy.

Parametr: KŚT

Parametr: KŚT pozwala na zawężenie listy środków trwałych na zestawieniu do jednej, wybranej stawki KŚT. W tym celu należy w puste pole wpisać symbol wybranej stawki z listy stawek klasyfikacji rodzajowej.

Parametr: Status

Parametr: Status pozwala na zawężenie listy środków trwałych na zestawieniu według ich statusu. Dostępne są następujące statusy:

Parametr: Rodzaj

Parametr: Rodzaj pozwala na zawężenie listy środków trwałych na zestawieniu według rodzaju określonego na karcie środka trwałego. Do wyboru mamy następujące rodzaje:

Parametry: Metoda Umorzenia i Metoda Amortyzacji

Parametry: Metoda Umorzenia i Metoda Amortyzacji pozwalają na zawężenie listy środków trwałych na zestawieniu według metody generowania odpowiednio amortyzacji bilansowej i amortyzacji podatkowej dla danego środka trwałego. Do wyboru są następujące metody:

Parametr: Dwutorowość

Parametr: Dwutorowość pozwala na zawężenie listy środków trwałych na zestawieniu do tych, które są amortyzowane dwutorowo. Do wyboru są następujące opcje:

Parametry: Stawka bilansowa i Stawka podatkowa

Parametry: Stawka bilansowa i Stawka podatkowa pozwalają na zawężenie listy środków trwałych na zestawieniu ze względu na stawkę, według której generowane są odpisy odpowiednio amortyzacji bilansowa i amortyzacji podatkowa dla danego środka trwałego. Wybraną stawkę należy wpisać w puste pole.

Parametr: Amortyzacja przyśpieszona

Parametr: : Amortyzacja przyśpieszona pozwala na zawężenie listy środków trwałych na zestawieniu do tych, które na karcie mają zaznaczoną opcję: Amortyzacja przyspieszona (czyli będzie dla nich wygenerowany w pierwszym roku użytkowania odpis 30 %). Do wyboru są następujące opcje:

Parametr: Numer inwentarzowy

Parametr: Numer inwentarzowy pozwala na zawężenie listy środków trwałych na zestawieniu do jednego, wybranej numeru inwentarzowego z karty środka trwałego. W tym celu należy w puste pole wpisać numer inwentarzowy danego środka trwałego przypisany do jego karty.

Parametr: Kontrahent docelowy

Parametr: Kontrahent docelowy pozwala na zawężenie listy środków trwałych na zestawieniu według kontrahenta docelowego określonego na karcie środka trwałego. W tym celu należy w puste pole wpisać akronim kontrahenta docelowego wybranego na karcie środka trwałego.

Parametry: Osoba odpowiedzialna i Akronim osoby odpowiedzialnej

Parametry: Osoba odpowiedzialna i Akronim osoby odpowiedzialnej, powinny być wykorzystywane razem. Pozwalają one na zawężenie listy środków trwałych na zestawieniu dynamicznego raportowania do takich, które mają wybranego określonego pracownika jako osobę odpowiedzialną za środek trwały. Dodatkowo dzięki parametrom tym można określić czy pod uwagę ma być brany pracownik określony na karcie czy aktualnie odpowiedzialna osoba (po ewentualnych zmianach osoby odpowiedzialnej).

Dla parametru: Osoba odpowiedzialna do wybory są opcje:

Parametry: Miejsce użytkowania (@p_MiejsceBezwzglednie i @p_MiejsceUzyw)

Parametry: Miejsce użytkowania (@p_MiejsceBezwzglednie i @p_MiejsceUzyw) podobnie jak parametry: Osoba odpowiedzialna i Akronim osoby odpowiedzialnej, powinny być wykorzystywane razem. Pozwalają one na zawężenie listy środków trwałych na zestawieniu dynamicznego raportowania do takich, które mają wybrane określone miejsce użytkowania dla środka trwałego. Dodatkowo dzięki parametrom tym można określić, czy pod uwagę ma być brane miejsce użytkowania określone na karcie czy aktualne miejsce (po ewentualnych zmianach miejsca użytkowania).

Dla parametru Miejsce użytkowania (@p_MiejsceBezwzglednia) do wybory są opcje:

Parametry: Likwidacja i Data likwidacji do

Parametry: Likwidacja i Data likwidacji do powinny być używane razem. Pozwalają one na zawężenie listy do środków trwałych zlikwidowanych przed wskazaną datą.

Dla parametru: Likwidacja do wyboru są następujące opcje:

Parametr: Data likwidacji do pozwala na ustalenie granicznej daty likwidacji.

Parametr: Sposób likwidacji

Parametr: Sposób likwidacji, pozwala na zawężenie listy środków trwałych na zestawieniu dynamicznego raportowania do tych, które zostały zlikwidowane, i na karcie, na zakładce: Księgowe wybrano jeden ze sposobów likwidacji ze zdefiniowanej wcześniej w konfiguracji listy.

W celu zawężenia listy należy w puste pole wpisać jeden ze zdefiniowanych wcześniej w konfiguracji sposobów likwidacji.

Uwaga

Aby użycie parametru: Sposób likwidacji było możliwe należy w pierwszej kolejności określić wartość parametru: Likwidacja na: Tak.

Parametr: Sposób sortowania

Parametr: Sposób sortowania pozwala na wybór najbardziej dogodnego układu środków trwałych na zestawieniu dynamicznego raportowania. Dla parametru: Sposób sortowania do wyboru są następujące opcje:

Parametry typu: Klasa atrybutu

Parametry typu: Klasa atrybutu służą do zawężenia listy środków trwałych na zestawieniu dynamicznego raportowania według klasy atrybutu jaką środki te są opisane.

W celu zawężenia listy należy w puste pole wpisać nazwę klasy atrybutu

Parametry typu: Wartość atrybutu

Parametry typu: Wartość atrybutu, służą do zawężenia listy środków trwałych na zestawieniu dynamicznego raportowania według wartości atrybutu.

W celu zawężenia listy należy w puste pole wpisać jedną z wartości atrybutu.

Idea prowadzenia rozrachunków w systemie Comarch ERP XL

W programie Comarch ERP XL zostało wprowadzone uszczelnienie rozliczeń i rozrachunków. Generalna zmiana dotyczyła tzw. uszczelnienia rozliczeń i rozrachunków. Polegała ona na tym, iż  podczas dokonywania rozrachunku istotne znaczenie ma fakt, czy dekret księgowy jest powiązany z dokumentem źródłowym. Analizując to stwierdzenia na przykładzie, można oprzeć się na dokumentach handlowych. Załóżmy, iż w programie są zaewidencjonowane i zaksięgowane dwa dokumenty handlowe dotyczące tego samego kontrahenta: faktura sprzedaży na kwotę 2000 PLN oraz faktura zakupu na kwotę 1500 PLN. Płatności tych dokumentów podlegają kompensacie w wysokości 1500 PLN – czyli niższej z wartości tych dwóch dokumentów. W związku z tym, iż dokumenty te są zaksięgowane schematem zbudowanym w oparciu o kwotę płatność, dokonaniu kompensaty automatycznie będzie towarzyszyło powstanie rozrachunku. W takiej sytuacji na płatnościach faktury sprzedaży pozostaje do rozliczenia kwota 500 PLN, która jest równa kwocie, jaka pozostaje do rozrachowania na dekrecie wynikowym tej faktury. W programie wystawiony jest również zapis księgowy wprowadzony bezpośrednio do dziennika księgowego, będący dokumentem, który nie ma powiązania z żadnym innym dokumentem posiadającym płatności, czyli jest dokumentem bez tzw. źródła. We wcześniejszych wersjach możliwe było dokonanie rozrachunku między takim zapisem księgowym, a częściowo już rozrachowanym dekretem wynikowym z faktury sprzedaży. Jednak w efekcie tego następowała rozbieżność między wartością, która pozostawała do rozliczenia na dokumencie (500 PLN), a wartością, jaka pozostawała do rozrachunku na dekrecie (0 PLN). Taka sytuacja powodowała różnego rodzaju nieścisłości, dlatego zdecydowano się ją uniemożliwić. w obecnej wersji systemu dokonanie rozrachunku takich dekretów, tzn. zapisu księgowego wprowadzanego bezpośrednio do dziennika z częściowo już rozrachowanym dekretem wynikowym faktury, jest niemożliwe, a przy jego próbie pojawia się stosowny komunikat, przedstawiony na rysunku:

W analogiczny sposób system zachowa się w sytuacji, gdy dekret pochodzący z zaksięgowania faktury sprzedaży zostanie najpierw rozrachowany z zapisem księgowym wprowadzonym bezpośrednio do dziennika księgowań, a w kolejnym kroku będzie następowała próba rozliczenia płatności faktury sprzedaży z płatnością pochodzącą z zaksięgowanej faktury zakupu. W takim przypadku pojawi się komunikat podany na rysunku:

Identyczny komunikat pojawiłby się również w sytuacji, gdy próba skojarzenia tych dokumentów następowałaby z poziomu dekretów tych dokumentów. Aby przedstawione powyżej rozliczenia i rozrachunki były możliwe do wykonania, należy przeksięgowania dokonane za pomocą zapisu księgowego zamienić na księgowania dokonywane za pomocą not memoriałowych, lub też do zapisu księgowego wygenerować uproszczoną notę memoriałową. Wprowadzone  zmiany w kierunku uszczelnienia rozliczeń i rozrachunków sprawiły, że poprawne dokonanie rozrachunku w niektórych sytuacjach wymagało wykonania dodatkowych czynności, co było widoczne, m.in. w czasie przeprowadzania wyceny rozchodu środków pieniężnych wyrażonych w walutach obcych. Aby zoptymalizować wykonywanie tych czynności zdecydowano się na wprowadzenie nowej opcji dokonywania rozrachunków, a mianowicie opcji: Dodaj rozrachunek bez rozliczenia. Pozwala ona na wykonanie rozrachunku głównie w sytuacjach, gdzie konieczny jest tylko rozrachunek na dekretach, bez dokonywania rozliczenia na płatnościach. Warto dodatkowo zauważyć, iż wprowadzenie funkcjonalności: Rozrachuj bez rozliczenia nie oznacza rozszczelnienia rozrachunków. Wszystkie zmiany zostały wprowadzone zgodnie z ideą dokonywania rozliczeń i rozrachunków i nie odznaczają odstępstwa od tych zasad.

Idea użycia opcji: Rozrachuj bez rozliczenia

Wprowadzona  funkcjonalność: Rozrachuj bez rozliczenia, jak sama nazwa wskazuje, pozwala na dokonanie tylko rozrachunku dekretów pochodzących z zaksięgowania np. dokumentów handlowych, bez równoczesnego dokonywania rozliczenia płatności tych dokumentów. Dostępna jest ona z poziomu listy rozrachunków. Można ją zobrazować na następującym przykładzie. Na koncie 201 zostały zaksięgowane dwa dokumenty: faktura sprzedaży i faktura zakupu. Dekrety wynikowe tych dokumentów rozrachowano za pomocą opcji: Rozrachuj bez rozliczenia, co obrazuje rysunek ponizej:

W efekcie na tych dekretach powstał rozrachunek, któremu jednak nie towarzyszyło powstanie rozliczenia na płatnościach dokumentów, co jest poprawną sytuacją.

Wybranie opcji: Rozrachuj bez rozliczenia powoduje, że rozrachunek zostaje utworzony na niższą z kwot dekretów. Jeśli konieczne jest utworzenie częściowego rozrachunku bez rozliczenia należy skorzystać w opcji: Dodaj częściowy rozrachunek bez rozliczenia, co zostało przedstawione na rysunku:

Jeśli dekrety zostały częściowo rozrachowane bez rozliczenia, to na pozostałą część również muszą być rozrachowane za pomocą opcji: Dodaj rozrachunek bez rozliczenia. w takiej sytuacji rozrachunek na dekretach wykona się na pozostałą kwotę. Jeśli dekrety są już częściowo rozrachowane za pomocą opcji: Rozrachuj bez rozliczenia i w przypadku rozrachowywania ich na pozostałą kwotę zostanie wybrana opcja: Dodaj rozrachunek, to w momencie ich rozrachowywania pojawi się komunikat widoczny poniżej:

Uwaga

W przypadku dokonywania częściowych rozrachunków na koncie rozrachunkowym kontrahenta warto zwrócić uwagę na kolejność dokonywania rozrachunków. Jeśli dekrety zostały ze sobą częściowo rozrachowane za pomocą opcji: Rozrachuj bez rozliczenia, to na pozostałą kwotę będą mogły być rozrachowane tylko przy użyciu tej samej opcji, co zostało opisane powyżej.

Przykładowe scenariusze wykorzystania funkcjonalności: Rozrachuj bez rozliczenia

Funkcjonalność: Dodaj rozrachunek bez rozliczenia może być wykorzystana w różnorodnych sytuacjach. Poniżej kilka scenariuszy jej wykorzystania.

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

Wykorzystanie opcji: Dodaj rozrachunek bez rozliczenia w aspekcie wyceny rozchodu środków pieniężnych zostało opisane w osobnym biuletynie technicznym poświęconym wycenie pt. Wycena rozchodu środków pieniężnych wyrażonych w walutach obcych.

Obsługa kart płatniczych

Ewidencja rozrachunków z tytułu obsługi kart płatniczych została przedstawiona w osobnym biuletynie technicznym pt. Obsługa kart płatniczych w systemie Comarch ERP XL. Rozrachunki dokonywane na koncie służącym do ewidencji transakcji dokonywanych za pomocą karty, mogą być dokonywane za pomocą opcji: Rozrachuj bez rozliczenia.

Uzgodnienie konta 303 – Rozliczenie zakupu

Wcześniej konto rozliczenie zakupu, aby można było dokonywać na nim poprawnie rozrachunków, musiało mieć status konta rozrachunkowego specjalnego. Teraz zrezygnowano z kont rozrachunkowych specjalnych, zostawiając tylko konta rozrachunkowe. Wobec tego, zakładając, że na koncie 303 mają być przeprowadzane rozrachunki, powinno ono mieć status konta rozrachunkowego. W takiej sytuacji podczas przeprowadzania rozrachunków na koncie 303 należy używać opcji: Rozrachuj bez rozliczenia. Opis wykorzystania opcji: Rozrachuj bez rozliczenia na koncie 303 – Rozliczenie zakupu można przedstawić na podstawie rozliczania zakupów importowych. Przedstawiony poniżej przykład będzie przeprowadzony przy założeniu, że towar na magazyn został przyjęty w tym samym dniu, w którym dotarła do firmy faktura, w związku z czym kursy walut na wszystkich dokumentach są jednakowe. Faktura importowa zostaje zaksięgowana na konto 303 Rozliczenie Zakupu po stronie DT. Następnie z tej faktury zostaje wygenerowany dokument SAD, z którego na konto: Rozliczenie zakupu po stronie DT zaksięgowane są Cło, Akcyza, wartość transportu krajowego oraz wartość transportu zagranicznego. Następnie z dokumentu SAD zostaje wygenerowany dokument PZI, z którego na konto 303 po stronie CT jest zaksięgowana wartość netto dokumentu. W efekcie tych księgowań dekrety na koncie rozrachunkowym 303 – Rozliczenia zakupu wyglądają tak jak na rysunku poniżej:

Po zaznaczeniu wszystkich dekretów przedstawionych na rysunku powyżej i wybraniu opcji: Rozrachuj bez rozliczenia, następuje ich rozrachowanie z pominięciem rozliczenia, co jest widoczne na rysunku poniżej.  W związku z tym, iż suma kwot po stronie DT konta Rozliczenia zakupu była równa kwocie po stronie CT tego konta, nastąpiło całkowite rozrachowanie tego konta.

Wykonanie kompensaty dokumentów tylko na ich dekretach

Czasami zachodzi potrzeba wykonania rozrachunku tylko na dekretach dokumentów. W takiej sytuacji Użytkownik świadomie decyduje, że płatności danych dokumentów nie będą podlegać rozliczeniu, rozrachowywane będą tylko dekrety. Wybierając taki sposób przeprowadzenia rozrachunków i rozliczeń należy pamiętać, iż na płatnościach rozliczanych dokumentów, przed zaksięgowaniem tych dokumentów, należy zaznaczyć parametr ‘Nie rozliczaj’. Kompensata natomiast w takim wypadku nie jest przeprowadzana przez dokument kompensaty ani generowany automatycznie dekret kompensacyjny, ale przez wprowadzony bezpośrednio do dzienników księgowań dekret księgowy pełniący rolę dekretu kompensacyjnego. Opisaną sytuację można zrealizować opierając się na następującym przykładzie. W programie zostaje wystawiona na kontrahenta AAA faktura importowa z kwotą płatności równą 1000 EUR po kursie 100 EUR=381,95PLN. Na płatnościach tej faktury zaznaczony jest parametr: Nie rozliczaj. Faktura zostaje zaksięgowana schematem zbudowanym w oparciu o płatność na konto 205 powiązane z kontem 905. Na tego samego kontrahenta AAA jest również wystawiona faktura eksportowa z kwotą płatności równą 1000 EUR po kursie 100EUR=382,08PLN, która również na płatności ma znaczony parametr: Nie rozliczaj i również została zaksięgowana schematem zbudowanym w oparciu o płatność na konto 206 powiązane z kontem 906. Następnie bezpośrednio w dziennikach księgowań zostaje wprowadzony jednopozycyjny zapis księgowy po kursie innym niż kursy na wymienionych powyżej dokumentach, będący kompensatą na wymienione powyżej konta księgowe. Taki przykładowy zapis księgowy przedstawiony jest na rysunku:

Kolejnym krokiem jest dokonanie rozrachunków na kontach rozrachunkowych tego kontrahenta. Dokonanie takich rozrachunków powinno być przeprowadzone za pomocą opcji: Rozrachuj bez rozliczenia. W wyniku takiej czynności zostaje dokonany rozrachunek tylko na dekretach, bez dokonania rozliczenia na płatnościach dokumentów (gdzie został zaznaczony parametr: Nie rozliczaj). W wyniku rozrachunku powstaje dekret różnicy kursowej, co zostało pokazane na rysunku poniżej, na przykładzie konta 206.

W identyczny sposób rozrachunki powinny być dokonane na drugim z kont rozrachunkowych, gdzie również powinna powstać różnica kursowa. W efekcie przeprowadzenia opisanych powyżej czynności, dekrety dokumentów handlowych zostały ze sobą rozrachowane przy pomocy trzeciego dokumentu, będącego ręcznie wystawionym dekretem kompensacyjnym. Opisana powyżej sytuacja jest przykładem dokonywania rozrachunku tylko na dekretach księgowych przy użyciu opcji: Rozrachuj bez rozliczenia, któremu to rozrachunkowi nie towarzyszy powstanie rozliczenia na płatnościach tych dokumentów.

Inne zastosowania funkcjonalności: Rozrachuj bez rozliczenia

Warto podkreślić, iż przedstawione powyżej przykłady nie są wszystkimi możliwymi scenariuszami wykorzystania funkcjonalności: Rozrachuj bez rozliczenia. Opcja ta może być bowiem użyta wszędzie tam, gdzie zachodzi potrzeba dokonania tylko samego rozrachunku, np. na koncie Rozliczeń międzyokresowych kosztów, przy założeniu, że jest to konto rozrachunkowe, lub też tam, gdzie rezygnacja z rozliczenia na dokumentach jest świadomą decyzją Użytkownika, który dokonuje tylko rozrachunku na dekretach, co również może mieć zastosowani,e np. do konta służącego do ewidencji środków pieniężnych w drodze. Trudno wymienić tutaj wszystkie przykłady zastosowania tej funkcjonalności, gdyż ich wielość wynika bowiem z różnorodności operacji przeprowadzanych w Księgowości.  

Rozpoczęcie pracy w module: Księgowość systemu Comarch ERP XL w trakcie roku

Wdrożenie programu księgowego w trakcie roku musi być przeprowadzone ostrożnie ze względu na specyfikę rozrachunków i rozliczeń w systemie.

Powiązania pomiędzy płatnościami i rozrachunkami są bardzo istotne dla prawidłowości pracy z programem. Nie ma problemu z wprowadzeniem stanu początkowego na kontach zwykłych natomiast dla kont rozrachunkowych należy wydzielić kwoty związane z rozrachunkami rozliczonymi na dzień rozpoczęcia pracy w programie oraz z rozrachunkami nierozliczonymi na dzień rozpoczęcia pracy w programie.

Wprowadzenie stanów początkowych kont zwykłych

Wprowadzenie stanów początkowych na kontach zwykłych musi zostać podzielony na dwie części: na faktyczny BO na dzień 01/01 roku obrotowego oraz obroty za okres od 01/01 do dnia poprzedzającego dzień rozpoczęcia pracy w programie, czyli np. na dzień 31/03, jeżeli start w programie ma nastąpić od dnia 01/04

Faktyczny Bilans Otwarcia na dzień 1 stycznia roku obrotowego

Bilans otwarcia wprowadza się dokumentem BO z poziomu menu: Księgowość, Bilans Otwarcia. Jest to ręczny dokument BO, w którym rejestrowane są salda kont zwykłych.

Dokumentów Bilansu Otwarcia może być kilka, np. BO dla kont zwykłych i BO dla kont rozrachunkowych.

Obroty za okres na kontach zwykłych

Druga część stanu początkowego kont zwykłych, na dzień rozpoczęcia pracy w programie, np. na dzień 1 kwietnia, dotyczy obrotów za okres od początku roku, czyli od 01/01 bieżącego roku do dnia poprzedzającego dzień rozpoczęcia pracy w systemie, czyli w opisywanym przypadku 31/03 bieżącego roku. Obroty mogą zostać wprowadzone zapisami księgowymi na konto księgowe bezpośrednio w dziennikach księgowań.

Przy księgowaniu obrotów za dany okres za pomocą dokumentu PK, wymagane jest zawsze podanie kont przeciwstawnych. Dlatego należy wprowadzić konto techniczne, najlepiej wynikowe, dla zbilansowania PK i zatwierdzenia dokumentu. Konto będzie istnieć tylko w tym okresie, w którym rozpoczynamy pracę w systemie, więc po przeniesieniu planu kont do następnego okresu należy je wykasować, a status konta „wynikowe” uniemożliwi przeniesienie BO.

Wprowadzenie stanów początkowych kont rozrachunkowych

Wprowadzanie stanów kont rozrachunkowych jest nieco bardziej skomplikowane i wymaga nie tylko wprowadzenia stanu faktycznego BO i obrotów za okres, ale także wydzielenia płatności rozliczonych i nierozliczonych, dlatego powinno się odbywać etapami wymienionymi poniżej.

Faktyczny Bilans Otwarcia na dzień 1 stycznia roku obrotowego

Bilans Otwarcia na dzień 1 stycznia roku obrotowego powinien zostać podzielony na dwie części. Kwotę wynikającą z płatności nierozliczonych do dnia rozpoczęcia pracy w systemie, czyli do 31/03 oraz kwotę salda BO, wynikającą z płatności rozliczonych do dnia 31/03. Rozbicie kwot jest wskazane ze względu na strukturę i powiązanie pomiędzy płatnościami (rozliczeniami) a dekretami (rozrachunkami). W przypadku kwot nierozliczonych konieczne jest odtworzenie płatności, natomiast dla rozrachunków rozliczonych nie jest wymagane odtwarzanie płatności.

Wprowadzanie BO dla pozycji rozliczonych

Wartość salda z BO wynikającą z dokumentów rozliczonych na dzień poprzedzający rozpoczęcie pracy w systemie, czyli na 31/03, mogłaby zostać wprowadzona zbiorczą kwotą, na koncie każdego kontrahenta a płatność zaznaczona jako "nie rozliczaj". Tym samym ta część nie podlegałaby rozliczeniom, nie byłaby widoczna na żadnej liście płatności i nie trzeba byłoby odtwarzać zapłat.

Wprowadzenie BO dla pozycji nierozliczonych

Część BO, która wynika z dokumentów nierozliczonych na dzień poprzedzający rozpoczęcie pracy w systemie, czyli np. na 31/03, musi zostać wprowadzona kwotami, które generują płatność i będą podlegały rozliczeniom w trakcie pracy z systemem.

Stan obrotów między Bilansem Otwarcia a dniem rozpoczęcia pracy w systemie

Obroty za okres od 01/01 do dnia rozpoczęcia pracy z programem, czyli, np.01/04 na kontach rozrachunkowych również muszą być podzielone na dwie części, na część rozliczoną, która rozrachunkom już nie będzie podlegać oraz część nierozliczoną, która będzie rozliczana.

Obroty wynikające z dokumentów rozliczonych

Tego typu obroty na kontach rozrachunkowych mogą być wprowadzone jako zapisy księgowe bezpośrednio w dziennikach, ponieważ nie będą one tworzyć rozliczeń.

Przy księgowaniu obrotów za dany okres, wymagane jest zawsze podanie kont przeciwstawnych, celem bilansowania się PK. Dlatego należy wprowadzić konto techniczne, najlepiej wynikowe, dla zbilansowania PK i zatwierdzenia dokumentu. Konto będzie istnieć tylko w tym okresie, w którym rozpoczynamy pracę w systemie, więc po przeniesieniu planu kont do następnego okresu należy je wykasować, a status konta „wynikowe” uniemożliwi przeniesienie BO.

Obroty wynikające z dokumentów nierozliczonych

To jest część kwoty wynikająca z dokumentów, które zostały wystawione, zaksięgowane i nierozliczone w okresie od 1 stycznia do 1 kwietnia. Tego typu obroty trzeba wprowadzić jako faktury a’vista zakupu w rejestrze vat zakupu (dla zobowiązań) lub sprzedaży (dla należności) oraz zaksięgować na odpowiednie konta rozrachunkowe. Dokumenty utworzą płatności, które pozwolą na przeprowadzenie pełnego rozrachunku na koncie. Obroty wynikające z nierozliczonych dokumentów można również wprowadzić używając dokumentu UNM (uproszczona nota memoriałowa).

Takie dzielenie rozrachunków jest konieczne z dwóch powodów:

Na kontach rozrachunkowych, kwoty wynikające ze stanów obrotów rozliczonych do okresu rozpoczęcia pracy w systemie będą pozostawać jako nierozrachowane.

Umożliwi to dokonanie rozrachunku, zarówno części BO wprowadzonego dla kwot rozliczonych, jak również obrotów za okres od 01/01 do dnia rozpoczęcia pracy w systemie dla części rozliczonej.

Zestawienie obrotów i sald

Zestawienie obrotów i sald będzie prawidłowo sporządzone w przypadku, kiedy stan bilansu otwarcia będzie wprowadzony dokumentem Bilans Otwarcia, a stany obrotów za okres od 01/01 do dnia poprzedzającego rozpoczęcie pracy w systemie będą wprowadzone zapisami księgowymi. Zapewni to prawidłową prezentację bilansu otwarcia strony Wn i Ma oraz prawidłową prezentację obrotów narastająco strony Wn i Ma.

Rozwiązanie to wymaga dosyć szczegółowego ustalenia struktury rozrachunków na kontach księgowych, oraz wyliczenia poszczególnych sum rozrachunków, które należy wprowadzić. Jest to jednak rozwiązanie stosowane w firmach rozpoczynających pracę w systemie Comarch ERP XL w trakcie roku.

 

Ewidencjonowanie środków trwałych

W momencie rozpoczynania pracy z modułem: Środki trwałe systemu Comarch ERP XL bardzo często zdarza się, że Użytkownik posiada środki trwałe ewidencjonowane wcześniej w innym systemie. W momencie wprowadzania takich środków do systemu bardzo ważne jest wprowadzenie ich w taki sposób, aby dane generowane później w programie były prawidłowe.

Wprowadzanie kart inwentarzowych

Pierwszym krokiem w trakcie rozpoczęcia pracy z modułem: Środki trwałe, jest wprowadzenie kart inwentarzowych dla środków trwałych. Dla każdego środka trwałego należy wprowadzić kartę inwentarzową i zapisać na niej prawidłowe dane dla danego środka: symbol klasyfikacji rodzajowej, akronim, stawki i współczynniki dla amortyzacji bilansowej i podatkowej lub własnego toru, metody dla amortyzacji podatkowej i bilansowej lub własnego toru. Na karcie należy również określić miesiąc rozpoczęcia naliczania amortyzacji bilansowej i podatkowej lub własnego toru.

Na wprowadzanej karcie środka trwałego należy wprowadzić datę faktycznego przyjęcie środka do użytkowania (np. 01.01.2009)

Wprowadzenie dokumentów

Po założeniu dla środków trwałych kart inwentarzowych należy wprowadzić dla nich odpowiednie dokumenty z zachowaniem historyczności.

Przyjęcie środka trwałego do użytkowania – dokument OT

Po zarejestrowaniu kart inwentarzowych środków trwałych należy każdy ze środków przyjąć do użytkowania za pomocą dokumentu OT. Bardzo ważne jest to, aby na dokumencie OT podać datę faktycznego przyjęcia do użytkowania środka trwałego, czyli datę, od której środek był użytkowany w poprzednim systemie (np. 01.01.2009).

Na dokumencie OT wprowadzamy pozycje. Na pozycji w polach: Podstawa BIL i Podstawa POD lub dla własnego toru amortyzacji podajemy faktyczną wartość początkową środka trwałego.

Zmiany wartości środka trwałego – dokument MW

W celu zachowania historyczności oraz prawidłowych odpisów amortyzacyjnych środków trwałych użytkowanych wcześniej w innych systemach, należy w momencie ich ewidencji w systemie Comarch ERP XL wprowadzić dla nich wszelkie wcześniej dokonane modyfikacje wartości. Modyfikacje te wprowadzamy z faktyczną datą ich wykonania (np. 01.03.2010) za pomocą dokumentu MW.

Na dokumencie MW wprowadzamy pozycje. Na pozycji w polach: Podstawa BIL i Podstawa POD lub dla własnego toru amortyzacji podajemy faktyczną wartość, o którą ma zostać zwiększona/zmniejszona wartość początkowa środka trwałego. W tym miejscu określamy również, czy dokument MW będzie obowiązywał od miesiąca jego wystawienia, czy od kolejnego miesiąca.

Uwaga

W przypadku środków trwałych amortyzowanych metodą degresywną dokument MW domyślnie obowiązuje od kolejnego roku użytkowania środka trwałego, chyba że zaznaczono w konfiguracji Środków trwałych parametr: Metoda degresywna – zmiana wartości w pierwszym roku od następnego miesiąca.

Dotychczasowa amortyzacja środka trwałego – dokument AM

Dla środków trwałych częściowo zamortyzowanych w innych systemach należy, oprócz podstawy amortyzacji bilansowej i podatkowej lub własnego toru amortyzacji, wprowadzić również wartości dotychczasowych odpisów bilansowych i podatkowych lub własnego toru amortyzacji. W tym celu należy wystawić odpowiednie dokumenty AM. Dokument taki należy wystawić w grudniu roku poprzedzającego rok rozpoczęcia pracy z systemem Comarch ERP XL (np. rozpoczęcie pracy 01.01.2012 – dokument AM 31.12.2011). Dokument taki należy wystawić z pozycji Tabeli amortyzacji, zakładka: Generacja. Ważne jest, aby w momencie generowania dokumentu AM, w oknie: Parametry generacji, zaznaczyć opcję: Uwzględniaj zaległe odpisy od daty rozpoczęcia amortyzacji.

W wyniku generacji zostanie utworzony dokument AM o wartości odpisów wyliczonych automatycznie według wprowadzonych wcześniej stawek i wartości na dzień 31.12.2011.

Jeżeli odpisy automatycznie wygenerowane w systemie nie są wartościowo zgodne z odpisami wcześniej poniesionymi, wówczas dokument AM można wystawić z pozycji listy dokumentów. Dokument ten również powinien być wystawiony z datą 31.12.2011.

Na pozycji dokumentu AM należy wybrać opcję generacji: od daty rozpoczęcia amortyzacji. Na pozycji dokumentu AM można dodatkowo modyfikować wartość odpisów.

Wprowadzone w ten sposób środki trwałe można prawidłowo amortyzować od stycznia 2012 roku. Wszystkie dokumenty wystawione w systemie od tej daty powinny być księgowane. Dokumenty wystawione z datami wcześniejszymi (wprowadzone historycznie dla celów prawidłowego naliczania amortyzacji) nie są księgowane.

Uwaga

Jeżeli praca z modułem: Środki trwałe, nie rozpoczyna się od początku danego roku, wówczas oprócz opisanego wcześniej dokumentu AM w grudniu roku poprzedzającego rozpoczęcie pracy z systemem należy wprowadzić dodatkowo dokument AM w miesiącu poprzedzającym rozpoczęcie pracy z systemem. Przykładowo, jeśli rozpoczęcie pracy następuje dnia 01.07.2012, należy wprowadzić dokumenty AM z następującymi datami: 31.12.2011 oraz 30.06.2012. W trakcie generacji drugiego dokumentu AM należy zaznaczyć opcję: Uwzględniaj zaległe odpisy od początku roku.

Ogólne zasady zastosowania storna do bufora

W programie Comarch ERP XL w oknie: Konfiguracja, na zakładce: Księgowania, w sekcji: Księgowanie przez bufor istnieje możliwość wybrania flagi „storno” oraz drop down pozwalający na wybór bufora. Zaznaczenie tego parametru ma na celu umożliwić użytkownikowi wystornowanie zapisów do bufora. Pozwala to na bezśladowe wykasowanie zapisu stornującego.

Storno w buforze tworzy się w tym samym dzienniku, w którym wygenerowano zapis pierwotny, a pomiędzy zapisem stornującym a stornowanym pozostaje zachowane powiązanie. Zapis stornujący w Buforze nie kasuje więc powiązania pomiędzy „źródłem”, a zapisem stornowanym. Oznacza to, że dopóki nie zostanie on przeniesiony do Księgi Głównej, nie ma możliwości ponownego zaksięgowania dokumentu źródłowego.

Przeniesienie zapisu stornującego z bufora do Księgi Głównej powodować będzie:

W programie istnieje również możliwość wskazania daty, pod którą ma zostać utworzony zapis stornujący.

Scenariusze storna zapisu księgowego

W punkcie tym przedstawione zostaną trzy możliwości wykonania storna w programie Comarch ERP XL. W zależności od ustawień konfiguracyjnych storno zapisu księgowego może być generowane w Buforze lub w Księdze Głównej.

Storno zapisu księgowego znajdującego się w księdze głównej do księgi głównej

Storno zapisu księgowego znajdującego się w księdze głównej do bufora

Krok 1. Wygenerowanie storna w buforze

Zachowanie powiązania między zapisem stornowanym, a dokumentem źródłowym.

Zachowania rozrachunku między dekretami wynikowymi.

Krok 2. Przeniesienie storna do Księgi Głównej

Skasowanie powiązania między zapisem stornowanym, a dokumentem źródłowym.

Skasowanie rozrachunku między dekretami wynikowymi.

Powstanie rozrachunku między dekretami stornowanym a stornującym.

Uwaga

Przeniesienie storna do Księgi Głównej powoduje automatyczne odksięgowanie dokumentu źródłowego, w związku z tym należy pamiętać, aby go ponownie zaksięgować.

Storno zapisu księgowego znajdującego się w buforze do bufora

Krok 1. Wygenerowanie storna w buforze

Zachowanie powiązania między zapisem stornowanym, a dokumentem źródłowym.

Zachowanie rozrachunku między dekretami wynikowymi.

Krok 2. Przeniesienie storna do Księgi Głównej

Skasowanie powiązania między zapisem stornowanym, a dokumentem źródłowym.

Skasowanie rozrachunku między dekretami wynikowymi.

Powstanie rozrachunku między dekretami stornowanym a stornującym.

Uwaga

Przeniesienie storna do Księgi głównej powoduje automatyczne odksięgowanie dokumentu źródłowego, w związku z tym należy pamiętać, aby go ponownie zaksięgować.

Korekta noty memoriałowej

Uproszczona Nota Memoriałowa (UNM) jest dokumentem, który ma za zadanie ułatwić księgowanie kwot na konta rozrachunkowe, do których powinny być generowane płatności.

W wyniku wystornowania zapisu księgowego, do którego wygenerowano notę, następuje skasowanie powiązania pomiędzy zapisem a notą. Notę taką można wówczas bezśladowo usunąć. Jeśli natomiast użytkownik chciałby pozostawić ślad po nocie, może do niej wystawić korektę (UNK). Dokument ten generuje się automatycznie na podstawie UNM, z poziomu listy not uproszczonych.

Płatności związane z dokumentami UNK mogą być prezentowane ze znakiem minus (przy włączonym parametrze: prezentuj płatności korekt ze znakiem minus) lub po stronie przeciwnej.