Przykład 1

Typ importu T1 zawiera konfigurację dla trzech typów operacji. Informacje te widzimy w nowym szczególe Konfiguracja dla typów operacji. Wpisy te zawierają następujące ustalenia:

• Transakcje sprzedaży T mają być księgowane przy użyciu symbolu konta i symbolu rozrachunku ustalanych z zamówień utworzonych za pośrednictwem BaseLinkera (sposoby ustalania wartości BL.Zam.Kh.Konto – Zwraca Konto rozrachunkowe kontrahenta z zamówienia podpiętego do płatności i BL.Zam.Numer – Zwraca Numer zamówienia podpiętego do płatności) i opisu będącego złożeniem frazy Zapłata za i identyfikatora operacji.
• Dla zwrotów Z konto i rozrachunek wyliczane powinny być za pomocą niestandardowych sposobów Zwrot1.Konto i Zwrot1.Numer wyszukujących dane zamówienia, którego dotyczy zwrot, zaś opis brany jest bezpośrednio z opisu operacji.
• Opłaty O księgowane mają być na stałe konto 202/000134 z identyfikatorem operacji jako symbolem rozrachunku i opisem przeniesionym bezpośrednio z operacji.
• Zarówno kwoty samych operacji, jak i prowizje będą uwzględniane bez zmiany znaku w nagłówku importowanego zbioru.

W ramach T1 importujemy transakcje w PLN. W nagłówku konfiguracji typu importu T1 widać, że księgowanie ma się odbywać przy użyciu schematu EC_P – Rozliczenie importu płatności e-commerce w PLN, a konto docelowe dla kwoty przelewu od operatora jest ustalone na stałe na 200/000134, natomiast dla prowizji dla operatora – odpowiednio na 202/000134. Obie kwoty jako symbol rozrachunku będą miały przypisany identyfikator rozliczenia (zaimportowanego zbioru operacji). Opisy linijek ustalane są za pomocą sposobów PrzelewZa.IdRozl i ProwizjaZa.IdRozl zwracających identyfikator rozliczenia poprzedzony odpowiednim przedrostkiem.

Rys. Konfiguracja typu importu T1 dla przykładu 1

Zaimportowane zostaną pliki z pokazaną niżej zawartością. Widać, że oprócz operacji T, Z i O, dla których istnieje konfiguracja, pliki zawierają także operacje W – wypłaty od operatora płatności na nasz rachunek bankowy. Nie chcemy jednak używać bezpośrednio danych z tych operacji, posłużą one tylko informacyjnie. Wiemy, że wypłata jest ostatnią operacją w zbiorze i jej kwota powinna pokryć się z sumą pozostałych operacji.

Rys. Zawartość dwóch importowanych plików w ramach przykładu 1

Po zaimportowaniu pierwszego pliku widać, że ustalone zostały wartości dla kont, rozrachunków i opisów zgodnie z konfiguracją i teraz trzy operacje sprzedaży mają zaznaczony znacznik Przetwarzaj, dzięki czemu mogą zostać zsumowane w nagłówku (są sumowane, ponieważ tak są skonfigurowane operacje T) oraz że będą uwzględniane podczas księgowania. Widać też, że jest jedna operacja W na kwotę minus 600 PLN, ale nie będzie ona dalej przetwarzana.

W nagłówku słownika buforowego widać, iż nasz zbiór operacji ma identyfikator Z0 i że suma trzech operacji T daje łącznie kwotę płatności 600 PLN (czyli pokrywa się z kwotą operacji wypłaty minus 600 PLN), a kwota prowizji to minus 12 PLN. Mamy tutaj też uwidocznione opisy, jakie zostały ustalone dla księgowania tych kwot.

Rys. Dane po zaimportowaniu pierwszego pliku dla przykładu 1

