Wstęp

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

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

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

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

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

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

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

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

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

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

Uwaga

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

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

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

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

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

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

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

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

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

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

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

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

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

Uwaga

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

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

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

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

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

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

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

Uwaga

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

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

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

Uwaga

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

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

exec cdn.ImportListPlacOptima ID_Zestawu,1

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

Drugi parametr procedery przyjmuje zawsze wartość 1.

Zwracane wyniki procedury:

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

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

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

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

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

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

Uwaga

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

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

exec cdn.ImportListPlacOptima ID_Zestawu,1

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

Drugi parametr procedery przyjmuje zawsze wartość 1.

Zwracane wyniki procedury:

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

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

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

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

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

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

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

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

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

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

Login failed for user ‘CDNDTS’

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

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

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

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

Uwaga

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

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

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

Ustawienia usługi zostały opisane w biuletynie technicznym: XL114 – Konfiguracja synchronizacji systemu Comarch ERP XL z modułem kadrowo-płacowym Comarch ERP XL HR do wersji 2016.3.4.

 

 

Wstęp

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

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

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

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

Specyfikacja kwot na listach płac

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

Uwaga

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

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

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

Warianty opisu analitycznego

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

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

Najczęściej wykorzystywany jest wariant 1 i 2.

Sposoby ujęcia analitycznego kosztów wynagrodzeń

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

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

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

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

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

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

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

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

Koszt całkowity: Brutto + ZUS pracodawcy

Uwaga

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

Specyfikacja kwot związanych z opisem analitycznym

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

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

Uwaga

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

Przykładowe zmniejszenia w opisie analitycznym

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

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

Przykładowy opis analityczny listy płac

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

Uwaga

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

Ujęcie kosztów w wariancie „Netto”

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

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

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

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

Ujęcie kosztów w wariancie „Brutto”

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

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

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

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

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

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

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

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

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

Wstęp

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

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

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

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

Przygotowanie deklaracji podatkowej do wysłania

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

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

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

Dla deklaracji VAT-7:

Dla deklaracji VAT-UE i VAT-UEK:

Uwaga

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

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

Wysyłanie deklaracji

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

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

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

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

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

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

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

Uwaga

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

Urzędowe Poświadczenie Odbioru

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

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

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

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

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

Wstęp

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

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

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

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

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

Ogólne zasady analizy komunikatów

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

Przyklad

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

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

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

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

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

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

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

Proponowane rozwiązanie: ponowne wystawienie upomnienia.

Test: Zgodność kasy

Poprawność stanów kasowych

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

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

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

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

Poprawność rejestrów i operacji kasowych

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

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

Rozwiązanie:

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

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

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

Błąd opisany jest komunikatem:

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

Rozwiązanie:

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

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

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

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

Rozwiązanie:

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

Test: Zgodność rozrachunków

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

Zgodność rozrachunków z dekretami

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

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

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

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

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

Rozwiązanie:

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

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

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

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

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

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

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

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

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

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

Zgodność rozrachunków z rozliczeniami

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

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

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

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

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

Rozrachunki dokonane bez wykorzystania dekretu kompensacyjnego

Test zgłasza błąd:

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

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

Test: Zgodność rozliczeń

Zgodność rozliczeń z zapisami kasowymi

W pierwszym etapie test sprawdza następujace warunki:

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

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

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

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

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

Rozwiązanie:

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

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

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

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

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

Zgodność rozliczeń z płatnościami

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

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

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

TrP_Kwota – TrP_Pozostaje = suma Roz_Kwota

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

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

Rozwiązanie:

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

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

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

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

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

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

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

z tabeli RożniceKursowe:

RKN_Dok1Typ, RKN_Dok1Numer, RKN_Dok1Lp, RKN_Dok2Typ,  RKN_Dok2Numer, RKN_Dok2Lp

z polami z tabeli Rozliczenia:

