Fakturnia Developers Szybki start Dokumentacja API English

Dziennik zmian

API jest wersjonowane w ścieżce (/external/v1). Zmiany łamiące zgodność są wprowadzane w nowej wersji głównej; zmiany addytywne (nowe pola, nowe punkty końcowe, nowe parametry opcjonalne) są udostępniane w ramach v1. Nieznane pola odpowiedzi należy traktować jako zgodne w przód: pomijaj te, których nie rozpoznajesz.

v1 (bieżąca)

2026-10-09: faktury w procedurze marży

  • Pozycje w marży. Stawka vatRate: "marza" oznacza pozycję w procedurze marży (art. 119 i 120 ustawy o VAT): faktura pokazuje tylko kwoty brutto, w KSeF pozycja nie ma P_12, a suma trafia do P_13_11. Dokument musi mieć annotations.marginProcedure (inaczej 422 MARGIN_LINE_WITHOUT_PROCEDURE). Pozycje w marży i ze zwykłymi stawkami mogą być na jednej fakturze.
  • Kwota nabycia i VAT od marży. Nowe pola pozycji marginPurchaseValue (kwota nabycia brutto w PLN) i marginTaxRate (23, 8, 5, 0) w POST, PUT i PATCH /documents oraz w odpowiedziach GET /documents/{id}. Nie trafiają na fakturę ani do KSeF; z nich powstają marża i VAT od marży w rejestrze VAT i JPK_V7. Nowe kody: 422 MARGIN_TAX_RATE_INVALID, 422 MARGIN_PURCHASE_INVALID. Przewodnik: Procedura marży.
  • Kwota nabycia po wystawieniu. PATCH /documents/{id}/margin-purchases (scope documents:update, narzędzie MCP updateDocumentMarginPurchases) ustawia kwotę nabycia i stawkę VAT od marży pozycji w marży także po wysyłce do KSeF. Kody 422 MARGIN_LINE_NOT_FOUND i 422 MARGIN_PURCHASES_INVALID. PUT i PATCH /documents/{id} bez pól marży przy pozycji zostawiają zapisane wartości.
  • Sprzedaż w marży w podglądzie. POST /documents/validate zwraca preview.totals.marginSaleSum (sprzedaż w marży zawarta w netSum, w KSeF P_13_11), a narzędzie MCP prepareDocument podaje w podsumowaniu netto zwykłych stawek osobno od sprzedaży w marży. Zapisany netSum nie zmienia znaczenia.
  • Korekta faktury marżowej pobranej z KSeF. Faktura sprzedaży w procedurze marży wystawiona w innym programie (pozycje bez P_12, suma w P_13_11) ma po odczycie pozycje ze stawką marza i można do niej wystawić korektę. Kod 422 CORRECTED_INVOICE_MARGIN_LINES zostaje tylko dla pozycji bez stawki na fakturze bez adnotacji procedury marży.

2026-10-09: korekta faktury sprzedaży pobranej z KSeF

  • Korekta faktury wystawionej poza Fakturnią. POST /documents przyjmuje w correctedInvoiceId fakturę sprzedaży pobraną z KSeF (source: "ksef", direction: "income", typ FakturaVAT). API czyta jej pozycje, sumy i adres nabywcy z XML faktury (pobierając go z KSeF, gdy trzeba), liczy korektę jako różnicę i w KSeF wskazuje numer KSeF faktury pierwotnej. Nowe kody: 422 CORRECTED_INVOICE_NOT_INCOME, 422 CORRECTED_INVOICE_WITHOUT_POSITIONS; CORRECTED_INVOICE_TYPE_MISMATCH obejmuje też importy innych typów. Przewodnik: Korekty.
  • Pozycje faktur pobranych z KSeF. GET /documents/{id} faktury pobranej z KSeF zwraca products, netSum i vatSum, gdy jej XML został już odczytany (po otwarciu w aplikacji albo po wystawieniu korekty); wcześniej takie faktury miały tylko grossSum.

