Rozbieżność między metadanymi KSeF a kwotą "Do zapłaty"

[kmichalik-tm]

Występuje rozbieżność pomiędzy danymi zwracanymi przez API KSeF (/invoices/query/metadata) a wizualizacją faktury (PDF/HTML) w przypadku faktur zawierających kaucje.

Podczas pobierania danych z API dostępne są jedynie podstawowe pola finansowe:

• netAmount
• grossAmount
• vatAmount
• currency

Przykładowe dane z metadanych:
"netAmount": 1472.71
"grossAmount": 1739.46
"vatAmount": 266.75
"currency": "PLN"

Jednocześnie na wizualizacji faktury występuje dodatkowa wartość:

• "Do zapłaty": 1815.46 PLN (uwzględniająca kaucje)

Oznacza to, że kwota końcowa widoczna na fakturze nie jest odzwierciedlona w metadanych zwracanych przez API.

Problem:
W metadanych brak jest pola odpowiadającego rzeczywistej kwocie do zapłaty widocznej na fakturze, w szczególności w przypadkach, gdy występują kaucje.

Wpływ:

• systemy integrujące KSeF prezentują niepełną lub nieprawidłową kwotę końcową,
• w listach faktur używane jest grossAmount, które nie uwzględnia kaucji,
• konieczne jest dodatkowe przetwarzanie wizualizacji faktury zamiast korzystania z danych strukturalnych,
• problem będzie narastał wraz ze wzrostem liczby faktur zawierających kaucje.

Oczekiwane zachowanie:
Metadane powinny zawierać pole odpowiadające finalnej kwocie „Do zapłaty”, zgodnej z wizualizacją faktury.

[kw-cirf]

Tak, w metadanych nie zwracamy wszystkich danych z xml-a. Pełne dane znajdziesz w export.
Dlaczego w Twoim scenariuszu nie możesz użyć exportu?

[kmichalik-tm]

Tak, w metadanych nie zwracamy wszystkich danych z xml-a. Pełne dane znajdziesz w export. Dlaczego w Twoim scenariuszu nie możesz użyć exportu?

To nie jest rozwiązanie problemu, przecież w export też są dane z metadata więc dalej nie ma łatwego sposobu na odczyt kwoty z kaucją bez analizowania XML'a.

[kw-cirf]

Chodziło mi o pliki xml.
Analizujemy możliwość rozszerzenia, ale nie jest to takie trywialne jak wydaje się na pierwszy rzut oka.

[kmichalik-tm]

Rozumiem, że temat nie jest trywialny. Natomiast z perspektywy integratorów obecny stan powoduje realny problem systemowy, który w praktyce zostaje przeniesiony na każdą firmę integrującą KSeF osobno.

[Dzyszla]

Wykorzystam: @kw-cirf A pamiętasz o wciąż bez odpowiedzi temacie #393 ?
Przy okazji przypomnę też o #538

[Marmelada100]

Może jestem naiwny, ale wydaje mi się, że metadane nie powinny być podstawą do operacji księgowych lub płatniczych. Metadane nie są dokumentem. Jeśli coś się kiedyś w ksefie skaszani, to urzędnik US będzie miał gdzieś usprawiedliwienia, że to metadane miały jakiś błąd.

[kmichalik-tm]

Może jestem naiwny, ale wydaje mi się, że metadane nie powinny być podstawą do operacji księgowych lub płatniczych. Metadane nie są dokumentem. Jeśli coś się kiedyś w ksefie skaszani, to urzędnik US będzie miał gdzieś usprawiedliwienia, że to metadane miały jakiś błąd.

Nikt tutaj nie sugeruje używania metadanych jako podstawy do operacji księgowych lub płatniczych. Pełnią one zupełnie inną rolę i oczywiście źródłem prawdy pozostaje XML faktury.

Metadane zostały stworzone przede wszystkim po to, aby umożliwić szybkie wyszukiwanie, filtrowanie oraz prezentowanie najważniejszych informacji o fakturze bez konieczności pobierania i analizowania całej zawartości pliku XML.

W efekcie, żeby poprawnie zaprezentować dane użytkownikowi faktury np. w liście, integrator musi dla części przypadków dodatkowo parsować XML. Stąd postulat dotyczy tylko zapewnienia spójności między metadanymi a wizualizacją w zakresie kwoty prezentowanej jako końcowa do zapłaty.