ProstaPaczka2
ProstaPaczka2 => Subiekt GT => Wątek zaczęty przez: kidl w Grudzień 15, 2020, 11:06:54 am
-
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?
-
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?
-
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.
-
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
-
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.
-
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".
-
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" :)
-
W tym przykładzie też jest jedno ZK :)
*;ZK 6797/12/2020 ;*
-
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
-
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ć.