r2_Dok1Typ, r2_Dok1Numer, r2_Dok1Lp, r2_Dok2Typ, r2_Dok2Numer, r2_Dok2Lp

W razie wykrycia niezgodności test zwraca komunikat:

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

Rozwiązanie

Należy dokonać ponownego rozliczenia dokumentów.

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

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

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

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

Rozwiązanie:

Dokonać ponownego rozrachunku.

Test: Sprawdzenie kompletności księgowań

Sprawdzenie istnienia dekretów wynikowych

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

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

Rozwiązanie:

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

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

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

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

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

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

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

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

Rozwiązanie:

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

Sprawdzenie istnienia nagłówka dekretu wynikowego

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

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

Rozwiązanie:

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

Sprawdzenie ilości księgowań dokumentów

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

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

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

Sprawdzenie kompletności księgowania raportów

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

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

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

Rozwiązanie

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

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

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

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

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

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

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

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

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

Rozwiązanie

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

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

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

DZK_SumaDt-DZK_SumaCt=0

W przypadku niezgodności pojawia się komunikat:

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

Rozwiązanie

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

Sprawdzenie czy konta na dekretach istnieją w tabeli Konta

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

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

Rozwiązanie

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

Sprawdzenie czy dekrety mają wypełnione pole DT_Dziennik

W przypadku nieprawidłowości test zwraca komunikat:

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

Rozwiązanie

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

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

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

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

Sprawdzenie poprawności dekretów w okresie obrachunkowym

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

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

Rozwiązanie

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

Test: Poprawność kont i ich stanów

Sprawdzenie poprawności numerów kont

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

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

Rozwiązanie

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

Zgodność stanów kont

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

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

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

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

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

Rozwiązanie

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

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

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

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

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

Rozwiązanie

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

Sprawdzenie istnienia kont w okresach obrachunkowych, ustawienia waluty

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

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

Rozwiązanie

Wykonać update na pole KKS_Waluta.

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

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

Rozwiązanie

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

Sprawdzenie konta zapisu

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

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

Rozwiązanie

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

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

Czy dekrety zostały wprowdzone na odpowiednie konto?

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

Test: Noty memoriałowe

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

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

W przypadku błędu pojawia się komunikat:

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

Rozwiązanie

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

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

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

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

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

Rozwiązanie

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

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

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

Rozwiązanie

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

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

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

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

Rozwiązanie

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

Test: Bilans otwarcia

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

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

Rozwiązanie

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

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

Zakończenie

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

Częściowa likwidacja środka trwałego

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

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

Zmniejszenie wartości środka trwałego amortyzowanego jednotorowo

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

Wystawienie dokumentu RT

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

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

Wystawienie dokumentu MW

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

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

Zmniejszenie wartości środka trwałego amortyzowano dwutorowo

Zmniejszenie wartości środka trwałego amortyzowanego dwutorowo przebiega w analogiczny sposób jak zmniejszenie wartości środka trwałego amortyzowanego jednotorowo. Jednak w takim przypadku nie ma potrzeby wystawiania dokumentu RT (Rozdzielenie torów). Dla środka amortyzowanego dwutorowo, na dokumencie MW (Modyfikacja wartości) aktywne są obie kwoty: Podstawa bilansowa i Podstawa podatkowa. Przy wystawianiu dokumentu MW dla takiego środka należy podać kwotę bilansową, o jaką ma być zmniejszona wartość inwentarzowa środka. Pozostałe kwoty zostaną automatycznie wyliczone przez system i wpisane we właściwe pola.

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

Synchronizacja baz danych Comarch ERP XL- Comarch ERP XL HR

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

Konfiguracja parametrów synchronizacji w Comarch ERP XL

Uwaga

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

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

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

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

Należy zaznaczyć role: public i sysadmin

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

Uwaga

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

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

Uwaga

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

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

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

Uwaga

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

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

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

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

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

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

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

Konfiguracja parametrów synchronizacji w Comarch ERP XL HR

Uwaga

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

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

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

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

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

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