Rozliczenie pierwszego pliku powoduje wygenerowanie dowodu PK/010/23/1 na podstawie zaimportowanych danych. Utworzony dowód zawiera faktycznie księgowania zgodne z konfiguracją. Operacje T trafiły na konto 200% po stronie Ma, rozliczając należności za zamówienia/faktury. Kwota prowizji trafiła na konto 202 operatora płatności po stronie Wn, rozliczając nasze zobowiązanie względem niego. Kwota przelewu widnieje po stronie Wn konta 200 operatora płatności, tworząc należność od operatora (która będzie rozliczona za pomocą dowodu wpłaty z wyciągu bankowego). Operacja W nie znalazła odzwierciedlenia w utworzonym dowodzie, gdyż w ramach konfiguracji typu importu T1 nie mamy wpisu dla tego typu operacji.

Rys. Dowód rozliczający operacje z pierwszego pliku dla przykładu 1

Import drugiego pliku zaciąga kolejne operacje, w tym zwrot Z za pewien uszkodzony przedmiot (operacja Z051) oraz opłatę O za reklamę (operacja O007). Zgodnie z konfiguracją operacji opłaty przypisane zostało konto 202/000034, a zwrot otrzymał konto i rozrachunek za pomocą niestandardowych sposobów. W przypadku zwrotu w polu Operacja pierwotna widać identyfikator operacji T, której ten zwrot dotyczy i który jest pomocny przy ustalaniu wartości konta i rozrachunku.

W nagłówku importu o identyfikatorze Z1 mamy sumę wszystkich operacji z wyjątkiem wypłaty W. Łączna kwota płatności to 950 PLN, a kwota prowizji to 20 PLN. Na przelewie od operatora spodziewamy się kwoty 930 PLN (co widać w danych operacji W), jest to zgodne z różnicą kwot widocznych w nagłówku słownika.

Rys. Dane po zaimportowaniu drugiego pliku dla przykładu 1

W efekcie rozliczenia zbioru Z1 przy użyciu schematu księgowania EC_P uzyskujemy dowód o numerze PK/010/23/2. Kwota przelewu oraz kwota prowizji zaksięgowały się w ten sam sposób, jak dla pierwszego pliku. Zapłaty za sprzedaż również tak samo – na konto 200% po stronie Ma, rozliczając należności od kupujących. Kwota zwrotu księgowana jest również na koncie 200% po stronie Ma, ale ze znakiem przeciwnym – pozostając w ramach tego samego rozrachunku dotyczącego sprzedaży zwracanego przedmiotu. Opłata za reklamę zaksięgowana została ze znakiem minus po stronie Ma na koncie 202%, rozliczając zobowiązanie względem operatora płatności.

Rys. Dowód rozliczający operacje z drugiego pliku dla przykładu 1

W powyższym przykładzie nie przetwarzaliśmy operacji wypłat W. Kwota przelewu księgowana na dowodzie rozliczającym wyliczana była z kwot pozostałych operacji. Wypłata pozostała natomiast w ewidencji i mogliśmy użyć jej kwoty w celu weryfikacji.

Przykład 2

Konfiguracja typu importu T2 określa, jak przetwarzać aż sześć typów operacji: K – kaucje, KZ – zwroty kaucji, O – opłaty, T – sprzedaż, W – wypłaty i Z – zwroty. Kwoty wszystkich tych operacji będą sumowane w nagłówku. Sam nagłówek określa zaś, że przelew i prowizja będą księgowane na specjalnym koncie 180/01 odwzorowującym stan środków na naszym rachunku u operatora płatności. Do księgowania użyty zostanie standardowy schemat księgowania EC_P – Rozliczenie importu płatności e-commerce.

Rys. Konfiguracja typu importu T2 dla przykładu 2

W ramach przykładu zaimportowane zostaną dwa pliki z zawartością przedstawioną poniżej. W pierwszym pliku w szczególności mamy pobranie kaucji przez operatora płatności. W drugim pliku jest zwrot pobranej kaucji oraz wiele różnych operacji.

Rys. Zawartość dwóch importowanych plików dla przykładu 2

Import pierwszego pliku powoduje utworzenie importu Z10 zawierającego operacje T z danymi wyliczonymi tak samo jak w przykładzie 1. Poza tym jest operacja K – pobranie kaucji przez operatora, której, zgodnie z konfiguracją, przypisane zostało stałe konto 203/000134, stały opis „Pobranie kaucji”, a jako symbol rozrachunku system nadał identyfikator rozliczenia zbioru (sposobem IdRozl – Zwraca identyfikator rozliczenia zbioru danych). Import nie zawiera żadnej operacji wypłaty W.

