Wpis z mikrobloga

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
  • 665
  • Odpowiedz
Domyślam się, że jeśli od rana na produkcyjnym mam status 120, to xml jest poprawnie spakowany jako zip i nie będzie już statusu 410 ? Pytam bo przed weekendem miałem 410, poprawiłem algorytm i teraz nie wiem czy to, że ciągle jest 120 to wyklucza już 410 :D
  • Odpowiedz
@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...
  • Odpowiedz
@yarpi87: Wysłałem służbowego maila na jpk serwis z prośbą o wyjaśnienie, dlaczego pliki podpisane przez nas oficjalnymi narzędziami nie wchodzą na bramkę MF. Dostaliśmy zwrotkę od billennium, że oni to wrzucają do proCertum i nie waliduje się jakaś część. Na co ja dałem im do zrozumienia, że my każdy podpisany plik przed wysłaniem i tak weryfikujemy w trzech różnych narzędziach i jednym z nich jest właśnie proCertum ( dodałem screena ), na co dostaliśmy odpowiedź, że InitUpload jest zły i całą stronę instrukcji jak można xml walidować względem xsd - jak do głupiego. Więc się #!$%@?łem i napisałem do billennium i jpk + dw moich przełożonych, że my wiemy gdzie dokładnie jest problem i nie leży on w pliku InitUpload, więc czy mogli by zacząć rozwiązywać nasze problemy, a nie jakieś wyssane z palca. Na co dostaliśmy zwrotkę - cytat:

"Plik JPKTestFileInitUpload.xml jest zgodny ze schemą XSD dostępną na stronie Ministerstwa Finansów. Problem z plikiem pojawia się po podpisaniu go. Pańskie zgłoszenie zostało przekazane do zespołu developerskiego. Numer zgłoszenia XXX-XX."

A potem:

"Z informacji uzyskanych z zespołu developerskiego, problem leżał po stronie infrastruktury. Na środowisku testowym Państwa plik powinien być
  • Odpowiedz
Przychodzi mi na myśl tylko jeden cytat z filmu "Nic śmiesznego" - "...i tak k..wa do za.....nia".
Pozdrawiam wszystkich. ;)
  • Odpowiedz
W sumie z przypadku tą aplikację piszę i sporo problemów ogarniałam po raz pierwszy, ale mam wrażenie, że dla ministerstwa jeszcze mniej kompetentni ludzie to piszą...
Teraz niby wszytsko mi działa, ale jaką mam gwarancję że zaraz jakiejś pierdoły nie zmienią i przestanie?
  • Odpowiedz
@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
  • Odpowiedz
Walcze z tym od marca, od kiedy opublikowali specyfikację, kilka razy z sukcesem, zakonczonym pobraniem UPO ( na testowej i preprodukcyjnej), ale po każdym sukcesie następowała zmiana specyfikacji i ten sam plik wysłany taką samą metodą rano miał status 200 a wysłany po południu już nie przechodził.
  • Odpowiedz
Bardzo proszę kogoś, komu udało się przesłać 2 pliki .xml w jednej sesji o udostępnienie pliku metadanych .xml do żądania InitUpload.
  • Odpowiedz
Wczoraj rano około 9 wysyłałem plik na produkcyjne środowisko. Cały czas otrzymuję kod 120. Jak u was sprawa wygląda, macie podobny problem?
  • Odpowiedz
witam wszystkich.
Czy ktos jeszcze działa z JPK w c++ z uzyciem biblotek Wincrypt (standardowej krypografii wbudowanej w Windows)?
  • Odpowiedz
Znowu zwraca bląd 410. Nie mam pojęcia co jest nie tak.
Moja metoda kompresji wyglada tak:

byte[] buffer = new byte[2048];
FileOutputStream fos = new FileOutputStream(zipFileName);
ZipOutputStream zos = new ZipOutputStream(fos);
  • Odpowiedz