Prośba o dodanie możliwości aby plikiem żródłowym był plik VAT7M.xml pola w znacznikach html

[mocakow]

Poniżej spreparowany plik VAT7M.xml
JPK_VAT.xml.zip

[toudi]

musiałbym przypomnieć sobie strukturę JPK bo program do jego obsługi pisałem bardzo dawno :D ale czy to nie jest tak że w JPK nie ma żadnych informacji o pozycjach? tzn że tam są trzymane jedynie agregaty ile łącznie jest VAT'u itd ? coś kojarzę że to był jeden z powodów dla którego ministerstwo wprowadziło KSeF bo chciało dokładniej wiedzieć co sprzedają ludzie a nie tylko za jaką łącznie kwotę

[mocakow]

Fakt. Nawet FA_VAT nie zawiera nazwy sprzedawanego towaru/usługi

[mocakow]

Będę musiał grzebnąć w bazie i dostosować do Twojego importu.
Chyba, że uprościsz czytelność format csv. Próbuję się w niego wczytać ;)
Czy końce linii są ważne? Czy ważne są sekcje ?
Muszę przyjąć, że wszystko jest ważne.

Pomysł z Pegasusem jest na czasie :)

[toudi]

format CSV przewidziany był dla naprawdę archaicznych systemów. tak na dobrą sprawę przez zastosowanie sekcji to wcale nie jest "czyste" CSV bo każda sekcja ma inną ilość pól - ale to powoduje prostsze generowanie każdej z sekcji. Jeśi nie chcesz używać csv, spróbuj yaml'a (też jest przykładowy plik) albo po prostu użyj programu jak biblioteki (jeśli Twój program też jest napisany w go) wtedy podejrzewam, że będzie CI najprościej. Mogę rozważyć też dodanie wsparcia dla JSON'a jeśli miałoby Ci to w jakiś sposób pomóc tylko obecnie wolę skupić się na poprawie dokumentacji (bo ta w README jest katastrofalna)

idea sekcji była właśnie taka, żeby wypełniać tylko minimum informacji i żeby nie trzeba było tworzyć dziesiątek pustych pól. dlatego CSV staje się wtedy niejako tylko "matrycą" gdzie w osi "y" masz sekcje a każda sekcja ma pola które dotyczą tylko jej

[mocakow]

Mi to prościej z bazy w „csv ubrać” ale zobaczę yaml jeśli jest faktycznie czytleniejszy. I tak będę musiał protezę zrobić.

[toudi]

jeszcze jedna bardzo ważna sprawa - mój program nie robi jakiejkolwiek walidacji wygenerowanej faktury - służy jedynie do wypychania jej do KSeF. oczywiście można użyć xmllint żeby upewnić się, że wygenerowany xml jest zgodny ze schematem xsd natomiast warto pamiętać, że to wystawca faktury musi sam wiedzieć jakich pól potrzebuje. ministerstwo wypuściło broszurę informacyjną w PDF gdzie dość szczegółowo opisuje które pola co oznaczają i kto musi je uzupełniać https://www.podatki.gov.pl/media/9512/broszura-informacyjna-struktury-logicznej-fa-2.pdf. Możesz też zalogować się do systemu testowego, wygenerować sobie fakturę za pomocą ministerialnego klikacza i na tej podstawie wiedzieć które pola Cię dotyczą

[mocakow]

Mam nadzieję, że to zrobią do czerwca 2024 w programie inni, ale warto się przygotować na najgorsze. :)
Ważne, że ze źródłowego csv i jaml generują się przykadowe pliki faktur. Czyli funkcjonalność jakaś jest :)
Ze swojej strony spróbuję zrobić protezę sql > coś > csv

[toudi]

hm wyświetlił mi się na mailu Twój komentarz ale tu go nie widzę. wywołanie dla yamla w wersji "bulk" jest takie samo jak dla pojedynczego tj:

./ksef generate -f przykladowe-pliki-wejsciowe/bulk.yaml -o yaml-bulk

aczkolwiek jesli są jakieś błędy to daj znać to będę poprawiać :)

[mocakow]

Wywalilem, bo mój bład -f nie dodalem..

[lol2x]

Mogę rozważyć też dodanie wsparcia dla JSON'a jeśli miałoby Ci to w jakiś sposób pomóc

dodanie JSON'a byłoby bardzo fajną sprawą, csv jest mało czytelny (choć rozumiem jego cel)

[toudi]

ok zatem pokombinuję z JSON'em. na chwilę obecną skupiam się na dodaniu porządnego logowania bo na tą chwilę nie ma żadnego a to mocno utrudnia debugowanie