Uwaga

Tylko atrybuty o typie: Okresowy podlegają synchronizacji.

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

Konfiguracja po stronie serwera SQL

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

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

Konfiguracja zestawu transformacji DTS

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

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

Uwaga

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

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

Import list płac

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

 

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

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

Uwaga

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

Uwaga

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

Import deklaracji PIT/DRA/PPK

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

Uwaga

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

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

Uwaga

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

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

W przypadku deklaracji DRA przenoszone są :

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

Typy generowanych płatności:

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

Na deklarację PPK przenoszona jest:

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

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

Ogólny opis funkcji: naprawa stanów towarów

Naprawa stanów towarów jest funkcją specjalną służącą do naprawy błędów w bazie dotyczących obrotem towarów. Może również służyć do analizy historii dostaw towaru.

Parametry konfigurujące działanie Naprawy stanów towarów

W oknie Naprawa Stanów Towarów, w module Administrator, na zakładce: Test, znajdują się parametry służące do ustalenia zakresu wykonywanego testu oraz towaru, dla którego będzie on wykonywany.

Poprzez zaznaczenie opcji: Wszystkie towary/Wybrany towar, Użytkownik decyduje, czy test ma być wykonany dla wszystkich towarów, czy też dla wybranego towaru/grupy towarów. W nowszych wersjach dostępna jest również opcja wskazania konkretnej dostawy.

Zakres tabel, które będą przeglądane można ustalić poprzez opcje znajdujące się w grupie Sprawdzaj.

Parametry decydujące dla jakich dokumentów wykonywane są wybrane testy

Parametry odpowiadające za rodzaj wykonywanych testów

TrE=TrS: porównuje sumę wartości z subelementów (tabela cdn.TraSElem) z odpowiednimi wartościami na elemencie (tabela cdn.TraElem). W ramach testu kontrolowane są wartości następujących pól: TrE_Ilosc=sum(TrS_Ilosc),TrE_KosztKsiegowy=sum(TrS_KosztKsiegowy), TrE_KosztRzeczywisty=sum(TrS_KosztRzeczywisty)

Opcja: Historia

Jej zaznaczenie uruchamia tryb historyczny Naprawy stanów towarów. Ten tryb pracy nie wyszukuje błędów dla towarów. Służy on do analizy historii dostaw.

Tryb wyszukiwania uszkodzonych stanów towarowych

Aby uruchomić test w trybie wyszukiwania błędów należy odznaczyć opcję: Historia oraz ustalić dla jakich dokumentów ma być wykonany test.

Wykonanie testu powoduje wygenerowanie listy towarów, dla których występują błędy. Lista ta wyświetlana jest w grupie: Naprawa uszkodzonych towarów. Aby indeks towarowy znalazł się na liście towarów uszkodzonych, wartości na zasobach muszą różnić się od odpowiednich wartości wynikających z historii dokumentów. Podświetlenie towaru z listy powoduje wyświetlanie stanu wg zasobów oraz stanu wg historii dokumentów.

Różnica w którymkolwiek z pól (Stan: handlowy, magazynu, ilości, wartość; Stan: celny, wartość) powoduje uznanie towaru za uszkodzony.

Lista błędów dla towaru wybranego z listy uszkodzonych znajduje się na zakładce: Szczegóły.

Znajdujące się tutaj błędy można odbudować przy użyciu funkcji: Odbuduj, wywoływanej spod menu kontekstowego. W tym przypadku mamy do czynienia z sytuacją kiedy ilość na zasobie jest większa niż ilość w historii, dlatego naprawa polega na prostym odbudowaniu zasobu.

W celu wykonania ręcznej modyfikacji wartości na dostawach lub zasobach należy użyć funkcji Szczegóły dostawy/Szczegóły zasobu. Funkcje te powodują otwarcie formatki z wyświetlonymi wartościami z tabel cdn.Dostawy/cdn.TwrZasoby.

Uwaga

