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.