Krajowy system e-Faktur

Zauważyłem że w przypadku odświeżania tokenu przez pewien krótki czas (około minuty) nie działa nowy token do api Ksef dla zapytania o nagłówki faktur online/Query/Invoice/Sync, po czym zapytania znowu normalnie przechodzą. W odpowiedzi dostaję jako błąd:

{
    "exception": {
        "serviceCtx": "srvTEMFA",
        "serviceCode": "20221123-EX-342003693B-22F3584AE1-C4",
        "serviceName": "online.query.query.invoice",
        "timestamp": "2022-11-23T11:27:08.260Z",
        "referenceNumber": "20221123-SE-E01DE39B84-F4A5D0BAB9-79",
        "exceptionDetailList": [
            {
                "exceptionCode": 21304,
                "exceptionDescription": "Brak uwierzytelnienia."
            }
        ]
    }
}

Czy ktoś natrafił na podobny błąd, czy może należy odczekać jakiś czas po odświeżeniu tokenu żeby z niego korzystać(co wydaję się dosyć szalone ale przyznam że już spodziewam się wszystkiego)?

Wysyłam paczkę faktur interfejsem wsadowym (​/batch​/*) z podpisem.
W odpowiedzi dostaję tylko timestamp i referenceNumber.
Okazuje się że 1 faktura na X ma błąd.
W jaki sposób mogę dowiedzieć się która ?

GET /common/Status/{ReferenceNumber} zwraca tylko błąd do całej sesji i ew. UPO jak wszystko jest OK.

GET /online​/Session​/Status​/{ReferenceNumber} owszem zwraca mi wszystkie faktury i ich błędy, ale nie mam jak powiązać konkretnego błędu z fakturą bo nie mam elementReferenceNumber a invoiceNumber jest NULL

{
"timestamp": "2022-11-25T10:26:40.007Z",
"referenceNumber": "20221124-SE-4C3610EE2B-A61CB53052-xx",
"numberOfElements": 1,
"pageSize": 10,
"pageOffset": 0,
"processingCode": 441,
"processingDescription": "Błąd etapu weryfikacji wyników podprocesów przetwarzania faktury",
"invoiceStatusList": [
{
"processingCode": 430,
"processingDescription": "Nieprawidłowy wystawca dokumentu.",
"elementReferenceNumber": "20221124-EA-9C3DB17723-2CDFDC597A-xx",
"invoiceNumber": null,
"ksefReferenceNumber": null,
"acquisitionTimestamp": null
}
]
}

Czy da się wystawić fakturę końcową (rozliczającą "ROZ") tak aby jej kwota wyszła ujemna (czyli zwrot dla klienta)?. U nas w firmie to częsty przypadek gdy zaliczka była większa niż wartość usługi i na fakturze końcowej jest kwota ujemna. Próbuję to samo zrobić na ksef ale nie da się wstawić nigdzie ujemnych kwot (ani jako pozycja na fakturze ani w wartości faktury). Najwyżej mogę ją wyzerować. I jeszcze jedno pytanie, numery faktur zaliczkowych na końcowej wpisuje się ksefowe czy to są numery z programu księgowego sprzedawcy?

Zauważyłem że od wczoraj na serwerze testowym nie działa endpoint online/Session/Status
W odpowiedzi na request otrzymuję response jak poniżej :

{"exception":
  {"serviceCtx":"srvTEMFA",
   "serviceCode":"F4EF745C-E93F-46DB-A4C1-71FF10B5E062",
   "serviceName":"exception.handler",
   "timestamp":"2022-11-26T16:42:39.076Z",
   "referenceNumber":null,
   "exceptionDetailList":
     [{"exceptionCode":21100,
      "exceptionDescription":"Nieprawidłowe żądanie."
      }
     ]
  }
}

Na serwerze produkcyjnym ten sam request zwraca prawidłowy response.
Może ktoś wie o co chodzi. Jakieś prace serwisowe ?

Rozszyfrowaliście te limity ? Widzę, że jakieś znowu zmiany wprowadzili ale ja przyznam, że nie rozumiem do końca tego pliku ? Czy to jest w ramach nawiązanej sesji i faktycznie to jest w MINUTACH? Raz mi się pojawia błąd, raz nie.. z limitem żądań.. ;/ w sytuacji jak próbuje go specjalnie wywołać..

Cześć, gdzie mogę znaleźć wszystkie 'processingCode' dla wysłanej faktury. Bo jak na razie z tej bramki 'GET /online​/Invoice​/Status​/{InvoiceElementReferenceNumber}' tylko z requestów odczytałem sobie 200 i 425

dorakeen napisał(a):

Witam

Wie ktoś może o co chodzi z tym błędem ?
Otrzymuję go wysyłając polecenie /batch/Init.

dziękuję

400
{"exception":{"serviceCtx":"srvTEMFB","serviceCode":"20221122-EX-784D1F6DAA-0BA4C9BCAB-DE","serviceName":"batch.init","timestamp":"2022-11-22T15:21:35.657Z","referenceNumber":"20221122-SE-D4BE53820E-0E08DAA437-03","exceptionDetailList":[{"exceptionCode":21406,"exceptionDescription":"Konflikt podpisu i typu uwierzytelnienia."}]}}

Nadal nie mogę pokonać tego problemu... co jest nie tak z moim plikiem initRequest.xml?

initRequest.xml.zip

dziękuję

Witam,
Robię testy na NIPie 1111111111. Robię zapytanie: POST online/Query/Invoice/Sync?PageSize=100&PageOffset=0
{"queryCriteria":{"subjectType":"subject1","type":"incremental","acquisitionTimestampThresholdFrom":"2022-10-27T22:00:00.000Z","acquisitionTimestampThresholdTo":"2022-10-28T21:59:59.999Z"}}

Otrzymuję odpowiedź:
"numberOfElements": 480,
"pageSize": 100,
"pageOffset": 0,

System nie zwraca 480 nagłówków tylko 464:
/api/online/Query/Invoice/Sync?PageSize=100&PageOffset=0 - 98 faktur
/api/online/Query/Invoice/Sync?PageSize=100&PageOffset=1 - 97 faktur
/api/online/Query/Invoice/Sync?PageSize=100&PageOffset=2 - 96 faktur
/api/online/Query/Invoice/Sync?PageSize=100&PageOffset=3 - 98 faktur
/api/online/Query/Invoice/Sync?PageSize=100&PageOffset=4 - 75 faktur

Czy ja robię coś źle czy to po stronie KSeF?

Czy ktoś może robił integrację z KSEF w niszowym oprogramowaniu jakim jest ABAP (SAP) i mógłby się podzielić wskazówkami ?

dorakeen napisał(a):

dorakeen napisał(a):

Witam

Wie ktoś może o co chodzi z tym błędem ?
Otrzymuję go wysyłając polecenie /batch/Init.

dziękuję

400
{"exception":{"serviceCtx":"srvTEMFB","serviceCode":"20221122-EX-784D1F6DAA-0BA4C9BCAB-DE","serviceName":"batch.init","timestamp":"2022-11-22T15:21:35.657Z","referenceNumber":"20221122-SE-D4BE53820E-0E08DAA437-03","exceptionDetailList":[{"exceptionCode":21406,"exceptionDescription":"Konflikt podpisu i typu uwierzytelnienia."}]}}

Nadal nie mogę pokonać tego problemu... co jest nie tak z moim plikiem initRequest.xml?

initRequest.xml.zip

dziękuję

Witam

Czy jest ktoś, kto ma ważny podpisany plik initRequest.xml, aby podzielić się ze mną ?
dziękuję

Hej,
Czy coś się zmieniło w wysyłce wsadowej? Od niedawna zauważyłem problem przy inicjalizacji sesji wsadowej tj. Dokument nie jest zgodny ze schemą (xsd).

{"exception":{"serviceCtx":"srvTEMFB","serviceCode":"20221201-EX-AB59606E12-E4146AB472-32","serviceName":"batch.init","timestamp":"2022-12-01T00:40:14.722Z","referenceNumber":"20221201-SE-61DD7B1D4C-C438176766-A3","exceptionDetailList":[{"exceptionCode":21401,"exceptionDescription":"Dokument nie jest zgodny ze schemą (xsd)."}]}}

Wygenerowany XML na potrzeby endpointa "/batch/Init" walidowałem i żadnych błędów nie widzę (walidacja bez podpisu). Również walidowałem sam dokument FA(1) i tutaj także nie widać problemów.

Z drugiej strony, wysyłka dokładnie tej samej faktury, ale za pomocą sesji interaktywnej (autoryzacja tokenem) przechodzi pomyślnie i faktura widoczna jest w systemie. Walidacja dokumentu wygenerowanego na potrzeby endpointa "/online/Invoice/Send" także jest poprawna. W obu przypadkach (sesja wsadowa i interaktywna) korzystam z API testowego.

Poniżej załączam wygenerowany XML dla wysyłki wsadowej (z podpisem)

<?xml version="1.0" encoding="utf-8"?>
<InitRequest xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/init/request/2021/10/01/0001">
   <Identifier xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="p3:SubjectIdentifierByCompanyType" xmlns:p3="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
      <Identifier xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">1112223334</Identifier>
   </Identifier>
   <DocumentType>
      <Service xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">KSeF</Service>
      <FormCode xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
         <SystemCode>FA (1)</SystemCode>
         <SchemaVersion>1-0E</SchemaVersion>
         <TargetNamespace>http://ksef.mf.gov.pl/schema/gtw/svc/batch/init/request/2021/10/01/0001</TargetNamespace>
         <Value>FA</Value>
      </FormCode>
   </DocumentType>
   <Encryption>
      <EncryptionKey xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
         <Encoding>Base64</Encoding>
         <Algorithm>AES</Algorithm>
         <Size>256</Size>
         <Value>LSeamZwDYJoTchws6cFdGR2r+pv8rH1h9aG38pdP7GRjHMb7fr3p9X7ywpP3GU9zwy2jc10KkN/vB4Q1z7dSxEY0qzsdKSP27+hmU9dkDcX9oDUvtPKXoCVlLVahCGGgjicdKm0dsfK6MwqgvvyzsF0Hyq96Ukj05rjUbro9G21AupaIaqMvCyWyWlq/4ydowCxZOGYmjb+9Tsbf4JSpUZXKjECwGc0CoGOUQSbAMnVci11ZjzYvFyx1vF7PoRBCFdtRSPqps3GfXYAUGzqmS/AnlHDRMVTDj423qm1oMSPLudfEUHQ0mDSed64XNiRQGRLYusXDpPjEFadOZ87huA==</Value>
      </EncryptionKey>
      <EncryptionInitializationVector xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
         <Encoding>Base64</Encoding>
         <Bytes>16</Bytes>
         <Value>NDYNC2LmkDfxXIsoGGEzIQ==</Value>
      </EncryptionInitializationVector>
      <EncryptionAlgorithmKey xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
         <Algorithm>RSA</Algorithm>
         <Mode>ECB</Mode>
         <Padding>PKCS#1</Padding>
      </EncryptionAlgorithmKey>
      <EncryptionAlgorithmData xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
         <Algorithm>AES</Algorithm>
         <Mode>CBC</Mode>
         <Padding>PKCS#7</Padding>
      </EncryptionAlgorithmData>
   </Encryption>
   <PackageSignature>
      <Package>
         <PackageType xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">split</PackageType>
         <CompressionType xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">zip</CompressionType>
         <Value xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">KsefBatch-20221201-013025048</Value>
      </Package>
      <PackageFileHash>
         <HashSHA xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
            <Algorithm>SHA-256</Algorithm>
            <Encoding>Base64</Encoding>
            <Value>Vjkx9I7in7rc/ef4lqo90NuRomqscRo6cMDFGRJE5ms=</Value>
         </HashSHA>
         <FileSize xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">2927</FileSize>
      </PackageFileHash>
      <PackagePartsList>
         <PackagePartSignature>
            <OrdinalNumber xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">1</OrdinalNumber>
            <PartFileName xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">KsefBatch-20221201-013025048.zip.aes</PartFileName>
            <PartFileHash xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">
               <HashSHA xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">
                  <Algorithm>SHA-256</Algorithm>
                  <Encoding>Base64</Encoding>
                  <Value>c6Gbzh+5fRYPNk0kkuxNxfVJh7Bfo3M/LSXbx7hfEtU=</Value>
               </HashSHA>
               <FileSize xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001">2928</FileSize>
            </PartFileHash>
         </PackagePartSignature>
      </PackagePartsList>
   </PackageSignature>
   <ds:Signature Id="SignatureId-4a04e11a-a80e-4419-a4ee-e45e050ccf5e" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
         <ds:Reference URI="">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
               <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <ds:DigestValue>q/iKItjSjwG7nDv9CwMS3AGFX/55mJnSt8fi14CpVsI=</ds:DigestValue>
         </ds:Reference>
         <ds:Reference URI="#SignedPropertiesId-4a04e11a-a80e-4419-a4ee-e45e050ccf5e" Type="http://uri.etsi.org/01903/v1.3.2#SignedProperties">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <ds:DigestValue>aLhXVbRaleZXHeVfpeAOc/7eXYjgEkReo065MZqxAsA=</ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>KriBpSC7xbmNNBIMRwzU4ccI60LcqFAwGRbzUo7Mp0mqXgQ6bT2Y1sbdvbYuSuy8d6NdHU2kkZ5tK9q9kZcFn2pu97tpDZ0cqN8KqOaY+7tXDXX9cpLAWJe3tc3EAadMvA1Wu7G1Uxb6yF39TBdiHR77u9JvXYAVIOpX74ydrmhS4galAHIxk3lUuRUJWUmDyMKiaRkHB97kTX+U4eDDBS9i5uRW1o7XQPEEiU604/AQJ+RnVykmx2ADcDKIkm2gaTDRDrHPGnEM3HrajNCGH0V9VsRDA4uZcWb57sAdQRO/r0eptIVDli0vppVkQYvIx0TKFOo18Rj+2nn8ELJyZQ==</ds:SignatureValue>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>MIIDSTCCAjECFF79LP7/MCyuxuJHg+7vHnlPv64rMA0GCSqGSIb3DQEBCwUAMGExHTAbBgNVBAMMFE9sZ2llcmQgV2lzbmlvd2llY2tpMRAwDgYDVQQqDAdPbGdpZXJkMRUwEwYDVQQEDAxXaXNuaW93aWVja2kxFzAVBgNVBAUTDk5JUC04Mzg5MzMxNDQ2MB4XDTIyMDMxMjAxNTkzM1oXDTIzMDMxMjAxNTkzM1owYTEdMBsGA1UEAwwUT2xnaWVyZCBXaXNuaW93aWVja2kxEDAOBgNVBCoMB09sZ2llcmQxFTATBgNVBAQMDFdpc25pb3dpZWNraTEXMBUGA1UEBRMOTklQLTgzODkzMzE0NDYwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmMS21/q5W2s557r7Yhhl7sYFarPhvComqmmQ1RAGLXLeM2rO0XqYcfivpiDzLLARn1ubGjjz/WbIw3RY1jDGL1Gs5TbDOBHSbGs74bcERSYEOCTqa1ajLgraX+r+V87cMDMWAODEi0kKXTp8CvEItMI9n6QA8v57BKc9+3dEg2Xlkc87cAq2SDtRYqR+khjKak3fjFv/V2UcvRspskUkJfLwO4kmdkAeW2zGlDJYk9MQK6WK7zUrAZ/lZbqzSbg4THGe51Q/CrstQohphG98pTorJtSI6NmksVAIWEq8ZtZNbfkMOoiQjNvSCU8drMBjfedwKuHwjWiVh7fx0Ls97AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAIarwAMllTKsnoRqMtl5T1KPPbqtdIfqIK6QDPxuKUG1+KO/AEX0AmhsXtgdLfcktPGEonYGvJiJ7G6i9tVoYs5xZgOV3dLSl9lFQEeJqmLsw9W/l6v3/Asi7goxrzAEU0AhwFkPFI4JeVImuT3KawNtxXYtbnyBH/4p5D5tMTVz4IE16T8itQM2TelydNE1+vpJTBSQxXOF+LG8EtAqjA63p3AZXYtLpo0J7Wu8/fNpzgzOu8GUekp8JBx9r9BH16zOiV3Ywj3LW+eF/W54GvcP40gSIW8ANyh9Um2dFk1BBhsqOmvjS6cTgy9HXax3CHWB8fLzpWTE+JezEHGHRPM=</ds:X509Certificate>
         </ds:X509Data>
      </ds:KeyInfo>
      <ds:Object>
         <xades:QualifyingProperties Target="#SignatureId-4a04e11a-a80e-4419-a4ee-e45e050ccf5e" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">
            <xades:SignedProperties Id="SignedPropertiesId-4a04e11a-a80e-4419-a4ee-e45e050ccf5e">
               <xades:SignedSignatureProperties>
                  <xades:SigningTime>2022-12-01T01:30:25.539Z</xades:SigningTime>
                  <xades:SigningCertificate>
                     <xades:Cert>
                        <xades:CertDigest>
                           <xades:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                           <xades:DigestValue>aAhnNcYxTEyDlySgDnYnhO2KXs4=</xades:DigestValue>
                        </xades:CertDigest>
                        <xades:IssuerSerial>
                           <ds:X509IssuerName>SERIALNUMBER=NIP-1112223334, SN=Kowalski, G=Janusz, CN=Janusz Kowalski</ds:X509IssuerName>
                           <ds:X509SerialNumber>542291140704174633749583876758472265606769913387</ds:X509SerialNumber>
                        </xades:IssuerSerial>
                     </xades:Cert>
                  </xades:SigningCertificate>
               </xades:SignedSignatureProperties>
            </xades:SignedProperties>
         </xades:QualifyingProperties>
      </ds:Object>
   </ds:Signature>
</InitRequest>

Z góry dzięki!

Hej,

Może ktoś wesprzeć w interpretacji:

"Wartości limitów są akumulowane dla każdego duplikatu wywołania usługi. Czas życia akumulatora kończy się po określonym czasie od momentu zarejestrowania ostatniego duplikatu wywołania usługi. "

Anlaizując :"online.session.authorisation.challenge | limit : 2 | czas życia : 2".
-> Jeżeli 2 razy wykonam to czekam 2 min. (Ograniczenie na liczbę identycznych wywołań usługi authorisation.challenge w sekwencji.)

pytanie co jaki czas nie są akumulowane. Jeżeli wywołam "challenge" za jakies 20 min "challenge" to czy on jest brany do kumulacji czy jak to interpretpwać.

Dziękuję za wszelkie informację.

Hej,

Zajmuje się wysyłką wsadową do ksefu od paru dni i po wysłaniu batch/Init dostaje 200 i na podstawie zwróconego url wywołuje batch/Upload gdzie w headers mam ustawione: Content-Length, Content-Type, X-targetXrv-Name i Content-SHA256 zgodnie z odpowiedzią batch/Init. Wynik jest zawsze ten sam, 400 "Nieprawidłowy skórt części pakietu.".

Próbowałem szyfrować archiwum na różne sposoby, ale bez skutku:
fileContent -> kompresja (bez dzielenia, jedna faktura, ~1kb) -> skrót sha256 -> base64 i to do request.init:PackageFileHash
i potem dla tej jednej części już skompresowanej (czyli w zasadzie tego samego) -> aes + passphrase co ksef w dokumentacji ujmuje jako "klucz symetryczny aes" + iv -> skrót sha256 -> base64
Metody kompresji, których próbowałem (PHP): gzencode, gzdefale, ZipArchive

Czy moja metoda rozumowania klucza symetrycznego aes jest poprawna, że to jest po prostu secret, którego będę używał przy szyfrowaniu aes?
xml (bez nipu i podpisu), który wysyłam w batch/Init
initRequest.zip

Tak z ciekaości, ktoś wie czemu api ksefu przy wyzwaniu autoryzacji sesji wysyła znacznik czasowy w czasie GMT ale oczekuje użycia tego znacznika w tokenie ale w czasie lokalnym? Już nie pytam czemu tego nie ma w dokumentacji bo sie domyślam :).

Nowa wersja schemy FA(2) i całkiem nowa FA_RR
wczoraj zostaly opublikowane przez MF do konsultacji https://www.gov.pl/web/finanse/konsultacje-podatkowe-struktur-logicznych-fa2-i-farr

Jest też ciekawostka w ustawie - procedura awaryjna na wypadek awarii ksef. W takim wypadku, fakturę należy dostarczyć odbiorcy w inny sposób, a w ciągu 7 dni od usunięcia awarii, wysłać do ksef. Za niedotrzymanie terminy kara finansowa.

Na stronie min. jest wyjaśnienie, że na środowisko demo trzeba wysyłać dane zanonimizowane, tak jak na test. Mimo, że do demo dostęp jest ograniczony uprawnieniami.
Jak sobie radzicie z testami? Pasowałoby na jakiś okres włączyć wysyłanie faktur na preprodukcję i obserwowanie jak to wygląda w rzeczywistości.

Witam,
czy ktoś próbował zwalidować plik xml utworzonej faktury ze schematem ?

próbuję wykorzystać do tego bibliotekę msxml.dll
fragment kodu Delphi

var
  xml, xsd: MSXML2_TLBv6.IXMLDOMDocument3;
  cache: MSXML2_TLBv6.IXMLDOMSchemaCollection;
begin
  xsd := MSXML2_TLBv6.CoDOMDocument60.Create;
  xsd.Async := False;
  xsd.load(xsdFilePath);

  cache := MSXML2_TLBv6.CoXMLSchemaCache60.Create;
  cache.add('http://crd.gov.pl/wzor/2021/11/29/11089/',xsd);

  xml := MSXML2_TLBv6.CoDOMDocument60.Create;
  xml.async := False;
  xml.schemas := cache;

  Result := xml.load(xmlFilePath);
  if not Result then
    raise Exception.Create(IntToStr(xml.parseError.errorCode) + ': ' + xml.parseError.reason);
end;

jednak na lini cache.add dostaje komunikat
każda wskazówka będzie pomocna

Opublikowali wykaz różnic pomiędzy FA(1) i FA(2) https://www.gov.pl/web/finanse/konsultacje-podatkowe-struktur-logicznych-fa2-i-farr
Jest tego dużo.

processingCode":315,"processingDescription":"Sesja interaktywna aktywna. Komunikacja otwarta."
Jak zakończyć aktywną sesję ?

Jak pobrać FV w formacei PDF?
Udaje mi się jedynie xml.

Szanowni państwo z ksefa zrobili jeszcze większy bajzel z pobieraniem dokumentów w sesji online.
Wprowadzili nowe ograniczenie:
21177-Przekroczona maksymalna liczba wyników [10000]. Doprecyzuj kryteria.

Jeśli masz pecha to nie wylistujesz doków praktycznie nigdy bo zawężając okno czasowe musisz liczyć się z tym, że jest tylko kilka prób przed dostaniem limitu...
Ja potrafię utknąć na ich aplikacji webowej na tym. Już nie wspomnę co to robi dla automatów...

Ciąg dalszy projektowanych zmian: "Projekt nowelizacji zakładającej wprowadzenie obowiązkowego e-fakturowania z początkiem 2024 r. przewiduje również szczegółowe rozwiązania na wypadek awarii KSeF. Stworzony zostanie dodatkowy (niezależny od KSeF) interfejs do informowania podatników o awarii. Co istotne, z tym interfejsem będą mogły integrować się programy księgowe podatników, co pozwoli na automatyczne sprawdzanie dostępności systemu."

A jeśli się dodatkowy interfejs również zepsuje ?

Spotkał się ktoś z zawieszoną sesją? Napisane jest w "dokumentacji", że sesja interaktywna może trwać max 120 minut. Jestem praktycznie pewien, że online/session/terminate przeszło ok, a co więcej, zakończenie sesji w aplikacji też nic nie daje. Zwróćcie uwagę na datę rozpoczęcia (1) i datę ostatniej aktualizacji (2). Sesja nadal otwarta w trakcie pisania posta.

Co może być nie tak i czemu sesje nie dają się zabić?

Ja nek napisał(a):

Spotkał się ktoś z zawieszoną sesją? Napisane jest w "dokumentacji", że sesja interaktywna może trwać max 120 minut. Jestem praktycznie pewien, że online/session/terminate przeszło ok, a co więcej, zakończenie sesji w aplikacji też nic nie daje. Zwróćcie uwagę na datę rozpoczęcia (1) i datę ostatniej aktualizacji (2). Sesja nadal otwarta w trakcie pisania posta.

Co może być nie tak i czemu sesje nie dają się zabić?

wcześniej tak się nie działo, od paru dni mam to samo :)

Witam, miał ktoś taki problem?
podpisuję żądanie xadesem online/InitSigned -> działa, sesja w KSeF sie otwiera i tak dalej.
W analogiczny sposób podpisuję xadesem żadanie batch/Init i dostaję w odpowiedzi "nieprawidłowy podpis" .... ktoś coś?

Zbudowałem klasy do komunikacji z API KSEF za pomocą pliku .yaml pobranego ze swaggera. Inicjalizacja i autoryzacja - OK. Próbuję wysłać fakturę która wcześniej zaimportowałem już przez aplikację testową więc jest poprawna.
Próbuje ją wysłać endpoint - /online/Invoice/Send
W zbudowanej klasie na bazie pliku yaml mam do tego funkcje System.Threading.Tasks.Task<SendInvoiceResponse> Invoice_sendAsync(SendInvoiceRequest body)
Klasa SendInvoiceRequest:

public partial class SendInvoiceRequest 
{
    [Newtonsoft.Json.JsonProperty("invoiceHash", Required = Newtonsoft.Json.Required.Always)]
    [System.ComponentModel.DataAnnotations.Required]
    public File1MBHashType InvoiceHash { get; set; } = new File1MBHashType();

    [Newtonsoft.Json.JsonProperty("invoicePayload", Required = Newtonsoft.Json.Required.Always)]
    [System.ComponentModel.DataAnnotations.Required]
    public InvoicePayloadType InvoicePayload { get; set; } = new InvoicePayloadType();   
}

Buduję obiekt który po serializacji json wygląda tak:

{
"invoiceHash":
{
"fileSize":3337,
"hashSHA":
{
"algorithm":"SHA-256",
"encoding":"Base64",
"value":"5k1abqAusbghG95FIX9PsbBtWyIC/pNYKnzheufIUTQ="
}
},
"invoicePayload":
{
"type":"plain",
"invoiceBody":"PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZ...0dXJhPg=="
}
}

Niby wszystko ok... a dostaje Bad Request. Co robię nie tak?

Sesja interaktywna z ekstra szyfrowaniem (encryption w request), a pobieranie faktury w ramach takiej sesji zwraca mi fakturę niezaszyfrowana... Nie miała być zaszyfrowana skoro sesja jest z ekstra szyfrowaniem ? Nie oprogramowali jeszcze czy jakiś bubel u mnie?

Mam kilka pytań...

1. Serwer testowy. Czy u Was też tak długo trwa uzyskanie UPO ? Jak wysyłam przykładową e-faktury udostępnioną na stronie mf, dostaje UPO po ok 2h, jak wysyłam swoją wygenerowana od dwóch dni mam status 340 "Zakończenie etapu weryfikacji wyników podprocesów przetwarzania faktury". Czy to kwestia testowego a na demo i produkcji jest inaczej/szybciej ?
2. Rozumiem, że na testowy nie można podpisywać kluczem kwalifikowanym (gwizdek) ? Jak sprawa wygląda w tej kwestii na demo i produkcji
3. Czy zmiana serwera (testowy/produkcja/demo) wiążę się tylko ze zmianą adresów i podmianie klucza .pem ?
   W mojej sytuacji sprawa dotyczy tylko wysyłki wsadowej.

Z góry dziękuję za odpowiedzi :)

Witam,
Czy ktoś może integruje się z KSeF za pomocą PHP?
Czy moze komuś udało się skonfigurować do konca połączenie z API i odpowie mi na kilka pytań?

Czy ktoś podpowie jak zachowuje się RemoveToken?
Z tego co widzę są dwie wersje i druga wersja jest bez identifiera.
Ale czy to fakt, że muszę przekazywać w tokenNumber nie faktyczny token tylko refnum zwracany podczas generowania tokena?
W V2 wychodzi, że przekazujemy tylko 1 parametr TokenNumber czy źle odczytuje tego yamla?