Skocz do zawartości

ZUA/ZZA do KEDU

Polecane posty

Ten problem leży chyba bardziej po stronie e-Płatnika, ale zgłoszę go tutaj, bo myślę, że jest szansa go w prosty sposób wyeliminować. Otóż e-Płatnik przy importowaniu pliku XML ze zgłoszeniem pracownika do ubezpieczeń (zarówno ZUA jak i ZZA) zawsze wywala błąd weryfikacji przy obywatelstwie pracownika. Nie wiem z czym konkretnie e-Płatnik ma kłopot, bo to co wychodzi z Gratyfikanta jest poprawne:

<IV>
      <p1>Wojciech</p1>
      <p3>polskie</p3>
      <p4>M</p4>
 </IV>

ale zawsze zaznacza na czerwono to POLSKIE, trzeba wejść w edycję, zmienić "POLSKIE" na "POLSKIE ", potem "POLSKIE " z powrotem na "POLSKIE" i już e-Płatnik jest zadowolony, ale trwa to długo bo e-Płatnik muli i długo myśli, przy zgłoszeniu kilkunastu osób robota głupiego ?

tymczasem pole p3 nie jest obowiązkowe, jeśli zostanie pominięte to ZUS domyślnie przyjmie obywatelstwo jako polskie

dlatego od jakiegoś czasu po prostu w Notatniku wywalam to <p3>polskie</p3> z plików KEDU i wtedy jest cud miód i malina

Może przy jakiejś okazji albo wykryjecie co powoduje ten błąd e-Płatnika, albo poprawicie eksport do pliku wymiany płatnika, tak żeby <p3> generować tylko kiedy obywatelstwo jest niepolskie?

 

Link to postu

No cóż. Do e-Płatnika nigdy nie udostępniono dokumentacji. Zresztą nawet gdyby ją udostępniono w postaci schemy do XMLa to to jest za mało. Schema, której używamy przy tworzeniu plików do Płatnika jest bardzo mało restrykcyjna, a większość weryfikacji odbywa się dopiero w programie. A do tego żadnej dokumentacji nie ma.

W świetle tego, że deklarujemy zgodność Gratyfikanta nexo z Płatnikiem (a z e-Płatnikiem nogdy takiej zgodności nie deklarowaliśmy - właśnie ze względu na brak dokumentacji), trudno byłoby nam podjąć takie ryzyko, że jednak w jakichś przypadkach zwykły Płatnik nie zacząłby komunikować problemów.

Czy dobrze zrozumiałem, że zmiana jednego słowa na takie samo słowo (w dodatku dwa razy) przynosi efekt???

Link to postu

Tak, oczywiście, obecny problem jest wyłącznie po stronie e-Płatnika, zdaję sobie z tego sprawę. Z jakiegoś powodu przy imporcie pliku KEDU uznaje wartość <p3>polskie</p3>  za nieprawidłową. Może chodzi o wielkość znaków, może o jakieś kodowanie, a może to zwykły błąd w programie (najprawdopodobniej). W każdym razie przy weryfikacji deklaracji zgłasza to jaką błąd, jakakolwiek ręczna ingerencja w tę wartość (np. skasowanie wartości i wpisanie POLSKIE od nowa, albo dodanie jakiegokolwiek znaku i skasowanie go po chwili - tak żeby program widział zmianę i zapisał POLSKIE ponownie) już wystarcza, bo przecież to jest prawidłowa wartość tego pola.

W dokumentacji do zwykłego Płatnika pole <p3> jest obowiązkowe tylko wtedy, gdy wartość ta jest inna niż "polskie". Więc podejrzewam, że nie byłoby problemu z utratą kompatybilności gdyby Gratyfikant nie eksportował tego do XML. Oczywiście być może jestem już ostatnią osobą na świecie, która używa e-Płatnika ?

Link to postu

W dokumentacji we-wy do Płatnika jest tak jak Pan pisze, ale jak już wspomniałem zasady opisane w tej dokumentacji są bardzo mało restrykcyjne. Większość kontroli biznesowych jest zaszyta wewnątrz programu, a do tego nie mamy dokumentacji. Nie odważymy się na eksperymentowanie na żywym, od lat działającym, organizmie w celu "łatania" cudzych błędów.

Nie widzę także eleganckiego rozwiązania jak byśmy mogli pomóc.

Link to postu

Rozumiem brak chęci naprawiania czegoś, co nie jest Waszą winą. Natomiast możliwych rozwiązań jest wiele, można w konfiguracji programu dodać możliwość ustawiania czy ma się zawsze eksportować parametr <p3> czy tylko dla wartości innej niż "polskie" (oba rozwiązania zgodne z dokumentacją Płatnika!), albo można zrobić jedną opcję "Ctrl-G generuj plik wymiany do płatnika" a drugą "generuj plik wymiany do e-płatnika"  - i pewnie jeszcze kilkanaście innych rozwiązań, ograniczonych wyłącznie wyobraźnią. Z pokorą przyjmuję jednak informację, że jestem jedynym klientem, który zgłaszał ten problem, więc priorytet mojej prośby jest zerowy.

Link to postu

Nie chodzi o niechęć do naprawiania czegoś co nie jest naszą winą tylko obawę, że popsujemy coś co działa wielu użytkownikom. Czemu miało by się coś popsuć opisałem wyżej.

Dodawanie parametru :generuj plik do e-Płatnika" nie wchodzi w rachubę - przy braku dokumentacji nie możemy brać odpowiedzialności za działanie eksportu do e-Płatnika.

Dodanie parametru "nie eksportuj <p3>" będzie zupełnie niezrozumiałe dla 99% użytkowników.

Pomyślimy jeszcze.

Link to postu
×
×
  • Dodaj nową pozycję...