Rozrachunki Amazon i Subiekt GT

Najpierw po numerze rozliczenia w tytule przelewu, potem po kwocie, walucie i dacie wypłaty w oknie od dwóch dni przed do sześciu dni po.

Raport czyta z Subiekta dokumenty sprzedaży (FAKTURA SPRZEDAZY, KOREKTA SPRZEDAZY, PARAGON). Zwroty (ZW) i zamówienia (ZK) nie są w tym przebiegu czytane. Zwrot do paragonu pomniejsza sumę dokumentów zamówienia, a zamówienia (ZK) to obieg magazynowy, do rozliczenia z Amazonem nie wchodzą.

Nadpłaty, niedopłaty, zwroty bez korekty i kwoty nieporównywalne - status każdego wiersza stoi w kolumnie Status. Paragon w złotówkach przy zamówieniu w euro jest przeliczany tym kursem, którym księgowany jest sam dokument (kurs z jego uwag), a gdy dokument kursu nie podaje - średnim kursem NBP z ostatniego dnia roboczego przed datą dokumentu; użyty kurs widać przy numerze dokumentu, a w arkuszu stoi w osobnej kolumnie razem z kwotą sprzed przeliczenia. Kolumny Dokument i Różnica zostają puste tylko wtedy, gdy kursu na ten dzień nie ma albo kwota dokumentu jest niepewna: wtedy różnicy nie ma z czego policzyć, a numer dokumentu stoi obok.

Zamówienia w euro rozliczone paragonem w złotówkach. Kwoty schodzą się co do kursu: zostają grosze z zaokrągleń po przeliczeniu paragonu na walutę zamówienia. Kolumna Różnica pokazuje ile dokładnie, a użyty kurs stoi przy numerze dokumentu. Większa rozbieżność (ponad 1% kwoty zamówienia) nie trafia tutaj, tylko wyżej, do różnic kwotowych.

Pozycji: 77, razem -1 343,26 EUR, -1 137,73 PLN

Pozycji: 6, razem -295,10 EUR

Pozycji: 2, razem 0,00 EUR

Pozycji: 1, razem -96,40 EUR

Wbudowane zestawienia Subiekta pokazują wartości przeliczone na złotówki, a waluta i kurs stoją w osobnych kolumnach — więc „brutto 21 543,20 / EUR / 4,28” nie musi znaczyć 21 543,20 EUR. Zgadywać tego nie można: pomnożenie kwoty złotowej przez kurs daje liczbę cztery razy za dużą i wygląda wiarygodnie. Dlatego rozstrzygają to dane — które czytanie kwoty zgadza się z kwotami z Amazona. Jeśli źródło podaje obie kolumny, nie ma czego ustalać i program bierze je wprost.

Amazon płaci osobno za każde rozliczenie, a z konta walutowego pieniądze wychodzą jednym przelewem i dopiero on jest przewalutowany. Dlatego kurs banku dotyczy całej paczki wpłat, a nie pojedynczej wpłaty. Konto jest wymiatane do zera, więc przelew zabiera cały dostępny stan: jeśli zostanie grosz, wychodzi z następnym przelewem — kolumny „zostało” pokazują właśnie to. Paczka z uwagą nie dostaje kursu, bo nie wiadomo, który przelew wyprowadził które wpłaty.

Kurs z dokumentu jest ten, który Subiekt zapisał przy wystawieniu. Kurs banku pochodzi z wyciągu: albo wprost z przewalutowanej wpłaty, albo z przelewu zbiorczego, w którym ta wpłata wyszła. Różnica to odjęcie dwóch kwot w złotówkach, czyli tego, co zaksięgowane, a nie iloczyn samej różnicy kursów: przy mnożeniu wprost wychodzi czasem grosz mniej, bo obie kwoty są zaokrąglone osobno. Obie kolumny stoją obok, więc rachunek da się sprawdzić.