2026-10-09: identyfikatory kontrahenta zgodne z KSeF

  • Jedne zasady identyfikatorów dla kontrahentów i stron dokumentu. POST i PUT /clients oraz nabywca i odbiorca podani danymi w POST /documents, POST /documents/validate, PUT i PATCH /documents/{id} zapisują identyfikatory w postaci, którą przyjmie KSeF: NIP jako 10 cyfr, numer VAT UE z prefiksem kraju w vatUE (Grecja EL), other z krajem. Przewodnik: Identyfikatory kontrahenta.
  • Numer VAT UE wpisany w nip trafia do vatUE. Bez identifierType numer DE123456789 w nip jest zapisywany jako vatEu w vatUE z countryCode z prefiksu, a nie jako NIP.
  • Ostrzeżenia data.warnings. Odpowiedzi kontrahentów i dokumentów (także validate) mówią, jak odczytano identyfikatory: ustalony typ, przeniesiony numer, ustalony kraj (code, field, message). Narzędzie MCP prepareDocument zwraca je w identifierNotes.
  • Sprzeczne dane są odrzucane. Kontrahenci: 422 VALIDATION_ERROR, dokumenty: nowy kod 422 PARTY_IDENTIFIER_INVALID, zawsze z nazwą pola. Dotyczy to też NIP-u z błędną cyfrą kontrolną podanego bez identifierType (wcześniej przyjmowanego) oraz identyfikatora idWew w innej postaci niż NIP-NNNNN.
  • Dane zapisane wcześniej pozostają edytowalne. Identyfikatory równe zapisanym nie są ponownie sprawdzane przy PUT /clients ani przy PUT i PATCH dokumentu.

2026-10-09: daty FA(3), raty, kilka wpłat zaliczki, dzień wpłaty

  • Okres sprzedaży: subDateTo. Z subDate jako początkiem daje OkresFa w KSeF (np. usługa za cały miesiąc). PATCH zachowuje zapisany okres i nagłówek daty.
  • Kurs waluty z dniem i tabelą NBP: exchangeRateDate, exchangeRateTable. Kurs faktury to kurs z dnia roboczego przed obowiązkiem podatkowym, a gdy faktura jest wcześniejsza, przed datą wystawienia (art. 31a ustawy o VAT). Korekta bez exchangeRate przejmuje kurs, dzień i tabelę faktury korygowanej (art. 31b ust. 1).
  • Obowiązek podatkowy z datą wystawienia: taxPointRule. Dla usług budowlanych, książek i prasy, mediów, telekomunikacji, najmu, leasingu, ochrony i stałej obsługi (art. 19a ust. 5 pkt 3 i 4). Decyduje o okresie w raportach VAT i o dniu kursu. Gdy konto ma włączone ustawienie z domyślną regułą, dokument bez taxPointRule dostaje ją z ustawień (preview.appliedDefaults: TAX_POINT_RULE); useAccountDefaults: false albo jawne null ją pomija.
  • Raty i termin opisowy: paymentInstallments, paymentDeadlineTerm. Kilka terminów z kwotami albo termin w rodzaju „14 dni od doręczenia faktury”; w KSeF TerminPlatnosci i TerminOpis. Błędne raty: 422 PAYMENT_INSTALLMENTS_INVALID. Przewodnik: Tworzenie dokumentów.
  • Równe raty liczone przez API: paymentInstallmentsSplit. POST, PUT i PATCH /documents oraz POST /documents/validate przyjmują { count, firstDate?, every? }; API dzieli kwotę do zapłaty co do grosza (reszta w ostatniej racie) i zapisuje zwykłe paymentInstallments. Podgląd validate pokazuje raty w preview.paymentInstallments, a narzędzia MCP prepareDocument i patchDocument przyjmują to samo pole. Przewodnik: Tworzenie dokumentów.
  • Kilka wpłat na fakturze zaliczkowej: advanceReceipts. Każda wpłata z datą, kwotą i kursem; w KSeF ZaliczkaCzesciowa. Błędne wpłaty: 422 ADVANCE_RECEIPTS_INVALID.
  • Daty korekty: correctionEffectDate, correctionConfirmationDate. Dzień, od którego korekta działa (zwiększenie po sprzedaży z przyczyną w innym miesiącu daje TypKorekty 3), i dzień potwierdzenia przez nabywcę korekty wystawionej poza KSeF. Korekta bez subDate przejmuje datę albo okres sprzedaży faktury korygowanej. Przewodnik: Korygowanie dokumentów.
  • Dzień wpłaty przy oznaczaniu zapłaty. PATCH /documents/{id}/payment-status przyjmuje paymentDate (domyślnie dzisiejszy dzień w Polsce, nie z przyszłości); GET zwraca go w payment.receivedPaymentDate. Przy metodzie kasowej to dzień obowiązku podatkowego.
  • Daty sprawdzane jak w aplikacji: 422 DOCUMENT_DATES_INVALID. Okres sprzedaży z początkiem po końcu, data sprzedaży ponad 60 dni po wystawieniu, data zapłaty późniejsza niż wystawienie, korekta wystawiona przed fakturą korygowaną. PUT i PATCH sprawdzają też format dat.
  • KSeF: więcej dat w XML. Miejsce wystawienia (P_1M), raty i termin opisowy, wpłaty zaliczki. Data z godziną to dzień w Polsce, a nieczytelna data jest błędem walidacji zamiast dzisiejszej.