Uwaga: Modyfikacja wartości na formatce oraz jej zapisanie powoduje zaktualizowanie odpowiednich wartości w tabelach.

Nie wszystkie błędy mogą być naprawione na podstawie historii dokumentów. Automatyczna odbudowa części z błędów spowodowałaby występowanie wartości niedopuszczalnych przez system CDN XL (np. ujemne stany na zasobie). W takim przypadku należy przeanalizować historię dostawy na zakładce: Historia.

Na zakładce: Historia, znajduje się lista wszystkich subelementów wskazujących na dostawę podświetloną na zakładce: Szczegóły. W menu kontekstowym wywoływanym dla pozycji z listy znajdują się funkcje pozwalające na modyfikację nagłówka, elementu oraz subelementu wskazanego przez operatora.

Tryb historyczny naprawy stanów towarów

W celu uruchomienia Naprawy stanów towarów w trybie historycznym należy w grupie Sprawdzaj zaznaczyć opcję: Historia.

Tryb historyczny nie wyszukuje błędów dla towarów. Jest to narzędzie służące do analizy historii dostawy dla towarów.

Wykonanie testu w trybie historycznym, powoduje zapełnienie zakładki Szczegóły listą wszystkich dostaw towaru. Po wskazaniu interesującej dostawy, na zakładce Historia wyświetlane są wszystkie subelementy korzystające z niej. Analiza historii dostaw pozwala na odszukanie przyczyn stanów, które nie są uznawane za błąd (nie wynikają z utraty spójności bazy danych), np. niezgodność ilości handlowych i magazynowych towaru.

Przykłady zastosowania Naprawy stanów towarów

Nie można anulować korekty ilościowej dokumentu sprzedaży

Komunikat:

Zasób, z którego korzystała korekta został rozchodowany przez inny dokument.

Zamienić dostawę na jednym z dokumentów rozchodowujących towar, korzystającym z tej samej dostawy co korekta, której nie można anulować.

Należy uruchomić test Naprawa stanów towarów, w trybie historycznym. Na zakładce: Szczegóły znajdują się wszystkie dostawy dla towaru.

Zaznaczenie dostawy spowoduje wyświetlenie na zakładce: Historia, wszystkich subelementów, które wskazują na dostawę założoną dokumentem PW-5/01/2019. Na liście tej występuje RWK-3/01/2019, który chcemy anulować.

Na subelemencie dokumentu ZWM-5/01/2019 podpiętego do RW-4/01/2019 należy zmienić numer dostawy, na dostawę założoną przez inny dokument, np. dokument PW-4/01/2019. W celu wyedytowania tej formatki należy na określonej pozycji z menu kontekstowego wybrać: Szczegóły subelementu i przejść na zakładkę GIDy. W grupie: Dostawa, należy podać GIDNumer nowej dostawy.

Aby sprawdzić numer dostawy PW-4/01/2019 należy w sposób na zakładce Szczegóły zaznaczyć tę dostawę oraz przejść na Historię i z tego poziomu sprawdzić GIDNumer dostawy. W tym przypadku będzie to numer 144267.

Zmieniamy numer dla dokumentu magazynowego na zakładce GIDy na subelemencie.

Analogicznie należy zamienić numer dostawy dla subelementu RW.

Dla subelementu oraz elementu RW należy zamienić również wartości w grupie: Koszty (zakładka: Wartości), w przypadku, gdy różnią się one dla starej i nowej dostawy.

Uwaga

Uwaga: Jeśli zostały zmienione koszty na subelemencie należy pamiętać o poprawie kosztów na elemencie. W tym celu dla pozycji z listy, z menu kontekstowego należy wybrać: Szczegóły elementu i na zakładce: Ogólne, wypełnić wartości w grupie Koszty.

