[Liferov]

Próbował już ktoś tworzyć aplikacje do wysyłania JPK zgodnie ze specyfikacją MF? Przebrnąć przez te wszystkie kompresje, kodowanie, generowanie xml, podpis elektroniczny i podłączenie się do bramki?

#programowanie #sap #erp #jpk

[hipek1001]

po 23h dostałem odpowiedź i mam ten sam błąd - 410.Używam biblioteki DotNetZip

http://pastebin.com/mdSrJeu0

[kemot13]

@hipek1001: Cyganieszka napisała, ze miała ten sam problem i uzyła do zaszyfrowania losowego kodu innego pem'a. I zadziałało. @Cyganieszka, czy możesz napisać którego dokładnie pliku pem uzywasz na PROD? Dzieki

[kemot13]

Dziwne, że obojętnie którego pliku pem uzyje, to dostaje ten sam błąd, czyli 410. Coś tu jest nie tak.

[kemot13]

Napisałem na [e-mail], ale pewnie jak zwykle zadnej odpowiedzi.

[hipek1001]

@kemot13 tylko jeśli użyję innego .pem do szyfrowania to MF już nie odszyfruje klucza i danych

[kemot13]

@hipek1001: no właśnie, czyli jeżeli wysyłam pliki szyfrowane przy użyciu dwóch różnych kluczy publicznych to przynajmniej w jednym przypadku powinienem otrzymać nieco inny komunikat

[rollon]

Jeżeli dostałem odpowiedź:

{"Code":401,"Description":"Weryfikacja negatywna – dokument niezgodny ze schematem xsd","Details":"ERRORVALIDATE","Timestamp":"2016-08-09T10:18:05+00:00","Upo":""}_

To oznacza że plik udało się odszyfrować i rozpakować czy wcale tak nie musi być?

[Gibonowski]

@rollon: wszystko git, miałem to samo. Wyślij poprawny plik JPK to dostaniesz 200

[hipek1001]

@Gibonowski rozumiem, że otrzymujesz UPO ?

[Gibonowski]

@hipek1001: tak, masz tu jak to wygląda: https://e-dokumenty.mf.gov.pl/api/Storage/Status/693c90500020c2bc000000b0026546ed

[robert111222333]

mam pytanie do osob, ktore otrzymywaly status
"410 - Przesłane pliki nie są prawidłowym archiwum ZIP",

jak udało Ci się rozwiązać ten problem?

Dodatkowo pytanie do wszystkich - ile czasu czekasz od statusu

[rollon]

@Gibonowski Mógłbyś zamieścić przykładowy plik JPK.xml. Ten z ministerstwa ma tylko nagłówek :(
Nagłówek mam tak samo jak w pliku z ministerstwa więc coś nie tak w węzłach sprzedaży ... :(

[hipek1001]

@Gibonowski odnosnie szyfrowania wygenerowanego klucza AES. Domyślam się, że szyfrujesz tylko PrivateKey, konwertujesz go na Base64 i umieszczasz w xml InitUpload. A co z IV z klucza AES ? Też go szyfrujesz czy tylko konwertujesz do Base64 i umieszczasz w InitUpload ?

[Gibonowski]

@hipek1001: konwertuje do base64
@rollon: http://www.speedyshare.com/WPHCt/FA-FA2016-07-28-21-00-15.xml

[Gibonowski]

@robert111222333: strasznie długo trzeba czekać, pare godzin gdzies ale nie wiem ile dokładnie bo nie odświeżam co chwilę

[durek89]

@Gibonowski glupie pytanie ale czy wyslasz spakowany plik to ma roszerzenie .zip czy np .zip.aes

[Gibonowski]

@durek89: nie głupie, sam to rozkminiałem ale rozszerzenie chyba nie ma znaczenia. Ja robie wszystko w pamięci także nie mam żadnego rozszerzenia. Począwszy od utworzenia zipa poprzez zaszyfrowanie i wysyłke, nic nie zapisuje na dysku

[hipek1001]

@Gibonowski też robię wszystko w pamięci a jednak coś nie pasuje. Z JPKVAT też otrzymujesz UPO ? bo ja obecnie testuję tylko JPKVAT a widzę, że podesłałeś JPK_FA.

[Gibonowski]

@hipek1001: VAT: https://e-dokumenty.mf.gov.pl/api/Storage/Status/693b7f7c0187bc5d000000b06f61450d

[adam-bubula]

Jak przesyłaliście plik do InitUploadSigned? ja próbuję przez HttpClient. Mam coś takiego:

HttpClient client = new HttpClient(handler);
client.BaseAddress = new Uri("[https://test-e-dokumenty.mf.gov.pl](https://test-e-dokumenty.mf.gov.pl)");
client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/xml"));

var