Krajowy system e-Faktur

0

Dzień dobry, kolejny problem napotkałem, otóż nie mogę pobrać faktury jeśli to robię od razu po zalogowaniu się tokenem (błąd "Brak uwierzytelnienia."), kod wygląda tak:

niedziałający:

        $session = $service->createTokenSession('nip...', 'token...');
        $invoice = $service->getInvoice($session, 'ref...');

działający:

        $session = $service->createTokenSession('nip...', 'token...');
        sleep(1);
        $invoice = $service->getInvoice($session, 'ref...');

Ogólnie api mi działa, tzn. mogę się logować, wysyłać faktury itp, jedynie problem jest przy pobieraniu faktur od razu po utworzeniu sesji, czy ktoś się z czymś takim spotkał?

0

Witam
Batch Init, Upload, Finish idzie bez błędu (status 200),
ale gdy pobieram UPO

common/Status/'+refNr

dostaję

"processingCode":420,
"processingDescription":"20005:Nieprawidłowo zaszyfrowana treść."

Robiłem deszyfrowanie - daje to samo, co było przed szyfrowaniem.
Może znowu brakuje mi jakiegoś parametru szyfrowania albo pakowania ?
Używam Delphi 10.2 Professional i REST.
Pakowanie robię na "7-ZIP DELPHI API" (https://github.com/geoffsmith82/d7zip).

var
  Arch:I7zOutArchive;
begin
  Arch:=CreateOutArchive(CLSID_CFormat7z);
  SetCompressionLevel(Arch,2);  
  Arch.AddFile('fa1.xml','fa1.xml'); 
  Arch.SaveToFile('faktury.7z');

Szyfrowanie robię na OpenSSL

var
  EncUtil:TEncUtil;
  klucz,iv:TBytes;
begin
  klucz:=[16,157,72,101,43,4,78,225,243,166,128,46,217,171,55,135,24,116,36,54,242,53,145,187,50,231,67,77,73,90,17,151];
  iv:=[72,108,172,227,245,139,53,90,83,62,64,90,61,51,217,229];
  EncUtil:=TEncUtil.Create;
  try
    EncUtil.UseBase64:=false;
    EncUtil.Passphrase.Create(klucz,iv);
    EncUtil.Cipher:='AES-256-CBC';
    EncUtil.Encrypt('faktury.7z','faktury.tmp.000');
  finally
    EncUtil.Free;
  end;
end;

W załączniku zebrałem wszystkie dane z kolejnych etapów.
Może ktoś zechciałby coś podpowiedzieć ?
Może mógłby wrzucić dane do swojego programu i porównać ?
Bardzo proszę o pomoc.

0

W FA(2) rozbito pole P_13_6 na trzy pola: P_13_6_1, P_13_6_2, P_13_6_3. Kiedyś sumowałem sobie wszystkie wiersze z P_12 == TStawkaPodatku.VALUE_8 ("0") do 13_6. Po jakim polu wiersza faktury (albo innym) mogę sprawdzić, do którego z trzech nowych pól powinna trafić wartość?

Obecny opis:
P_13_6_1: Suma wartości sprzedaży ze stawką 0% z wyłączeniem wewnątrzwspólnotowej dostawy towarów i eksportu. W przypadku faktur zaliczkowych, kwota zaliczki. W przypadku faktur korygujących, kwota różnicy, o której mowa w art. 106j ust. 2 pkt 5 ustawy
P_13_6_2: Suma wartości sprzedaży ze stawką 0% w przypadku wewnątrzwspólnotowej dostawy towarów. W przypadku faktur korygujących, kwota różnicy, o której mowa w art. 106j ust. 2 pkt 5 ustawy
P_13_6_3: Suma wartości sprzedaży ze stawką 0% w przypadku eksportu . W przypadku faktur zaliczkowych, kwota zaliczki. W przypadku faktur korygujących, kwota różnicy, o której mowa w art. 106j ust. 2 pkt 5 ustawy

0

W przypadku faktur korygujących stosuje się zapis:
Było : lp.(wiersza faktury pierwotnej) cena, jmiary, ilosc itd.
Winno być: lp (wiersza faktury pierwotnej) cena poprawna, ilosc poprawna itd.
W przykladach do wersji FA(1) numeracja wierszy w takich przypadkach jest kolejna 1,2 wiersze są unikalne i kolejne.
Z tego nie wynika którego wiersza faktury pierwotnej dotyczy korekta.
Czy tez w taki sposób numerujecie wiersze?

0

Cześć, czy ktoś się orientuje jak długo ważny jest token sesji na produkcji? (do sesji interaktywnej)

0

Cześć, dawno mnie tu nie było, wracam do dalszego tworzenia aplikacji KSeF i widzę, że program, który działał mi pół roku temu, teraz nie działa, a dokładnie pierwszy krok połączenia.
Korzystam ze środowiska testowego i wykonując pierwsze połączenie https://ksef-test.mf.gov.pl/api/online/Session/AuthorisationChallenge już zwraca mi błąd. Czy została jakoś zmieniona struktura zapytania bądź wyłączone zostało środowisko testowe? Ktoś wie co może być przyczyną?

0

Cześć.
Po nawiązaniu sesji ciężko stwierdzić ile czasu będzie ona aktywna, np jeśli nawiąże się połączenie o godzinie 8:00 i przez np 2 godziny nic się nie zrobi to sesja na pewno w KSeF wygaśnie. Tutaj właśnie mam problem ponieważ w mojej aplikacji mam zasygnalizowane, że ta sesja jest aktywna i przy próbie sprawdzenia jej statusu wyrzuca mi błąd HTTP/1.1 400 Bad Request

...
 try
    ss := TStringStream.Create('', TEncoding.UTF8);
    IdHTTP.Get('https://ksef-test.mf.gov.pl/api/online/Session/Status/' + ASessionNr, ss);  // <---- HTTP/1.1 400 Bad Request
    Result := ss.DataString;
    ss.Free;
  except
    on E: EIdHTTPProtocolException do
      Showmessage(E.Message);
    on E: Exception do
      Showmessage(E.Message);
  end;
  ...

Gdy sesja jest aktywna w KSeF'ie, to komponent Indy (IdHTTP) zwraca normalnie JSON'a ze statusem ale gdy w KSeF sesja automatycznie wygaśnie to już nawet nie można sprawdzić statusu.
U mnie podczas wywołania IdHTTP.Get() i wyrzuceniu błędu nawet nie wchodzi w blok 'except' tylko od razu wychodzi z funkcji.
Czy w jakiś sposób można obsłużyć taki błąd?

0

Pod jakim adresem jest swagger środowiska testowego?

0

Planuję otworzyć jedną sesję i w ramach tej sesji wysyłać pojedynczo wiele faktur, aby ominąć limit AuthorisationChallenge (dwa wywołania na dwie minuty). Co się stanie, gdy w ramach tej sesji wyślę pięć faktur, ale jedna okaże się błędna? Po zamknięciu sesji otrzymam UPO dla czterech, czy wszystkie pięć zostanie odrzuconych?

0

Czoem.
Podeślijcie link do przykładowych danych w nowej wersji FA(2)

0

dysponujecie może sprawdzonym poleceniem do generowania certyfikatu do podpisu XMLa do wysyłki wsadowej przez komendę New-SelfSignedCertificate? podpisuję, wysyłam do batch/Init i mam odpowiedź: "exceptionCode": 21406, "exceptionDescription": "Konflikt podpisu i typu uwierzytelnienia." Poniżej podpisany xml, wydaje mi się że czegoś brakuje porównując inne tu dostępne.

<?xml version="1.0" encoding="UTF-8"?>

-<InitRequest xmlns:batch="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001" xmlns:types="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/init/request/2021/10/01/0001">


-<Identifier xsi:type="types:SubjectIdentifierByCompanyType">

<types:Identifier>1111111111</types:Identifier>

</Identifier>


-<DocumentType>

<types:Service>KSeF</types:Service>


-<types:FormCode>

<types:SystemCode>FA (1)</types:SystemCode>

<types:SchemaVersion>1-0E</types:SchemaVersion>

<types:TargetNamespace>http://ksef.mf.gov.pl/schema/gtw/svc/batch/init/request/2021/10/01/0001</types:TargetNamespace>

<types:Value>FA</types:Value>

</types:FormCode>

</DocumentType>


-<Encryption>


-<types:EncryptionKey>

<types:Encoding>Base64</types:Encoding>

<types:Algorithm>AES</types:Algorithm>

<types:Size>256</types:Size>

<types:Value>qnPChkUCEnIoeAHMSGUQykGnzBdvoSIxtWrxdbcJfSG8eRZ3JrDWcDn4ukEUq27oDuDiradPouJ5Rg4IIh+uH+XRWJ7CqswqcgGppuBFeJ1LNsSdrH185fHcnF2aU+t/RCPowED9ot7AUenD8Up+irh2dEYM+x1vViXkgD85aMTi8T4Q3NjvSAiN7DrAOloA+cJW1kB2yGuNX+dhtE1gx0tGtUyz4fvCny8BEKdoiDDP7Jaan2zl7lPVwTZI1o0pHMz8GfjNmPLG+hcjbWVuNdogE4s7rag/jwSdVuxg6qkX52NuGLX37v2g+5tinIsgFIigNkOkggVoKOnHi0mWbw==</types:Value>

</types:EncryptionKey>


-<types:EncryptionInitializationVector>

<types:Encoding>Base64</types:Encoding>

<types:Bytes>16</types:Bytes>

<types:Value>4eh/WPkFQ4eHcMWYkhcJqw==</types:Value>

</types:EncryptionInitializationVector>


-<types:EncryptionAlgorithmKey>

<types:Algorithm>RSA</types:Algorithm>

<types:Mode>ECB</types:Mode>

<types:Padding>PKCS#1</types:Padding>

</types:EncryptionAlgorithmKey>


-<types:EncryptionAlgorithmData>

<types:Algorithm>AES</types:Algorithm>

<types:Mode>CBC</types:Mode>

<types:Padding>PKCS#7</types:Padding>

</types:EncryptionAlgorithmData>

</Encryption>


-<PackageSignature>


-<Package>

<batch:PackageType>split</batch:PackageType>

<batch:CompressionType>zip</batch:CompressionType>

<batch:Value>1111111111-20220916-A68B55-6C3D79-4D.zip</batch:Value>

</Package>


-<PackageFileHash>


-<types:HashSHA>

<types:Algorithm>SHA-256</types:Algorithm>

<types:Encoding>Base64</types:Encoding>

<types:Value>6qfA4fPJkIAPopvp7/nbVr02hhOwVXvVbmyIzhFng6I=</types:Value>

</types:HashSHA>

<types:FileSize>988</types:FileSize>

</PackageFileHash>


-<PackagePartsList>


-<PackagePartSignature>

<batch:OrdinalNumber>1</batch:OrdinalNumber>

<batch:PartFileName>1111111111-20220916-A68B55-6C3D79-4D.zip.1.aes</batch:PartFileName>


-<batch:PartFileHash>


-<types:HashSHA>

<types:Algorithm>SHA-256</types:Algorithm>

<types:Encoding>Base64</types:Encoding>

<types:Value>51Nr6wm6uGD3n5yAMWZ0CEppjPF7NA0+HZ5tgVl4v5o=</types:Value>

</types:HashSHA>

<types:FileSize>992</types:FileSize>

</batch:PartFileHash>

</PackagePartSignature>

</PackagePartsList>

</PackageSignature>


-<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">


-<SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>


-<Reference URI="">


-<Transforms>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<DigestValue>LCj8O/ScmjNGPXgxijyMRUwg0zLqY+DphlJDb8Hx5f8=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>E/Lot65XHLH1MWKjGZiEePzL/PHaKieDGUzKGXghXzgKzl9KFR07EBFkeFsfsjzlPSenv+77e7yss5TmmhP9bDESYZ53zw2/xYL11LNFYTOBVQWpOHBVCLNwU3eQ1/sJznSbCDitvxX9rBcYySjq6xZqdhFyzY/2qf1/5gsCTm3I2oYn9XJqXIS9Z43cWy1MicpkJ3BOjAMUzekatbWpfNRL9Ll8/E/WmftJTO/U5IZL9u/CbMJHCT25UlJHd/2TXkjq92CWb6J9/4g5RmatvYlkQICDjUTOWVZPWMqTKMC/UsUuNx5UrJjaKA7tM/ECA7xO9C9NZZZacW9U8S8MJQ==</SignatureValue>


-<KeyInfo>


-<X509Data>

<X509Certificate>MIIDyzCCArMCFC1I0C9bwQb9zevuQ7XQASDymjEWMA0GCSqGSIb3DQEBDQUAMIGhMQswCQYDVQQGEwJQTDESMBAGA1UECBMJTHViZWxza2llMQ8wDQYDVQQHEwZMdWJsaW4xDjAMBgNVBAoTBXNraWNoMQwwCgYDVQQLEwNFQ00xFDASBgNVBAMTC3Rlc3Qga2xpZW50MR4wHAYJKoZIhvcNAQkBFg9rb3dhbHNraUB4eHgucGwxGTAXBgNVBGETEFZBVFBMLTUyNTAwMDEwOTAwHhcNMjMwNzEzMTUyNTQ5WhcNMjMwODEyMTUyNTQ5WjCBoTELMAkGA1UEBhMCUEwxEjAQBgNVBAgTCUx1YmVsc2tpZTEPMA0GA1UEBxMGTHVibGluMQ4wDAYDVQQKEwVza2ljaDEMMAoGA1UECxMDRUNNMRQwEgYDVQQDEwt0ZXN0IGtsaWVudDEeMBwGCSqGSIb3DQEJARYPa293YWxza2lAeHh4LnBsMRkwFwYDVQRhExBWQVRQTC01MjUwMDAxMDkwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnuUS+jgivek4arDMg5jv/N1s0WL6br2X4nz9H/c2+wJPW3g05DvhIYGJm/WEmOQGbqinBiqAU8UthMMCAMqDf3QrVpBWfvPLKCuuMmbieIuGRXhIHskAB2ntehQnjV3fVOGbZhR5VZm6jOY5kWcySeWqDRx6oNmUf5lpPkeCYrVGBymb0b/vSfdD5GHEyLmjaVT7HlMZuN/e4gRTbUj+/WTv3RzN8+8HgHbRsvHDTWjQha0XGRivgxw7nyE1QjEStCRm1BMX3BpJfZ01BR+ePnUKtCsbQopaOslV0vTmJUgCQ3gGqa8669tM6p9PI0HdoAd+OJzOwdOxMWvVB/m60wIDAQABMA0GCSqGSIb3DQEBDQUAA4IBAQCDlkClXYgvH5R2I3PJ1S4zku8ns5aEdJ4um1Aa27PRibKWWmZFPvljr5aq1fqIKakbAoHwcl2yXb9QJcrwtGELkYyIZunIlGNy/dz0C/w+/Oo6+LCmiBecpw6TpUizztdSJdlOSEcIemWRFGpzZapW2zibjJp/AnHQuRnNzrQD5kiJMT/CbyypOduMRKMzEc3C7DImR734X2HZja4zFM1PvNvnqSav7TEKORHOiNA31q8p8UrtzM5MnU+7BmUeIWrslYcOB+k2hbL5iy0Qe0GpwALb3XALJo/FWffu57hkxRpcl5hB0wri+OZooDOzRp8FUzuZT8mExn5eEqsrwAKL</X509Certificate>

</X509Data>

</KeyInfo>

</Signature>

</InitRequest>

0

Jak obejść limity w przypadku gdy kilku użytkowników generuje faktury pojedynczo? Mam problemy następującej natury:

W przypadku 1 faktura / 1 sesja jest problem limitu "online.session.authorisation.challenge | limit : 2 | czas życia : 2 | Ograniczenie na liczbę identycznych wywołań usługi authorisation.challenge w sekwencji.", czyli w przypadku, gdy trzech użytkowników kliknie wysyłkę w czasie mniejszym niż 2 minuty, to się posypie poprzez naruszenie powyższego limitu.
W przypadku N faktur/1 sesja nie wchodzi w grę ze względu na limit "online.invoice.invoice.send | limit : 1 | czas życia : 60 | Ograniczenie na liczbę identycznych wywołań usługi invoice.send w sekwencji."

Słyszałem, że gdzieś jacyś hakerzy nie mogąc ogarnąć wsadowej wysyłki, opracowali rozwiązanie w stylu pętli wysyłek pojedynczych, więc jakoś da się powyższe problemy pokonać.

0

Sprawdzał ktoś już FA(2) na środowisku testowym ?

0

Czy byłby ktoś tak miły i podrzucił jakieś swoje przykładowe XMLe z FA(2)? Chciałbym potestować i mieć pewność, że działa na środowisku demo zanim wezmę się za robotę

0

A mnie ciągle męczy temat UPO. Otwieram sesję interaktywną, tworzę dwie faktury, zamykam (terminate) sesję, statusem pobieram UPO. W tym UPO są dwie faktury. Czy cały XML to UPO, czy tylko fragmenty dotyczące danych faktury? Czy trzymacie cały XML przy każdej z dwóch faktury, czy tylko fragmenty dotyczące danej faktury?

0

Mam taki kod:

 InvoiceSendJSON_1 = //
'{' + //
'  "timestamp": "%s",' + #13 + //
'  "invoiceHash": {' + #13 + //
'    "hashSHA": {' + #13 + //
'      "algorithm": "SHA-256",' + #13 + //
'      "encoding": "Base64",' + #13 + //
'      "value": "%s"},' + #13 + //
'    "fileSize": %s},' + #13 + //
'  "invoicePayload": {' + #13 + //
'    "type": "plain",' + #13 + //payloadType
'    "invoiceBody": "%s"}' + #13 + //
'}';

  RRequest.Params.clear;
  RRequest.Body.ClearBody;
  RRequest.Accept := 'application/json';
  RRequest.Resource := InvoiceSendResource;
  RRequest.AcceptCharset := 'utf-8';
  RRequest.Params.AddHeader('SessionToken', tokenSesji);
  RRequest.Body.Add(format(InvoiceSendJSON_1, [TimeStamp, sSHAvalue, sFileSize, sInvoiceBody]), trestcontenttype.ctAPPLICATION_JSON);
  RRequest.Method := rmPUT;
  RRequest.Execute;

Tak wygląda JSON po sformatowaniu:

{  "timestamp": "2023-07-19T13:17:29.131Z",
  "invoiceHash": {
    "hashSHA": {
      "algorithm": "SHA-256",
      "encoding": "Base64",
      "value": "IbutHS0IWfEIh3bI1L52/McJF3NGP0yZYzFKEUBVubM="},
    "fileSize": 5458},
  "invoicePayload": {
    "type": "plain",
    "invoiceBody": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjxGYWt0dXJhIHhtbG5zOmV0ZD0iaHR0cDovL2NyZC5nb3YucGwveG1sL3NjaGVtYXR5L2R6aWVkemlub3dlL21mLzIwMjEvMDYvMDkvZUQvRGVmaW5pY2plVHlweS8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiDQp4bWxucz0iaHR0cDovL2NyZC5nb3YucGwvd3pvci8yMDIxLzExLzI5LzExMDg5LyI+DQoJPE5hZ2xvd2VrPg0KCQk8S29kRm9ybXVsYXJ6YSBrb2RTeXN0ZW1vd3k9IkZBICgxKSIgd2Vyc2phU2NoZW15PSIxLTBFIj5GQTwvS29kRm9ybXVsYXJ6YT4NCgkJPFdhcmlhbnRGb3JtdWxhcnphPjE8L1dhcmlhbnRGb3JtdWxhcnphPg0KCQk8RGF0YVd5dHdvcnplbmlhRmE+MjAyMy0wNy0xOVQwOTozMDo0N1o8L0RhdGFXeXR3b3J6ZW5pYUZhPg0KCQk8U3lzdGVtSW5mbz5JS0tJU29mdDwvU3lzdGVtSW5mbz4NCgk8L05hZ2xvd2VrPg0KCTxQb2RtaW90MT4NCgkJPERhbmVJZGVudHlmaWthY3lqbmU+DQoJCQk8TklQPjcyNzIzODcxOTg8L05JUD4NCgkJCTxQZWxuYU5hendhPklLS0ktU29mdCBTcC4geiBvLm8uPC9QZWxuYU5hendhPg0KCQk8L0RhbmVJZGVudHlmaWthY3lqbmU+DQoJCTxBZHJlcz4NCgkJICAgCTxBZHJlc1BvbD4NCgkJCQk8S29kS3JhanU+UEw8L0tvZEtyYWp1Pg0KCQkJCTxVbGljYT5KYXJhY3phPC9VbGljYT4NCgkJCQk8TnJEb211PjcyPC9OckRvbXU+DQoJCQkJPE5yTG9rYWx1PkY8L05yTG9rYWx1Pg0KCQkJCTxNaWVqc2Nvd29zYz5Mb2R6PC9NaWVqc2Nvd29zYz4NCgkJCQk8S29kUG9jenRvd3k+OTAtMjUxPC9Lb2RQb2N6dG93eT4NCgkJCTwvQWRyZXNQb2w+DQoJCTwvQWRyZXM+DQoJCTxFbWFpbD5zb2Z0QGlra2kucGw8L0VtYWlsPg0KCQk8VGVsZWZvbj40MzYzOTkzODA8L1RlbGVmb24+CQkNCgk8L1BvZG1pb3QxPg0KCTxQb2RtaW90Mj4NCgkJPERhbmVJZGVudHlmaWthY3lqbmU+DQoJCQk8TklQPjcyODIyNTA0NzI8L05JUD4NCgkJCTxQZWxuYU5hendhPlRXSVNURVI8L1BlbG5hTmF6d2E+DQoJCTwvRGFuZUlkZW50eWZpa2FjeWpuZT4NCgkJPEFkcmVzPg0KCQkgICAJPEFkcmVzUG9sPg0KCQkJCTxLb2RLcmFqdT5QTDwvS29kS3JhanU+DQoJCQkJPFVsaWNhPlJvam5hPC9VbGljYT4NCgkJCQk8TnJEb211PjI2PC9OckRvbXU+DQoJCQkJPE5yTG9rYWx1PjE2PC9Ockxva2FsdT4NCgkJCQk8TWllanNjb3dvc2M+TG9kejwvTWllanNjb3dvc2M+DQoJCQkJPEtvZFBvY3p0b3d5PjkxLTEyMzwvS29kUG9jenRvd3k+DQoJCQk8L0FkcmVzUG9sPg0KCQk8L0FkcmVzPg0KCQk8RW1haWw+dHdpc3Rlci5ha296bG93aWN6QGdtYWlsLmNvbTwvRW1haWw+DQoJCTxUZWxlZm9uPjYwMDIxNzY2OTwvVGVsZWZvbj4NCgkJPE5yS2xpZW50YT45NDQ2PC9OcktsaWVudGE+DQoJPC9Qb2RtaW90Mj4NCgk8RmE+DQoJCTxLb2RXYWx1dHk+UExOPC9Lb2RXYWx1dHk+DQoJCTxQXzE+MjAyMy0wNy0xOTwvUF8xPg0KCQk8UF8xTT5Mb2R6PC9QXzFNPg0KCQk8UF8yPkZWMjAyMy8wNy8wMDE8L1BfMj4NCgkJPFdaPjQ0MzQzNDM0LzIwMjM8L1daPg0KCQk8UF8xM18xPjUyMjYwLjEwPC9QXzEzXzE+DQoJCTxQXzE0XzE+MTIwMTkuODI8L1BfMTRfMT4NCgkJPFBfMTU+NjQyNzkuOTI8L1BfMTU+DQoJCTxBZG5vdGFjamU+DQoJCQk8UF8xNj4yPC9QXzE2Pg0KCQkJPFBfMTc+MjwvUF8xNz4NCgkJCTxQXzE4PjI8L1BfMTg+DQoJCQk8UF8xOEE+MjwvUF8xOEE+DQoJCQk8UF8xOT4yPC9QXzE5Pg0KCQkJPFBfMjI+MjwvUF8yMj4NCgkJCTxQXzIzPjI8L1BfMjM+DQoJCQk8UF9QTWFyenk+MjwvUF9QTWFyenk+DQoJCTwvQWRub3RhY2plPg0KCQk8Um9kemFqRmFrdHVyeT5WQVQ8L1JvZHphakZha3R1cnk+DQoJCTxGYVdpZXJzemU+DQoJCQk8TGljemJhV2llcnN6eUZha3R1cnk+MzwvTGljemJhV2llcnN6eUZha3R1cnk+DQoJCQk8V2FydG9zY1dpZXJzenlGYWt0dXJ5MT41MjI2MC4xMDwvV2FydG9zY1dpZXJzenlGYWt0dXJ5MT4NCgkJCTxGYVdpZXJzej4NCgkJCQk8TnJXaWVyc3phRmE+MTwvTnJXaWVyc3phRmE+DQoJCQkJPFVVX0lEPmFhYWExMTExMzMzMzk5OTA8L1VVX0lEPg0KCQkJCTxQXzZBPjIwMjItMDEtMDM8L1BfNkE+DQoJCQkJPFBfNz5sb2TDs3drYSBaaW1ub3RlY2ggbWsxPC9QXzc+DQoJCQkJPENOPjg0MTggMjEgOTE8L0NOPg0KCQkJCTxQXzhBPnN6dC48L1BfOEE+DQoJCQkJPFBfOEI+MTA8L1BfOEI+DQoJCQkJPFBfOUE+MTYyNi4wMTwvUF85QT4NCgkJCQk8UF8xMT4xNjI2MC4xMDwvUF8xMT4NCgkJCQk8UF8xMj4yMzwvUF8xMj4NCgkJCQk8UF8xMl9Qcm9jZWR1cmE+NzwvUF8xMl9Qcm9jZWR1cmE+DQoJCQk8L0ZhV2llcnN6Pg0KCQkJPEZhV2llcnN6Pg0KCQkJCTxOcldpZXJzemFGYT4yPC9OcldpZXJzemFGYT4NCgkJCQk8VVVfSUQ+YWFhYTExMTEzMzMzOTk5MTwvVVVfSUQ+DQoJCQkJPFBfNkE+MjAyMi0wMS0xMDwvUF82QT4NCgkJCQk8UF83PnphbXJhxbxhcmthIFppbW5vdGVjaCBtazI8L1BfNz4NCgkJCQk8Q04+ODQxOCA0MCAyMDwvQ04+DQoJCQkJPFBfOEE+c3p0LjwvUF84QT4NCgkJCQk8UF84Qj4yMDwvUF84Qj4NCgkJCQk8UF85QT4xMDAwPC9QXzlBPg0KCQkJCTxQXzEwPjEwMDwvUF8xMD4NCgkJCQk8UF8xMT4xODAwMDwvUF8xMT4NCgkJCQk8UF8xMj4yMzwvUF8xMj4NCgkJCQk8UF8xMl9Qcm9jZWR1cmE+NzwvUF8xMl9Qcm9jZWR1cmE+DQoJCQk8L0ZhV2llcnN6Pg0KCQkJPEZhV2llcnN6Pg0KCQkJCTxOcldpZXJzemFGYT4zPC9OcldpZXJzemFGYT4NCgkJCQk8VVVfSUQ+YWFhYTExMTEzMzMzOTk5MjwvVVVfSUQ+DQoJCQkJPFBfNkE+MjAyMi0wMS0xNTwvUF82QT4NCgkJCQk8UF83PnpteXdhcmthIEJyeXphIDEwMDwvUF83Pg0KCQkJCTxDTj44NDIyIDExIDAwPC9DTj4NCgkJCQk8UF84QT5zenQuPC9QXzhBPg0KCQkJCTxQXzhCPjE1PC9QXzhCPg0KCQkJCTxQXzlBPjEyMDA8L1BfOUE+DQoJCQkJPFBfMTE+MTgwMDA8L1BfMTE+DQoJCQkJPFBfMTI+MjM8L1BfMTI+DQoJCQkJPFBfMTJfUHJvY2VkdXJhPjc8L1BfMTJfUHJvY2VkdXJhPg0KCQkJPC9GYVdpZXJzej4NCgkJPC9GYVdpZXJzemU+DQoJCTxSb3psaWN6ZW5pZT4NCgkJCTxPZGxpY3plbmlhPg0KCQkJCTxLd290YT4xMDAwPC9Ld290YT4NCgkJCQk8UG93b2Q+bmFkd3nFvGthIHNhbGRhIG5pZXJvemxpY3pvbnljaCDFm3JvZGvDs3c8L1Bvd29kPg0KCQkJPC9PZGxpY3plbmlhPg0KCQkJPFN1bWFPZGxpY3plbj4xMDAwPC9TdW1hT2RsaWN6ZW4+DQoJCQk8RG9aYXBsYXR5PjYzMjc5LjkyPC9Eb1phcGxhdHk+DQoJCTwvUm96bGljemVuaWU+DQoJCTxQbGF0bm9zYz4NCgkJCTxUZXJtaW55UGxhdG5vc2NpPg0KCQkJCTxUZXJtaW5QbGF0bm9zY2k+MjAyMi0wMy0xNTwvVGVybWluUGxhdG5vc2NpPg0KCQkJPC9UZXJtaW55UGxhdG5vc2NpPg0KCQkJPEZvcm1hUGxhdG5vc2NpPjY8L0Zvcm1hUGxhdG5vc2NpPg0KCQkJPFJhY2h1bmVrQmFua293eUZha3RvcmE+DQoJCQkJPE5yUkJQTD43MzExMTExMTExMTExMTExMTExMTExMTExMTwvTnJSQlBMPg0KCQkJCTxSYWNodW5la1dsYXNueUJhbmt1PjI8L1JhY2h1bmVrV2xhc255QmFua3U+DQoJCQkJPE5hendhQmFua3U+QmFuayBCYW5rb3dvxZtjaSBCYW5rb3dlaiBTLiBBLjwvTmF6d2FCYW5rdT4NCgkJCTwvUmFjaHVuZWtCYW5rb3d5RmFrdG9yYT4NCgkJPC9QbGF0bm9zYz4NCgkJPFdhcnVua2lUcmFuc2FrY2ppPg0KCQkJPFphbW93aWVuaWE+DQoJCQkJPERhdGFaYW1vd2llbmlhPjIwMjItMDEtMjY8L0RhdGFaYW1vd2llbmlhPg0KCQkJCTxOclphbW93aWVuaWE+NDM1NDM0MzwvTnJaYW1vd2llbmlhPg0KCQkJPC9aYW1vd2llbmlhPg0KCQkJPE5yUGFydGlpVG93YXJ1PjIzMTIzMjMvMjAyMjwvTnJQYXJ0aWlUb3dhcnU+DQoJCQk8V2FydW5raURvc3Rhd3k+Q0lQPC9XYXJ1bmtpRG9zdGF3eT4NCgkJCTxUcmFuc3BvcnQ+DQoJCQkJPFJvZHphalRyYW5zcG9ydHU+MzwvUm9kemFqVHJhbnNwb3J0dT4NCgkJCQk8UHJ6ZXdvem5paz4NCgkJCQkJPERhbmVJZGVudHlmaWthY3lqbmU+DQoJCQkJCQk8TklQPjY2NjY2NjY2NjY8L05JUD4NCgkJCQkJCTxJbWllUGllcndzemU+SmFuPC9JbWllUGllcndzemU+DQoJCQkJCQk8TmF6d2lza28+Tm93YWs8L05hendpc2tvPg0KCQkJCQkJPE5hendhSGFuZGxvd2E+SmFuIE5vd2FrIFRyYW5zcG9ydDwvTmF6d2FIYW5kbG93YT4NCgkJCQkJPC9EYW5lSWRlbnR5ZmlrYWN5am5lPg0KCQkJCQk8QWRyZXNQcnpld296bmlrYT4NCgkJCQkJCTxBZHJlc1BvbD4NCgkJCQkJCQk8S29kS3JhanU+UEw8L0tvZEtyYWp1Pg0KCQkJCQkJCTxVbGljYT5CdWtvd2E8L1VsaWNhPg0KCQkJCQkJCTxOckRvbXU+NTwvTnJEb211Pg0KCQkJCQkJCTxNaWVqc2Nvd29zYz5Qb3puYcWEPC9NaWVqc2Nvd29zYz4NCgkJCQkJCQk8S29kUG9jenRvd3k+MDAtMDA0PC9Lb2RQb2N6dG93eT4NCgkJCQkJCTwvQWRyZXNQb2w+DQoJCQkJCTwvQWRyZXNQcnpld296bmlrYT4NCgkJCQk8L1ByemV3b3puaWs+DQoJCQkJPE9waXNMYWR1bmt1PjEzPC9PcGlzTGFkdW5rdT4NCgkJCQk8SmVkbm9zdGthT3Bha293YW5pYT5hPC9KZWRub3N0a2FPcGFrb3dhbmlhPg0KCQkJCTxXeXN5bGthWj4NCgkJCQkJPEFkcmVzUG9sPg0KCQkJCQkJPEtvZEtyYWp1PlBMPC9Lb2RLcmFqdT4NCgkJCQkJCTxVbGljYT5Ld2lhdG93YTwvVWxpY2E+DQoJCQkJCQk8TnJEb211PjE8L05yRG9tdT4NCgkJCQkJCTxOckxva2FsdT4yPC9Ockxva2FsdT4NCgkJCQkJCTxNaWVqc2Nvd29zYz5XYXJzemF3YTwvTWllanNjb3dvc2M+DQoJCQkJCQk8S29kUG9jenRvd3k+MDAtMDAxPC9Lb2RQb2N6dG93eT4NCgkJCQkJPC9BZHJlc1BvbD4NCgkJCQk8L1d5c3lsa2FaPg0KCQkJCTxXeXN5bGthRG8+DQoJCQkJCTxBZHJlc1BvbD4NCgkJCQkJCTxLb2RLcmFqdT5QTDwvS29kS3JhanU+DQoJCQkJCQk8VWxpY2E+U2Fkb3dhPC9VbGljYT4NCgkJCQkJCTxOckRvbXU+MTwvTnJEb211Pg0KCQkJCQkJPE5yTG9rYWx1PjM8L05yTG9rYWx1Pg0KCQkJCQkJPE1pZWpzY293b3NjPktyYWvDs3c8L01pZWpzY293b3NjPg0KCQkJCQkJPEtvZFBvY3p0b3d5PjAwLTAwMjwvS29kUG9jenRvd3k+DQoJCQkJCTwvQWRyZXNQb2w+DQoJCQkJPC9XeXN5bGthRG8+DQoJCQk8L1RyYW5zcG9ydD4NCgkJPC9XYXJ1bmtpVHJhbnNha2NqaT4NCgk8L0ZhPg0KCTxTdG9wa2E+DQoJCTxJbmZvcm1hY2plPg0KCQkJPFN0b3BrYUZha3R1cnk+S2FwaWHFgiB6YWvFgmFkb3d5IDUgMDAwIDAwMDwvU3RvcGthRmFrdHVyeT4NCgkJPC9JbmZvcm1hY2plPg0KCQk8UmVqZXN0cnk+DQoJCQk8S1JTPjAwMDAwOTk5OTk8L0tSUz4NCgkJCTxSRUdPTj45OTk5OTk5OTk8L1JFR09OPg0KCQkJPEJETz4wMDAwOTk5OTk8L0JETz4NCgkJPC9SZWplc3RyeT4NCgk8L1N0b3BrYT4NCjwvRmFrdHVyYT4NCg=="}
}

Po wysyłce otrzymuję wyjątek:

{"exception":{"serviceCtx":"srvTEMFA","serviceCode":"20230719-EX-0F70995B09-7FA330D830-70","serviceName":"online.invoice.invoice.send","timestamp":"2023-07-19T13:17:40.484Z","referenceNumber":"20230719-SE-ED9DD3BE25-9E8A8EF25B-B6","exceptionDetailList":[{"exceptionCode":21404,"exceptionDescription":"Nieprawidłowy format dokumentu (json)."}]}}

Co jest nie tak w moim formacie?

0

Jaki element faktury używacie/będziecie używać aby zidentyfikować wersję schemy FA(1) vs FA(2) dokumentu pobranego z KSeF? Bo numer wersji schemy zmienił się w stosunku do wcześniejszej definicji w dwóch miejscach: TKodFormularza.kodSystemowy ="FA (2)", WariantFormularza="2" , a w trzecim (TKodFormularza.wersjaSchemy ="1-0E") pozostał bez zmian.

0

Czy miał ktoś sytuację, w której faktury na preprodzie się nie pobierały mimo, że zawierały się w zakresie dat?

Przykład: wrzucone 3 faktury o 13:11 - synchronizacja dat między 12:00 a 14:00 - wynik: 0 faktur pobranych

0

Czy ma ktoś może plik InitSessionTokenRequest dla wersji FA (2)? samo podmienienie poniższych danych powoduje błąd Nieprawidłowy typ dokumentu.


<ns2:SystemCode>FA (2)</ns2:SystemCode>

<ns2:SchemaVersion>1-0E</ns2:SchemaVersion>

<ns2:TargetNamespace>http://crd.gov.pl/wzor/2023/06/29/12648/</ns2:TargetNamespace>

<ns2:Value>FA</ns2:Value>

</ns2:FormCode>

0

Czy ktoś z Was używał plik schemat.xsd do walidacji swojego xml ze schemą ? Pracuję, aby jakoś kontrolować jesli dane z mojego xml są niepoprawne ze schemą ?
Używam takiej klasy XmlReaderSettings ale ma problem z xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" enumeration. Miał ktoś może podobny przypadek, ale coś podobnego próbował uzyskać ?

0

Mam taką prośbę/sugestię - głównie chyba @andi00 @TymOnX @gbbsoft @Stl86 @Małgorzata Gunia ale jak ktoś jeszcze, to też...
Z racji, że dokumentacja jest jaka jest, Szwagra nie ma, to czy ktoś ma przetestowane wszystkie możliwości odpytań o faktury i mógłby w jednym poście dać opis, przykładowe zapytanie i skomentować parametry (możliwe zakresy) do /online/Query/Invoice/Sync (czy opłaca się w ogóle robić Async?)... Ja wciąż nie umiem ogarnąć działania incrementa... Wiem, że już kilka postów o tym było, ale może warto byłoby zebrać teraz wyniki doświadczeń w jednym miejscu?

0

Czy dzisiaj działa serwer testowy ? Ja mam ciągle 400.
Mam wrażenie że nie... Może (lipiec się kończy i) trwa wprowadzanie FA(2) ?
Strona web też nie wchodzi.

0

Mam pytanie odnośnie przekazywania faktur do KSeF które zostały wystawione w trybie "offline" (w trakcie awarii działania KSeF). Obiła się o mnie informacja nie wiem czy prawdziwa, że do przesyłania takich faktur potrzebny jest jakiś kod QR albo inny parametr określający taką fakturę wystawioną offline. Pytanie brzmi gdzie należy przekazywać te parametry o fakturach offline w przypadku wysyłki w sesji interaktywnej/wsadowej? Czy to jest jakiś parametr wewnątrz faktury czy gdzieś w zapytaniu należy coś dodatkowo przesłać? I skąd te parametry należy w ogóle wziąć?

1

Prawdopodobnie w niedziele wprowadzą FA(2), na stronie jest komunikat: https://www.podatki.gov.pl/komunikaty-techniczne/prace-serwisowe-na-srodowisku-testowym-krajowego-systemu-e-faktur/
"31 lipca 2023 r. w godzinach od 12.00 do 13:00 będą prowadzone prace serwisowe na środowisku testowym Krajowego Systemu e-Faktur.
W tym czasie mogą wystąpić chwilowe utrudnienia w dostępie do tego środowiska.
Przepraszamy za utrudnienia."

0

Ja czegoś nie widzę w dokumentacji, czy co? Chcę po prostu odczekać na autoryzowanie się sesji, żeby móc pobrać listę faktur; robię:
online/Session/Status?PageSize=1&PageOffset=0
Bad request
online/Session/Status?PageSize=2&PageOffset=0
Bad request
online/Session/Status?PageSize=10&PageOffset=0
Wszystko ok.

A w YAMLU widzę jak byk:
name: PageSize
required: true
schema:
type: integer
format: int32
maximum: 100
minimum: 0

Czemu ten system jest tak durny, że mam mu nakazywać pobieranie 10 faktur podczas, gdy mnie wcale one nie interesują?

A w ogóle robię po tym:
online/Query/Invoice/Sync?PageSize=100&PageOffset=0

i mi timeout wywala (bo za duży zakres czasowy chyba)

EDIT: Dla NIP 5170359458 system testowy, range - pobieranie z zakresu 03.01.2023-27.07.2023 trwa 40 sekund
dla zakresu 04.01.2023-27.07.2023 trwa 3 sekundy

Oba zwracają tą samą ilość wyników. Dziwne...

0

Cześć,
w piątek Sejm odrzucił weto Senatu i KSeF wchodzi na dobre od 1 lipca 2024 r.

Jestem nowy :-) Przeanalizowałem całą dyskusję w wątku i w większości dotyczy komunikacji z KSeF. Jestem analitykiem biznesowym i zaczynam na dobre analizę pod modyfikację procesów w systemach fakturujących i dopiero później komunikacji.

Czy w tym wątku można prowadzić również dyskusję na temat wymagań funkcjonalnych systemów fakturujących, sposoby generowania FV z QR Kod, generowania xmla? Czy też to jest tylko wątek techniczny związany z komunikacją?

Na dobry początek dla analityków materiał z Senatu obrazujący wszystkie zmiany w ustawie o VAT związane z KSeF. Cobyśmy nie sklejali z treści nowelizacji, co gdzie zmieniać:
KSeF_wszystkie_zmiany_ustawy.pdf

0

Jak sprawdzacie czy wysłana faktura została już przyjęta u nich ? Jaką macie ścieżkę, żeby zaktualizować sobie info o statusie faktury już w swojej bazie ?

0

Stl86 napisał(a):

Jak sprawdzacie czy wysłana faktura została już przyjęta u nich ? Jaką macie ścieżkę, żeby zaktualizować sobie info o statusie faktury już w swojej bazie ?

czy przyjęta w KSEF? Po wysłaniu faktury w wyniku jest odpowiedź czy faktura jest zaakceptowana czy nie. Jeśli tak to po chwili wywołuję pobranie UPO dla sesji w której wysyłałem faktury. UPO jest potwierdzeniem zarejestrowania faktury w KSEF.

0

marek.kotowski napisał(a):

Stl86 napisał(a):

Jak sprawdzacie czy wysłana faktura została już przyjęta u nich ? Jaką macie ścieżkę, żeby zaktualizować sobie info o statusie faktury już w swojej bazie ?

czy przyjęta w KSEF? Po wysłaniu faktury w wyniku jest odpowiedź czy faktura jest zaakceptowana czy nie. Jeśli tak to po chwili wywołuję pobranie UPO dla sesji w której wysyłałem faktury. UPO jest potwierdzeniem zarejestrowania faktury w KSEF.

no tak, przy wysyłce faktury za pomoca /online/Invoice/Send potem pobieram status wysłanej faktury /online/Invoice/Status/{elementReferenceNumber} i w niej mam informację o tym czy została zaakceptowana i potem pobieram UPO

0

Też Wam nie działa od 15 minut? Nie dość, że 1/6 zapytań wywala się czymś z d*, tak teraz w ogóle nic... najpierw 404, teraz już w ogóle pluje jakimś "unknown error".

Stl86 napisał(a):

marek.kotowski napisał(a):

Stl86 napisał(a):

0 użytkowników online, w tym zalogowanych: 0, gości: 0

Praca dla programistów

Forum dyskusyjne

Sprawy administracyjne

O nas

Skontaktuj się z nami