Kursu nie zgadujemy. Dopóki wpłata nie jest rozstrzygnięta albo nie ma kursu w wyciągu, dokument czeka tutaj i nie wchodzi do wyniku z wymyśloną liczbą.

Gdy pasuje więcej niż jeden kandydat, program nie wybiera nic. Sprawa trafia tutaj razem ze wszystkimi kandydatami i powodem, dla którego nie da się zdecydować automatycznie. Wybór ma podjąć człowiek, nie algorytm.

Starsze paragony nie mają order-id, więc szukamy zamówienia po kwocie, walucie i dacie. Jeden kandydat wiążemy od razu, kilku trafia do kolejki wyżej, a te bez żadnego kandydata zostają tutaj i nie znikają po cichu.

Pole własne dokumentu ma id z Sellasist, ale Sellasist nie zna dla tego zamówienia numeru Amazona - to sprzedaż z innego kanału (Allegro, Empik, Erli, IdoSell). Takie dokumenty nie dotyczą rozliczeń Amazona, więc nie są dopasowywane i nie leżą na liście wyżej.

Arkusz powiazania.csv czytany przy każdym przebiegu: wpisana raz decyzja obowiązuje w każdym kolejnym uruchomieniu i o to samo nie pytamy drugi raz. Wzór do wypełnienia leży w plikach do pobrania.

Nic nie ginie po cichu: pozycja nieznanego typu nadal wchodzi do sumy kontrolnej rozliczenia i czeka tutaj na decyzję, do której kategorii należy.

Kraj konsumpcji, stawka i status nabywcy pochodzą z raportu transakcji VAT, nie z rozliczenia. Sprzedaż i zwroty stoją osobno, a obok nich wynik netto, który idzie do deklaracji. Ostatnia kolumna mówi, ile z tych zwrotów dotyczy sprzedaży z wcześniejszego okresu: ta sama kwota stoi niżej w tabeli korekt, więc nie należy odejmować jej drugi raz.

Podatek bierzemy z raportu, obok stoi podstawa pomnożona przez stawkę. Różnica nie musi być błędem: wysyłka bywa opodatkowana inaczej niż towar, dochodzą promocje i zaokrąglenia pojedynczych wierszy. Ma być widoczna, a nie ukryta w jednej liczbie.

Zwroty, których sprzedaż poszła w innym kwartale albo nie ma jej w raporcie transakcji VAT. Takie pozycje zmniejszają bieżącą deklarację, a dotyczą okresu już rozliczonego.

Sam numer VAT nabywcy nie przesądza o B2B. Liczy się schemat rozliczenia podatku i to, kto podatek odprowadza: przy dostawie uznanej robi to marketplace i transakcja nie wchodzi do naszej deklaracji OSS.

Program chodzi codziennie sam, więc błąd musi być widoczny tutaj, a nie tylko w logu. Błąd jednego pliku nie przerywa przebiegu: pozostałe wchodzą normalnie, a ten wraca do kolejki poniżej.

Rozliczenia Amazon wystawia sam, więc program tylko listuje gotowe i bierze te, których jeszcze nie ma: numer raportu zostaje w bazie, dlatego drugie uruchomienie tego samego dnia nie pobiera niczego po raz drugi. Raport transakcji VAT jest zamawiany na okres i pobierany, gdy Amazon go przygotuje.

Czas liczenia kończy się w chwili, gdy raport idzie do zapisu, więc ostatnia linia w pliku logu pokazuje więcej: dochodzi zapis strony, plików CSV i skoroszytu. Kod wyjścia programu: 0 wszystko wczytane, 3 raport gotowy, ale były problemy, 4 inny przebieg jeszcze trwał. Harmonogram zadań może po tym poznać, że coś wymaga uwagi.

Klucz każdego wiersza wynika z jego treści i po tym kluczu wiersz wchodzi do bazy tylko raz. Drugie uruchomienie tego samego pliku pokazuje zero nowych wierszy.