Następnie należy ponownie wykonać test dla towaru w trybie wyszukania błędów. Na zakładce: Szczegóły, zostanie wyświetlona lista błędów dotycząca ilości na zasobach. Należy poprawić te błędy korzystając z funkcji: Odbuduj, wywoływanej z menu kontekstowego. W celu weryfikacji poprawności wykonanych prac oraz spójności bazy danych konieczne jest ponowne wykonanie testu dla towaru.

Nie podano kosztów na korekcie ręcznej faktury sprzedaży; dostawa założona przez ten dokument została częściowo rozchodowana

Proponowane rozwiązanie

Należy ustalić koszt na dostawie oraz odpowiednio zmodyfikować koszty na dokumentach rozchodujących tą dostawę.

Aby zmodyfikować koszt na dostawie, po uruchomieniu testu w trybie historycznym na zakładce: Szczegóły, należy wyświetlić szczegóły dostawy założonej modyfikowaną korektą faktury sprzedaży.

W grupie: Wartości księgowe, znajdują się koszty określone na dostawie, które mają zostać zmodyfikowane. Wartości wyświetlone w kontrolkach zaznaczonych odpowiadają następującym polom w tabeli cdn.Dostawy: Dst_KsiegowaNetto, Dst_KsiegowaBrutto, Dst_RzeczywistaNetto.

Po zapisaniu zmian na dostawie zmienione zostaną koszty.

Uwaga

W wyniku wykonania tej operacji baza utraci spójność.

Następnym krokiem będzie wykonanie poprawek na elementach i subelementach dokumentów.

Z zakładki: Historia, należy wyedytować szczegóły subelementu dla dokumentu zakładającego dostawę. W grupie: Koszty subelementu powinny znajdować się wartości równe – co do znaku (!)- wartościom zapisanym na dostawie w polach: Dst_KsiegowaNetto, Dst_RzeczywistaNetto.

Uwaga

Dla korekty ręcznej faktury sprzedaży koszty zapisane w subelemencie, zakładającym dostawę powinny mieć przeciwny znak (ujemny) do wartości księgowej/rzeczywistej dostawy. Dla dokumentów zakupowych koszty na subelemencie mają ten sam znak co zapisane w tabeli cdn.Dostawy.

Analogiczną operację wykonujemy dla elementu. Należy tutaj zauważyć, że koszt w elemencie powinien być sumą kosztów zapisanych w subelementach związanych z tym elementem.

Następnym krokiem jest poprawa kosztów na subelementach i elementach dla dokumentów handlowych rozchodujących tą dostawę. Lista wszystkich dokumentów (subelementów) korzystających z tej dostawy wyświetlona jest na zakładce: Historia.

W celu wykonania dalszych poprawek należy ponownie wykonać test bez zaznaczonej opcji: Historia (poszukiwanie błędów). Test zwraca na zakładce: Szczegóły, błędy związane z zasobami, które można odbudować funkcją: Odbuduj, dostępną w menu kontekstowym.

Uwaga

Poprawa kosztów na dokumentach handlowych wiąże się z ponownym zaksięgowaniem dokumentów.

Stan magazynu na dzień bieżący nie zgadza się ze stanem wg zasobów

Przyczyn występowania tego typu problemów może być wiele. Przykład ten ma na celu przedstawienie ścieżki postępowania w celu odszukania ich przyczyny oraz sposobu poprawy błędu.

Na liście towarów wyświetlany stan towaru do sprzedaży i magazynowy jest sumą jego zasobów.

Stan magazynu na dzień dla towaru (raport: Stan magazynu na dzień) jest wyliczany na podstawie historii dokumentów. Jeśli nie istnieją dokumenty z analizowanym towarem na datę późniejszą niż wykonywany raport, stany magazynowe i handlowe powinny być zgodne z sumą zasobów.

Niezgodność stanów jest często spowodowana błędnymi ilościami handlowymi i magazynowymi dla zasobów (tabela cdn.TwrZasoby, pola TwZ_IlSpr, TwZ_IlMag, TwZ_Ilosc). Na rysunku pokazano ilości handlowe i magazynowe dla towaru wyliczone wg zasobów. Ilości magazynowe nie zgadzają się z wyliczonymi przez raport Stan magazynu na dzień.