Wszystkie nowe pola są opcjonalne: integracje, które ich nie wysyłają, działają jak dotąd.

2026-10-09: korekta korekty

  • Jedna korekta na dokument. Nowa korekta dokumentu, który ma już korektę, dostaje 409 CORRECTED_INVOICE_HAS_CORRECTION z numerem i id ostatniej korekty łańcucha w errors[0]. Kolejną zmianę wystawiasz jako korektę tej korekty, więc stan „przed” uwzględnia wcześniejsze zmiany i kwoty nie liczą ich dwa razy. Tak samo odpowiadają PUT i PATCH, gdy przepinasz korektę na dokument z inną korektą. Przewodnik: Korygowanie dokumentów.
  • Korekta korekty wskazuje w KSeF fakturę pierwotną. DaneFaKorygowanej podaje numer, datę i numer KSeF faktury pierwotnej, a nie poprzedniej korekty (Podręcznik KSeF 2.0, część II, punkt 2.13.3). Wydruk pokazuje fakturę pierwotną i poprzednią korektę.
  • Faktura pierwotna bez numeru KSeF. POST /documents/validate zwraca w preview.warnings uwagi, które nie blokują dokumentu. Na koncie połączonym z KSeF korekta, której faktura pierwotna nie ma numeru KSeF, dostaje kod CORRECTION_ORIGINAL_KSEF_PENDING, CORRECTION_ORIGINAL_NOT_SENT_TO_KSEF albo CORRECTION_ORIGINAL_OUTSIDE_KSEF. Wysyłka do KSeF działa jak dotąd. Przewodnik: Korygowanie dokumentów.
  • Korekta korekty zaliczkowej. FakturaKorygujacaZaliczkowa może korygować poprzednią korektę zaliczkową: zamówienie i zaliczka przed korektą to stan po niej.

