Krajowy system e-Faktur

Hej, robię wysyłkę wsadową. W ksefie pojawia się wpis, ze wysyłka jest w trakcie przetwarzania. Sprawdzam status i dostaję odpowiedz:

  'https://ksef-test.mf.gov.pl/api/common/Status/20220622-SE-77C1DD975A-88C3F5D478-57' \
  -H 'accept: application/json'

W odpowiedzi dostaje:
{
"timestamp": "2022-06-22T2007.842Z",
"referenceNumber": "20220622-SE-77C1DD975A-88C3F5D478-57",
"processingCode": 335,
"processingDescription": "Zakończenie etapu eksportu danych oraz inicjalizacji podprocesów przetwarzania faktury",
"upo": null
}

Czy napotkaliście taki problem? Czy to jest problem z moją paczką czy coś nie działa po stronie KSEFa.

Cześć,
Próbuję zabrać się za wysyłkę wsadową, ale nie rozumiem dokładnie co należy przygotować.
Z tego co wiem, żeby w ogóle zacząć wysyłkę wsadową to trzeba przygotować plik InitRequest.xml z odpowiednimi wartościami. W tym pliku musi być zawarta sekcja <Encryption>, która to wcześniej musi być również określona przy logowaniu za pomocą InitSessionSigned.
W sekcji <Encryption> są sekcje <EncryptionKey> oraz <EncryptionInitializationVector> i w nich trzeba umieścić odpowiednią wartość <Value>.

Co dokładnie należy wpisać w opcji <Value> ?

Próbuję to ogarnąć w Delphi XE6 z komponentami TMS CryptoPack. Czy przy sekcji <EncryptionKey> -> <Value> mam utworzyć swój wymyślony zaszyfrowany tekst przy pomocy AES a później ten tekst dodatkowo zaszyfrować kluczem publicznym przy pomocy RSA?

A co powinno być w sekcji <EncryptionInitializationVector> -> <Value> ?

<ns3:Encryption>
    <EncryptionKey>
        <Encoding>Base64</Encoding>
        <Algorithm>AES</Algorithm>
        <Size>256</Size>
        <Value>?????</Value> // Jaka tutaj ma być wartość?
    </EncryptionKey>
    <EncryptionInitializationVector>
        <Encoding>Base64</Encoding>
        <Bytes>16</Bytes>
        <Value>?????</Value>  // Jaka tutaj ma być wartość?
    </EncryptionInitializationVector>
    <EncryptionAlgorithmKey>
        <Algorithm>RSA</Algorithm>
        <Mode>ECB</Mode>
        <Padding>PKCS#1</Padding>
    </EncryptionAlgorithmKey>
    <EncryptionAlgorithmData>
        <Algorithm>AES</Algorithm>
        <Mode>CBC</Mode>
        <Padding>PKCS#7</Padding>
    </EncryptionAlgorithmData>
</ns3:Encryption>

Cześć,

Mam kolejny problem przy przetwarzaniu batchowym.

KSeF przyjmuje moje requesty batchInit/batchUpload i batchFinish do przetwarzania. Request batchInit ma taką postać:

