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?
Hej, założyłem konto bo też na tym siedzę :) Męczmy się razem. @rollon tez miałem taki błąd. Po prostu ta biblioteka Microsoft.Xades nie robi takiego Xadesa jak chce JPK. Najlepiej wydrukuj swój pliczek (ja robie enveloping) i ich pliczek i linijka po linijce sobie popatrz na różnice. Niestety nie obejdzie się bez dłubania w libie do xadesa i jego rekompilacji. Najważniejsza zmiana to to że brakuje przedrostków "xades:" od wężła QualifyingProperties w
W związku z tym że razem siedzimy w tym bagnie to mam kilka pytanek. Wydaje mi się że mam już wszystkie etapy zrobione, ale czuje że jeszcze to nie do końca bedzie grało (działa, ale nie tak jak potrzeba :P ) . Mam w zwiazku z tym pytanka do was:
@mmm234 czyli masz podpis prawdziwy kupiony. Jak zatem robisz technicznie sam podpis w c#. Generujesz sobie pliczek meta InitUpload.xml. potem go podpisujesz Xadesem? Czy po prostu proces jest półautomatyczny, czyli generujesz pliczek meta. Potem jakoś ręcznie w zestawie od certum zaznaczasz ten plik do podpisania, podpisujesz i potem wysyłasz w kolejnym kroku do bramki? Pytam bo nigdy nie miałem takiego zestawu w rękach. Bo w c# można pobrać certy ze storu za
@mmm234 właśnie o to mi chodziło. Czyli wczytujemy ten cert ze Stora (nawet mam też taki kawałek kodu już gotowy wiec spoko). Tak wiec jak ktoś kupi sobie podpis i go zainstaluje w systemie to on pojawia się tam w storze i ja moge go sobie pobrać...? Sam podpis Xadesem mam już ogarnięty tylko nie miałem obrazu jak wyglada ładowanie tam certu. Bo kombinowałem z PFXami, a wychodzi że to jest łatwiejsza
a czego używasz do zipowania? Ja użyłem Ionic.Zip . Niby spakowało ale niestety z racji powyższego że test mi dalej nie przetwarza to nie jestem w stanie powiedziec czy przygotował poprawne archiwum...
Ok przerobiłem kod na pobieranie certów ze stora. Ale wychodzi na to że jednak mój podpis XADES jest zły - dlatego go nie weryfikuje? Czy ktos tutaj dobrnał do podpisania pliku za pomocą Microsoft.Xades? Obstawiam że jednak mam tam jakiś błąd chyba...
@rollon Na chłopski rozum to by dotyczyło niezgodności pliku InitUpload.xml ale skoro wysyłasz sampla to powinno być ok. Oni cały czas przy tym grzebią więc nie zdziwiłbym się gdyby ten samplowy plik był rozjechany z tym co wymaga xsd. Ja bym szedł tym tropem.
@Przemek78 a tobie udało się podpisac tą bibioteką Microsoft.Xades? Bo niby po moich poprawkach już pokazuje że nie jest to podpis w innym formacie niż XADES ale ciagle stoi na tym że niby podpis niezweryfkowany. Stąd myślę że może moje poprawki to jeszcze zbyt mało...
@durek89 a Tobie udało się podpisać tym zmodyfikowanym Microsoft.Xades? Bo cały czas myślę czy mam zły podpis (raczej nie bo wypuszczam na testa gdzie go nie weryfkują), czy może coś zwaliłem w tym podpisywaniu?
@rollon: ja to ("Could not find schema information for the element 'Signatures'." .) bardziej rozumiem jako: "W twoim dokumencie XML jest element Signature ale nie ma go w schemie XSD". Czyli moze podpis nie w tym miejscu?
@rollon - właśnie to jest to co mówiłem do podpisu musisz mieć klucz PUBLICZNY i PRYWATNY w jednym cercie. Ten cert który ładujesz ma tylko klucz publiczny (zresztą z reguły tak jest) więc masz babola. Nawe po wczytaniu zdebaguj sobie zmienną x509 i luknij że masz null na PriveteKey a na PubliKey masz coś tam. Ja na razie sobie fejkuje jakimś certyfikatem który wygenerowałem najpierw z pliku crt + key do pfxa
return finishResult; } ta metoda performRESTRequest to mój twór - wyekstraktowałem sobie część wspólną z kilku tych restów. Nie wiem w czym dokładnie masz problem, ale to działa:
Ja olałem temat bo żeby wygenerować XMLa który PO spakowaniu ma 60MB to musi być naprawde opasły plik. U nas nie przewidujemy żeby nawet przed spakowaniem XMLe były większe niż kilkanaście MB. Bo mówimy tutaj tylko o JPK_VAT - pozostałe pliki są "na żądanie" w razie kontroli - a je juz się nie przesyła tylko mozna przekazać np. na pendrive z tego co wiem.
@xide odłożyłem temat na dwa dni żeby podgonić zległości jutro wracam. Nie mam 100% pewności że to wina MD5, ale na pewno mi krzyczy że schemat niezgodny z XDS i wskazuje na pole Hash. Niby za długie - jutro od rana bede to badał.
@Spokey miałem dokłądnie taki sam błąd jak podpisywałem biblioteką Micosoft.Xades. Ale jak przeszedłem na XadesNet to łyknął i teraz krzyczy mi o to że hashe mi sie nie
Wybór mam tak samo, z tym że biore z StoreLocation.LocalMachine ale to nie powinno mieć wpływu. Ja kompilowałem sam z XadesNet_v1.0.1-src.zip . Co prawda też sam lib jak wywołam: XadesHelper.Verify(outputPath).Perform(); to mi sypie błędem że podpis nieprwidłowy, ale bramka przyjmuje (na to wyglada) - mam status 140 teraz, no chyba że te hashe to są sprawdzane PRZED sprawdzaniem podpisu. Ale raczej nie bo wcześniej miałem status 120 na tamtym libie taki jak
@aksapon2 no na testowym to wogóle chyba to się zatrzymuje na statusie 120... Takie info jest na ich stronie. Mają podobno dac znać jak środowisko bedzie w pełni przetwarzało...
@Spokey Tutaj dllek nie moge załączać, ale wgrałem to na jakiś hosting: http://www.filedropper.com/xadesnetlib . Jest skompilowana w trybie debug póki co, ale u mnie niby podpisuje ibramka to łyka - spróbuj podmienić na tą dllkę i zobacz. Dzisiaj bede dalej walczył. z tymi Hashami.
@Spokey poprawiłem hashe i teraz już mi bramka testowa łyka to w 100% - co prawda przy czekaniu na UPO mam komunikat {"Code":120,"Description":"Sesja została poprawnie zakończona. Dane zostały poprawnie zapisane. Trwa weryfikacja dokumentu","Details":"","Timestamp":"2016-08-03T07:21:01.6579463+00:00","Upo":""} ale to potweirdza moją teorię że podpis jest ok. Tutaj Cie pocieszę bo sprawdzałem i ten mój podpis nie jest wogóle zgodny z tym co oni wygenerowali (np. nie mam tych przedrostków ds: oraz xades: ) ale mimo to
@Gibonowski mam nadzieje że ruszy bo na preprodukcji nie zdążyłem tego w pełni testnąć bo zacząłem kodzić 2 dni przed 29 lipca :) A z tego co widzę to op statusie 120 jest jeszcze cała masa innych potencjalnych błędów wiec zakładam że pewnie mam coś tam jeszcze nie tak (chociażby szyfrowanie zipa czy kodowanie klucza ich publicznym). Jest tak wogóle jakiś kontakt do nich? Nie wiem email czy telefon?
@Spokey takie coś? Ja ten cert sam soie robiłem z pliku CRT i KEY za pomocą poen ssl do pliku PFX a potem instalowałem w systemie. Wiec nie wiem - może to coś źle robie i mi na normalnym podpisie nie pojdzie? Nie mam jak teraz tego zweryfikować na prawdziwym podpisie. Tak czy inaczej - bramka testowa to łapie.
@Spokeyhttp://pastebin.com/m3RQiX6C . Czyli jak podejrzewałem - zbyt gładko poszło :) W takim razie musze dzisiaj gdzieś dorwać prawdziwy podpis elektroczniczny i zobaczymy co bedzie sie działo.
@Spokey - bede walczył dalej. Dziwne zatem że bramka mnie puszcza. Skoro aż tak jest to inne to powinien mi dawać info ze to nie jest podpis w formacie Xades lub że jest niezweryfikowany, a tak mialem wczesniej i przestało gdy przeszedłem na to. Stąd olałem temat - działa to działa - po co drążyć :)
@Spokey - podpiąłem się z jednym z naszych klientów - księgowym i zrobiłem realny test na realnym podpisie. Sprawdziłem nawet ten serial number - jest hexanumeryczny (jakieś krzaki typu 1a 4e 50 6e .....). I o dziwo podpisało, wysłało na bramkę testową i mam status 120 https://test-e-dokumenty.mf.gov.pl/api/Storage/Status/54e1616400e250cd000000b009fdacf4 ). Czyli dalej wyglada jakby działało? A ty wysyłasz na testową z parametrem: ?enableValidateQualifiedSignature=true ?? Bo ja bez niego - bo nie mam kwalifikowanego podpisu
Ja rano miałem 120 na kwalifikowanym podpisie. Przed chwilą puściłem na niekwalifikowanym i też mam 120. 100 to wyglada jakbyś wywołał samo initUploadSigned bez wysyłki blobów.
@Spokey - pytanie pomocnicze - czy Xadesy wygenerowane przez te programy zewnętrzne procertum, kir itd - są zgodne ze specyfikacją? Bo wiążąc to z moim przypadkiem gdzie nie pasuje niby podpis a przechodzi czy oni czasem niemają tak samo?
i jeszcze jeden trop. Gdzieś mi się o uszy obiło samo kodowanie pliku że ktoś tam UTF8 dał, bez BOMów itd. Może tym tropem idźcie. Chociaż jak podpisujesz samplowego to nie powinno to
@hipek dokładnie tego brakuje w specyfikacji interfejsu - czyli opisu kolejności w jaki to jest przetwarzane. Bo mam nieodparte wrażenie że większy numer błedu to wcale nie oznacza że zabrnęliśmy "dalej". To + brak supportu z ich strony - tworzy ten chaos który widać w tym wątku - takie partyzanckie kodowanie na czuja... Sam tez pisałem na tego ich maila supportowego ale oczywiście 0 odzewu...
@Cyganieszka oczywiście że nie masz gwarancji. Mało tego - naprawdopodobniej to się zmieni i zmieniać bedzie w ciągu całego roku bo podejrzewam że ten okres do końca roku - zanim wejdzie w obowiązek JPK większa ilość firm - to taki właśnie okres testowy. A teraz to bedzie jedna wielka inftrastrukturalno-developerska faza przejściowa (tylko domyślam się co dzieje się teraz po drugiej stronie bramki - w firmie billenium :) ). Podejrzewam że bedziemy
@MnieTuNieMaJuz: Ale masz blad 400 bad request - to sobie zajrzyj do JSONa w odpowiedzi na ta 400tkę co masz konkretnie za kod. (strona 20 dokumentacji). Sama 400tka to za mało info - tam pod tym siedzi z 15 różnych opcji co może być nie tak... Poza tym idea sklejania podpisu ręcznie z XMLem - to jest zła droga - w tym idea podpisu że nie można go sobie potem ręcznie
@spider07 cytując klasyka z misia "Nie ciesz nie ciesz i tak Ci wyłączą" :) Coś tam chłopaki w bramce pewnie jeszcze pogrzebią :) Ja na chwile wstrzymałem prace odkąd dali info że 22go bedzie appka kliencka od nich. Zobacze co sie bedzie działo 25go i wtedy dokończe ostatnie szlify...
#programowanie #sap #erp #jpk
1. Jak sobie testujecie to wysyłacie to na https://test-e-dokumenty.mf.gov.pl/api/Storage/ czy na https://e-dokumenty.mf.gov.pl/api/Storage/ ? W zależności od tego na które wysyłam - mam
@ggiewon tak to zrobiłem:
Pobrałem xadesnet, potem skompilowałem projekt XadesnetLib i dodałem dllkę do referencji u siebie. A potem to już prosto:
void SignXmlFileNew2(string FileName, string SignedFileName, X509Certificate2 x509)
{
var outputPath = SignedFileName;
var selectedCertificate = x509;
var inputPath = FileName;
var howToSign =
XadesHelper.Sign(inputPath).Using(selectedCertificate).
IncludingCertificateInSignature();
howToSign.SignToFile(outputPath);
//XadesHelper.Verify(outputPath).Perform();
sama metoda do finisza:
private string finishUpload(string destinationUrl)
{
var finishJson = "{ \"ReferenceNumber\": \"" + transactionInfo.InitReferenceNumber + "\", \"AzureBlobNameList\": [ \"" + transactionInfo.InitBlobName + "\" ]}";
byte[] bytes;
bytes = System.Text.Encoding.ASCII.GetBytes(finishJson);
string finishResult = performRESTRequest(destinationUrl, "POST", "application/json; encoding='utf-8'", bytes);
transactionInfo.Log += finishResult;
return finishResult;
}
ta metoda performRESTRequest to mój twór - wyekstraktowałem sobie część wspólną z kilku tych restów. Nie wiem w czym dokładnie masz problem, ale to działa:
@Spokey miałem dokłądnie taki sam błąd jak podpisywałem biblioteką Micosoft.Xades. Ale jak przeszedłem na XadesNet to łyknął i teraz krzyczy mi o to że hashe mi sie nie
@durek89 u mnie śmiga - przed chwila nawet wysyłałem na testa.
void SignXmlFile(string FileName, string SignedFileName, X509Certificate2 x509)
{
var outputPath = SignedFileName;
var selectedCertificate = x509;
var inputPath = FileName;
var howToSign =
XadesHelper.Sign(inputPath).Using(selectedCertificate).
IncludingCertificateInSignature();
howToSign.SignToFile(outputPath);
//XadesHelper.Verify(outputPath).Perform();
}
i jeszcze jeden trop. Gdzieś mi się o uszy obiło samo kodowanie pliku że ktoś tam UTF8 dał, bez BOMów itd. Może tym tropem idźcie. Chociaż jak podpisujesz samplowego to nie powinno to