2026-10-09: powód i typ korekty, limit przyczyny korekty

  • Powód korekty (correctionCause) i typ korekty w KSeF (correctionType). Korekta może podać, dlaczego ją wystawiasz: after_sale (zdarzenie po sprzedaży: rabat, zwrot, reklamacja) albo mistake (błąd na fakturze korygowanej). Z powodu i kwot Fakturnia wylicza TypKorekty wysyłany do KSeF, dotąd zawsze 2; correctionType (1, 2, 3) ustawia go ręcznie. Oba pola przyjmują POST, PUT i PATCH /documents, a zwracają GET /documents/{id} i webhooki dokumentów. Powód decyduje też o okresie korekty w raportach aplikacji (rejestr VAT, JPK_V7, KPiR). Integracje, które nie wysyłają nowych pól, działają jak dotąd. Przewodnik: Korygowanie dokumentów.
  • Przyczyna korekty najwyżej 256 znaków. Tyle przyjmuje KSeF w PrzyczynaKorekty. Dłuższy correctionReason dostaje teraz błąd walidacji od razu (400 przy POST, 422 przy PUT i PATCH), a nie odrzucenie przez KSeF przy wysyłce.

2026-10-02: połączenie z KSeF tokenem

  • Token KSeF jako metoda połączenia. POST /ksef/connection przyjmuje connectionType: TOKEN z token wygenerowanym w Aplikacji Podatnika KSeF albo, jak dotąd, certyfikat (connectionType: CERTIFICATE). Zapis jednej metody zastępuje drugą. GET /ksef/connection podaje connectionType, hasToken i hasCertificate.

2026-10-01: webhooki dla dokumentów z aplikacji i z KSeF, limity zapytań, unikalne numery

  • document.created także dla dokumentów z aplikacji. Dokument zapisany w aplikacji webowej albo mobilnej (także szkic i dokument magazynowy) wyzwala document.created, tak jak dokument z API, MCP albo reguły cyklicznej. Korekta wystawiona w aplikacji wyzwala też document.updated dla faktury korygowanej. Nie trzeba już okresowo czytać GET /documents, żeby zobaczyć dokumenty wystawione w aplikacji. Przewodnik: Webhooki.
  • Wystawienie szkicu w aplikacji wyzwala document.updated. To samo zdarzenie przychodzi po zamianie dokumentu z powrotem w szkic i po zmianie w aplikacji oznaczeń isSent, isPrinted i isDownloaded (także przy pierwszym wydruku albo pobraniu), zawsze tylko przy rzeczywistej zmianie. Integracja od razu wie, kiedy szkic stał się wystawionym dokumentem (isDraft: false).
  • Faktury pobrane z KSeF: document.ksefImported. Synchronizacja z KSeF zgłasza nowe faktury (zakupowe i sprzedażowe wystawione poza Fakturnią) jednym zdarzeniem z listą data.documentIds, do 100 identyfikatorów w dostawie; większy import przychodzi w kilku dostawach. Takie faktury nie wysyłają document.created.
  • source i direction w dokumentach. GET /documents i GET /documents/{id} zwracają source (local albo ksef) i direction (income, expense albo order), więc faktury zakupowej z KSeF nie pomylisz z własną sprzedażą.
  • Więcej zdarzeń z aplikacji. document.updated po potwierdzeniu albo cofnięciu wydania magazynowego, po usunięciu ostatniej korekty (dla faktury korygowanej), po wystawieniu WZ do faktury (dla faktury), po wysyłce e-mailem przez regułę cykliczną i gdy synchronizacja z KSeF dopisze numer KSeF; client.created dla kontrahenta zapisanego z danych nabywcy dokumentu z API albo MCP; client.updated po zapisaniu adresów e-mail kontrahenta.
  • Limity zapytań liczone dla aplikacji. Liczniki z tabeli w Limitach zapytań należą teraz do aplikacji (konta API), którą identyfikuje token, a nie do adresu IP, więc kilka integracji za jednym NAT-em nie dzieli już limitu. Doszedł ogólny limit 240 zapytań na minutę z jednego adresu IP, sprawdzany przed uwierzytelnieniem; zapytania z brakującym, błędnym albo wygasłym tokenem liczą się tylko do niego. Kod 429 RATE_LIMIT_EXCEEDED i nagłówki bez zmian.
  • Numer dokumentu unikalny na całym koncie. POST /documents oraz PUT i PATCH /documents/{id} zwracają 409 DOCUMENT_NUMBER_EXISTS także wtedy, gdy ten sam pełny numer ma już dokument innego typu (np. proforma i proforma bez VAT z tym samym symbolem) albo dokument przeniesiony na inny miesiąc. PUT i PATCH sprawdzają to, gdy zmieniasz numer, a komunikat w errors[0] podaje dokument, który ma ten numer.
  • Schemat dokumentu w specyfikacji OpenAPI opisuje wszystkie pola, które zwraca API: isDraft, invoiceName, externalSource, externalOrderId, externalOrderNumber, correctionAdvanceAmountAfter, correctionSettlementAmountAfter, ksefNumber, ksefReferenceNumber, ksefStatus i ksefSent. Odpowiedzi API się nie zmieniły, te pola były w nich już wcześniej.

