Krajowy system e-Faktur

https://github.com/CIRFMF/ksef-pdf-generator/

trochę nie tego się spodziewałem, ale lepsze to niż nic

faktura.pdf
upo.pdf

Wrzucam przykładowe wizualizacje z generatora jakby ktoś chciał zobaczyć bez uruchamiania apki

Czy istnieje sposób na dokładne określenie, czy faktura jest B2B, czy B2C? Czy ma to związek z polem Podmiot2?

Miał być dziś (dziwna data na publikację) MCU, ale o ile wcześniej była informacja 'trwają prace' na domenowym, tak dziś wygląda, że w ogóle przestał istnieć adres?

MCU działa ale pod linkiem:
https://ksef.mf.gov.pl/web/

Jak na razie działa w 100% ok, w 2min wygenerowałem oba certy.
Jedna uwaga która mnie zaskoczyła to klucz prywatny, dla obu cert jest osobny dla auth i podpisu fv offline.
Interfejs dosyć intuicyjny nawet dla amatora nie powinno być problemu

Otrzymany prv key to EC (nie ma opcji wyboru np RSA więc jak mieliscie przygotowaną APK tylko pod RSA to czas na update)

Czy wiecie, jak w programie zastosować podane w MCU hasło, by odczytać zawartość klucza prywatnego z pliku *.key?
(Z etykiety PEM wynika, że klucz jest zapisany w PKCS#8, ale wyłożyłem się na haśle - czy przypadkiem nie jest "dopychane" do 32 bajtów jakimiś znakami z prawej lub lewej?) Próbuję ten klucz załadować w ten sposób (.NET Core 9.0):

  //pkeyText to zawartość pliku *.key, metoda GetPemSection() zwraca jego czysty Base64 spomiędzy etykiet "---- BEGIN ... " i "---- END ..."
  byte[] encryptedKey = Convert.FromBase64String(pkeyText.GetPemSection(PemSection.PRIVATE_KEY, asBase64:true));
  var ecd = new ECDsaCng();
  ecd.ImportEncryptedPkcs8PrivateKey(Encoding.ASCII.GetBytes(pwdECD), encryptedKey, out _);

Ciągle dostaję błąd:

System.Security.Cryptography.CryptographicException: The EncryptedPrivateKeyInfo structure was decoded but was not successfully interpreted, the password may be incorrect.
       ---> System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.

14:00 EDIT: Nie ma tematu - po prostu podawałem złe hasło
Powyższy kod działa poprawnie (może się komuś przyda), a w razie czego widzicie, jaki wyskoczy wyjątek, gdy użytkownik zrobi literówkę.

16:00 EDIT: Wszystko fajnie, tylko certyfikatem (instancja klasy X509Certificate2) z tak załadowanym kluczem nie da się podpisać XML-a. Przy próbie podpisania Request.xml dostaję błąd od serwisu z biblioteki MF:

System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.
         at System.Security.Cryptography.Xml.SignedXml.ComputeSignature()
         at KSeF.Client.Api.Services.SignatureService.Sign(XmlDocument xmlDocument, X509Certificate2 certificate) 

Po dokładniejszym sprawdzeniu: przyczyna chyba nie leży w certyfikacie.
Metoda SignatureService.Sign() nie jest w stanie podpisać XML-a także certyfikatem ECDsa self-signed, generowanym przez tą bibliotekę, A jednocześnie drugi serwis biblioteki bez problemu używa tego samego certyfikatu do podpisania url kodu QR. No cóż, kolejny błąd do zgłoszenia. Liczę, że chłopaki w tydzień to poprawią...

21:30 EDIT: Chłopaki (a dokładniej CIRF-DEV2) podał dodatkową linię, którą przekierowuje podpisywanie certyfikatami ECDsa do biblioteki .NET, dzięki czemu zaczęły działać (por. to zgłoszenie na GH).
Jestem mu bardzo wdzięczny!

W miejscu, gdzie uruchamiam środowisko, trzeba było dodać:

.
.
using KSeF.Client.Extensions; //W tej namespace jest pomocnicza klasa Ecdsa256SignatureDescription 
.
.
.
//Wywołaj standardowe metody Klienta KSeF:
services.AddKSeFClient(options => {	options.BaseUrl = targetUrl; });

services.AddCryptographyClient(); 

//To ta dodatkowa linia: rejestracja algorytmu podpisywania ECDsa
CryptoConfig.AddAlgorithm( typeof(Ecdsa256SignatureDescription), "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256");
.
.
.

Po wstawieniu tej linii, metoda ISignatureService.Sign() zaczęła poprawnie podpisywać XML-e także certyfikatami ECDsa.

Przepraszam że termin ale czy może komuś udało się wygenerować token autoryzacyjny przez MCU?

Czy w MCU da się wygenerować certyfikat na firme (NIP) a nie PESEL bezkosztowo? (bez potrzeby płatnych sposobów logowania?)

Może nie rozumiem ale dlaczego tak wszyscy rzucili się na MCU skoro zarówno uprawnieniami jak i certyfikatami da(ło) się zarządzać z poziomu dostępnego już wcześniej API ? Poza GUI coś więcej to wnosi ? Coś źle interpretuję ?

Chcę się zalogować do KSEF 2.0 z uzyciem tokena za pomocą metody:
auth/ksef-token

Na wejściu mam encryptedToken. Jakim kluczem mam go zaszyfrować ?
Czy to ma być cert publiczny z: https://mcu.mf.gov.pl/web/login (dostepny od DZISIAJ).
? Tak sie domyslam. Poprawcie mnie albo wskazcie inny klucz. Chce sie zalogowac do kontekstu DEMO dla Ksef 2.0.
Po zalogowaniu wygenerowalem cert, tzn. 2 pliki: cert.crt (publiczny) i cert.key (prywatny).
Zapytałem AI: powiedział mi, żeby wyciągnął z tego cert.crt tylko klucz publiczny żeby pozbyc się metadanych x509: openssl x509 -in cert.crt -pubkey -noout > publicKey.pem .
Co bym nie robił funkcja szyfrująca generuje błąd. Mój klucz nie wyglad na RSA tylko na
openssl pkey -in ./mojkluczpub.pem -pubin -text -noout
daje
Public-Key: (256 bit)
pub:
"to oznacza, że ten klucz publiczny nie jest typu RSA, tylko najprawdopodobniej EC (Elliptic Curve)."
Moze nie mam szyfrowac tokena tym kluczem ?

Próbuje się utwierzytelnić certyfikatem z MCU.
Na teście z verifyCertificateChain=true dostaję błąd 400 "Nieprawidłowy certyfikat"
Na teście z verifyCertificateChain=false dostaję 200 ale z komunikatem "Uwierzytelnianie zakończone niepowodzeniem" i w details "Brak przypisanych uprawnień". Rozumiem, że test może nie znać kto w realu jest uprawniony do czego, więc ok. Zakładam, że certyfikat sam w sobie jest prawidłowy (poza tym chainem, na to chyba jest issue, ale nie mogę znaleźć)

Ale na demo dostaję 400 "Nieprawidłowy certyfikat", również z verifyCertificateChain=false. O co może chodzić?

Czy w waszych aplikacjach jest wsparcie dla faktur RR? Wiecie może gdzie znaleźć oficjalny schemat xsd dla RR? Na epuapie nie mogę się dokopać do tego

Kompiluję KSeF.Client ten z GitHub MF w VS2022 i dostaję error

https://github.com/CIRFMF/ksef-docs/issues/23#issuecomment-3478118345

API ma otrzymać nowe endpointy, które mają obowiązywać od 1.02 prawdopodobnie! Tym razem jednak powrót do zgłaszania scamu (coś, co było w 1.0, potem zostało z 2.0 wyrzucone).

Przecież to jest chore. Klienci jak opętani dopytują o szkolenia, a produkt wciąż nie jest skończony i to jest jawnie deklarowane!
I tu pytanie też - czy w MCU można jednostki wewnętrzne jakoś zakładać? (nie mam NIPu do sprawdzania tego). Bo takiego endponta, który był w 1.0, w 2.0 też wciąż nie ma.

Co jeszcze, poza pisaniem do mediów robić, bo do MF to nawet nie ma sensu.

@Dyszla to zaproponuj tutaj jakąś zajawkę która by zaciekawiła redakcję, żeby chciała zamówić u nas artykuł. Ja napisać mogę, ale przy Waszej współpracy technicznej

Miang napisał(a):

@Dyszla to zaproponuj tutaj jakąś zajawkę która by zaciekawiła redakcję, żeby chciała zamówić u nas artykuł. Ja napisać mogę, ale przy Waszej współpracy technicznej

To może coś w stylu:

KSeF - czy 1.02 dostaniemy niegotowy i nieprzetestowany system?

30 września MF udostępniło API do testów. To właśnie od tego dnia okazało się, jak wiele jeszcze pracy czeka nie tylko integratorów ale i zespół techniczny Ministerstwa, aby móc stworzyć rozwiązania dostępne dla przedsiębiorców. Już w pierwszych dniach okazało się, że system potrzebuje wielu gruntownych modyfikacji, które trwają po dziś dzień. Dość powiedzieć, że w ciągu minionego miesiąca otrzymaliśmy 6 aktualizacji, które często pociągają za sobą konieczność dostosowywania swoich systemów. A to wciąż nie koniec.

Wielu integratorów, w ślad za użytkownikami ich oprogramowania, dalej oczekuje rozwiązań pozwalających na prostą i czytelną wizualizację dokumentów z KSeF - zarówno faktur jaki i Urzędowych Potwierdzeń Odbioru. Choć taka funkcjonalność była zapowiedziana i udostępniona na koniec października, to jednak okazało się, że nie do końca spełnia ona oczekiwania i umożliwia na realizację zadania poprzez interfejsy aplikacji biznesowych. Programiści znów muszą odczekać do 14.11, kiedy zapowiedziane jest wydanie rozwiązania, które powinno bardzo podołać zadaniu.

Kolejnym aspektem, jaki pojawił się 2.11 to kwestia oznaczania faktur scamowych i ukrywania ich. Choć pierwotny system miał taką funkcjonalność i była ona zakładana na początku KSeF 2.0, to w toku późniejszych wyjaśnień i aktualizacji została wycofana. Teraz wraca zapowiedź, że ta funkcjonalność powróci przed uruchomieniem nowego systemu. Jednakże integratorzy nie mają w tym momencie nawet żadnej dokumentacji, która przedstawi, jak ma być ona zrealizowana. A czas ucieka...

Jeszcze trudniej mają wszelkie firmy, których programiści wykonujący oprogramowanie dla klientów biznesowych z naszego kraju, nie władają naszym językiem, gdyż nie do dziś nie wydana został angielska wersja dokumentacji. Co z resztą specjalnie nie dziwi przy takiej ilości zmian, modyfikacji i poprawek, jakie wciąż się pojawiają.

Warto nadmienić, że od momentu publikacji dokumentacji pojawiło się już blisko 300 zgłoszeń od integratorów związanych bądź to z trudnościami, nieścisłościami lub ewidentnymi błędami w działaniu KSeF. Nie ułatwia też fakt, że KSeF padł także ofiarą niedawnej awarii usługi Microsoft - Azure, uniemożliwiając tym samym ciągły proces testowania, jakże istotny w trakcie przygotowywania integracji. Ponadto przerwy pojawiają się także w wyniku planowanych prac modernizacyjnych przez MF. A to wszystko w okresie niecałych 3 miesięcy, gdy KSeF 2.0 zacznie obowiązywać wszystkich przedsiębiorców w zakresie odbierania faktur oraz największych w zakresie wysyłania. Czas obfitujący w liczne świąteczne dni. Czas, w którym już teraz przyszli użytkownicy powinni przechodzić szkolenia z używania narzędzi im dostarczonych. Jednak jest to niemożliwe, gdyż prace po stronie samego MF nie zakończyły się, tym bardziej nie dając możliwości deweloperom na prezentację gotowych rozwiązań.

Fakt, jak dużym jest to problemem, przejawia się także na szkoleniach organizowanych przez MF za pośrednictwem KAS, gdzie uczestnicy mogą co najwyżej obejrzeć statyczne prezentacje i zdjęcia bez możliwości przetestowania, zobaczenia "na żywo", jak to wszystko wygląda. Wszak sama aplikacja webowa ma być udostępniona dopiero 15.11. Pracownicy KAS odpowiedzialni z prowadzenie prezentacji także rozkładają ręce, gdy pojawiają się pytania. Z pewnością łatwiej byłoby, gdyby mogli sami zaznajomić się z tym, co muszą przekazać.

To tak pokrótce - idę się wyspać. Może coś jeszcze można by wyciągnąć z artykułów (część mogłą się zdezaktualizować):

• https://bezprawnik.pl/poczatek-obowiazkowego-ksef/
• https://www.pit.pl/aktualnosci/ksef-czy-bedzie-przesuniecie-terminu-1011826
• https://www.pit.pl/aktualnosci/trwa-pierwsza-awaria-serwera-testowego-ksef-jest-problem-w-wystawianiem-faktur-1011810
• https://www.pit.pl/aktualnosci/rynek-it-ostrzega-dostawcy-moga-nie-zdazyc-z-ksef-czy-prezydent-powinien-podpisac-ustawe-1011583
• https://www.pit.pl/aktualnosci/ksef-2-0-firmy-beda-mialy-tylko-4-miesiace-na-testy-1011430
• komentarze pod: https://www.bankier.pl/wiadomosc/KSeF-z-ostatnim-brakujacym-elementem-Od-listopada-2025-r-rusza-modul-certyfikatow-9033090.html
• https://www.bankier.pl/wiadomosc/Branza-IT-Do-wejscia-KSeF-zostalo-tylko-5-miesiecy-Wiele-firm-nie-zdazy-sie-przygotowac-9002453.html

Jak ktoś może widział coś więcej, to niech dorzuci.

A w MCU jest w końcu generowanie starych tokenów?

Ja od 3 dni walczę z problemem i potrzebuję pomocy.
Odbieram z API EP: /api/v2/security/public-key-certificates te dwa certyfikaty kluczy publicznych.
Próbuję z pomocą tego certyfikatu oznaczonego Usage: SymmetricKeyEncryption zaszyfrować klucz do szyfrowania faktur, ale rozbijam się na funkcji CryptoAPI:

CryptDecodeObjectEx(X509_ASN_ENCODING or PKCS_7_ASN_ENCODING,
                                     X509_PUBLIC_KEY_INFO,
                                     Pbyte(@derCert[0]), derCertLen,
                                     CRYPT_ENCODE_ALLOC_FLAG
                                     Nil,
                                     @publicKeyInfo, publicKeyInfoLen);

która zwraca mi błąd: 0x8009310B - ASN.1 bad tag value met.

Próbowałem na różne sposoby, ale nic nie pomaga, a ja utknąłem i nie wiem co dalej.

@Dzyszla: opublikowałeś kod który realizuje szyfrowanie RSA, gdzie używasz podobnych funkcji, wnioskuję, że Tobie to działa, jakbyś mógł opisać szczegółowo, co robisz z tym certufikatem do MF-u, bo już nie wiem gdzie popełniam błąd. Dzięki.

FYI: Nie wiem czy to coś komuś zmienia i czy było poruszane gdzieś ale xsd AuthTokenRequest z dokumentacji: https://ksef-test.mf.gov.pl/docs/v2/schemas/authv2.xsd różni się od tego w javovym kliencie https://github.com/CIRFMF/ksef-client-java/blob/main/ksef-client/src/main/resources/xsd/AuthTokenRequest.xsd. Różnice są w regexpach elementu <AllowedIps>

Zastanawiam się jak w aplikacji desktopowej najłatwiej zrobić użytek z tego kodu TypeScript, który ma być udostępniony do wizualizacji faktur i UPO. Mam pewien pomysł, ale chętnie poznałbym opinie na jego temat osób, które coś robiły w tym TypeScripcie (a do któych się niestety nie zaliczam). Mianowicie czy dałoby się ten kod TypeScript jakoś (jak?) ładować do przeglądarki internetowej żeby go wykonywała i od razu wyświetlała wynikowy PDF? Z tego co wygooglałem, to chyba dałoby się konwertować ten TypeScript do JavaScript, i wrzucać do przeglądarki otagowany jako "script" w HTML? Ostatecznie przeglądarkę raczej każdy użytkownik ma (lub łatwo może mieć), a do tego przeglądarki potrafią teraz wyświetlać PDF.

Dzień dobry, Próbuję wysłać fakturę do KSeF z wykorzystaniem OpenSSL 3.6.0 1.

1.Generuję klucz (64 bajtowy) i iv (16 bajtowy).
2. Klucz zapisuję do pliku plaintext.txt szyfruję poleceniem:
openssl pkeyutl -encrypt ^
-in plaintext.txt ^
-inkey SymmetricKeyEncryption.pem ^
-pubin ^
-out encrypted.bin ^
-pkeyopt rsa_padding_mode:oaep ^
-pkeyopt rsa_oaep_md:sha256 ^
-pkeyopt rsa_mgf1_md:sha256

openssl base64 -in encrypted.bin -out encrypted_base64.txt -A
3. Odbieram z pliku encrypted_base64.txt zakodowany baze, koduję iv w base64,
wstawiam do jsona i wysyłam do endpointa.
Proces otwarcia sesji interaktywnej kończy się komunikatem "Sesja interaktywna otwarta".

1. Koduję klucz i iv w hex i wykonuję polecenie:
   openssl enc -aes-256-cbc -base64 -A ^
   -in afaktura.xml -out afaktura.b64 ^
   -K kluczHex ^
   -iv ivHex
2. Obliczam rozmiar pliku afaktura.xml (xml utf-8 bez bomu bez CRLF, spacji, w jednej linii) i hash.
3. Obliczam rozmiar i hash zaszyfrowanego pliku w base64 afaktura.b64.
4. Dołączam to do jsona i wysyłam do endpointa i wysyłam.

Wysyłka faktur kończy się komunikatem "Faktura przyjęta do dalszego przetwarzania".
Natomiast pobranie faktur sesji zgłasza komunikat "Błąd odszyfrowania pliku" (kod
435).

Jak próbowałem z komponentami Chilkat delphiDLL z wygenerowaną własną parą kluczy
to po zdekodowaniu otrzymuję ten sam plik co wysyłam.
Co tu mogę robić nie tak i jak można sprawdzić na którym etapie występuje błąd?

Czy ktoś się orientuje albo testował taką sytuację:

Podmiot A - dostawca oprogramowania do wystawiania faktur
Podmiot B - podmiot używający oprogramowania
Podmiot C - podmiot upoważniający podmiot B do wystawiania faktur w jego imieniu.

Jak widzicie takie rozwiązanie w sytuacji bezobsługowej , czyli nie angażujemy użytkownika w uwierzytelnianie :

1. Czy Aplikacja używa certyfikatu Podmiotu B do uwierzytelniania się w systemie i wystawia fakturę w imieniu Podmiotu C uwierzytelniając się w kontekście podmiotu C, wstawiając dane podmiotu B do Podmiot3 w roli 5 (wystawca)
2. Czy Podmiot B powinien nadać uprawnienia podmiotowi A do wystawiania faktur i aplikacja używa certyfikatu podmiotu A i podmiot A jest w stanie się uwierzytelnić w kontekście podmiotu C wtedy i wstawić w podmiot1 dane podmiotu A i w Podmiot3 wstawić dane Podmiotu B w roli wystawcy ?

W kroku 3. pomyliłem się, z pliku encrypted_base64.txt odbieram już zaszyfrowany i zakodowany w base64 zaszyfrowany 64 bajtowy klucz.

leszekp napisał(a):

Dzień dobry, Próbuję wysłać fakturę do KSeF z wykorzystaniem OpenSSL 3.6.0 1.

1.Generuję klucz (64 bajtowy) i iv (16 bajtowy).
2. Klucz zapisuję do pliku plaintext.txt szyfruję poleceniem:
openssl pkeyutl -encrypt ^
-in plaintext.txt ^
-inkey SymmetricKeyEncryption.pem ^
-pubin ^
-out encrypted.bin ^
-pkeyopt rsa_padding_mode:oaep ^
-pkeyopt rsa_oaep_md:sha256 ^
-pkeyopt rsa_mgf1_md:sha256

openssl base64 -in encrypted.bin -out encrypted_base64.txt -A
3. Odbieram z pliku encrypted_base64.txt zakodowany baze, koduję iv w base64,
wstawiam do jsona i wysyłam do endpointa.
Proces otwarcia sesji interaktywnej kończy się komunikatem "Sesja interaktywna otwarta".

1. Koduję klucz i iv w hex i wykonuję polecenie:
   openssl enc -aes-256-cbc -base64 -A ^
   -in afaktura.xml -out afaktura.b64 ^
   -K kluczHex ^
   -iv ivHex
2. Obliczam rozmiar pliku afaktura.xml (xml utf-8 bez bomu bez CRLF, spacji, w jednej linii) i hash.
3. Obliczam rozmiar i hash zaszyfrowanego pliku w base64 afaktura.b64.
4. Dołączam to do jsona i wysyłam do endpointa i wysyłam.

Wysyłka faktur kończy się komunikatem "Faktura przyjęta do dalszego przetwarzania".
Natomiast pobranie faktur sesji zgłasza komunikat "Błąd odszyfrowania pliku" (kod
435).

Jak próbowałem z komponentami Chilkat delphiDLL z wygenerowaną własną parą kluczy
to po zdekodowaniu otrzymuję ten sam plik co wysyłam.
Co tu mogę robić nie tak i jak można sprawdzić na którym etapie występuje błąd?

leszekp napisał(a):

Dzień dobry, Próbuję wysłać fakturę do KSeF z wykorzystaniem OpenSSL 3.6.0 1.

1.Generuję klucz (64 bajtowy) i iv (16 bajtowy).
2. Klucz zapisuję do pliku plaintext.txt szyfruję poleceniem:
openssl pkeyutl -encrypt ^
-in plaintext.txt ^
-inkey SymmetricKeyEncryption.pem ^
-pubin ^
-out encrypted.bin ^
-pkeyopt rsa_padding_mode:oaep ^
-pkeyopt rsa_oaep_md:sha256 ^
-pkeyopt rsa_mgf1_md:sha256

openssl base64 -in encrypted.bin -out encrypted_base64.txt -A
3. Odbieram z pliku encrypted_base64.txt zakodowany baze, koduję iv w base64,
wstawiam do jsona i wysyłam do endpointa.
Proces otwarcia sesji interaktywnej kończy się komunikatem "Sesja interaktywna otwarta".

1. Koduję klucz i iv w hex i wykonuję polecenie:
   openssl enc -aes-256-cbc -base64 -A ^
   -in afaktura.xml -out afaktura.b64 ^
   -K kluczHex ^
   -iv ivHex
2. Obliczam rozmiar pliku afaktura.xml (xml utf-8 bez bomu bez CRLF, spacji, w jednej linii) i hash.
3. Obliczam rozmiar i hash zaszyfrowanego pliku w base64 afaktura.b64.
4. Dołączam to do jsona i wysyłam do endpointa i wysyłam.

Wysyłka faktur kończy się komunikatem "Faktura przyjęta do dalszego przetwarzania".
Natomiast pobranie faktur sesji zgłasza komunikat "Błąd odszyfrowania pliku" (kod
435).

Jak próbowałem z komponentami Chilkat delphiDLL z wygenerowaną własną parą kluczy
to po zdekodowaniu otrzymuję ten sam plik co wysyłam.
Co tu mogę robić nie tak i jak można sprawdzić na którym etapie występuje błąd?

@leszekp: Sorry, pomyliłem się przy pisaniu, generuję klucz 32 bajtowy, inaczej by nie została otwarta sesja, bo KSeF sprawdza odszyfrowanie klucza.

Ja niegodny, jak pewnie większość z nas :D Mam małe doświadczenie w tym i potzrebuje pomocy.
Zadam pytanie które pewnie już się wielokrotnie tu ukazywało .. ale przyznam że nie było jednoznacznej odpowiedzi:.

Mam aplikacje webową (aplikacja XXX) która ma w sobie wielu sprzedawców (sprzedawcy YYY) którzy wystawiają faktury zwykłym ludkom z ulicy (ludzie ZZZ).

Jaka jest ścieżka poprawne tej weryfikacji. ? Bo przyznam że pogubiłem się srogo?
Robię uwierzytelnianie się przez token KSeF.

1. Uzyskuje challenge.
2. następne (token|timestamp) szyfruje kluczem publicznym. I tu pierwsze pytania : Który token z MCU? jaki certyfikat ?
3. Zakładam że uda mi się w końcu wykonać punkt 2. Czy wynikiem punktu 2 jest "Bearer" który wykożystuje potem w dalszej komunikacji ??

PS. Czy ktoś ma jakiś kod w PHP którym byłby chetny się podzielić ?

Wg dokumentacji do generowania kodu QR wystawcy można uzywać algorytmów RSA lub ECDSA. Certyfikat generowany przez MCU bez wątpienia jest certyfikatem z ECDSA. I w sumie to nie wiem jakie zadać pytanie, chyba tylko takie czy ich opuścił Bóg czy co?

Czy to nie dziś powinna zostać udostępniona testowa aplikacja
https://ksef-test.mf.gov.pl/web - adres pozostaje bez zmian?

Faktury offline. Rozumiem, że dostępność systemu sprawdzamy odpalając https://ksef-test.mf.gov.pl/api/v2. Czy jest może jakaś magiczna końcówka, w której możemy sprawdzić datę zakończenia awarii, czy kliencki system ma próbować sprawdzanie aż do skutku i wysyłać, gdy system jest dostępny?

Mamy kolejną, siódmą aktualizację. Pocieszające, że objętość changelogów nieco zmalała. Głównie nowe pola w odpowiedziach.

Dla przypomnienia, zmiany pod https://github.com/CIRFMF/ksef-docs/blob/2.0.0-RC5.6/api-changelog.md

Ma ktoś z Was przykład faktury XML w której są 3 testowe pozycje z różnymi stawkami VAT: 23%, 8% i zw. Z dokumentacji zrozumiałem że każdy rodzaj stawki VAT ma inne znaczniki XML a AI generuje mi przykład xml bez rozróżnienia jaka jest stawka VAT i nie wiem co ostatecznie jest poprawne.
Z góry dziękuje za sugestię/pomoc.