<?xml version="1.0" encoding="UTF-8"?><ns2:InitRequest xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001" xmlns:ns2="http://ksef.mf.gov.pl/schema/gtw/svc/batch/init/request/2021/10/01/0001" xmlns:ns3="http://ksef.mf.gov.pl/schema/gtw/svc/batch/types/2021/10/01/0001">
    <ns2:Identifier xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="SubjectIdentifierByCompanyType">
        <Identifier>7579996361</Identifier>
    </ns2:Identifier>
    <ns2:DocumentType>
        <Service>KSeF</Service>
        <FormCode>
            <SystemCode>FA (1)</SystemCode>
            <SchemaVersion>1-0E</SchemaVersion>
            <TargetNamespace>http://crd.gov.pl/wzor/2021/11/29/11089/</TargetNamespace>
            <Value>FA</Value>
        </FormCode>
    </ns2:DocumentType>
    <ns2:Encryption>
        <EncryptionKey>
            <Encoding>Base64</Encoding>
            <Algorithm>AES</Algorithm>
            <Size>256</Size>
            <Value>T6qBaKW0BqrzKRDR0iWueSY3ZpRSSeegBphHMOy5NwZK5S0Z26agJUIdSdYxNbJ0GJDigr+6fZaYLnsTQ83nZd7s/e4ZHGVF2IFPwzBG5am1NavOAxmOcr/yn7A2smE04CsPVEXVx3HJ5VIBLo0RzPXV5rMgix3zhhXJqt7iNkPmGCxGDv8tmLkDZmUC8AZQpnFclimdGV3s4ecjjOlkBslw3so1JPiVhaGapMGae7ParIpdLbkG7VZVLgSdqQY92unOKj+Zf07tiHODq2OLojNY+1Uv0rHfrubagY1tUeITwO8uqUbUkmhAeGDmyQPx6GwRJuEgfi4HL34yV93g3A==</Value>
        </EncryptionKey>
        <EncryptionInitializationVector>
            <Encoding>Base64</Encoding>
            <Bytes>16</Bytes>
            <Value>ZGPpo9Yr8d32KZw/SzlieQ==</Value>
        </EncryptionInitializationVector>
        <EncryptionAlgorithmKey>
            <Algorithm>RSA</Algorithm>
            <Mode>ECB</Mode>
            <Padding>PKCS#1</Padding>
        </EncryptionAlgorithmKey>
        <EncryptionAlgorithmData>
            <Algorithm>AES</Algorithm>
            <Mode>CBC</Mode>
            <Padding>PKCS#7</Padding>
        </EncryptionAlgorithmData>
    </ns2:Encryption>
    <ns2:PackageSignature>
        <ns2:Package>
            <ns3:PackageType>split</ns3:PackageType>
            <ns3:CompressionType>zip</ns3:CompressionType>
            <ns3:Value>batch-6.zip</ns3:Value>
        </ns2:Package>
        <ns2:PackageFileHash>
            <HashSHA>
                <Algorithm>SHA-256</Algorithm>
                <Encoding>Base64</Encoding>
                <Value>XJYlTIOZLY13qbFRLm1tg2oeF+5JtPib3mNCIR4mi38=</Value>
            </HashSHA>
            <FileSize>140022</FileSize>
        </ns2:PackageFileHash>
        <ns2:PackagePartsList>
            <ns2:PackagePartSignature>
                <ns3:OrdinalNumber>1</ns3:OrdinalNumber>
                <ns3:PartFileName>batch-6-part-1.zip</ns3:PartFileName>
                <ns3:PartFileHash>
                    <HashSHA>
                        <Algorithm>SHA-256</Algorithm>
                        <Encoding>Base64</Encoding>
                        <Value>XJYlTIOZLY13qbFRLm1tg2oeF+5JtPib3mNCIR4mi38=</Value>
                    </HashSHA>
                    <FileSize>140022</FileSize>
                </ns3:PartFileHash>
            </ns2:PackagePartSignature>
        </ns2:PackagePartsList>
    </ns2:PackageSignature>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="id-621d3437028bb66f1f54b92cbd28da30"><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 Id="r-id-621d3437028bb66f1f54b92cbd28da30-1" URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"><dsig-filter2:XPath xmlns:dsig-filter2="http://www.w3.org/2002/06/xmldsig-filter2" Filter="subtract">/descendant::ds:Signature</dsig-filter2:XPath></ds:Transform><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>1WJczoCYCHTkSZ8LRzrvpl9La+uMckmysEBCU0y9oLM=</ds:DigestValue></ds:Reference><ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xades-id-621d3437028bb66f1f54b92cbd28da30"><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>ckdaGGS1ClSTIIVlWkt84Q7uOBs/Se/htPwqu59/hw4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue Id="value-id-621d3437028bb66f1f54b92cbd28da30">WRrsMOYPOBfFgsQt42VBsXq74wpeyaF2Wu7RwubkKqo/CO0gmjwSLNOAmkRXqvetU0SuegoZsDQxpGFoCsYDbGdu+0vz6/8gaWLB3qXxD07BPPUt1/C47kYoGCF6X3K+grZTnRDcgg9DoyDN4NACrpfE8JqR789Xn0lrun5L7ZvVAb7VFw3fJyT7SL68UjwNA3JvNZeeRYEdn/YVOiMybnZ1AisgImjFXfCrPwSnCEHKwU1XSqnXGcEF59RTfnHeL/TT/zl0XKuEe87h+/d/7JajZxBjIdWGYkO+50gffAfizTW9r/zg+pYGzdYZcOhLd6eiqP6iv83TAEaWcrE2AQ==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIID/DCCAuSgAwIBAgIIRuvmmkiiEIUwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNVBAYTAlBMMRQwEgYDVQQIEwtNYXpvd2llY2tpZTERMA8GA1UEBxMIdGVzdEtzZWYxETAPBgNVBAoTCHRlc3RLc2VmMREwDwYDVQQLEwh0ZXN0S3NlZjERMA8GA1UEAxMIdGVzdEtzZWYxKDAmBgkqhkiG9w0BCQEWGXRlc3Rvd3kxMjNAdGVzdGtzZWYxMjIucGwxGTAXBgNVBGETEFZBVFBMLTc1Nzk5OTYzNjEwHhcNMjIwNjA3MDkwMzAwWhcNMjMwNjA3MDkwMzAwWjCBtDELMAkGA1UEBhMCUEwxFDASBgNVBAgTC01hem93aWVja2llMREwDwYDVQQHEwh0ZXN0S3NlZjERMA8GA1UEChMIdGVzdEtzZWYxETAPBgNVBAsTCHRlc3RLc2VmMREwDwYDVQQDEwh0ZXN0S3NlZjEoMCYGCSqGSIb3DQEJARYZdGVzdG93eTEyM0B0ZXN0a3NlZjEyMi5wbDEZMBcGA1UEYRMQVkFUUEwtNzU3OTk5NjM2MTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQVZx2s+QdoUhRyLSfvAsQW2Nqb9/Em3wLzPysClqluAB+QBpWxos0V4D2wEwsXyGt2ZvZkvU3aWSDhnuabp4TQGRROM+PXdSburha5a6MuPGaf8QesZNcpwcYod9X0Kcqtu4WwueUo6R3DVE9nYV+A6yqtI3jG+Si2c4pZD27+m2iEUJMtK36QYOQH4EE+r+yH4RkZ72kzLa8zZMAv81g/f0g70486VQ31Z9JUFySpPu4BTM7JxqfANlKFtqFQUWaKlh0zMcDGwyf+ogFKWZ6xmpst+B+foM5IxHxC2LOj7QHhBenW0p1EpY5P8rkLRNYTGI7V6wJ6Epc01QQoZRMCAwEAAaMQMA4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEARQ648Ngjs5yuDgfRp8nv16+oHOIgmYCLmskzkcCs5d4R+Hls0J3UMEKfErRZeo39qnkOXUtpZQkOh1WDiLDbzRHh0ru5DplWIn+jNpYyG7Un48shNOH7z6YHAk63CHlUVY/KXG+VyEMevOIRQiwXkRjLWWruyRSrTlG8+vvQTEJUhfcVf1caTUmQ0m1yjBzHPUY45cKBeAyJ6Y/X1MGgiwyyNwlL3Du38gNzSMWaMR/FVYuaUYHUsDMU3vvId+z3vUGwBsoLbgYglYw6szDgCXxQKogC8tFOag2DDUG4IS3moXNZSjrk4ljzGmwI+Dho8mTib1NXDnvZ7JEDNFXE+A==</ds:X509Certificate></ds:X509Data></ds:KeyInfo><ds:Object><xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#id-621d3437028bb66f1f54b92cbd28da30"><xades:SignedProperties Id="xades-id-621d3437028bb66f1f54b92cbd28da30"><xades:SignedSignatureProperties><xades:SigningTime>2022-06-24T07:15:02Z</xades:SigningTime><xades:SigningCertificateV2><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>HhvkToDw3TqoW7fm9IjRbFNgibvKhNjCCJt57fSjXluxAjnDo4gx6df4N2wqEQpxCgPZkgI1bJ5SH9JjIObu5Q==</ds:DigestValue></xades:CertDigest><xades:IssuerSerialV2>MIHHMIG6pIG3MIG0MQswCQYDVQQGEwJQTDEUMBIGA1UECBMLTWF6b3dpZWNraWUxETAPBgNVBAcTCHRlc3RLc2VmMREwDwYDVQQKEwh0ZXN0S3NlZjERMA8GA1UECxMIdGVzdEtzZWYxETAPBgNVBAMTCHRlc3RLc2VmMSgwJgYJKoZIhvcNAQkBFhl0ZXN0b3d5MTIzQHRlc3Rrc2VmMTIyLnBsMRkwFwYDVQRhExBWQVRQTC03NTc5OTk2MzYxAghG6+aaSKIQhQ==</xades:IssuerSerialV2></xades:Cert></xades:SigningCertificateV2></xades:SignedSignatureProperties><xades:SignedDataObjectProperties><xades:DataObjectFormat ObjectReference="#r-id-621d3437028bb66f1f54b92cbd28da30-1"><xades:MimeType>application/octet-stream</xades:MimeType></xades:DataObjectFormat></xades:SignedDataObjectProperties></xades:SignedProperties></xades:QualifyingProperties></ds:Object></ds:Signature></ns2:InitRequest>

Następnie gdy odpytuję KSeF o status przetwarzania otrzymuję w odpowiedzi:

{"timestamp": "2022-06-24T07:21:08.003Z", "processingCode": 416, "referenceNumber": "20220624-SE-393B8604E8-5C9ACDFC62-A6", "processingDescription": "Nieprawidłowy klucz szyfrujacy."}

Ma ktoś pomysł co może być nie tak?

Mam problem ze zrozumieniem poniższej schemy faktury i przemapowaniem na klasy:
http://crd.gov.pl/wzor/2021/11/29/11089/schemat.xsd