2026-09-27 (wersja specyfikacji 1.3.0): dokumenty magazynowe i ustawienia konta

  • Dokumenty magazynowe przez API. POST /warehouse/documents wystawia WZ, PZ, PW, RW i MM z pozycjami z kartoteki i księguje ruchy; POST /warehouse/documents/validate zwraca podgląd ze stanem przed i po. Nowy scope warehouse:documents:create. Przewodnik: Magazyn.
  • Braki towaru blokują wydanie. WZ, RW i MM (także wz-from-invoice), które zeszłyby ze stanem poniżej zera, dostają 422 STOCK_SHORTAGE, jak w aplikacji; allowNegativeStock: true wystawia mimo braku.
  • WZ do faktury dostaje symbol WZ i ustawienia konta, sprawdza magazyn (422 WAREHOUSE_INVALID) i zapisuje numer WZ przy fakturze (wydruk i KSeF).
  • Wartości domyślne z ustawień konta przy tworzeniu dokumentów: uwagi, podpisy, miejsce wystawienia, automatyczne adnotacje (MPP z rachunkiem VAT, marża), podstawa zwolnienia dla stawki zw, forma i status płatności, stawka VAT pozycji, wyświetlanie PKWiU. Nowe pole useAccountDefaults, podgląd preview.appliedDefaults i preview.resolved. Przewodnik: Tworzenie dokumentów.
  • Korekty przejmują nabywcę, odbiorcę, walutę i adnotacje z korygowanej faktury; faktury z korektą, rozliczonej zaliczki i zamówienia z zaliczkami nie da się zmienić ani usunąć (409 DOCUMENT_CORRECTED, 409 ADVANCE_INVOICE_SETTLED, 400 ORDER_HAS_ADVANCE_INVOICES).
  • Faktura zaliczkowa bez pozycji (pozycje to rozkład zaliczki) i bez daty sprzedaży; proforma bez VAT ma zawsze VAT 0.
  • KSeF: procedura marży trafia do XML (P_PMarzy ze znacznikiem procedury), nieznany numer procedury jest błędem walidacji. Zwolnienie z VAT włączone bez typu albo podstawy prawnej jest odrzucane.
  • Produkty: pola magazynowe productType, sku, ean, purchasePrice w odczycie, tworzeniu i aktualizacji (aktualizacja tylko przesłanych); quantity przy tworzeniu opcjonalne.
  • Dokumenty magazynowe przez /documents: usunięcie cofa ruchy, zmiana daty je przesuwa, zmiana pozycji zwraca 409 WAREHOUSE_LINES_LOCKED. Korekta stanu z quantity: 0 i unitCost to przecena (WYCENA).

2026-09-26: serwer MCP

  • Serwer MCP dla asystentów AI. https://prod.api.fakturnia.pl/mcp (sandbox: https://sandbox.api.fakturnia.pl/mcp): ChatGPT, Claude, Claude Code i własni agenci pracują na koncie użytkownika po logowaniu OAuth 2.1 (odkrywanie RFC 9728/8414, PKCE, rejestracja dynamiczna, dokumenty client_id, rotacja refresh tokenów) albo z kluczem fmcp_…. Narzędzia generowane z tej specyfikacji plus prowadzone wystawianie dokumentu (prepareDocument, issueDocument), confirm=true na operacjach nieodwracalnych, uprawnienia pracownika, bramka planu. Przewodnik: Serwer MCP.

