Autor Wątek: Realizacja kilku ZK do jednego LP i problematyczny separator numerów dokumentów  (Przeczytany 6838 razy)

kidl

  • Full Member
  • ***
  • Wiadomości: 107
W sytuacji gdy realizujemy kilka dokumentów, np 2 dokumenty ZK dla jednego klienta i wysyłamy to na jednym LP, to ProstaPaczka wrzuca w pole Opis dwa numery oddzielone średnikiem ";". Okazało się, że zastosowanie tego separatora może stanowić kłopot w szczególnych przypadkach.
Jeśli mamy do zamówień pobranie, to do opisu przesyłki dostajemy np "ZK 6797/12/2020;ZK 6798/12/2020". Mieliśmy tak dla kuriera GLS. Dostaliśmy od nich później plik csv z zestawieniem zwracanych pobrań. Program do rozliczania wpłaty, po zaczytaniu pliku csv, podzielił dane po separatorze, który stosuje GLS, czyli po średniku. Niestety powoduje to przestawienie kolumn i w polu Opis mamy "ZK 6797/12/2020" a polu Data mamy "ZK 6798/12/2020"

Nie sprawdzałem pozostałych firm kurierskich, jednak zapewne w ProstejPaczce wszędzie zastosowany został ten sam separator. Tzn, że w każdej firmie kurierskiej wysyłającej pliki csv gdzie stosowany jest średnik, będą pojawiały się problemy z przestawieniem kolumn.

Panie Piotrze, jest możliwość, żeby zamienić na inny separator? Może przecinek?

Piotr

  • Administrator
  • Hero Member
  • *****
  • Wiadomości: 1763
Faktycznie łączymy numery wykorzystując średnik jako separator..
Część firm kurierskich dostarcza raporty w XLS lub XLSX, które powinny być odporne na tego typu problemy.

W przypadku generowania plików CSV jak w treści pola pojawia się separator kolumn to należy taką wartość umieścić w cudzysłowu:

field1_value,field2_value,"field 3,value",field4, etc...

Wtedy program wczytujący plik CSV powinien taką wartość rozpoznać i nie traktować tej wartości jako oddzielnych kolumn tylko całą wartość.

Jak to wygląda w pliku generowanym przez GLS?

kidl

  • Full Member
  • ***
  • Wiadomości: 107
W przypadku generowania plików CSV jak w treści pola pojawia się separator kolumn to należy taką wartość umieścić w cudzysłowu:

field1_value,field2_value,"field 3,value",field4, etc...

Wtedy program wczytujący plik CSV powinien taką wartość rozpoznać i nie traktować tej wartości jako oddzielnych kolumn tylko całą wartość.

Oczywiście można sobie z tym poradzić, choćby poprzez zmianę ręcznie średnika na przecinek, kłopot w tym że rozliczaniem plików zajmują się księgowe, które w kwestiach technicznych miewają problemy. Dochodzi dodatkowa praca. Trzeba sprawdzać każdy plik lub gdy program wyrzuci błąd z niewłaściwa strukturą pliku, wtedy szukać gdzie jest problem.
Pliki zaczytujemy przez emSzmal. Struktury plików przygotowali pod firmy kurierskie i nie mam jak zmienić ustawienia, żeby uwzględniało taką sytuację.
Błąd wyrzucany przez emSzmal nie określa w czym dokładnie jest problem, więc mając zestawienie z 50 pobraniami dochodzi chwila na zmianę danych i ponowne zaczytanie pliku.


Jak to wygląda w pliku generowanym przez GLS?
Otwierany w Excelu od razu rozdziela te dane na osobne komórki. Otwierany w notatniku to ciąg danych gdzie nie sądzę, żeby księgowa poradziła sobie bez mojej pomocy.


Generalnie sytuacji takich nie ma dużo, jednak jest to coś, co dołoży mi pracy zamiast księgowej.

Piotr

  • Administrator
  • Hero Member
  • *****
  • Wiadomości: 1763
Skoro  Excel sobie z tym radzi, to mogłoby oznaczać że w pliku generowanym przez GLS jest poprawnie zapisane (z cudzysłowem).

