Cześć.
czy ktoś już przymierzał się do integracji z KSeF?
Jakieś wrażania, pomysły, problemy?
https://ksef-test.mf.gov.pl/
Pozdrawiam
Jacek
0
0
Ja pracuję nad tym, odezwij się.
1
Ogólnie tragedia, nie działa w całości, ciągłe zmiany.
Email kontaktowy [email protected] nie odpowiada.
Dokumentacja nie pełna, braki pól które są niezbędne do komunikacji.
Nagranie Webinar w nędznej jakości (przerwy)
2
@karol75: Webinar w dobrej jakości dostępny jest od jakichś dwóch tygodni na YouTube na kanale Ministerstwa Finansów:
Ogólnie potwierdzam, że tragedia... W dokumentacji nieścisłości, napisana nieprzystępnie, wszystkiego trzeba się domyślać, brak opisów błędów, brak opisów wymaganych stałych. W dodatku na maile nikt nie reaguje. Mimo to wysyłkę na środowisko testowe da się jednak zrealizować bazując na opublikowanych informacjach. Mi w każdym razie się udało nawiązać połączenie, wysłać dokument i otrzymać zwrotnie UPO :)
0
słabo to wygląda, ale ostatnio nieco się ruszyło i po zmianach z końca grudnia (niekompatybilnych z wcześniejszą wersją) można się zalogować, wygenerować token i wysłać fakturę - przynajmniej interfejsem interaktywnym. Działa też sprawdzanie uprawnień i pobieranie listy faktur. Dokumentacja jest tragiczna, na pytania zadane mailem brak odpowiedzi. Z wersji na wersję to co już działało poprawnie - przestaje działać.
0
Undocumented
Failed to fetch.
Possible Reasons:
CORS
Network Failure
URL scheme must be "http" or "https" for CORS request.
Sprawdzanie sesji, statusu faktury i pewnie inne.
Przed świętami działało.
0
Na github mam kod, który jeszcze w czwartek 30 grudnia działał.- logowanie, status sesji wysyłka faktury. Tuż po świętach była zmiana w modelu i wywalało się już na logowaniu. 1 stycznia były kolejne zmiany, ale jeszcze nie sprawdzałem czy działa.
0
Czy komuś udało się użyć endpointu api/online/Session/InitToken? Wygenerowałem token online/Credentials/GenerateToken, przygotowałem request XML zgodnie z tym co jest w "dokumentacji" i co zostało zademonstrowane na webinarze, ale od tygodnia dostaję 500 Internal Server Error, a na maile, uprzejmi autorzy systemu - nie odpisują. Odpowiedź z api/online/Session/InitToken:
{
"exception": {
"serviceCtx": "srvTEMFA",
"serviceCode": "20220106-EX-_______________________",
"serviceName": "online.session.session.token.init",
"timestamp": "2022-01-06T10:56:28.317Z",
"referenceNumber": "20220106-SE-____________________",
"exceptionDetailList": [
{
"exceptionCode": 33000,
"exceptionDescription": "Błąd wewnętrzny (A)."
}
]
}
}
Request:
POST https://ksef-test.mf.gov.pl/api/online/Session/InitToken
Accept: application/json
Content-Type: application/octet-stream
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:InitSessionTokenRequest 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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://ksef.mf.gov.pl/schema/gtw/svc/online/auth/request/2021/10/01/0001 https://ksef.mf.gov.pl/schema/gtw/svc/online/auth/request/2021/10/01/0001/authRequest.xsd">
<ns3:Context>
<Challenge>20211230-_________________________</Challenge>
<Identifier xsi:type="ns2:SubjectIdentifierByCompanyType">
<ns2:Identifier>________________________</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>
<Token>............................................................</Token>
</ns3:Context>
</ns3:InitSessionTokenRequest>
0
Czy jest ktoś chętny do podzielenia się (odpłatnie) kodem w C# potrafiącym wysłać fakturę i pobrać UPO?
0
Z czym konkretnie masz problem? Czego nie wiesz jak zrobić?
0
czy komuś udało zalogować się tokenem autoryzacyjnym? Czyli najpierw zalogować się "tradycyjnie", podpisanym żądaniem autoryzacyjnym, wygenerować token a następnie zalogować się tokenem przez endpoint api/online/Session/InitToken? Próbuję na testowym i produkcyjnym środowisku, o ile generowanie tokena ostatnio działa, to już sprawdzenie jego statusu oraz logowanie nim, kończy zawsze się 500 Internal Server Error błąd wewnętrzny (A).
Wczoraj i w poniedziałek ogólnie nic nie działało, ale dziś wraca do normy. Poza logowaniem tokenem.
0
U mnie działa! Jeśli Wam także pojawia się Internal Server Error, Błąd wewnętrzny (A) podczas logowania się tokenem - to sprawdźcie klucze publiczne. Okazuje się, że po cichutku, zostały zmienione na nowe. Taki drobiazg. Dodatkowo, warto zwrócić uwagę, na to czy pobielamy je z właściwej strony, odpowiadającej środowisku na które chcemy się logować - na stronach środowiska produkcyjnego opis głosi że to klucze to środowiska testowego, co jest nieprawdą. Można stracić trochę czasu na rozkminkę.
Jeśli sądzicie, ze dowiedziałem się tego z pomocy technicznej... to nie.
0
Cześć,
Próbuję zacząć się integrować z KSeF, przy wywołaniu online/Session/InitSigned dostaję zwrotkę: {exceptionCode=21207, exceptionDescription=Nieprawidłowy podmiot podpisu.}
Jeżeli dobrze rozumiem, to nie potrafię dobrze wygenerować testowego certyfikatu.
Czy ktoś mógłby podać łatwy przepis na generowanie certyfikatu do podpisu?
Bardzo chętnie również się wymienię z kontaktem, by móc się ewentualnie wspierać przy walkach z KSefem.
Pozdrawiam,
Tomek
0
@alapierre: Dziękuję za podpowiedź. Używając openssl mogę ustawić atrybuty takie jak: Country, State, Location, Organization i kilka innych. Nie wiem jak ustawić serialNumber. Czy dysponuje Pan jakimś wywołaniem, które umożliwia wygenerowanie certyfikatu odpowiedniego dla KSeF (dla dowolnej firmy testowej)?
Czy jest ktoś komu udało się wygenerować certyfikat akceptowalny przez środowisko testowe KSeF i mógłby podpowiedzieć jak to zrobić?
0
@alapierre: Stosując się do Pana zaleceń generuję CSR w następujący sposób (okazuje się, że mogę podać serialNumber również poprzez -subj):
-
Generowanie CSR:
openssl req -new -keyout mykey.key -subj '/CN=www.testfirma.pl/O=Testowa firma/C=PL/serialNumber=NIP-1801908070' -out mycsr.csr -
Podgląd CSR:
openssl req -in mycsr.csr -noout -text -nameopt sep_multiline
Co daje:
Certificate Request:
Data:
Version: 0 (0x0)
Subject:
CN=www.testfirma.pl
O=Testowa firma
C=PL
serialNumber=NIP-1801908070
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
.....
-
Podpisuję CSR:
openssl x509 -signkey mykey.key -in mycsr.csr -req -days 365 -out certificate.pem -
Podgląd certyfikatu:
openssl x509 -text -noout -in certificate.pem
Co daje:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 10600119439181737325 (0x931b3077d523ed6d)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=www.testfirma.pl, O=Testowa firma, C=PL/serialNumber=NIP-1801908070
Validity
Not Before: Jan 20 10:43:00 2022 GMT
Not After : Jan 20 10:43:00 2023 GMT
Subject: CN=www.testfirma.pl, O=Testowa firma, C=PL/serialNumber=NIP-1801908070
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
.....
-
Eksportuję do keystore:
openssl pkcs12 -export -out keyStore.p12 -inkey mykey.key -in certificate.pem -
Pobieram challenge oraz generuję podpisane żądane (
signedRequest.xml- w załączniku) request wysłany na:https://ksef-test.mf.gov.pl/api/online/Session/InitSigned.
Dostaję zwrotkę z kodem 400:
{exception={exceptionDetailList=[{exceptionCode=21207, exceptionDescription=Nieprawidłowy podmiot podpisu.}], referenceNumber=20220120-SE-4039B34264-374702A21F-3F, serviceCode=20220120-EX-EE561894B4-0CA03A3553-8D, serviceCtx=srvTEMFB, serviceName=online.session.session.signed.init, timestamp=2022-01-20T10:52:26.717Z}}
Jestem trochę w martwym punkcie.
Czy ktoś mógłby się podzielić poprawnym certyfikatem, może robie coś źle przy wywołaniu?
1
U mnie generowanie csr-a przy generowaniu pieczęci wygląda tak:
openssl req -newkey rsa:2048 -nodes -keyout key.pem -out certificate.csr -subj "/C=PL/ST=Lubelskie/L=Lublin/O=skich/OU=ECM/CN=test klient/[email protected]/2.5.4.97=VATPL-5250001090"
0
Cześć
Możecie się podzielić jakie response otrzymujecie z /online/Credentials/Status/{CredentialsElementReferenceNumber} sprawdzając status tokenu. Obecnie mam
"processingCode": 200,
"processingDescription": "Zakończenie etapu finalizacji i zakończenia procesu"
Na webinarze prowadzący otrzymał
"processingCode": 200,
"processingDescription": "Proces uprawnień zakończony".
Wykorzystując token w /online/Session/InitToken otrzymuje "Brak autoryzacji" i teraz nie wiem czy w miedzy czasie zmienili description i token jest ok ale ja niepoprawnie szyfruje go kluczem publicznym czy może po stronie KSEF proces związany z tokenem nie został zakończony.
0
Też dostaję:
"processingCode": 200,
"processingDescription": "Zakończenie etapu finalizacji i zakończenia procesu",
}
i nawiązuje sesje nowym tokenem poprawnie.
Sprawdz klucz publiczny Ksef, niedawno go zmienili, może starym szyfrujesz.
0
A czy komuś udało się na środowisku testowy dostać w odpowiedzi na api/online/Session/Status/{ReferenceNumber} dostać json-a z niepustą listą invoiceStatusList ?
Ile bym nie czekała odpowiedź zawsze wygląda mniej więcej tak:
{
"timestamp": "2022-01-20T08:13:34.213Z",
"referenceNumber": "...",
"numberOfElements": 1,
"pageSize": 0,
"pageOffset": 100,
"processingCode": 200,
"processingDescription": "Zakończenie etapu finalizacji i zakończenia procesu",
"invoiceStatusList": []
}
Wg schemy powinna być tam lista faktur z numerami ksef i processingCode ale nawet dla sesji dla których mamy upo ta lista jest pusta.
Może na produkcji to działa?
0
@michalll88: ja na produkcji otrzymuję Internal Server Error "błąd wewnętrzny (A)", choć token jest prawidłowy i można się nim zalogować. Na teście nie sprawdzałem. Tokenem można (powinno dać) się zalogować, nawet jeśli proces jego weryfikacji nie zakończył się jeszcze. Klucze publiczne zostały po cichu podmienione, ale podpisanie złym kluczem, lub w wysłanie nieprawidłowego request'u daje 500 Internal Server Error. Ostatnio czytałem w komentarzach do artykułu o KSeF na Gazecie Prawnej, że dla twórców KSeF status 500 i 400 są synonimami i oznaczają bad content.
0
konfiguracja OpenSSL dla pieczęci:
[ req ]
distinguished_name = dn
prompt = no
[ dn ]
CN = Testowa Firma
O = Firma Testowa
C = PL
organizationIdentifier=VATPL-1111111111
konfiguracja dla podpisu
[ req ]
distinguished_name = dn
prompt = no
[ dn ]
CN = Adam Nowakowski
SN = Nowakowski
GN = Adam
O = Firma Konsultingowa
C = PL
serialNumber = NIP-1111111111
L = Mazowieckie
eventuate, jak ktoś chce można z PESEL, wtedy serialNumber = PNOPL-11111111111
UWAGA: zarówno NIP jak i PESEL powinny się walidować.
generowanie CSR:
openssl req -new -config nazwa_pliku_konfiguracyjnego.txt -keyout a.key -out a.csr
0
@michalll88: Cześć. Mam podobnie jak Ty problem z poprawnym wywołaniem online/Session/InitToken.
W pierwszej fazie, gdy status tokena jest Proces rozpoczety, to wywołując online/Session/InitToken dostaję błąd 400 - {exceptionCode=21102, exceptionDescription=Token nieaktywny.}
W momencie, gdy token jest już w statusie Zakończenie etapu finalizacji i zakończenia procesu, to wywołanie online/Session/InitToken zwraca błąd 400 - {exceptionCode=21101, exceptionDescription=Brak autoryzacji.}
Rozumiem, że szyfruję wiadomość prawidłowo, skoro KSeF "wie" o jaki token chodzi. Mam problem z rozgryzieniem błędu "Brak autoryzacji"
Daj proszę znać, jeżeli uda Ci się rozwiązać ten problem.
0
@tomaszka: jakie uprawnienia dałeś generując token?
0
Dziś na środowisku testowym na zapytanie o aktywną sesję, (api/online/Session/Status?PageSize=100&PageOffset=0) wraca poprawna lista faktur wysłanych:
{
"timestamp": "2022-01-22T10:04:17.590Z",
"referenceNumber": "...................................................",
"numberOfElements": 1,
"pageSize": 100,
"pageOffset": 0,
"processingCode": 315,
"processingDescription": "Sesja interaktywna aktywna. Komunikacja otwarta.",
"invoiceStatusList": [
{
"processingCode": 200,
"processingDescription": "Zakończenie etapu finalizacji i zakończenia procesu",
"elementReferenceNumber": "...............................................",
"invoiceNumber": "FV2022/01/4",
"ksefReferenceNumber": "...........................",
"acquisitionTimestamp": "2022-01-22T10:01:33.638Z"
}
]
Zapytanie o status sesji po jej numerze referencyjnym (api/online/Session/Status/20220122-XX-XXXXXXXXXX-XXXXXXXXXX-13?PageSize=100&PageOffset=0), także zwraca poprawną listę:
{
"timestamp": "2022-01-22T10:12:16.010Z",
"referenceNumber": "..........................................,
"numberOfElements": 1,
"pageSize": 100,
"pageOffset": 0,
"processingCode": 350,
"processingDescription": "Sesja interaktywna zakończona. Komunikacja zamknięta.",
"invoiceStatusList": [
{
"processingCode": 200,
"processingDescription": "Zakończenie etapu finalizacji i zakończenia procesu",
"elementReferenceNumber": "..................................................................",
"invoiceNumber": "FV2022/01/4",
"ksefReferenceNumber": ".....................................................",
"acquisitionTimestamp": "2022-01-22T10:01:33.638Z"
}
]
}
na zapytania o sesję, z podaniem błędnego numeru referencyjnego (api/online/Session/Status/20220119-XX-XXXXXXXXXX-XXXXXXXXXX-XX?PageSize=100&PageOffset=0), znany i lubiany Błąd wewnętrzny (A). Czyli faktycznie, jak to napisała pewna miła pani komentując artykuł w Gazecie Prawnej, dla twórców KSeF statusy błędów o kodzie 500 i 400 są synonimami. Pogratulować twórcom znajomości dobrych praktyk i specyfikacji HTTP.
Pewnie to ona programowała obsługę błędów....
Pobranie UPO także działa - dzięki za wcześniejszą wskazówkę.
0
{
"timestamp":"2022-01-22T1743.735Z",
"invoiceHash": {
"hashSHA": {
"algorithm": "SHA-256",
"encoding": "Base64",
"value": "mAJHWtZG0gYmQ9MVXdgdkZ6obBaRs9d+DRgt4a7JZBg="
},
"fileSize": 5977
},
"invoicePayload": {
"payloadType": "plain",
"invoiceBody": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjxGYWt0dXJhIHhtbG5zOmV0ZD0iaHR0cDovL2NyZC5nb3YucGwveG1sL3NjaGVtYXR5L2R6aWVkemlub3dlL21mLzIwMjEvMDYvMDkvZUQvRGVmaW5pY2plVHlweS8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiDQp4bWxucz0iaHR0cDovL2NyZC5nb3YucGwvd3pvci8yMDIxLzExLzI5LzExMDg5LyI+DQoJPE5hZ2xvd2VrPg0KCQk8S29kRm9ybXVsYXJ6YSBrb2RTeXN0ZW1vd3k9IkZBICgxKSIgd2Vyc2phU2NoZW15PSIxLTBFIj5GQTwvS29kRm9ybXVsYXJ6YT4NCgkJPFdhcmlhbnRGb3JtdWxhcnphPjE8L1dhcmlhbnRGb3JtdWxhcnphPg0KCQk8RGF0YVd5dHdvcnplbmlhRmE+MjAyMi0wMi0xNVQwOTozMDo0N1o8L0RhdGFXeXR3b3J6ZW5pYUZhPg0KCQk8U3lzdGVtSW5mbz5TYW1wbG9mYWt0dXI8L1N5c3RlbUluZm8+DQoJPC9OYWdsb3dlaz4NCgk8UG9kbWlvdDE+DQoJCTxEYW5lSWRlbnR5ZmlrYWN5am5lPg0KCQkJPE5JUD44NjA2ODkyMjQyPC9OSVA+DQoJCQk8UGVsbmFOYXp3YT5BQkMgQUdEIHNwLiB6IG8uIG8uPC9QZWxuYU5hendhPg0KCQk8L0RhbmVJZGVudHlmaWthY3lqbmU+DQoJCTxBZHJlcz4NCgkJICAgCTxBZHJlc1BvbD4NCgkJCQk8S29kS3JhanU+UEw8L0tvZEtyYWp1Pg0KCQkJCTxVbGljYT5Ld2lhdG93YTwvVWxpY2E+DQoJCQkJPE5yRG9tdT4xPC9OckRvbXU+DQoJCQkJPE5yTG9rYWx1PjI8L05yTG9rYWx1Pg0KCQkJCTxNaWVqc2Nvd29zYz5XYXJzemF3YTwvTWllanNjb3dvc2M+DQoJCQkJPEtvZFBvY3p0b3d5PjAwLTAwMTwvS29kUG9jenRvd3k+DQoJCQk8L0FkcmVzUG9sPg0KCQk8L0FkcmVzPg0KCQk8RW1haWw+YWJjQGFiYy5wbDwvRW1haWw+DQoJCTxUZWxlZm9uPjY2NzQ0NDU1NTwvVGVsZWZvbj4JCQ0KCTwvUG9kbWlvdDE+DQoJPFBvZG1pb3QyPg0KCQk8RGFuZUlkZW50eWZpa2FjeWpuZT4NCgkJCTxOSVA+ODIxODg3NzM3NDwvTklQPg0KCQkJPFBlbG5hTmF6d2E+Q0RFIHNwLiBqLjwvUGVsbmFOYXp3YT4NCgkJPC9EYW5lSWRlbnR5ZmlrYWN5am5lPg0KCQk8QWRyZXM+DQoJCSAgIAk8QWRyZXNQb2w+DQoJCQkJPEtvZEtyYWp1PlBMPC9Lb2RLcmFqdT4NCgkJCQk8VWxpY2E+U2Fkb3dhPC9VbGljYT4NCgkJCQk8TnJEb211PjE8L05yRG9tdT4NCgkJCQk8TnJMb2thbHU+MzwvTnJMb2thbHU+DQoJCQkJPE1pZWpzY293b3NjPktyYWvDs3c8L01pZWpzY293b3NjPg0KCQkJCTxLb2RQb2N6dG93eT4wMC0wMDI8L0tvZFBvY3p0b3d5Pg0KCQkJPC9BZHJlc1BvbD4NCgkJPC9BZHJlcz4NCgkJPEVtYWlsPmNkZUBjZGUucGw8L0VtYWlsPg0KCQk8VGVsZWZvbj41NTU3Nzc5OTk8L1RlbGVmb24+DQoJCTxOcktsaWVudGE+ZmRmZDc3ODM0MzwvTnJLbGllbnRhPg0KCTwvUG9kbWlvdDI+DQoJPFBvZG1pb3QzPg0KCQk8RGFuZUlkZW50eWZpa2FjeWpuZT4NCgkJCTxOSVA+MjIyMjIyMjIyMjwvTklQPg0KCQkJPFBlbG5hTmF6d2E+QmFuayBCYW5rb3dvxZtjaSBCYW5rb3dlaiBTLiBBLjwvUGVsbmFOYXp3YT4NCgkJCTxOYXp3YUhhbmRsb3dhPkJCQiBGYWt0b3Jpbmc8L05hendhSGFuZGxvd2E+DQoJCTwvRGFuZUlkZW50eWZpa2FjeWpuZT4NCgkJPEFkcmVzPg0KCQkgICAJPEFkcmVzUG9sPg0KCQkJCTxLb2RLcmFqdT5QTDwvS29kS3JhanU+DQoJCQkJPFVsaWNhPkJhbmtvd2E8L1VsaWNhPg0KCQkJCTxOckRvbXU+MTwvTnJEb211Pg0KCQkJCTxNaWVqc2Nvd29zYz7FgcOzZMW6PC9NaWVqc2Nvd29zYz4NCgkJCQk8S29kUG9jenRvd3k+MDAtMDAzPC9Lb2RQb2N6dG93eT4NCgkJCTwvQWRyZXNQb2w+DQoJCTwvQWRyZXM+DQoJCTxFbWFpbD5iYmJAZWZha3RvcmluZy5wbDwvRW1haWw+DQoJCTxUZWxlZm9uPjY2Njg4ODk5OTwvVGVsZWZvbj4NCgkJPFJvbGE+MTwvUm9sYT4NCgk8L1BvZG1pb3QzPg0KCTxGYT4NCgkJPEtvZFdhbHV0eT5QTE48L0tvZFdhbHV0eT4NCgkJPFBfMT4yMDIyLTAyLTE1PC9QXzE+DQoJCTxQXzFNPldhcnN6YXdhPC9QXzFNPg0KCQk8UF8yPkZWMjAyMi8wMi8xNTA8L1BfMj4NCgkJPFdaPjQ0MzQzNDM0LzIwMjI8L1daPg0KCQk8UF8xM18xPjUyMjYwLjEwPC9QXzEzXzE+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=="
}
}
Próbuję wysłać na testowym Fakturę.
Zgłasza bład 400 "exceptionCode":21204,"exceptionDescription":"Nieprawidłowy format dokumentu (json).
Może ktoś coś?
0
@alapierre: Uprawnienia z którymi generuję token to:
{
"generateToken": {
"description": "string",
"credentialsRoleList": [
{
"roleType": "invoice_read",
"roleDescription": "Odczyt faktur"
}
]
}
}
Nadal otrzymuję komunikat exceptionDescription=Brak autoryzacji przy próbie nawiązania sesji tokenem.
0
Cześć,
Czy ktoś mógłby się podzielić tokenem do logowania na środowisku testowym? Aktualnie wszystkie moje próby logowania tokenem kończą się błędem Brak autoryzacji?
Może po prostu coś żle robie przy logowaniu, niestety jedyna szansa to sprawdzić już działający token, którego nie mam.
Pozdrawiam,
Tomek
**EDIT: Udało mi się zalogować tokenem wygenerowanym z sesji certyfikatem z PESEL w kontekście testowego NIP. **
0
Kolejna zagwostka.
Czy ktoś wie co oznacza status "skip" przetwarzania dodanej faktury (sprawdzenie przez /Invoice/Status)? Udało mi się wczoraj wytawić jedną fakturę natomiast teraz każda kolejna kończy się na "skip".
processingCode=320, processingDescription=skip
Pozdrawiam,
Tomek
0
Zgodnie z -Treść pola Token to zakodowana Base64 tablica bajtów zaszyfrowanego kluczem publicznym ciągu
znaków składającego się z konkatenacji tokena autoryzacyjnego, znaku separatora | oraz wartości
liczbowej (long) znacznika czasowego wyzwania autoryzacyjnego.'
CZas biorę z /online/Session/AuthorisationChallenge
zczas:= MillisecondOfTheDay(lDate)
Próbuję xxxxxx+'|'+zczas i dalej rsa base64
i dostaję nieprawidłowy czas tokena.
Czy coś robię nie tak?
0
Czy ktoś wie jak poprawnie sprawdzić czy sesja interaktywna jest aktywna i pozwala na wyknywanie zapytań? Oczywiście wykonanie zapytania na nieaktywnej sesji zwróci błąd 400 oraz opis exceptionCode=21219, exceptionDescription=Sesja interaktywna zakończona.. Czy przy wowołaniu Session/Status powinno przyjść "processingCode": 200 czy jest jakis inny jendoznaczny wyznacznik, mówiący że sesja interaktywna wygasła?