Aby odnaleźć przyczynę występowania niezgodności należy uruchomić naprawę stanów towarów w trybie wyszukiwania błędów.

Na zakładce: Szczegóły, znajduje się lista błędów. Kolejne błędy pokazują, dla których dostaw ilości na zasobach są nieprawidłowe W tym przypadku ilość magazynowa na zasobach, wyliczona wg historii dokumentów powinna być ujemna co jest sytuacja nieprawidłową. Możemy przypuszczać, że istnieje dokument magazynowy nieprawidłowo wydający towar.

Na zakładce: Historia, można odszukać subelement, który nieprawidłowo rozchodowuje towar. Jak można zauważyć dostawa przyjęta dokumentem FZ opiewa na 30 szt. Została ona całkowicie rozchodowana dokumentami FS, do której podpięty był dokument magazynowy (nie pokazany na rysunku). Dokument WM, niezwiązany z handlowym, nieprawidłowo rozchodowuje towar, powodując wyliczenie ujemnych stanów magazynowych na zasobie.

Okazało się, że dokument ten nieprawidłowo korzysta również z innych zasobów. Ilość analizowanego towaru znajdująca się na nim w pełni wyjaśniała różnicę między stanem magazynowym wyliczonym wg historii dokumentów a ilością wynikającą z zasobów.

W celu naprawy stanów można anulować ten dokument lub podpiąć subelement do innej dostawy. Nie można anulować korekty ilościowej dokumentu sprzedaży). Następnie należy ponownie wykonać test Naprawa stanów towarów i odbudować błędy przyciskiem: Odbuduj zasoby na podstawie historii dokumentów, dostępnym na zakładce: Test.

Po wykonaniu odbudowy można ponownie wystawić dokument WM identyczny z anulowanym.

Aby przyspieszyć wystawienie takiego dokumentu, przed anulowaniem można wczytać go do Notatnika i wygenerować ponownie przy użyciu tej funkcjonalności.

Uwaga

Wszelkie naprawy dokonywane przy użyciu Naprawy stanu towarów ingerują w bazę danych. Nieprawidłowo przeprowadzona naprawa może spowodować występowanie jeszcze większej ilości błędów niż przed jej wykonaniem.

Dla bezpieczeństwa proponujemy wykonywać wszelkie operacje na kopii bazy. Jeśli przyniosą one spodziewany efekt można wykonać je na bazie produkcyjnej.

 

Obsługa w systemie

W programie CDNXL została dodana nowa funkcjonalność służąca do obsługi zwrotu podatku VAT nabywcom indywidualnym spoza UE, którzy wywożą zakupiony towar poza granice Unii.

Podstawa prawna …

Art. 126. 1. Osoby fizyczne niemające stałego miejsca zamieszkania na terytorium Wspólnoty, zwane dalej “podróżnymi”, mają prawo do otrzymania zwrotu podatku zapłaconego przy nabyciu towarów na terytorium kraju, które w stanie nienaruszonym zostały wywiezione przez nie poza terytorium Wspólnoty.

…

Art. 128. 1. Zwrot podatku może być dokonany, jeżeli podróżny wywiózł zakupiony towar poza terytorium Wspólnoty nie później niż w ostatnim dniu trzeciego miesiąca następującego po miesiącu, w którym dokonał zakupu.