Suma wszystkich czterech operacji w nagłówku daje łączną kwotę 1500 PLN oraz minus 50 PLN z prowizji. Opisy dla kwoty przelewu i prowizji widoczne w nagłówku słownika zostały wyliczone sposobami SaldoOperZa.IdRozl – Zwraca opis „Saldo operacji z” + {Identyfikator rozliczenia}. i ProwizjaZa.IdRozl – Zwraca opis „Prowizja za” + {Identyfikator rozliczenia}, a jako konto przyjęte zostało 180/01.

Rys. Dane po zaimportowaniu pierwszego pliku dla przykładu 2

Rozliczenie zaimportowanego pliku Z10 powoduje wygenerowanie dowodu PK/010/23/3. Operacje sprzedaży księgują się tak jak w przykładzie 1. Kwota operacji K, czyli kaucja, księguje się z minusem na wskazanym koncie 203/000134 po stronie Ma. Wszystkie operacje poza kaucją posiadały kwotę prowizji. Suma tych kwot w wysokości 50 PLN księgowana jest po stronie Wn na specjalnym koncie 180/01 z opisem „Prowizja za Z10”. Jeśli będziemy chcieli rozliczyć fakturę od operatora, trzeba będzie przeksięgować tę kwotę z konta 180/01 na konto rozrachunku z owej faktury.

W linijce numer pięć mamy 1450 PLN zaksięgowane również na koncie 180/01 z opisem „Saldo operacji z Z10”. Jest to kwota, którą spodziewamy się otrzymać od operatora płatności, kiedy w przyszłości dokona on przelewu. W tym przykładzie nie mamy jednak założenia, że każdy plik jest skojarzony z przelewem od operatora. Taka sytuacja może wystąpić, jeśli np. sami generujemy ten plik ze strony operatora co jakąś ilość dni lub gdy pobieramy dane z dowolnego zakresu dni z systemu web service. Czyli spodziewamy się przelewu, ale niekoniecznie na dokładnie taką kwotę, jaka wychodzi z danego zakresu dni (bo przelew może być za inny okres). W związku z tym w momencie otrzymania przelewu, a właściwie zaksięgowania wyciągu, zaistnieje potrzeba wyksięgowania z konta 180/01 tej kwoty. W ten sposób w dowolnym momencie saldo na koncie 180/01 będzie prezentowało stan naszych środków na naszym rachunku u operatora płatności.

Rys. Dowód rozliczający operacje z pierwszego pliku dla przykładu 2

Import drugiego pliku powoduje zarejestrowanie importu Z11, a w nim różnych operacji. Widzimy, że wśród nich są dwie wypłaty W, którym przypisane zostało stałe konto 200/000134, a rozrachunek stanowi identyfikator operacji (sposób IdOper – Zwraca Identyfikator operacji (płatności) z ewentualnym prefixem i postfixem). Mamy również zwrot kaucji KZ, którego konto i rozrachunek wyliczone zostały sposobem Kaucja. Sposób ten zwraca dane wpłaconej operatorowi kaucji z poprzedniego importu. Dane te powinny zatem pokrywać się z danymi operacji K z pierwszego pliku. Powstały również wpisy dla operacji zwrotów Z. Dla typu importu T2 zostały one skonfigurowane inaczej niż w przykładzie 1 i tworzą one odrębne rozrachunki (nie szukamy rozrachunku zamówienia, którego dotyczy zwrot). Ponadto mamy operacje T, O oraz K, które są skonfigurowane identycznie jak w przykładzie 1.

W nagłówku importu mamy sumę kwot operacji i kwot prowizji ze wszystkich operacji, łącznie z wypłatami – po to, aby utrzymać znaczenie używanego konta 180/01 prezentującego aktualny stan środków na naszym rachunku u operatora.