2026-09 (wersja specyfikacji 1.2.0)

  • REST API jest modułem planu MAX. Konta API, wszystkie endpointy /external/v1 i webhooki wymagają aktywnego planu MAX. Endpoint tokenu odpowiada 403 access_denied z error_code: SUBSCRIPTION_REQUIRED, wywołania z tokenem 403 SUBSCRIPTION_REQUIRED. Opis w Uwierzytelnianiu.
  • Stałe kody błędów w całej kopercie. 401 zwraca UNAUTHORIZED albo TOKEN_EXPIRED, 403 bez scope NO_PERMISSIONS, 429 RATE_LIMIT_EXCEEDED; zdanie wyjaśniające trafia do errors[0]. Błędy walidacji treści mają kod VALIDATION_ERROR, zwykle ze statusem 422; tworzenie dokumentów (także magazynowych) zwraca 400 przy błędach kształtu żądania, więc traktuj oba statusy jako błąd walidacji. Nowa tabela kodów w Błędach.
  • Unieważnienie konta API i lista adresów IP działają natychmiast, przy każdym wywołaniu, nie dopiero po wygaśnięciu tokenu (401 UNAUTHORIZED, 403 FORBIDDEN).
  • Webhooki: pełne zarządzanie. POST /webhooks z wyborem zdarzeń, GET/PATCH/DELETE /webhooks/{id}, rotacja sekretu, historia dostaw (/deliveries) i ping testowy (/test). Nowe scope'y webhooks:update i webhooks:delete. Przewodnik: Webhooki.
  • Webhooki: nowa treść dostawy. Każda dostawa ma id (także w nagłówku X-Webhook-Delivery) i blok data z identyfikatorem nazwanym po typie zasobu (documentId, clientId, ...). Pola resourceId/resourceIds zostały dla zgodności. Schemat WebhookEventPayload w specyfikacji.
  • Nowe zdarzenia document.ksefRejected (KSeF odrzucił dokument albo wysyłka zakończyła się błędem) i document.paymentStatusChanged (oznaczono albo cofnięto zapłatę). document.sentToKSeF przychodzi też dla wysyłek z aplikacji i z kolejki, a document.updated po powiązaniu z zamówieniem.
  • Konta pocztowe (odczyt). GET /email-accounts i GET /email-accounts/{id} ze scope'ami email-accounts:browse i email-accounts:read; bez sekretów. Przewodnik: Konta pocztowe.
  • Kompletna specyfikacja OpenAPI. Każda operacja ma opis, schemat odpowiedzi z kształtem data, schemat i przykład treści żądania oraz udokumentowane 401/403/429/500. Nowe nagłówki X-Request-ID, X-RateLimit-*, Retry-After, Idempotent-Replayed. Kolekcja Postman bierze przykłady żądań ze specyfikacji.
  • Historia przez API. GET /documents/{id}/history (dziennik dokumentu), GET /activity (aktywność całego konta, nowy scope activity:read), GET /employees/{id}/activity (aktywność pracownika) i GET /warehouse/movements (księga ruchów magazynowych). Przewodnik: Historia i aktywność.
  • Nowe odczyty po id: GET /warehouse/{id}, GET /employees/{id}; raport stanów przyjmuje productId.
  • Paginacja list, które jej nie miały: GET /recurring-rules, GET /recurring-rules/{id}/history i GET /webhooks/{id}/deliveries zwracają currentPage, itemsPerPage, totalCount, totalPages (limit nadal działa jako alias itemsPerPage).
  • Listy do 100 pozycji na stronę (itemsPerPage, wcześniej 20) w GET /documents, /clients, /products.
  • Usuwanie zwraca data.id także dla dokumentów, kontrahentów i produktów; DELETE /documents/{id}/external-reference zwraca wyczyszczone pola powiązania.