Nie miałem na myśli ręcznego modyfikowania pliku, bo to może wiązać się z innymi problemami.
Jeżeli plik GLS nie jest poprawny i nie obejmuje takiej kolumny cudzysłowem to należałoby do nich się zwrócić aby generowali poprawne pliki.

Jeżeli pliki te są przygotowane prawidłowo a nie da się ich zaimportować w innym systemie to należałoby się zwrócić do producenta tego systemu aby poprawić importowanie takich danych.

Po naszej stronie nie jest to zmiana jednego znaku, którą można przeprowadzić w 5 minut i wolelibyśmy uniknąć takich zmian jeżeli uda się je wykonać w innym miejscu. Tym bardziej jeżeli chodzi o poprawne generowanie / wczytywanie pliku CSV


kidl

  • Full Member
  • ***
  • Wiadomości: 107
Skoro  Excel sobie z tym radzi, to mogłoby oznaczać że w pliku generowanym przez GLS jest poprawnie zapisane (z cudzysłowem).
Excel radzi sobie rozdzielając oba nr ZK w osobne komórki. Niestety w pliku cudzysłów nie został użyty. Zapis wygląda jak poniżej:
"*25685815168;6168144994;2020-12-01;-233,00;25001817;ZK 4663/11/2020          ;2020-11-30;"

Teraz też zauważyłem, że w opisie paczki gdzie wrzucony jest nr ZK są tez puste miejsca (spacje).

Wyślę do GLS wiadomość jednak nie wierzę żeby szybko zareagowali, jeśli w ogóle. Na szczęście takich sytuacji nie ma dużo: 2-3 w miesiącu. Zaczekam i zobaczę co GLS odpisze.

Piotr

  • Administrator
  • Hero Member
  • *****
  • Wiadomości: 1763
W przykładzie jest jedno ZK. Teoretycznie jak w danej kolumnie nie ma znaku specjalnego/separatora to nie trzeba wstawiać dodatkowego cudzysłowia, dopiero jak się taki znak pojawia to powinno się taką kolumnę zapisać inaczej
np:
*abc;"ZK 1/2020;ZK 2/2020";abc

Lepiej byłoby poszukać przykładu z dwoma ZK, abo zapytać producenta programu w którym plik jest importowany.
Skoro do tego służy narzędzie to mogą mieć rozwiązanie "od ręki".

kidl

  • Full Member
  • ***
  • Wiadomości: 107
Posłużyłem się losowym przykładem dla zobrazowania zapisu jaki jest w pliku. W przypadku podwójnego ZK zapis wygląd jak poniżej (skopiowany z pliku z pominięciem danych klienta):

*25685815206;6168144994;2020-12-04;-300,00;25001817;ZK 6797/12/2020          ;2020-12-03;

Rozmawiałem z "serwisantem", który uruchamiał program. Jego odpowiedź: "nie miałem takiej sytuacji"   :)

Piotr

  • Administrator
  • Hero Member
  • *****
  • Wiadomości: 1763
W tym przykładzie też jest jedno ZK :)
*;ZK 6797/12/2020          ;*



kidl

  • Full Member
  • ***
  • Wiadomości: 107
W tym przykładzie też jest jedno ZK :)
*;ZK 6797/12/2020          ;*
Tak się dzieje, gdy wrzucam coś bez czytania zawartości. Wiedziałem że chodzi o ZK 6797/12/2020, więc wyszukałem w pliku tą wartość i skopiowałem co było. Teraz się okazuje, że wysłaliśmy w tym dniu 4 paczki do tego samego ZK, wszystkie były z COD, ale tylko ostatnia ma zapis o dwóch nr ZK. Skopiowałem złą pozycję:


*25879679159;6168144994;2020-12-04;-300,00;25001817;ZK 6797/12/2020;ZK 6798/1;2020-12-03;

Mam nadzieję, że już ostatni raz wklejam zapis z pliku CSV  ::) ;D

Piotr

  • Administrator
  • Hero Member
  • *****
  • Wiadomości: 1763
No to w tym przykładzie widać jasno że GLS generując plik nie oznaczył kolumny cudzysłowem i program importujący dane może mieć problem z odczytem.

Też ze swojej strony wyślemy do nich zapytanie, czy planują coś z tym zrobić.