Rys. Dane po zaimportowaniu drugiego pliku dla przykładu 2

Dowód PK/010/23/4 otrzymany w wyniku rozliczania importu Z11 zawiera takie jak poprzednio księgowania operacji T, O oraz K. Operacja KZ, czyli zwrot kaucji, księgowany jest na konto 203/000134 z symbolem rozrachunku Z10, czyli trafia dokładnie w rozrachunek utworzony przez kaucję z poprzedniego pliku. Zwroty tworzą odrębne rozrachunki, ale trafiają, podobnie jak sprzedaż, na konto 200% po stronie Ma, z ujemną kwotą.

Wypłaty zaksięgowane zostały po stronie Wn na konto 200/000134, na którym też spodziewamy się ewidencji rozrachunków związanych z wpłatami od operatora z księgowanych wyciągów bankowych. Prowizja i saldo operacji zbioru Z11 trafiły, tak jak wcześniej, na konto 180/01 i ciągle konto to przedstawia aktualny stan naszych środków u operatora.

Rys. Dowód rozliczający operacje z drugiego pliku dla przykładu 2

Powyższy przykład zawierał import z konfiguracją wielu operacji, w tym także wypłat W. Operacje te są tu traktowane niejako na równi z innymi – dla każdej operacji powstaje jedna linijka w dowodzie rozliczającym. Po przeciwnej stronie dla zbilansowania księgujemy saldo z tych wszystkich operacji (z uwzględnieniem sumy prowizji zaksięgowanej na oddzielnej linijce). Takie podejście uniezależnia ewidencjonowanie zbioru operacji z dowolnego zakresu dat od wpłat przychodzących od operatora płatności.

Przykład 3

Konfiguracja typu importu T3 definiuje przetwarzanie operacji typu T i Z. Na potrzeby księgowania kwoty salda oraz prowizji wskazuje specjalne konto 182/01. W tym przypadku zakładamy, że kwoty operacji są w walucie obcej. Do księgowania używany będzie schemat księgowania EC_WL – Rozliczenie importu płatności e-commerce w walucie.

Rys. Konfiguracja typu importu T3 dla przykładu 3

Na potrzeby przykładu zaimportowany zostanie plik zawierający przedstawione niżej dane. Kwoty operacji są w walucie EUR, kurs nie został podany w pliku. Zastosowany zostanie średni kurs NBP z dnia poprzedzającego datę operacji.

Rys. Zawartość importowanego pliku w ramach przykładu 3

Po zaimportowaniu otrzymujemy import z identyfikatorem rozliczenia Z31 zawierający operacje T i Z, których dane (konta, rozrachunki, opisy) zostały wyliczone analogicznie jak w poprzednich przykładach. Tym, co wyróżnia ten import, są kwoty w walucie EUR. W nagłówku słownika zsumowano wartości wszystkich operacji oraz prowizji.

Rys. Dane po zaimportowaniu pliku dla przykładu 3

Rozliczając import Z31 otrzymujemy dowód o numerze PK/010/23/5, w którym każda operacja zbioru została zaksięgowana w postaci trzech linijek. W każdej mamy kwotę w walucie EUR oraz w PLN przeliczoną po średnim kursie NBP z dnia poprzedzającego dzień operacji. Wartość operacji jest ewidencjonowana na koncie 200% po stronie Ma, rozliczając należność wynikającą ze sprzedaży. Natomiast po stronie Wn mamy na koncie 182/01 dwa dekrety. Jeden z kwotą prowizji za daną operację, a drugi z kwotą operacji pomniejszoną o prowizję. W ten sposób na koncie 182/01 będziemy mieli odwzorowany aktualny stan naszych środków na rachunku u operatora płatności. Każda linijka w opisie ma wskazanie na identyfikator operacji, dzięki czemu łatwo zorientować się, które trzy linijki dotyczą tej samej operacji. Oczywiście kwoty zwrotów księgowane są ze znakiem minus.

Rys. Dowód rozliczający operacje z pliku dla przykładu 3

Powyższy przykład przedstawia możliwość importu danych walutowych z użyciem standardowego schematu księgowania EC_WL.