Opis widoków wystawianych przez system KS- SOMED dla systemu KS-FKW

Transkrypt

1 Opis widoków wystawianych przez system KS- SOMED dla systemu KS-FKW Widoki Stan na dzień: czwartek, 19 maja 2011 ostatnie zmiany Nazwa widoku: V_FK_DOK Opis: Widok ten udostępnia nagłówki faktur z zadanego okresu czasu. Pojęcie faktura oznacza tu każdy z dokumentów znajdujących się w tabeli DOKF. Są to więc i faktury VAT, rachunki, faktury wewnętrzne, faktury zbiorcze itp. To jakie dokumenty będą przenoszone zależy od ustawień opcji w systemie KS-SOMED. Uwaga, po każdej zmianie opcji konieczne jest przekompilowanie pakietu FK z poziomu systemu KS-SOMED. Kompilacja ta stworzy nowy widok dostosowany do ustawionych opcji. Opcje mówią również o tym dla jakich kontrahentów widok będzie udostępniał dane. Uwaga: tylko faktury z DEL = 0 są widoczne w widokach. Jeśli więc ktoś anuluje fakturę, to zniknie ona z widoku. Struktura: Nazwa pola Opis Typ pola Możliwe wartości Informacje dodatkowe TYPD Typ dokumentu VARCHAR2(20 SSFV6 faktura VAT SSFVK6-korekta faktury VAT SSWO6- wewnętrzna opłata SSWK6- wewnętrzna wypłata SSRU6 rachunek SSRUK6-korekta rachunku SSFW6 faktura wewnętrzna SSFWK6 faktura wewnętrzna korekta SSZR6 zestawienie refundacyjne SSZRK6 korekta zestawienia refundacyjnego SSWPL6 wpłata bez usługi SSWYP6 wypłata bez usługi SSDAR6 darowizna SSDRK6 darowizna, korekta SSFPF6 faktura pro forma SSFPK6 faktura pro forma korekta SSF2V6 - faktura VAT2 SSF2K6 faktura VAT2 korekta SSFZ6 faktura zbiorcza SSFZK6 korekta faktury zbiorczej SKRK6 - raport kasowy SKAP6 raport kasowy anulowane płatności SSFR faktury wystawione w module refundacje SSFRK korekty faktur z modułu refundacje 6 na końcu to wartość domyślna. Uzależniona jest od wartości opcji FK_NUMER Faktura wewnętrzna może również pełnić rolę trzeciego rejestru VAT. Zestawienie refundacyjne nie wykazuje VAT Wartość pola budowana jest na podstawie wyników funkcji GET_PREFIX_DOKUMENTU oraz GET_NUMER_DLA_TYPD ta druga funkcja zwraca właśnie wartość 6. Uwaga, w przypadku faktury zaliczkowej zamiast SS będzie SZ Uwaga, jeśli faktura została zafiskalizowana, to wówczas zamiast SS będziemy mieli prefiks SF. Powinno to sugerować, że takie dokumenty fiskalnie rozliczane są w raporcie dobowym.

2 FRMP Forma płatności z nagłówka faktury VARCHAR2(1 G gotówka P przelew C czek K karta B - bezgotówkowo Wartość jest wynikiem wywołanie funkcji GET_SYMBOL_PLAT Dla raportów kasowych B DATA Data wystawienia DATE dokumentu DAT1 DATE NULL Nie obsługiwane przez KS-SOMED DAT2 Data wystawienia DATE Tożsame z DATA dokumentu DAT3 Data sprzedaży z DATE nagłówka faktury DAT4 Termin płatności z DATE nagłówka faktury DTRL DATE NULL Nie obsługiwane przez KS-SOMED NTPK Typ kontrahenta 0 nie rozpoznany 2 - kontrahent 5 inna przychodnia 6 OW NFZ 7 pacjent Przy odpowiednio ustawionych opcjach wszystko może być 2, wówczas nie rozróżniamy typów kontrahentów. Wynik funkcji GET_TYP_KONTRAHENTA. NKNT Kod kontrahenta VARCHAR2(6 NRDK Numer dokumenty finansowego VARCHAR2(20 Jednoznacznie identyfikujący dokument finansowy symbol NRPZ CHAR(1 -, dla Panoramy symbol dokumentu kasowego wyzwalającego fakturę (przelew) NDKR Symbol dokumentu VARCHAR2(20 korygowanego OSID Identyfikator VARCHAR2(20 6DOKFXXXXXXXXX dokumentu KNZW1 Nazwa kontrahenta VARCHAR2(100 Wynik funkcji GET_KOD_KONTRAHENTA Wykorzystywane jest pole NKNT z odpowiednich tabel. Dla raportów kasowych: 0 DOKF.SYZR w przypadku raportów kasowych wygląda to mniej więcej tak: RDF/XXX / gdzie RDF to raport dobowy fiskalny (w przypadku korekty KRDF) XXX numer unikatowy drukarki jeśli zapisano jeśli taka wersja programu była 884 numer wydruku raportu (nie wystąpi w przypadku generowania raportów archiwalnych) data raportu dla korekt mamy jeszcze # informującą kiedy była korekta raportu Nie obsługiwane przez system KS-SOMED chyba, że PANORAMA Wypracowuje funkcja. GET_SYMBOL_KOREKTY XXXXXXXXX ID DOKF Zwykle wartość pola NAZW Dla raportów kasowych NULL KNZW2 Nazwa kontrahenta CHAR(1 Space Nie obsługiwane przez KS-SOMED KNIPV NIP kontrahenta VARCHAR2(13 Dla raportów kasowych NULL KKODP Kod pocztowy VARCHAR2(6 Dla raportów kasowych NULL adresu kontrahenta KMISC Miejscowość adresu VARCHAR2(35 Dla raportów kasowych NULL kontrahenta KULIC Ulica adresu kontrahenta VARCHAR2(35 Z numerem posesji oraz lokalu Dla raportów kasowych NULL WLKRS 0 Nie obsługiwane przez KS-SOMED WLMNN 0 Nie obsługiwane przez KS-SOMED WLBRU 0 Nie obsługiwane przez KS-SOMED SDBRU Suma dokumentu brutto GET_SUMA_STAWEK_VAT_BRUTTO SDNET Suma dokumentu netto SDVAT Suma dokumentu VAT SUMA_STAWEK_VAT_VAT SDN23 Suma netto dla stawki 23% SDV23 suma vat dla 23% SUMA_STAWEK_VAT_VAT

3 SDN08 suma netto dla 8% SDV08 suma vat dla8% SUMA_STAWEK_VAT_VAT SDN05 suma netto dla 5% SDV05 suma vat dla 5% SUMA_STAWEK_VAT_VAT SDN00 Suma NETTO dla stawki 0% SDNZW Suma NETTO dla stawki zwolnionej SDN22 SDV22 SDN07 SDV07 SDN03 SDV03 Suma NETTO dla stawki 22% Suma VAT dla stawki 22% Suma NETTO dla stawki 7% Suma VAT dla stawki 7% Suma NETTO dla stawki 3% Suma VAT dla stawki 3% dla kasowego = 0 SUMA_STAWEK_VAT_VAT dla kasowego = 0 dla kasowego = 0 SUMA_STAWEK_VAT_VAT dla kasowego = 0 dla kasowego = 0 SUMA_STAWEK_VAT_VAT dla kasowego = 0 SDNNP 0 Nie obsługiwane przez KS-SOMED SDDZP Do zapłaty za (9,2) Nie koniecznie zgodne z wartością BRUTTO dokument SZNET 0 Nie obsługiwane przez KS-SOMED SZVAT 0 Nie obsługiwane przez KS-SOMED SZN23 0 Nie obsługiwane przez KS-SOMED SZV23 0 Nie obsługiwane przez KS-SOMED SZN08 0 Nie obsługiwane przez KS-SOMED SZV08 0 Nie obsługiwane przez KS-SOMED SZN05 0 Nie obsługiwane przez KS-SOMED SZV05 0 Nie obsługiwane przez KS-SOMED SZN22 0 Nie obsługiwane przez KS-SOMED SZV22 0 Nie obsługiwane przez KS-SOMED SZN07 0 Nie obsługiwane przez KS-SOMED SZV07 0 Nie obsługiwane przez KS-SOMED SZN03 0 Nie obsługiwane przez KS-SOMED SZV03 0 Nie obsługiwane przez KS-SOMED SZN00 0 Nie obsługiwane przez KS-SOMED SZNZW 0 Nie obsługiwane przez KS-SOMED SZNNP 0 Nie obsługiwane przez KS-SOMED SODCH 0 Nie obsługiwane przez KS-SOMED SDNRB 0 Nie obsługiwane przez KS-SOMED IDOPER ID w systemie KS operatora, który dodał rekord faktury TRNS Kod turnusu Varchar Wystawiany tylko w przypadku licencji PANORAMA BRT(0..5) Brutto kontrahenta Wystawiany tylko w przypadku licencji PANORAMA GOT(0..5) Gotówka kontrahenta Wystawiany tylko w przypadku licencji PANORAMA PRZ(0..5) Przelew kontrahenta Wystawiany tylko w przypadku licencji PANORAMA KLP(0..5) Płatność kartą kontrahenta Wystawiany tylko w przypadku licencji PANORAMA KNT(1..5) Kontrahent Wystawiany tylko w przypadku licencji PANORAMA

4 Nazwa widoku: V_FK_POZ Opis: Widok ten udostępnia pozycje faktur z zadanego okresu czasu. To, jakie dokumenty będą udostępniane zależy od ustawień opcji. To dla jakich typów kontrahentów dane będą udostępnione zależy od ustawień opcji. Jedna pozycja faktury może być rozbijana na kilka rekordów, w sytuacji, gdy pod tą pozycją kryje się kilka identycznych usług. Widok ten bowiem tak naprawdę jest widokiem po jednostkowych sprzedażach, a to ze względu na możliwość wykonania przez różne ośrodki kosztów. Na przykład mamy usług: konsultacja specjalistyczna, która zarówno w poradni okulistycznej, jak i kardiologicznej kosztuje tyle samo, ma ten sam kod KWIU, czyli na potrzeby finansowe jest tym samym! Wówczas pozycja na fakturze jest jedna, ale z ilością 2. Widok pokaże dwie takie pozycje! Jeśli więc coś takiego może się zdarzyć należy nie sumować kwot pozycji o tym samym OSID i POZC według pola WPOZ bo mogą pojawić się nieprawidłowe sumy lub sumować po polu KPOZ. Powyższa uwaga dotyczy również sytuacji, gdy usługa jest wykonana przez ten sam ośrodek kosztów, musimy bowiem rozbijać na poszczególne sprzedaże, bo może pojawić się inny ośrodek kosztów. To jest widok do analizy kosztów! I tylko z tego widoku czyli z wystawionych dokumentów sprzedaży możliwe jest wyliczanie kosztów i rozdział kwot na poszczególne ośrodki kosztów Struktura: Nazwa pola Opis Typ pola Możliwe wartości Informacje dodatkowe OSID Identyfikator VARCHAR2(12 6DOKFXXXXXXXXX Porównaj z V_FK_DOK.OSID dokumentu POZC Pozycja na fakturze (3) Może być kilka rekordów dla tej samej pozycji, dla tej samej faktury! Porównaj opis widoku i informacje o ośrodkach kosztów. DATA Data wystawienia DATE Porównaj z V_FK_DOK.DATA dokumentu DTRZ DATE NULL Nie obsługiwane przez KS-SOMED NTPK Typ kontrahenta Porównaj z V_FK_DOK.NTPK Porównaj z V_FK_DOK.NTPK NKNT Kod kontrahenta VARCHAR2(6 Porównaj z V_FK_DOK.NKNT TRAN CHAR(1 Nie obsługiwane przez KS-SOMED OSIR VARCHAR2(12 NULL OPIS Opis pozycji z faktury VARCHAR2(1024 Dokładnie to co jest w PDSP, czyli w pozycji faktury NUSL Nazwa usługi VARCHAR2(232 Dokładnie to co w polu nazwa tabeli usług lub towarów KGFK Kod grupy usługi dla FK VARCHAR2(20 Kod pobierany z pola FK na usłudze. Kilka usług może mieć ten sam kod, co pozwala łączyć je w systemie FK w jedno. KUSL Kod usługi VARCHAR2(17 Dokładnie to co jest w polu kod w tabeli usług lub towarów FKKD Kod FK poradni wykonującej DOZA Wartość pozycji - doza VARCHAR2(20 (9,2) Kod ten pobierany jest z poradni, która wykonała dane zlecenie umieszczone na fakturze. Równa KPOZ o ile ilość = 1 i o ile jest jeden płatnik zlecenia! Jeśli przenosimy zestawienia refundacyjne, to różnica pomiędzy KPOZ*ILOSC a DOZA będzie na właściwym zestawieniu refundacyjnym. WPOZ Wartość pozycji (9,2) KPOZ*ILSC czyli wartość pozycji. W szczególnych przypadkach różna od DOZA! KPOZ Kwota pozycji (9,2) Kwota ta będzie identyczna dla wszystkich rekordów dotyczących tej samej pozycji faktury, bez względu na liczbę ośrodków kosztu KZLC Wartość zlecenia (9,2) Wartość dla konkretnego zlecenia z pozycji faktury. Czyli ZLEC.CSBR * ZLEC.ILSC VALUE Wartość konkretnej, przekazywanej (9,2) Wartość pozycji wystawianej w widoku. Dla dokumentów pierwotnych jest to CSBR czyli to samo co KPOZ, dla korekt jest

5 pozycji brutto odpowiednio wyliczane. Szczegóły są opisane w dodatkowym punkcie dokumentu VAT wartość VAT (9,2) wartość podatku VAT wyliczana dla wartości VALUE NETTO wartość netto (9,2) wartość netto wyliczana dla wartości VALUE SVAT stawka VAT (9,2) stawka VAT 99 oznacza stawkę zwolnioną FRMP Forma płatności z VARCHAR2(1 Porównaj z V_KD_DOK.FRMP nagłówka faktury PRKD Kod FK dla pracownika VARCHAR2(20 Tożsamy z polem kod dla KP pracownika. KNTX Konto księgowań Domyślnie zwraca to samo co FKKD. OSKSZ Ośrodek kosztów Domyślnie zwraca to samo co FKKD Wypracowane na podstawie funkcji GET_NKTX, której parametrami są: KGFK,KUSL,FKKD,PRKD,FRMP,NTPK,NKNT. Ciało funkcji należy ustawić na etapie wdrożenia. Wypracowane na podstawie funkcji GET_OSKSZ. Ciało funkcji należy ustawić na etapie wdrożenia. W zależności od wdrożenia możliwe jest określenie dla każdej pozycji albo ośrodka kosztów albo konta księgowego. Można także korzystać z jednego i drugiego Jeśli potrzeba stworzyć konto ośrodków kosztu a nie można posłużyć się dostępnymi w widoku polami KGFK, KUSL, FKKD, PRKD, FRMP, NTPK, NKNT czyli Informacją o usłudze, poradni wykonującej, pracowniku wykonującym, formie płatności oraz typie i numerze kontrahenta bezpośrednio w programie FK, można wykorzystać funkcję GET_NKTX. Parametrami tej funkcji są wszystkie wspomniane przed chwilą wartości. Na ich podstawie, pewnie na podstawie wybranych i kilku wartości, należy zbudować konto. Funkcja GET_NKTX jest standardowo pustą dokładniej mówiąc zwraca jedną z wartości, ale tylko po to by coś było. Nie należy się tym kompletnie zajmować. Jeśli chcemy zbudować samodzielnie numer konta to wystarczy zmodyfikować odpowiednio tę właśnie funkcję. Co ważne, kompilacja pakietu FK nie wpływa na postać funkcji GET_NKTX o ile funkcja już istnieje i nie zawiera domyślnego tekstu RETURN FKKD;. Nie ma więc niebezpieczeństwa iż postać konta zmieni się po zmianie opcji i ponownym przekompilowaniu pakietu FK. Co również istotne, jeśli funkcja ta jest błędna i nie chce się kompilować, to nie pomoże w tym przypadku ponowna kompilacja pakietu, jako że ta jedna, jak na razie jedyna, funkcja nie jest nadpisywana. Podobnie z określeniem ośrodka kosztów. Można sobie wyobrazić przekazywanie do FK osobno konta księgowego, które zależy, a w zasadzie może zależeć, i od ośrodka kosztów i od kontrahenta i od sposobu płatności, jak i właściwego kodu ośrodka kosztów, który to zależy od wykonawcy usługi (poradni, gabinetu, pracownika). To drugie, czyli kod ośrodka kosztów może wypracować funkcja GET_OSKSZ, którą również można zmodyfikować na etapie wdrożenia. Opis w dalszej części dokumentu. Nazwa widoku: V_FK_ZAP Opis: Widok ten udostępnia informacje o dokumentach kasowych regulujących dokumenty finansowe. Jeden dokument kasowy może regulować kilka dokumentów finansowych. Jeden dokument finansowy może być regulowany przez kilka dokumentów kasowych. Struktura: Nazwa pola Opis Typ pola Możliwe wartości Informacje dodatkowe TYPD Typ dokumentu VARCHAR2(10 SWXG6 wpłata gotówkowa Wartość jest wypracowywana przez

6 FRMP Forma płatności VARCHAR2(1 SWYG6 wypłata gotówkowa SWWP6 wpłata przelew SWYP6 wypłata przelew G gotówka P przelew C czek K karta Brak - bezgotówkowo GET_TYP_DOKUMENTU_KASOWEGO i GET_NUMER_DLA_TYPD Wypracowywane przez funkcje GET_SYMBOL_PLAT, GET_FRMP_FROM_KASA. Uwaga, niekoniecznie musi być to zgodne z formą płatności właściwej faktury. DATA Data dokumentu DATE DAT1 DATE Nie obsługiwane przez KS-SOMED DAT2 Data dokumentu DATE Tożsame z Data NTPK Typ kontrahenta Porównaj V_FK_DOK.NTPK NKNT Kod kontrahenta VARCHAR2(6 Porównaj V_FK_DOK.NKNT NBKS Numer kasy VARCHAR2(4000 Zwraca NRFK ze stanowiska związanego z dany, stanowiskiem kasowym NRDK Symbol dokumentu VARCHAR2(40 Zgodny z wydrukiem KP lub KW NRRK OSID Numer raportu kasowego Identyfikator dokumentu kasowego Informacja co opłacamy VARCHAR2(4000 VARCHAR2(12 Jeśli płatność nie występuje jeszcze na żadnym dokumencie kasowym mamy tu NULL 6DOKKXXXXXX 6 zależne od opcji XXXXX ID rekordu z DOKK ZACO VARCHAR2(40 Symbol dokumentu DOKF. Może być to również WPL, czyli wpłata wewnętrzna. DTPB DATE Nie obsługiwane przez KS-SOMED OSIR Identyfikator VARCHAR2(12 6DOKKXXXXXXX regulowanego dokumentu PRZY Przychód ROZC Rozchód PRAC Numer techniczny pracownika, który stworzył dokument (9) NTBK Zawsze 3 ID z PRAC Istnieje opcja, która pozwala przenosić jedynie opłaty dostępne na raporcie kasowym. Uwaga ważny zakres dat. Może być tak, że pobieramy dajmy na to cały marzec, ale ostatnia opłata z marca jest na raporcie kasowym z kwietnia. Jeśli więc najpierw pobrano dane z marca do FK, następnie zrobiono raport kasowy z elementami z marca to robiąc pobranie za kwiecień może płatność marcowa nam nie wejdzie. Nie wejdzie, bo jest z marca, nie weszła w marzec, bo nie było raportu kasowego. Nazwa widoku: V_FK_KNT Opis: Widok ten udostępnia informacje o kontrahentach. Dzięki niemu możliwe jest następnie nadanie numeru kontrahenta przez system FKV dzięki funkcji KNT_NRFK z pakietu FK. Widok ten udostępnia kontrahentów mających jakieś dokument finansowe wystawione po dniu określonym w opcji FK_DATA_DF. Struktura: Nazwa pola Opis Typ pola Możliwe wartości Informacje dodatkowe NZW1 Nazwa kontrahenta VARCHAR2(100 NZW2 CHAR(1 Zawsze spacja Nie wykorzystywane w KS-SOMED IMIE Imię kontrahenta, jeśli jest to pacjent VARCHAR2(20 Imię pacjenta lub znak -

7 SKRT Skrót identyfikujący kontrahenta VARCHAR2(40 Skrót z pola odpowiedniego kontrahenta lub imię dla pacjenta ODBR CHAR(1 Zawsze - Nie wykorzystywane w KS-SOMED NKNT Identyfikator kontrahenta Wyliczany wg wzoru ID*100+typ Wystawiany zawsze, nawet jeśli kontrahent ma już kod. NTPK Typ kontrahenta Porównaj V_FK_DOK.NTPK NRFK Kod kontrahenta VARCHAR2(12 Jeśli NULL to FK powinna nadać Porównaj V_KF_DOK.NRFK wartość NIPV NIP VARCHAR2(13 PESL PESEL VARCHAR2(11 Znak -, chyba że kontrahentem jest pacjent REGN REGON VARCHAR2(20 Dla pacjenta znak - KRAJ Kraj VARCHAR2(35 MISC Miejscowość VARCHAR2(35 KODP Kod pocztowy VARCHAR2(6 ULIC Ulica VARCHAR2(35 TELF Telefon VARCHAR2(40 FAXM Fax CHAR(1 Nie wykorzystywane w KS-SOMED BANK Bank VARCHAR2(60 Dla pacjenta znak - RACH Rachunek bankowy VARCHAR2(50 Dla pacjenta znak - KODK STRING - Nie obsługiwane przez KS-SOMED NRVD STRING - Nie obsługiwane przez KS-SOMED Jak to wszystko uruchomić? Moduł Kasa -> opcje modułu Kasa -> zakładka Ksęgowość. Tu należy ustawić typ raportu na KS-FKW.

8 Następnie można poustawiać opcjami jakie dokumenty mają się przenosić. Nie wszystko ma sens i nie wszystko będzie działać poprawnie. Uwaga, na dokumenty wewnętrzne! Nie zalecam tego przenosić. Co innego faktura zbiorcza. Po każdej zmianie w ustawieniach opcji należy przekompilowac pakiet FK. W przypadku wykorzystania funkcjonalności faktur zbiorczych należy bezwzględnie wymagać takiego systemu pracy: 1. Polecać pacjentom faktury 2. Jeśli nie ma takiej potrzeby idziemy po dokumentach kasowych można nie fakturować i następnie te opłaty trafia do dokumentu zbiorczego sprzedaży 3. Jeśli pacjent nie płaci całości bezwzględnie należy wystawić mu fakturę. Inaczej będziemy mieli kompletny młyn nie mówiąc już o tym, że konieczne będą korekty faktury zbiorczej a i załapanie gdzie i co w którym miesiącu poszło będzie koszmarem 4. Do FK w widokach trafiają tylko sprzedaże. 5. Nie używać wpłat i wypłat bez usługi! A przynajmniej używać ich z głową. Coś takiego nie jest sprzedażą, więc nie pójdzie do dokutemu zbiorczego. Więc nie trafi do FK (patrz punkt 4). 6. Jeśli chcemy bawić się z ośrodkami kosztów należy przygotować funkcję na bazie GET_NKTX.

9 Funkcja GET_NKTX Jest to funkcja pozwalająca na uzyskanie konta księgowego na podstawie informacji o usłudze, wykonawcy, kontrahenta i pacjenta. Ta funkcja nie jest nadpisywana przy okazji kompilacji pakietu FK. Ta funkcja może być przez wdrożenie przystosowana do uzyskania właściwego konta ośrodków kosztu. Oryginalnie jest ona banalna, ale podczas wdrożenia można tu zrobić wszystko łącznie z selectami po dodatkowych tabelach pozwalających na przekodowanie Parametry funkcji: 1. KGFK kod usługi 2. KUSL kod grupy towarowej dla usługi 3. KTYP Czy IDUSLG to IDUSLG (wartość 0) czy IDTOWR(wartość 1) 4. IDUSLG ID wykonanej usługi 5. FKKD kod FK poradni, w której wykonano zlecenia 6. IDPORA ID poradni, w której wykonano zlecenia 7. PRKD kod FK pracownika, wykonawcy zlecenia 8. IDPRAC id pracownika, wykonawcy zlecenia 9. FRMP forma płatności 10. NTPK - typ kontrahenta 11. NKNT - numer kontrahenta Oryginalna postać funkcji: CREATE OR REPLACE FUNCTION GET_NKTX ( KGFK USLG.KGRF%TYPE, KUSL USLG.KOD%TYPE, KTYP, IDUSLG USLG.ID%TYPE, FKKD PORA.FKNT%TYPE, IDPORA PORA.ID%TYPE, PRKD PRAC.KPID%TYPE, IDPRAC PRAC.ID%TYPE, FRMP VARCHAR2, NTPK, NKNT VARCHAR2) RETURN VARCHAR2 IS BEGIN RETURN FKKD; END; Dzięki przekazywaniu do funkcji ID (usługi, towaru, poradni, pracownika) możliwe jest praktycznie nieograniczone rozszerzenie możliwości tworzenia konta. Można np. wyobrazić sobie iż mamy osobne konto na pacjentów obcokrajowców (informacja na karcie pacjenta). Można wyobrazić sobie osobne konto dla pacjentów VIP (szczególny rodzaj charakteru pacjenta). Można wyobrazić sobie osobne konto wybierane na podstawie grupy usług (tak, grupy widzianej jako widok, czyli iż tabel i WIDK). Liczba pól jest niegraniczona i możemy wykonać praktycznie wszystko. Oczywiście, należy pomyśleć, kto to będzie serwisował. UWAGA: Najnowsza wersja pakietu potrafi stworzyć na nowo funkcję GET_NKTX o ile jest ona funkcją domyślną, czyli zwraca FKKD dokładnie tak, jak napisałem nieco wcześniej. Jest to użyteczna właściwość, gdy musimy zmieniać listę argumentów tej funkcji i chcemy, by nie mieli problemów ci, którzy o istnieniu tej funkcji w ogóle nie wiedzą. Dlatego uwaga dla wdrożeniowców, wasza funkcja nie może zawierać czegoś, co da się zwrócić poprzez %RETURN FKKD;%, nawet, gdyby było to w

10 komentarzu. Bo wam funkcję wytnie. Nie wydaje mi się, by było to możliwe, w przypadku stworzenia własnej, sensownej funkcji, ale ostrzec nie zaszkodzi. Ta sama uwaga dotyczy i pozostałych takich funkcji, jak np. GET_OSKSZ Funkcja GET_NKTX2 Jest to prawie identyczna funkcja z GET_NKTX. Powstała po to, bo dziwnym trafem niektórzy chcą mieć dwie różne funkcje operujące prawie na tych samych parametrach. Więc są takie dwie funkcje. Dodatkowo GET_NKTX2 ma PDSPPLAT.ID co teoretycznie pozwala sięgnąć do płatności oraz zleceń lub sprzedaży. Ale ostrożne! W przypadku korekt można się tu zdecydowanie sparzyć. Oto przykład: 1. Mamy zlecenie na kwotę brutto 100 zł 2. Wystawiamy fakturę 3. Korygujemy fakturę i zmieniamy na 80 zł netto 4. Przy okazji dokumentu pierwotnego chcemy coś obliczyć i oprzeć się na kwocie ze zlecenia. Po korekcie dostaniemy 80 zł a nie 100! Oczywiście dokument pierwotny jest OK, bo w nim pamiętamy wszystko co potrzeba ze zlecenia, ale tenże dokument łączy się ze zleceniem już zmienionym. Stąd ostrożność. Podobnie będzie jeśli korektę zrobimy na zero, dokonamy edycji zlecenia i zmienimy np. poradnię. Odnosząc się do poradni ze zlecenia w dokumencie pierwotnym otrzymamy inną poradnię, niż była w trakcie wykonywania zlecenia! Oczywiście poradnia, która trafi do tej funkcji jako parametr jest OK., bo jest to poradnia zapamiętana z momentu wystawienia dokumentu. Mam nadzieję, że tych kilka przykładów uzmysłowi wszystkim, że do księgowości nie możemy popychać niczego, co jest związane bezpośrednio ze zleceniem lub sprzedażą. Możemy popychać bezpiecznie tylko to co jest związane z dokumentem, bo to nam się nie zmienia. I jeśli ktoś sobie grzebie zestawienia i sięga do zleceń i twierdzi, że tym sposobem udało mu się zrobić to czego SOMED nie potrafi to po prostu jest w błędzie. Pewnie nawet o tym nie wie, bo większość danych otrzymuje poprawnie, ale z pewnością trafi w końcu na sytuację, że całość trafi w maliny. Więc grzecznie ostrzegam. Funkcja GET_OSKSZ Jest to funkcja pozwalająca na uzyskanie informacji o ośrodku kosztów Ta funkcja, tak jak GET_NKTX, nie jest nadpisywana przy okazji kompilacji pakietu FK. Ta funkcja może być przez wdrożenie przystosowana do uzyskania właściwego ośrodków kosztu. Oryginalnie jest ona banalna, ale podczas wdrożenia można tu zrobić wszystko łącznie z selectami po dodatkowych tabelach pozwalających na przekodowanie Parametry funkcji: 1. FKKD kod FK poradni, w której wykonano zlecenia 2. IDPORA ID poradni, w której wykonano zlecenia

11 3. FKNT kod FK gabinetu, w którym wykonano zlecenie 4. IDJORG ID gabinetu, wykonawcy zlecenia 5. PRKD kod FK pracownika, wykonawcy zlecenia 6. IDPRAC id pracownika, wykonawcy zlecenia Oryginalna postać funkcji: CREATE OR REPLACE FUNCTION GET_OSKSZ ( FKKD PORA.FKNT%TYPE, IDPORA PORA.ID%TYPE, FKNT JORG.FKNT%TYPE, IDJORG JORG.ID%TYPE, PRKD PRAC.KPID%TYPE, IDPRAC PRAC.ID%TYPE ) RETURN VARCHAR2 IS BEGIN RETURN FKKD; END; Dzięki przekazywaniu do funkcji możliwe jest praktycznie nieograniczone rozszerzenie możliwości tworzenia kodu ośrodka kosztów. Liczba pól jest niegraniczona i możemy wykonać praktycznie wszystko. Oczywiście, należy pomyśleć, kto to będzie serwisował. Daty widoków Należy pamiętać, ze system KS-FKW ustawia samodzielnie daty dla którym ma być generowany widok dokumentów, pozycji, zapłat. Daty te, przez odpowiednią funkcję są umieszczone w tabeli FOPC. Są to wartości kolumny VALU rekordów o kolumnie NAZW = FK_DATA_OD oraz FK_DATA_DO. Chcąc samodzielnie sprawdzić widoki należy ustawić ręcznie odpowiednie daty w tej opcji. Nie ma obaw, za każdym razem FK, gdy chce coś pobrać, ustawi poprawne daty. Jest też data w rekordzie oznaczonym jako FK_DATA_DF. Datę tę będzie można ustawić w opcjach systemu. Jest to data startu systemu FK. Nic sprzed tej daty nie zostanie umieszczone w widoku, bez względu na bieżąca wartość FK_DATA_OD. Data ta jest również datą analizy dokumentów finansowych dla kontrahenta przy okazji wystawiania widoku kontrahentów. W widoku pojawią się kontrahenci tylko tacy, którzy począwszy od daty startu FK mają wystawiony dokument finansowy. V_FK_POZ kwoty,kwoty! Można zadać pytanie, dlaczego w V_FK_POZ jest aż pięć pól pokazujących kwotę pozycji. Wynika to po prostu ze skomplikowania samej faktury, a w zasadzie korekty faktury. W przypadku dokumentu pierwotnego to jest w miarę prosto, choć na skutek rozbijania pozycji na ośrodki kosztów nieco zaburzenia powstało. Więc aby było wszystko prostsze. Tak wygląda faktura w KS-SOMED:

12 Mamy tu trzy pozycje i mnóstwo liczb. Jest więc pozycja Do zapłaty. Jest to informacja ile za dana pozycję faktury płaci kontrahent a w zasadzie na ile jest wystawiona kwota dla kontrahenta, bowiem może część płacić inny płatnik. Problem bierze się stąd, że mamy jedna pozycję którą chcemy umieścić na dwóch dokumentach dla różnych kontrahentów. Np. dla pacjent i zakładu pracy. Powstanie tylko jedna faktura, a drugi dokument to zestawienie refundacyjne, nie mniej porządek być musi. Wówczas mamy sytuację taką, że oba dokumenty mają tę samą wartość brutto pozycji, ale ich wartość do zapłaty sumuje się do wartości pozycji brutto. Że to nie mój wymysł przekona się każdy, kto analizował paragon wystawiony w aptece, paragon na leki refundowane. Tam również jest brutto 321,12 zł (na przykład) a do zapłaty 3,20 zł (czyli ryczałt). Tę właśnie wartość mamy w widoku w polu DOZA. Należy zauważyć, że każda pozycja w tym widoku odnosząca się do tej samej pozycji faktury ma tę samą wartość i jest ona wartością z pozycji faktury. Więc nie można jej sumować! Bo jeśli mamy 10 zleceń do jednej pozycji faktury, to po zsumowaniu uzyskamy 10 x za dużą wartość w stosunku do faktury. Pozycja faktury ma również wartość brutto. Na 99% będzie to zgodne z DOZA, chyba, że zajdzie przypadek opisany powyżej. Pole w widoku odpowiadające tej wartości z faktury to WPOZ. I znów, nie można sumować! Istniej również cena brutto. W widoku jest to KPOZ. I tu, rzeczywiście można by myśleć o sumowaniu pozycji, aby uzyskać prawidłowe wartości. Tyle, że istnieje możliwość wystawienia zlecenia z ilością większą niż 1. Ponieważ jest to jedno zlecenie, to nie będzie ono się rozdzielało na poszczególne ośrodki kosztów, więc w widoku będzie jedna pozycja. Więc samo sumowanie po tym polu nic nam niestety nie da! Z przyczyn bardziej już archiwalnych w widoku istnieje pozycja KZLEC. Jest to wartość zlecenia. Czyli odnajdując zlecenie związane z daną pozycją faktury właśnie taką wartość otrzymamy. I tu znów nie można sumować, bo wyjdą bzdury. A przynajmniej mogą wyjść. Co wiec nam zostało? Nowe pole VALUE które w zależności od sytuacji jest odpowiednio wyliczane. Bowiem to co napisałem wcześniej to i tak nie są wszystkie kłody, które można mieć pod nogami. Bowiem w przypadku korekty zabawa jest jeszcze lepsza. Tak wygląda korekta w KS-SOMED.

13 Czerwonym kolorem widać co się zmieniło. I tak: 1. W przypadku pozycji 1 i 3 KPOZ = 0 bowiem CSBR przed korektą i po korekcie jest takie samo! Mamy tu korektę ilościową. Wiec wartość pozycji (rozumiana jako zmiana ceny brutto) jest 0! 2. W przypadku pozycji 1 mamy zmianę ilościową, ale zmianę taką, że jedno zlecenie spada z faktury 3. W przypadku pozycji 3 mamy zmianę ilościową, ale tu nie ma spadania zlecenia, bo pozycja ma tylko jedno zlecenie i zmiana ilości zmienia ilość zlecenia. To wszystko powoduje, że chcąc zachować pola do weryfikacji z faktura papierową musieliśmy wprowadzić dodatkowe pole VALUE, służące do wskazania wartości pojedynczego wiersza w widoku lub, w przypadku korekty, do wskazania zmiany wartości pojedynczego wiersza widoku. Dla dokumentów pierwotnych VALUE wyliczamy: DECODE(P.ILSC,1,P.CSBR,DECODE(P.CSBR - PL.KWOT, 0, P.CSBR, P.CSBR*P.ILSC)) AS VALUE DECODE(D.ZALI,0, DECODE(P.ILSC,1,P.CSBR,DECODE(P.CSBR - 1, 0, P.CSBR, P.CSBR*P.ILSC)), DECODE(P.ILSC,1,P.DOZA,DECODE(P.CSBR - PL.KWOT, 0, P.DOZA/P.ILSC, P.DOZA))) AS VALUE, Już nie, gdyż taka postać VALUE źle zwracała wartości dla zaliczek. Po zmianie mechanizmu fakturowania możliwe jest poprawne wyliczenie wartości zaliczki na fakturze na poszczególną pozycję ośrodka kosztów! czyli jeśli ilość jest 1 to po prostu zwracamy cenę pozycji

14 w przeciwnym razie musimy rozstrzygnąć, czy mamy pozycję o ilości <> 1 bo jest to zlecenie z ilością wówczas w widoku będzie tylko jednak pozycja, czy też mamy do czynienia ze zleceniami scalonymi pod jedną pozycję faktury. Możemy to wywnioskować porównując cenę pozycji faktury i wartość z PLAT. W przypadku zleceń z ilością > 1 w PLAT jest to wymnożone. Wówczas zwracamy o dla zleceń z ilością 1 - cenę pozycji faktury, tak, by było możliwe sumowanie o dla zleceń z ilością <> 1 cenę pozycji pomnożoną przez ilość czyli wartość pozycji faktury. No bo w widoku będzie tylko jedna pozycja w przypadku zaliczek jest podobnie, tylko że wykorzystujemy zamiast CSBR DOZA, gdyż to pole zawiera informację na jaką wartość poszła zaliczka. Uwaga, w przypadku zaliczek możemy mieć do czynienia z dzieleniem przez ilość. Jeśli więc wystawiono zaliczkę na 3 identyczne usługi po 10 zł i wpłacono zaliczkę 20 zł, to pole value zwróci na ile oracle pozwoli. Należy więc ostrożnie z sumowaniem pozycji i stwierdzaniem, czy wszystko jest poprawnie. Zaleca się w takim przypadku przekonać, że wystawianie faktur zaliczkowych ok., ale tylko na jedną pozycję! Jeśli mamy do czynienia z korektą wówczas VALUE wyliczamy jako: DECODE(M.ILSC1 - M.ILSC2,0,DECODE(M.ILSC1,1,M.CSBR2-M.CSBR1,DECODE(M.CSBR2- PL.KWOT,0,M.CSBR2-M.CSBR1,M.ILSC1*(M.CSBR2-M.CSBR1))),DECODE(PL.STRN,1,-M.CSBR1, - M.CSBR1*(M.ILSC1-M.ILSC2))) AS VALUE, W tym przypadku musimy ustalić, czy mamy do czynienia z korektą ilościową, czy wartościową. W przypadku korekty wartościowej musimy ustalić, czy mamy do czynienia z korektą pozycji o ilości <> 1 będącą jednym zleceniem. o dla ilości 1 mamy sprawę jasną. Zwracamy więc różnicę ceny pozycji o dla ilości <> 1 sprawdzamy, czy były to zlecenia z ilością 1 wówczas zwracamy różnicę ceny pozycji, bo w widoku pozycja zostanie zreplikowana albo jeśli jest to jedno zlecenie zwracamy różnice ceny pomnożoną przez ilość W przypadku korekty ilościowej sprawdzamy, czy pojawiły nam się pozycje ze STRN=1, świadczy to o tym, że są to zlecenia, które spadły z faktury. o jeśli to spadające zlecenia zwracamy po prostu cenę pozycji. Ponieważ cena jest dodatnia, zmieniamy znak o jeśli to zwykłe zlecenie ( zlecenie z ilością <> 1) ze zmianą ilości zwracamy cenę pozycji pomnożonej przez zmianę ilości. Uwaga, o ile w przypadku dokumentów pierwotnych oraz tradycyjnych korekt widok powinien zwracać poprawne wartości nawet na dokumentach wystawionych poprzednimi wersjami KS- SOMED, o tyle sytuacje zleceń z ilością <> 1 nie będą poprawnie obsługiwane. Nie da się tego po prostu zrobić, bez zmiany mechanizmu fakturowania. Dopiero więc na wersji systemu z nowym fakturowaniem (a dokładnie z nowym korygowaniem faktur) możliwe będzie uzyskanie dokumentów poprawnie widocznych w tym widoku. Z doświadczenia wiem jednak, że przypadki te są marginalne. Zlecenie z ilością > 1 to bardzo rzadki gość w systemie KS-SOMED.

15 Raporty fiskalne dobowe fiskalne Raporty fiskalne dobowe istnieją już jako normalne byty, to znaczy są zapisywane w bazie tak jak faktura i tak samo są wystawiane. W przypadku zafakturowania zlecenia, które było na raporcie dobowym, faktura z tymże zleceniem ma specjalny typ dokumentu różniący się tym, że zamiast SSxxx mamy SFxxx. W przypadku skorygowania faktury, nic się nie dzieje, korekta faktury nie wyzwala korekty raportu dobowego, należy rozliczać takie sytuacje normalnymi korektami. W przypadku skorygowania sprzedaży (dokładnie: wycofania opłaty i usunięcia zlecenia!!!) jeśli ta sprzedaż nie była fakturowana generuje korektę raportu dobowego. Korekty raportów dobowych generują się automatycznie wraz z wykonaniem najbliższego raportu dobowego dla tej drukarki fiskalnej, na której zafiskalizowano sprzedaż.