2. Podstawą do dokonania zwrotu podatku jest przedstawienie przez podróżnego imiennego dokumentu wystawionego przez sprzedawcę, zawierającego w szczególności kwotę podatku zapłaconego przy dostawie towarów. Wywóz towaru powinien być potwierdzony na tym dokumencie przez urząd celny stemplem zaopatrzonym w numerator. Do dokumentu powinien być dołączony wystawiony przez sprzedawcę paragon z kasy rejestrującej, o której mowa w art. 111 ust. 1.
3. Urząd celny potwierdza wywóz towaru na dokumencie, o którym mowa w ust. 2, po okazaniu przez podróżnego wywożonego towaru i sprawdzeniu zgodności danych dotyczących podróżnego zawartych w tym dokumencie z danymi zawartymi w przedstawionym paszporcie lub innym dokumencie stwierdzającym tożsamość.
4. Przepis ust. 3 stosuje się odpowiednio do potwierdzania wywozu z terytorium Wspólnoty towarów nabytych przez podróżnego na terytorium państwa członkowskiego innym niż terytorium kraju.
5. W przypadku, gdy podróżny opuszcza terytorium Wspólnoty z terytorium państwa członkowskiego innego niż terytorium kraju, zwrot podatku przysługuje, jeżeli dokument, o którym mowa w ust. 2, został potwierdzony przez urząd celny, przez który towary zostały wywiezione z terytorium Wspólnoty.
6. Sprzedawcy oraz podmioty, o których mowa w art. 127 ust. 5, dokonujący zwrotu podatku podróżnemu mają prawo do pobrania od podróżnego prowizji od zwracanej kwoty podatku.
7. Rozliczenia między podmiotem, który dokonał zwrotu, a sprzedawcą towaru regulują zawarte przez nich umowy.

Procedura sprzedaży Tax Free

Sprzedawca wystawia nabywcy paragon fiskalny z podatkiem VAT naliczonym według stawek krajowych. Do paragonu dołącza wypełniony formularz Tax Free z wyszczególnionymi towarami, ich cenami oraz kwotą zapłaconego podatku. Formularz jest imienny.

Nabywca wywożąc towar przedstawia UC granicznemu dokument Tax Free z paragonem i zakupione okazuje towary. Urząd Celny potwierdza fakt wywiezienia towarów stemplem na formularzu Tax Free.

Następnie występuje jeden z dwóch możliwych scenariuszy

 Zwrotu VAT-u dokonuje sprzedawca:

Zwrotu VAT-u dokonuje firma pośrednicząca, z którą sprzedawca podpisał stosowną umowę:

Dokument Tax Free

Obsługa powyższych scenariuszy w systemie została zrealizowana poprzez dodanie nowego dokumentu handlowego: Tax Free.

Dokument jest kolejnym z grupy handlowych, o strukturze opartej o tabelę TraNag. Ma nagłówek, płatności, tabelę VAT. Dokument ten nie ma elementów.

Obok daty wywozu umieszczony jest checkbox „Potwierdzenie wywozu”.

Spinanie TF do RSK

Przy spinaniu dokumentu TF do RSK, zastosowane zostały następujące zasady:

Obsługa prowizji

Przy zapisywaniu zatwierdzonego dokumentu Tax Free z zaznaczoną opcją „Potwierdzenie wywozu” zostaje wygenerowany automatycznie paragon, jeśli kwota prowizji jest niezerowa.

Paragon na prowizję od zwrotu VAT-u. będzie mieć płatność (należność), która zostanie automatycznie skompensowana z płatnością wynikającą z dokumentu TF, pomniejszając tym samym zobowiązanie z tytułu zwrotu podatku.

W definicji dokumentu TF będzie można ustawić procentową stawkę prowizji pobieranej przy zwrocie podatku.

Uwaga

Jeśli płatnik na dokumencie TF jest różny od kontrahenta głównego, dokument ten będzie wyświetlał zerową stawkę i zerową kwotę prowizji.  

Deklaracja VAT-7

Dokument RSK jest  uwzględniany w deklaracji VAT-7 w następujący sposób:

Rekordy tabeli VAT z typem transakcji krajowa zalicza się do kwoty sprzedaży krajowej opodatkowanej odpowiednią stawką (pola 25,27,29),

Rekordy o typie transakcji tax free zalicza się do „Dostawy na terytorium kraju…  opodatkowanej stawką 0%, o której mowa w art. 129 ustawy” (pole 23).

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.