Do generowania klas używam: jaxb2-maven-plugin Tworzenie klas ruszyło dopiero po włączeniu przełącznika: -XautoNameResolution, ponieważ powtarzają się nazwy, chociażby: TAdres. Niestety w ten sposób powstają klasy TAdres, TAdres1, TAdres2, które odpowiadają, ale mają inne nazwy niż opis w dokumentacji:

• Informacje opisujące adres
• Dane określające adres
• Dane określające adres - bez elementu Poczta w adresie polskim

Użyłem też generatora zaszytego w Java8:
xjc -d generated http://crd.gov.pl/wzor/2021/11/29/11089/schemat.xsd

W ten sposób wygenerowały się klasy TAdres i TAdres1. Powstał też pakiet "wzor", w którym znalazła się klasa TAdres przedstawiajaca "Informacje opisujące adres". poglądowa lista katalogów i plików:

**CRD/**
  **WZÓR/**
    *Faktura.java
    TAdres.java
    TAdresPolski.java
    TAdresZagraniczny.java
    TGTU.java
    TKluczWartosc.java
    TKodFormularza.java
    TKodWaluty.java
    TKodyKrajowUE.java
    TNaglowek.java
    TOznaczenieProcedury.java
    TOznaczenieProceduryZ.java
    TPodmiot.java
    TPodmiot1.java
    TRachunekBankowy.java
    TRodzajFaktury.java*
  **XML/**
    *TAdres.java
    TAdres1.java
    TAdresPolski.java
    TAdresPolski1.java
    TAdresZagraniczny.java
    TIdentyfikatorOsobyFizycznej.java
    TIdentyfikatorOsobyFizycznej1.java
    TIdentyfikatorOsobyFizycznej2.java
    TIdentyfikatorOsobyFizycznejPelny.java
    TIdentyfikatorOsobyFizycznejZagranicznej.java
    TIdentyfikatorOsobyNiefizycznej.java
    TIdentyfikatorOsobyNiefizycznej1.java
    TIdentyfikatorOsobyNiefizycznejPelny.java
    TIdentyfikatorOsobyNiefizycznejZagranicznej.java
    TKodKraju.java
    TOsobaFizyczna.java
    TOsobaFizyczna1.java
    TOsobaFizyczna2.java
    TOsobaFizyczna3.java
    TOsobaFizyczna4.java
    TOsobaFizyczna5.java
    TOsobaFizycznaPelna.java
    TOsobaFizycznaPelna1.java
    TOsobaNiefizyczna.java
    TOsobaNiefizyczna1.java
    TOsobaNiefizyczna2.java
    TOsobaNiefizycznaPelna.java
    TOsobaNiefizycznaPelna1.java
    TPodmiotDowolny.java
    TPodmiotDowolny1.java
    TPodmiotDowolny2.java
    TPodmiotDowolnyBezAdresu.java
    TPodmiotDowolnyBezAdresu1.java
    TPodmiotDowolnyBezAdresu2.java
    TPodmiotDowolnyBezAdresu3.java
    TPodmiotDowolnyPelny.java
    TPodmiotDowolnyPelny1.java*

Jak to rozumieć? Które klasy powinny być wykorzystywane?

Zgłupiałem

Edycja 2022/06/28 15
Myślę, że komuś się to przyda.
Najprościej do generowania użyć poniższego wywołania, oczywiście najpierw należy utworzyć katalog, do którego polecą generowane klasy:

C:\Program Files\Java\jdk1.8.0_202\bin>xjc -encoding UTF-8 -d generated http://crd.gov.pl/wzor/2021/11/29/11089/schemat.xsd

Lub:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxb2-maven-plugin</artifactId>
    <version>2.5.0</version>
    <executions>
        <execution>
            <id>xjc</id>
            <goals>
                <goal>xjc</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <xjbSources>
            <xjbSource>src/main/xsd/bindings.xjb</xjbSource>
        </xjbSources>
        <sources>
            <source>src/main/xsd/schemat.xsd</source>
        </sources>
    </configuration>
</plugin>

i binding:

<?xml version="1.0" encoding="UTF-8"?>
<jxb:bindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
              version="2.0">
    <jxb:bindings scd="x-schema::tns" xmlns:tns="http://crd.gov.pl/wzor/2021/11/29/11089/">
        <jxb:schemaBindings>
            <jxb:package name="pl.gov.mf.ksef.invoice.wzor2"/>
        </jxb:schemaBindings>
    </jxb:bindings>
    <jxb:bindings scd="x-schema::tns" xmlns:tns="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2021/06/09/eD/DefinicjeTypy/">
        <jxb:schemaBindings>
            <jxb:package name="pl.gov.mf.ksef.invoice.xml2"/>
        </jxb:schemaBindings>
    </jxb:bindings>
</jxb:bindings>

Hej, wiem, że ten temat już się przewijał na forum, ale czy komuś udało się rozkminić jak faktycznie interpretować limity? Na każdym środowisku jest załączony ten sam plik z limitami. Czy faktycznie dla konline.invoice.invoice.send limit:1 lifespan:60 można uderzyć raz na 60 minut? Czy może ktoś pomylił rząd wielkości i to są sekundy?

time unit: MINUTES

operationId: default limit:20 lifespan:20
operationId: bad_request limit:10 lifespan:10
operationId: online.session.authorisation.challenge limit:10 lifespan:10
operationId: online.session.session.signed.init limit:1 lifespan:60
operationId: online.session.session.token.init limit:1 lifespan:60
operationId: online.session.session.status.plain limit:20 lifespan:10
operationId: online.session.session.status.reference.number limit:10 lifespan:20
operationId: online.session.session.terminate.plain limit:1 lifespan:20
operationId: online.session.session.terminate.reference.number limit:1 lifespan:20
operationId: online.query.query.credentials limit:5 lifespan:60
operationId: online.query.query.invoice limit:5 lifespan:60
operationId: online.query.query.invoice.init limit:5 lifespan:60
operationId: online.query.query.invoice.status limit:20 lifespan:10
operationId: online.query.query.invoice.fetch limit:20 lifespan:10
operationId: online.payment.payment.identifier.request limit:1 lifespan:60
operationId: online.payment.payment.identifier.get.reference.numbers limit:10 lifespan:20
operationId: online.invoice.invoice.send limit:1 lifespan:60
operationId: online.invoice.invoice.get limit:10 lifespan:20
operationId: online.invoice.invoice.status limit:20 lifespan:10
operationId: online.credentials.credentials.status limit:20 lifespan:10
operationId: online.credentials.credentials.grant limit:1 lifespan:60
operationId: online.credentials.generate.token limit:1 lifespan:60
operationId: online.credentials.list.tokens limit:5 lifespan:60
operationId: online.credentials.revoke.token limit:10 lifespan:20
operationId: online.credentials.credentials.revoke limit:10 lifespan:20
operationId: common.invoice.ksef limit:2 lifespan:60
operationId: common.status limit:20 lifespan:10
operationId: batch.init limit:1 lifespan:60
operationId: batch.upload limit:2 lifespan:60
operationId: batch.finish limit:1 lifespan:60

Witam,
Męczę się z wysyłką wsadową. Na obecną chwilę mam błąd "Nieprawidłowy skrót części pakietu". Czy może mi ktoś podpowiedzieć co ja tu robię źle?

// Wrzucam do archiwum ZIP pliki XML faktur.
  ZipName := 'faktury.zip';
  ZIP := TZipFile.Create;
  ZIP.Open(ZipName, zmWrite);

  for i := 1 to 15 do
   ZIP.Add(XmlFilePath);

  ZIP.Close;
  ZIP.Free;

  // Szyfruję za pomocą wcześniej utworzonego klucza AES
  fEncryptedZipStream := TMemoryStream.Create;
  zipStream := TMemoryStream.Create;
  zipStream.LoadFromFile(ZipName);

  aes := TAESEncryption.Create;
  aes.AType := atCBC;
  aes.KeyLength := kl256;
  aes.Unicode := yesUni;
  aes.Key := fAESKey;
  aes.PaddingMode := TpaddingMode.PKCS7;
  aes.IVMode := TIVMode.userdefined;
  aes.IV := fAESIV;
  aes.EncryptStream(zipStream, fEncryptedZipStream);

  // Liczę skrót zaszyfrowanego archiwum
  HashSHA256 := TIdHashSHA256.Create;
  StreamBytes := HashSHA256.HashStream(fEncryptedZipStream); // hashowanie TStream na Bytes

  Hash := BytesToString(StreamBytes, IndyTextEncoding_OSDefault); // Konwersja TStream do String'a
  Hash := EncodeString(Hash);  // Zakodowanie do Base64

W wyniku powyższych czynności mam utworzony taki blok w pliku XML:

<ns3:PackageSignature>
        <ns3:Package>
            <ns2:PackageType>single</ns2:PackageType>
            <ns2:CompressionType>zip</ns2:CompressionType>
            <ns2:Value>faktury.zip</ns2:Value>
        </ns3:Package>
        <ns3:PackageFileHash>
            <HashSHA>
                <Algorithm>SHA-256</Algorithm>
                <Encoding>Base64</Encoding>
                <Value>8HEeQU0DvCNZ6ADtoS9Q2GNA55/fgkILIBPvz6G+e7M=</Value>
            </HashSHA>
            <FileSize>19321</FileSize>
        </ns3:PackageFileHash>
        <ns3:PackagePartsList>
            <ns3:PackagePartSignature>
                <ns2:OrdinalNumber>1</ns2:OrdinalNumber>
                <ns2:PartFileName>faktury.zip</ns2:PartFileName>
                <ns2:PartFileHash>
                    <HashSHA>
                        <Algorithm>SHA-256</Algorithm>
                        <Encoding>Base64</Encoding>
                        <Value>47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=</Value>
                    </HashSHA>
                    <FileSize>19328</FileSize>
                </ns2:PartFileHash>
            </ns3:PackagePartSignature>
        </ns3:PackagePartsList>
 </ns3:PackageSignature>

Niestety podczas próby upload'u wyrzuca mi błąd "Nieprawidłowy skrót części pakietu". Mam tylko jeden plik ZIP. Nie dzielę go na części bo waży tylko 19KB.
Help.

Hej, mam problem z autoryzacją z wykorzystaniem tokena. Ktoś coś wie co się mogło zmienić? Na demo błąd: Nieprawidłowo zaszyfrowana treść, na dev: Nieprawidłowe wywołanie. Nic nie zmieniałem w kodzie a metody autoryzacji przestały działać.

Czy moze komuś udało się skonfigurować do konca połączenie z API i odpowie mi na kilka pytań?

Słuchajcie czy to jest prawidłowa ścieżka generowania tokena:

Cześć,

Czy ktoś weryfikował, jakie są różnice w czasach przetwarzania między komunikacją interaktywną a batchową(z założeniem wysyłki 1 faktury)?

Do tej pory zrobiłem tylko przetwarzanie batchowe i zastanawiam się, czy to wystarczy, czy jednak warto robić dodatkowo wysyłkę interaktywną.

Cześć
Piszę w nowym wątku (wcześniej wyżej już pisałem w sprawie liczenia skrótu) bo nie mogę przeskoczyć tej wysyłki wsadowej.
Szyfruję i koduję plik ZIP faktur, ale wciąż mam błąd "Nieprawidłowo zaszyfrowana treść"

var 
    KeyToEncrypt: string;
	zipStream: TMemoryStream;
begin
// Przygotowanie klucza AES

  fAESKey := RandomKey(32); // funkcja RandomKey() zwraca string'a o długości podanej w parametrze z logowo wstawianymi liczbami od 0 do 9 np: 23758374612396857122345781289545 
  fAESIV := RandomKey(16);  // np: 1857463978564536 

  KeyToEncrypt := RandomKey(10); 

  aes := TAESEncryption.Create;
  aes.AType := atCBC;
  aes.KeyLength := kl256;
  aes.Key := fAESKey;
  aes.PaddingMode := TpaddingMode.PKCS7;
  aes.IVMode := TIVMode.userdefined;
  aes.IV := fAESIV;
  fKeyEncrypted := aes.Encrypt(KeyToEncrypt); // przygotwanie zaszyfrowanego klucza aes
  fEncryptionKeyValue := EncryptRSAToBase64(fKeyEncrypted); // zakodowanie klucza AES kluczem publicznym RSA i konwersja do Base64 
  fEncryptionInitializationVectorValue := EncodeString(RandomKey(16)); // Utworzenie EncryptionInitializationVector

// Załadowanie do stream'a pliku ZIP faktur

  fEncryptedZipStream := TMemoryStream.Create;
  zipStream := TMemoryStream.Create;
  zipStream.LoadFromFile(ZipName); 
  zipStream.Position := 0;
  
// Szyfrowanie utworzonym kluczem AES

  aes.AType := atCBC;
  aes.KeyLength := kl256;
  aes.Key := fAESKey;
  aes.PaddingMode := TpaddingMode.PKCS7;
  aes.IVMode := TIVMode.userdefined;
  aes.IV := fAESIV;
  aes.EncryptStream(zipStream, fEncryptedZipStream); // zaszyfrowanie stream'a z pliku ZIP faktur kluczem AES
  fEncryptedZipStream.Position := 0;
  
  ....
  // Wysyłka właściwa zaszyfrowanego stream'a
  RestPUT(putURL, fEncryptedZipStream, ctAPPLICATION_OCTET_STREAM);
end;

Gdy później wysyłam stream'a fEncryptedZipStream to wysyłka przechodzi ale wciąż mam zwrot "Nieprawidłowo zaszyfrowana treść"
Macie pomysł gdzie i co ustawić aby KSeF to zaakceptował?

Post przeredagowałem z pytania na, myślę, że ważną UWAGĘ dotyczącą nadawania poświadczeń za pomocą metody /online/Credentials/Grant

Prawidłowy, przykładowy request dla tej metody umieszczam poniżej.

Budując request należy zwrócić uwagę na stosowaną długość wartości dla "roleDescription".
Długość tej wartości musi być > 4 znaki.

Jeżeli wartość ma do 4 znaków proces nadawania poświadczeń kończy się statusem 410 - "Nieprawidłowy format dokumentu (json)."

Zmarnowałem kilka godzin zanim odkryłem tą zależność :/ dlatego umieszczam info ku przestrodze dla innych.

{
"grantCredentials": {
"credentialsIdentifier": {
"identifier": "11111111111",
"type": "pesel"
},
"credentialsRoleList": [
{
"roleDescription": "opis_koniecznie_dluzszy_niz_4_znaki",
"roleType": "credentials_read"
},
{
"roleDescription": "opis_koniecznie_dluzszy_niz_4_znaki",
"roleType": "credentials_manage"
},
{
"roleDescription": "opis_koniecznie_dluzszy_niz_4_znaki",
"roleType": "introspection"
}
]
}
}

Zastosowany powyżej PESEL został specjalnie zmieniony na nieprawidłowy.

Witam,
chciałbym dołączyć do grona ludzi niezadowolonych z KSeF.
Na początek... tak kwestia wiele razy tu powtarzana.. błąd z podpisem dokumentu.

Czy ktoś mógłby pomóc odnaleźć problem? weryfikowałem na stronie weryfikacjapodpisu i wykazuje, że mam:
Niepoprawna referencja: #SignedProperties - jak to wygenerować? debugując nie mam wartości w tym polu
Niepoprawny skrót z certyfikatu (pole SigningCertificate)
System nie był w stanie poprawnie odbudować ścieżki certyfikacji

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

-<ns3:InitSessionSignedRequest xmlns:ns3="http://ksef.mf.gov.pl/schema/gtw/svc/online/auth/request/2021/10/01/0001" xmlns:ns2="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001" xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/online/types/2021/10/01/0001">
-<ns3:Context>
<Challenge>20220629-CR-DD7154F4E0-FE5D56B4E5-A3</Challenge>
-<Identifier xsi:type="ns2:SubjectIdentifierByCompanyType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Identifier>1111111111</ns2:Identifier>
</Identifier>
-<DocumentType>
<ns2:Service>KSeF</ns2:Service>
-<ns2:FormCode>
<ns2:SystemCode>FA (1)</ns2:SystemCode>
<ns2:SchemaVersion>1-0E</ns2:SchemaVersion>
<ns2:TargetNamespace>http://crd.gov.pl/wzor/2021/11/29/11089/</ns2:TargetNamespace>
<ns2:Value>FA</ns2:Value>
</ns2:FormCode>
</DocumentType>
<Type>SerialNumber</Type>
</ns3:Context>
-<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="Signature">
-<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
-<Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#SignedProperties">
-<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>ygMbeIa/qh8nyVHXjHLs3/VvoKmUrBkSYvzjL0mvGA4=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>Ll2kNCu9+UjLLgaTO4hIyYTGqw2+esT5Kuoc1LWgcpBsCMHE7wogslos6XV6aBMZHpJ8iuFDipBcF9T45qEItUMeOtTDEPlGkh1byWj9EAynFsMgP0X6RsZX1hyf8M3wqKGryn+ptk/Y03mG0t+4NXDtoMTL9YwiWzn2SJbqgS8AOUfJMFts1agqjN/PBWKqi6MFFAP/B1Mp2/ZVjdPKAy9eu29tQGrPE1EA4zQFexXQT3k4aJ0CCYyQRxSC/WswC8gy8wl/DSid3PszkzkWaPVOgsewnFVOSYKTAAREm8JgD6msItTWzYKh+CB/a8Xf1TvK4at6EtDrq8Nz5ICmtw==</SignatureValue>
-<KeyInfo>
-<X509Data>
<X509Certificate>MIIDGzCCAgMCFDk2qIrrPgHDCdb+P7nMEtDcLkNdMA0GCSqGSIb3DQEBCwUAMEoxGTAXBgNVBGEMEFZBVFBMLTExMTExMTExMTExDTALBgNVBAMMBEFLTUYxETAPBgNVBAoMCFRFU1RBS01GMQswCQYDVQQGEwJQTDAeFw0yMjA3MDUxMTIzNTZaFw0yMzA3MDUxMTIzNTZaMEoxGTAXBgNVBGEMEFZBVFBMLTExMTExMTExMTExDTALBgNVBAMMBEFLTUYxETAPBgNVBAoMCFRFU1RBS01GMQswCQYDVQQGEwJQTDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNgUQk3kArwlkec+VIqKL69pbkJCWnYEK8Z1XCQyjSu1FYKktt4GTrVlstNpI1zh+C6Pclr16pA7pjmx/Jj20xN53v1En9ocwno8T263C60tSGtZ71FABDPhtAcOOXx3o9mmWK3zSSg7fpPpX7ybwoagtB5IBD+8oRlRSQd0EZIK723jEsLHS55er2O/1qRGl5wuhaUjYlmKmSTgWRtjObeS6vBCs4tZTud5tydxmcm/PDQKzv84nWZpkZ2cIzH1bqoDqluPD+lWAF6BIsjEn2YKqPMTTa3mrf9FZ5hM0lMJLClMYF4N72yCWzQ3PUHUSGESO0B+AGw78yhQBAR2fECAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAGTCaVpFkXCgm7B0fzSoP7CU8LqOJTXo5i0JR2OfuzTVhBwEdi3QacTzEGfzLAzjlIBMwaIkx2nhA+TDvqW0dA7z74RKWdYfNumObbbFXlpEOqnK8YT9A9pbhmlEuj+lK/2MUrklQHmsdNiY5ecZTayxV04KTYbXMcofYM2REbUkxEhBi0Rpa8+0jAySh1pRZyrPnf4Po3E0iawo367uevmVO5kmIHWuMXhMc1yxLYEAKyhzIX58Hz1ZWkNzrPEAzJjbPfw/G/OryMSrD8Ez3MmD+g0ibzoPJTAmHTWozDg4idkIGNoAkp+d4uKndXZ7lr6lAPUJFvhaZIsN3W3EsaA==</X509Certificate>
</X509Data>
</KeyInfo>
-<Object>
-<xades:QualifyingProperties Id="QualifyingPropsSignature" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#TargetSignature">
-<xades:SignedProperties Id="SignedProperties">
-<xades:SignedSignatureProperties>
<xades:SigningTime>2022-07-06T09:07:57+01:00</xades:SigningTime>
-<xades:SigningCertificate>
-<xades:Cert>
-<xades:CertDigest>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>zsQPN2mCNW8WU84xJqsi5L0yNjA=</DigestValue>
</xades:CertDigest>
-<xades:IssuerSerial>
<X509IssuerName>C=PL, O=TESTAKMF, CN=AKMF, OID.2.5.4.97=VATPL-1111111111</X509IssuerName>
<X509SerialNumber>326631396313373214491507679831009216590473216861</X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</Object>
</Signature>
</ns3:InitSessionSignedRequest>

Witam

Czy ktoś mógłby podesłać poprawną strukturę Signature dla XML'a dla Session/InitSigned? Po stronie PHP wykorzystuję klasę XMLSecurityDSig, jednak w odpowiedzi ciągle uzyskuje błąd: "Nieprawidłowa treść podpisu."

U mnie wygląda to tak:

  <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><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>hZ3gclArraoWGOME2yF+ErHj0LpbUWbEiTfpFGr+JRA=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>KJC05p+g2uCL9zGmQW8qKeSf269PJQsMWHGXO/0Ym+OpQmLqmK0lZT2APhay+/haAiCziJ3lhg8Osjenc6nxQlJFE1tFIP/54pEkhuiNZOiK7CLNXd8Vki01VoDMNokxa8spLL+x6wdcSLfuIQAdCK/r/favPEXRK8ib+eepRgiPDCWd/FWVkr7VUk4YcMMQe4Xk3eyUFr/cIZjM0O5TbKajCxKchR/OgkBendw1Y0O+Z8xNyvtp5rKtksbFUQUXdcBqBZm2MPYJ8HhR3f9sG2zWAgQb+9V16XZWMerX7y5bbr4k/25ptyA7u/58x3P/tkhuSsnGh8AjL8YA7l5xsA==</ds:SignatureValue>
</ds:Signature>

Po nierównej walce, walidacja na stronie przeszła, a przynajmniej wartości podpisu i referencje.
Jednak swagger wyrzuca niezgodność ze schemą... czy to wina tylko prefixu ds: ? czy coś jeszcze mogę mieć tu skopane?

-<ns3:InitSessionSignedRequest xmlns:ns3="http://ksef.mf.gov.pl/schema/gtw/svc/online/auth/request/2021/10/01/0001" xmlns:ns2="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001" xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/online/types/2021/10/01/0001">
-<ns3:Context>
<Challenge>20220707-CR-C326864FD9-4925E51F36-6B</Challenge>
-<Identifier xsi:type="ns2:SubjectIdentifierByCompanyType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Identifier>1111111111</ns2:Identifier>
</Identifier>
-<DocumentType>
<ns2:Service>KSeF</ns2:Service>
-<ns2:FormCode>
<ns2:SystemCode>FA (1)</ns2:SystemCode>
<ns2:SchemaVersion>1-0E</ns2:SchemaVersion>
<ns2:TargetNamespace>http://crd.gov.pl/wzor/2021/11/29/11089/</ns2:TargetNamespace>
<ns2:Value>FA</ns2:Value>
</ns2:FormCode>
</DocumentType>
<Type>SerialNumber</Type>
</ns3:Context>
-<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="SignatureId-65bec1a7-3d9c-41df-8f96-0ca2d56a9f1c">
-<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"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>aGM47SZRhNynAHxmOLgWk4O1QBYwySfIhUdDyNifBaM=</DigestValue>
</Reference>
-<Reference URI="#SignatureProperties-65bec1a7-3d9c-41df-8f96-0ca2d56a9f1c" Type="http://uri.etsi.org/01903#SignedProperties">
-<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>4pZaWMWyOigyPfdhjXPR6dcJt9abIX9utwe3u06lntw=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>T0HxGuKFuICpLHUEwQkW8ZMtj6ehEtmIvZHhsfWJsiaV/AU2ydCD4gR1cpyUVgJLpY0jSToipWqpxCg4/Px8B0v4SEcbvYpZeNLdZW3JCrzhNO6oSrFmP2Orja06EZm0nh46QLM+ttXoStlOyZBVACf0xF21oO6rUYIwmePct1lfl2n7jhcTgHgacFjh9/1g+x4jziVKD5JxNBnINk6aw/edHbx+YJxCfN+EnhA93y6ZneW5XAPbC7aRlltTU2cj3QIH8bTcyQFcJO5fR+U3D9lyTx75LT6NENY7DNEClcSSN4Guk7khNVeUbN7ZVO4EnA+9F+V9WPJ7wpmsSlzFbw==</SignatureValue>
-<KeyInfo>
-<X509Data>
<X509Certificate>MIIDGzCCAgMCFDk2qIrrPgHDCdb+P7nMEtDcLkNdMA0GCSqGSIb3DQEBCwUAMEoxGTAXBgNVBGEMEFZBVFBMLTExMTExMTExMTExDTALBgNVBAMMBEFLTUYxETAPBgNVBAoMCFRFU1RBS01GMQswCQYDVQQGEwJQTDAeFw0yMjA3MDUxMTIzNTZaFw0yMzA3MDUxMTIzNTZaMEoxGTAXBgNVBGEMEFZBVFBMLTExMTExMTExMTExDTALBgNVBAMMBEFLTUYxETAPBgNVBAoMCFRFU1RBS01GMQswCQYDVQQGEwJQTDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNgUQk3kArwlkec+VIqKL69pbkJCWnYEK8Z1XCQyjSu1FYKktt4GTrVlstNpI1zh+C6Pclr16pA7pjmx/Jj20xN53v1En9ocwno8T263C60tSGtZ71FABDPhtAcOOXx3o9mmWK3zSSg7fpPpX7ybwoagtB5IBD+8oRlRSQd0EZIK723jEsLHS55er2O/1qRGl5wuhaUjYlmKmSTgWRtjObeS6vBCs4tZTud5tydxmcm/PDQKzv84nWZpkZ2cIzH1bqoDqluPD+lWAF6BIsjEn2YKqPMTTa3mrf9FZ5hM0lMJLClMYF4N72yCWzQ3PUHUSGESO0B+AGw78yhQBAR2fECAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAGTCaVpFkXCgm7B0fzSoP7CU8LqOJTXo5i0JR2OfuzTVhBwEdi3QacTzEGfzLAzjlIBMwaIkx2nhA+TDvqW0dA7z74RKWdYfNumObbbFXlpEOqnK8YT9A9pbhmlEuj+lK/2MUrklQHmsdNiY5ecZTayxV04KTYbXMcofYM2REbUkxEhBi0Rpa8+0jAySh1pRZyrPnf4Po3E0iawo367uevmVO5kmIHWuMXhMc1yxLYEAKyhzIX58Hz1ZWkNzrPEAzJjbPfw/G/OryMSrD8Ez3MmD+g0ibzoPJTAmHTWozDg4idkIGNoAkp+d4uKndXZ7lr6lAPUJFvhaZIsN3W3EsaA==</X509Certificate>
</X509Data>
</KeyInfo>
-<Object>
-<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#SignatureId-65bec1a7-3d9c-41df-8f96-0ca2d56a9f1c">
-<xades:SignedProperties Id="SignatureProperties-65bec1a7-3d9c-41df-8f96-0ca2d56a9f1c">
-<xades:SignedSignatureProperties>
<xades:SigningTime>2022-07-08T09:10:04+01:00</xades:SigningTime>
-<xades:SigningCertificate>
-<xades:Cert>
-<xades:CertDigest>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>Tt2jgryiCmTMW3TV7b0gDZCf2CJ0i4nAvaUV2+upQuc=</DigestValue>
</xades:CertDigest>
-<xades:IssuerSerial>
<X509IssuerName>C=PL, O=TESTAKMF, CN=AKMF, OID.2.5.4.97=VATPL-1111111111</X509IssuerName>
<X509SerialNumber>326631396313373214491507679831009216590473216861</X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</Object>
</Signature>
</ns3:InitSessionSignedRequest>

radek64 napisał(a):

Po nierównej walce, walidacja na stronie przeszła, a przynajmniej wartości podpisu i referencje.
Jednak swagger wyrzuca niezgodność ze schemą... czy to wina tylko prefixu ds: ? czy coś jeszcze mogę mieć tu skopane?

Dla potomnych zostawie tutaj xmla, który przechodzi walidacje podpisu i jest przyjmowany przez KSeF:

<?xml version="1.0" encoding="UTF-8"?>
<ns3:InitSessionSignedRequest xmlns="http://ksef.mf.gov.pl/schema/gtw/svc/online/types/2021/10/01/0001" xmlns:ns2="http://ksef.mf.gov.pl/schema/gtw/svc/types/2021/10/01/0001" xmlns:ns3="http://ksef.mf.gov.pl/schema/gtw/svc/online/auth/request/2021/10/01/0001">
	<ns3:Context>
		<Challenge>challenge</Challenge>
		<Identifier xsi:type="ns2:SubjectIdentifierByCompanyType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<ns2:Identifier>nip</ns2:Identifier>
		</Identifier>
		<DocumentType>
			<ns2:Service>KSeF</ns2:Service>
			<ns2:FormCode>
				<ns2:SystemCode>FA (1)</ns2:SystemCode>
				<ns2:SchemaVersion>1-0E</ns2:SchemaVersion>
				<ns2:TargetNamespace>http://crd.gov.pl/wzor/2021/11/29/11089/</ns2:TargetNamespace>
				<ns2:Value>FA</ns2:Value>
			</ns2:FormCode>
		</DocumentType>
		<Type>SerialNumber</Type>
	</ns3:Context>
	<ds:Signature Id="Id-abeaae8a-3377-4e16-b5ed-a1bfd4569e85" 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 Id="Id-b56a27f4-2ef4-447a-ad16-0a1accb3a7af" 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>slV+SDwizpzBp1BUtUs9O5nNyIFLiQOpwjdvQifGhp4=</ds:DigestValue>
			</ds:Reference>
			<ds:Reference Id="3423423" URI="#Id-8ab82271-dd01-46b8-af27-cb8efa3ab1c3" Type="http://uri.etsi.org/01903#SignedProperties">
				<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
				<ds:DigestValue>W5Hin+2bgA/UcRqomVRoAx127BCvtYJpW/Wk/jEZHIg=</ds:DigestValue>
			</ds:Reference>
		</ds:SignedInfo>
		<ds:SignatureValue Id="Id-ae3e9cfc-d4a9-4d51-a1b7-0ed951215563">JQdN12Q5crnSd6qhiokXqfKq1GmCULfVQ6609eDoSQuZyzm2z1OZ7OmkRJ/ekh1erjQ19KNJnGsv5u9UfT3e2LlUApEGf8A7uK5kPsGSVAfJQUzYZsdZHJH/zTaKwMVWTM2/IGnsoWRWEMzrbPSThobAIjTnWAxWOJRIdDTkEqwOssY/BKUPJOg1u4ptLK+cYprJhYCfeMXVwqUyp6Y7wF57QEsZlu10RsH1kgxeCEYyzRyfwYN5JHZTZCxCX2tvLhFIpR9iN9S+56OmM12npGFE0Dmmqz9JSXql35loXsfeWlVePS9k5z+xpMoXuT5JnVMExRSVOLkvxGOPSOdMKg==</ds:SignatureValue>
		<ds:KeyInfo>
			<ds:X509Data>
				<ds:X509Certificate>base64</ds:X509Certificate>
			</ds:X509Data>
		</ds:KeyInfo>
		<ds:Object Id="Id-67de730f-5b67-4aad-b398-fca78f6334a3">
			<xades:QualifyingProperties Target="#Id-abeaae8a-3377-4e16-b5ed-a1bfd4569e85" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">
				<xades:SignedProperties Id="Id-8ab82271-dd01-46b8-af27-cb8efa3ab1c3">
					<xades:SignedSignatureProperties>
						<xades:SigningTime>2022-07-08T09:30:55</xades:SigningTime>
						<xades:SigningCertificate>
							<xades:Cert>
								<xades:CertDigest>
									<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
									<ds:DigestValue>QfNbcUFiOmJTKioaudnJxKG0jAs=</ds:DigestValue>
								</xades:CertDigest>
								<xades:IssuerSerial>
									<ds:X509IssuerName>OID.2.5.4.97=VATPL-1111111111, </ds:X509IssuerName>
									<ds:X509SerialNumber>5471940697339195432402296733546891396061469568</ds:X509SerialNumber>
								</xades:IssuerSerial>
							</xades:Cert>
						</xades:SigningCertificate>
						<xades:SignaturePolicyIdentifier>
							<xades:SignaturePolicyImplied/>
						</xades:SignaturePolicyIdentifier>
					</xades:SignedSignatureProperties>
				</xades:SignedProperties>
			</xades:QualifyingProperties>
		</ds:Object>
	</ds:Signature>
</ns3:InitSessionSignedRequest>

z powyższego oczywiście wyrzuciłem challenge i nip, a z podpisu base64 certyfikatu podpisującego oraz pole issuername. Przy podpisywaniu zwróćcie uwagę, czy wasze certyfikaty na pewno są prawidłowo wygenerowane.

Witam

Czy ktoś orientuje się co to za parametry PageSize i PageOffset w endpoincie /online/Session/Status/{ReferenceNumber}?

Witam

Mam problem z odczytem stanu poświadczeń. Wykorzystuję URL /online/Credentials/Status/{CredentialsElementReferenceNumber}.

Na początku otrzymuję:
{"timestamp":"2022-07-11T1257.465Z","referenceNumber":"20220711-SE-1D0F1AC1C9-9FA2D09E98-5F","processingCode":100,"processingDescription":"Proces został zarejestrowany.","elementReferenceNumber":"20220711-EG-CAF1C481E7-1F40618E5D-E0"}

Po chwili:
{"timestamp":"2022-07-11T1207.210Z","referenceNumber":"20220711-SE-1D0F1AC1C9-9FA2D09E98-5F","processingCode":410,"processingDescription":"Nieprawidłowy format dokumentu (json).","elementReferenceNumber":"20220711-EG-CAF1C481E7-1F40618E5D-E0"}

Ale żadnego JSON'a nie wysyłam...

Witam,
Mam pewien problem z polskimi znakami w zwracanych JSON'ach z KSeF'u. Gdy wysyłam fakturę interaktywnie i wyślę ją niepoprawnie to otrzymuję tekst

..."exceptionDescription":"Limit żÄdaÅ osiÄgniÄty."...

lub

..."exceptionDescription":"NieprawidÅowy skrót pliku."...

ale gdy wyślę fakturę poprawnie to polski znak "Ł" jest zwracany prawidłowo

...processingDescription":"Proces został zarejestrowany."...

Ustawiam parametry:

...
RestClient.ContentType := 'application/json;charset=utf-8'; 
RESTResponse.ContentType := 'application/json;charset=utf-8';
RESTRequest.AcceptCharset := 'utf-8';
...

...
// Pobieram zwracany kontekst z RestResponse
fJSONResp := RESTResponse.Content;
...
// Próbowałem już przekonwertować zwracany tekst
1) Result := UTF8Encode(RESTResponse.Content);
2) Result := AnsiToUTF8(RESTResponse.Content);
3) Result := TStringStream.Create(RESTResponse.Content, TEncoding.UTF8).DataString;

Jednak żadna z powyższych metod nie wyświetla poprawnie polskich znaków.
Czy jest jeszcze jakiś sposób aby uzyskać prawidłowe kodowanie znaków?

Czy komuś jeszcze wlasnie przestał działać AuthorisationChallange ?

EDIT: juz działa ;)

Polegliśmy na integracji z KSeF już na początku jej tworzenia, dlatego szukamy kogoś komu to już się udało, lub może nas wspomóc w integracji w PHP. Dobrze zapłacimy.

Wrzuciłem też ogłoszenie:
https://4programmers.net/Forum/Og%C5%82oszenia_drobne/362189-skrypt_w_php_do_polaczenia_z_ksef

Mogły ktoś podzielić się plikiem InitRequest do wysyłki wsadowej który przechodzi na swaggerze? :)

radek64 napisał(a):

Mogły ktoś podzielić się plikiem InitRequest do wysyłki wsadowej który przechodzi na swaggerze? :)

Zanonimizowany tylko, więc nie przejdzie już (walidacja podpisu) ;)
req.zip

Okej czyli w Encryption muszę podać zaszyfrowany AES, a poniżej wektor tak? Czy package type zawsze jest single czy przyjmuje inne wartości jeszcze?
Dalej podaje wyliczony hash archiwum i jego części w base64, a file size jest wyrażone w bajtch?

radek64 napisał(a):

Okej czyli w Encryption muszę podać zaszyfrowany AES, a poniżej wektor tak? Czy package type zawsze jest single czy przyjmuje inne wartości jeszcze?
Dalej podaje wyliczony hash archiwum i jego części w base64, a file size jest wyrażone w bajtch?

Wszystko jest albo w definicji xml (xsd), albo w dokumentacji.

O rozmiar można się domyślić po definicji pól pokrewnych:

Cześć, czy może ktoś napisać jaka jest prawidłowa ścieżka aby dostać listę faktur z wybranego range?

Init request zwraca mi kod 200 Undocumented. Czy to jest poprawna odpowiedź?
Numer referencyjny które podaję we właściwej wysyłce zwraca błąd jako nieprawidłowy numer.

{
  "timestamp": "2022-07-14T10:48:31.768Z",
  "referenceNumber": "20220714-SE-C9203D677F-93E6D94505-F3",
  "packageSignature": {
    "packageName": "2022.zip.encrypted",
    "packagePartSignatureList": [
      {
        "ordinalNumber": 1,
        "partFileName": "2022.zip.encrypted",
        "url": "https://ksef-test.mf.gov.pl/api/batch/Upload/20220714-SE-C9203D677F-93E6D94505-F3/20220714-EA-428CE2DB22-E76029B619-19",
        "method": "PUT",
        "headerEntryList": [
          {
            "key": "Content-SHA256",
            "value": "Yt/fIAOfp9H2FXjfpChjVuZ14RKEz7Dycq7bjf8nRTo="
          },
          {
            "key": "X-TargetSrv-Name",
            "value": "srvTEMFA"
          }
        ]
      }
    ]
  }
}

{
  "exception": {
    "serviceCtx": "srvTEMFA",
    "serviceCode": "20220714-EX-908924E839-BD81FEFFDC-8B",
    "serviceName": "batch.upload",
    "timestamp": "2022-07-14T11:27:37.282Z",
    "referenceNumber": "20220714-SE-C9203D677F-93E6D94505-F3",
    "exceptionDetailList": [
      {
        "exceptionCode": 21408,
        "exceptionDescription": "Nieprawidłowy numer referencyjny."
      }
    ]
  }
}

1. Utworzyłem sesję w DEMO poprzez InitSigned (uprawnienia właściciela)
2. Prawidłowo wygenerowałem token dla innej osoby
3. Za kilka godzin sprawdziłem czy sesja nie wygasła (sprawdziłem status sesji). ProcessingCode nadal 315 czyli sesja otwarta.
4. Chciałem wygenerować kolejny token ... i co? - "brak autoryzacji"

Czy ktoś wie o co chodzi?

PS. Zaczynam wątpić, że uda mi się opanować ten system :(

Czy ktoś może zderzył się z problemem wysyłania asynchronicznego zapytania o faktury? Wysyłam najpierw zapytanie na online/Query/Invoice/Async/Init

{"queryCriteria":{"type":"range","invoicingDateFrom":"2022-01-01T10:00:00Z","invoicingDateTo":"2022-07-01T10:00:00Z","subjectType":"subject1"}}

W odpowiedzi dostaje ReferenceNumber i ElementReferenceNumber. Następnie odpytuje online/Query/Invoice/Async/Status/{elementReferenceNumber}, które przetwarza to przez kilka godzin i początkowo zwraca odpowiedzi o przetwarzaniu i dzieleniu na podzapytania a potem kolejne zapytania odsyłają błąd

{"exceptionCode":31000,"exceptionDescription":"Nieprawidłowe wywołanie."}

Czy może to zapytanie musi wejść w tej samej sesji co Async/Init i wysłanie z nowym tokenem sesji prowadzi do nieprawidłowego wywołania?

W jaki sposób generujecie podpis i podpisujecie nim plik przesyłany na InitSigned?

Używam własnego imiennego podpisu zakupionego w Certum i po przesłaniu na bramkę testową dostaję Brak Autoryzacji:
{
"exception": {
"serviceCtx": "srvTEMFC",
"serviceCode": "20220715-EX-FE3C4DDB55-D3A69965AA-BB",
"serviceName": "online.session.session.signed.init",
"timestamp": "2022-07-15T1407.004Z",
"referenceNumber": "20220715-SE-F611267081-1FD5633962-FA",
"exceptionDetailList": [
{
"exceptionCode": 21301,
"exceptionDescription": "Brak autoryzacji."
}
]
}
}

Co ciekawe w ten sam sposób podpisany plik na serwerze produkcyjnym zwraca poprawnie token.

Nie wiem, gdzie szukać błędu.