2026-07

  • Dokumenty cykliczne w API. Nowe endpointy /recurring-rules: lista reguł z podsumowaniem (statusy, najbliższa generacja, miesięczny przychód brutto), szczegóły reguły, historia generacji oraz pauza i wznowienie. Nowe scope'y recurring:* (3). Wymaga planu MAX. Przewodnik: Dokumenty cykliczne.
  • Moduł magazynowy w API. Nowe endpointy /warehouse: magazyny (CRUD), korekty stanów (inwentaryzacja), raport stanów z parametrem asOf i automatyczne WZ do faktur sprzedaży. Wymaga planu MAX. Przewodnik: Magazyn.
  • Pracownicy i uprawnienia w API. Nowe endpointy /employees: rejestr uprawnień, tworzenie i edycja kont pracowniczych, dezaktywacja i usuwanie. Przewodnik: Pracownicy i uprawnienia.
  • Nowe scope'y: warehouse:* (7) i employees:* (4), opisane w Uwierzytelnianiu.
  • Filtr documentType na liście dokumentów przyjmuje teraz także typy magazynowe (np. WZ).
  • Filtry listy dokumentów. GET /documents przyjmuje documentType (pojedynczy typ lub listę rozdzieloną przecinkami) oraz zakres dat wystawienia dateFrom/dateTo. Szczegóły w Paginacji i filtrowaniu.
  • Kolekcja Postman i CLI obejmują całe API (produkty, ustawienia, webhooki, połączenie KSeF, auth/me, wyszukiwanie firmy po NIP, powiązania z zamówieniami).
  • Nowe przewodniki. Kontrahenci, Produkty, Ustawienia, Połączenie KSeF, Powiązania z zamówieniami i Dane firmy po NIP.

2026-06

  • Wersja beta dostępna w środowisku sandbox. API można testować pod adresem sandbox.app.fakturnia.pl.
  • Kwoty ujednolicone do dokładności co do grosza, zaokrąglanie w górę przy połowie. Sumy w poszczególnych wierszach oraz sumy dla całego dokumentu są teraz dokładnie zgodne z silnikiem fakturnia-shared. W każdym wierszu zachodzi netValue + amountOfVat === grossValue.
  • FakturaRozliczeniowa wyznacza teraz grossSum na podstawie settlementAmount (pozostało do zapłaty = wiersze − powiązane zaliczki) zamiast pełnej sumy wierszy; metadane powiązanych zaliczek są wypełniane automatycznie.
  • Sumy FakturaZaliczka są wyznaczane na podstawie proporcjonalnego rozbicia zaliczki (grossSum === advancePaymentAmount).
  • FakturaProforma / FakturaProformaBezVAT akceptowane przez POST /documents.
  • Korekty zaliczkowe i rozliczeniowe (FakturaKorygujacaZaliczkowa, FakturaKorygujacaRozliczeniowa) obliczają różnicę kwoty z proporcjonalnym VAT.
  • PUT oraz PATCH /documents/{id}; wiele bankAccounts[] przy tworzeniu i aktualizacji.

Polityka wersjonowania

  • Wersjonowanie w ścieżce. v1 jest stabilne. Wersja v2 pojawiłaby się wyłącznie w przypadku zmian łamiących zgodność.
  • Addytywnie w ramach v1. Nowe opcjonalne pola żądania oraz nowe pola odpowiedzi mogą pojawiać się bez zmiany wersji.
  • Wycofania są ogłaszane na tej stronie wraz z oknem migracyjnym przed usunięciem.

Śledź zmiany, obserwując tę stronę lub specyfikację OpenAPI (jej info.version odzwierciedla wydania).