On Thu, 19 Aug 2021 10:14:36 +0200, Adam wrote:
> Dnia Wed, 18 Aug 2021 18:45:41 +0200, J.F napisał(a):
>> On Wed, 18 Aug 2021 14:54:51 +0200, Adam wrote:
>>> Dnia Wed, 18 Aug 2021 14:10:05 +0200, J.F napisał(a):
>>>> On Wed, 18 Aug 2021 10:56:15 +0200, Adam wrote:
>>>>>> [...]
>>>> Ale XML to ani EDIFACT, ani VDA, ani X12, i pewnie jeszcze troche tych
>>>> "ani".
>>>
>>> Trudno mi tu dyskutować.
>>> W tych programach, z których mam pliki, to wszyskie są zapisywane w
>>> strukturze XML.
>>> Mam klientów, którzy ze swoimi dostawcmi wymieniają się plikami EDI i
>>
>> Same XML ?
>
> Wygląda na to, że tak.
> Widocznie ktoś swego czasu stwierdził, że strukturę plików (czyli
> komunikaty EDI) lepiej jest osadzi w formacie XML aniżeli w formacie TXT.

U nas byla pare lat temu seria dofinansowan na wdrozenia EDI,
to krajowe firmy mogly rozwinac fantazje.
Ale to co podawales wyglada na jakis zachodni standard.

>>>> Taki SAP potrafi wyprodukowac XML ?
>>> SAP to jest inny gatunek człowieka ;)
>> Ale popularny ... w pewnych sferach.
> Niestety.
> To jest dobre, dopóki nie natrafi się na coś mniej typowego.

Bo to SAP wyznacza standardy :-P

>>> Swego czasu, przy wymianie komputerów u jednego z moich klientów (na SAPie)
>>> okazało się, że nowe kompy nie mają fizycznego RS232.
>>> Drukarki fiskalne zapinały się przez USB emulujący COMy. Ale to nie był
>>> problem, wszak można wpisać (prawie) dowolny numer portu.
>>> Problem zaczął się, gdy z pewnych przyczyn trzeba było drukarkę puścić po
>>> innym numerze, niź COM1. Angole się zdziwili: po co? Przecież od zawsze
>>> było na COM1.
>>> Przerobienie SAPA na COM3 zajęło im miesiąc czasu. Tak, miesiąc.
>>
>> Jak na korporacje ... szybko poszlo.
>> Tylko na ile sie orientuje, to sam SAP potrafi byc szybki, tu chyba
>> zawalili owi "Angole" z firmy matki.
>> SAP pewnie w ogole dopuszczal rozne porty, tylko ktos musial doczytac
>> dokumentaje.
>
> Nie tylko SAP jest zdziwiony portami.
> Gdzieś tak w połowie lat 90-tych musiałem tlumaczyć programistom z jednej z
> ówczesnych największych firm produkujących oprogramiwanie w Polsce, co to
> jest 9600,n,8,1,p. Też chodziło o drukarki fiskalne.

No ale przeciez te drukarki ktos produkowal, i one zapewne byly
laczone z SAP znacznie wczesniej, niz miales ten problem :-)

>>> Natomiast nie wiem, jak tam jest z EDI. Może niebawem będę, to z ciekawości
>>> popytam i może wezmę próbkę plików, o ile już zdążyli dojść do obsługi XML
>>> - wszak to się pojawiło (dla Angoli) całkiem niedawno, dopiero dwadzieścia
>>> lat temu ;)
>>
>> Przede wszystkim to po co jakies XML, skoro sa do tego odpowiednie
>> formaty, opisane w standardach, itp.
>
> Co innego struktura (czyli np. EDI), a co innego format (XML, DBF, CSV
> itd).
> Nie wiem, nie wnikałem. Wszyscy znani mi posługują się formatem XML.

Bo siedzisz w polskim zascianku

https://en.wikipedia.org/wiki/Electronic_data_interc
hange#See_also

Zobacz ile tam standardow. XML tez tam jest ... w 8 wersjach.

A Ty mowisz, ze EDi rozwiazuje sprawe importu faktur :-)

>>>>> czyli może zawierać nadmiarowe dane. Parser czyta tylko to, co potrzebuje.
>>>>> Przykładowo mamy takie coś:
>>>>> <Document-Invoice>
>>>>> <Invoice-Header>
>>>>> <InvoiceNumber>EFV/0977/21</InvoiceNumber>
>>>>> <InvoiceDate>2021-01-29</InvoiceDate>
>>>>> <SalesDate>2021-01-29</SalesDate>
>>>>> <InvoiceCurrency>PLN</InvoiceCurrency>
>>>>> <InvoicePaymentDueDate>2021-02-28</InvoicePaymentDue
Date>
[...]
>>>>> Parser weźmie nazwy, daty, numery, natomiast ominie kolor samochody i
>>>>> samochód bossa.
>>>>
>>>> I to jest kolejny poziom.
>>>> Jedni moga ominac, a dla innych to sa wazne pola i nie mozna ich
>>>> ominac.
>>>> Tzn kontrahent uwaza, ze wazne, a twoj program do tej pory omijal, bo
>>>> niewazne.
>>>
>>> Nie, nie o to chodzi.
>>> Struktora XML polega na tym, że parser szuka i połyka to, co ma zadane,
>>> ignorując resztę.
>>> Czyli w uproszczeniu nie ma znaczenia kolejność pól i gałęzi, swoje pole w
>>> odpowiedniej gałęzi parser znajdzie i odczyta.
>>
>> A mnie o to chodzi, ze tu nadal moga wyjsc niezgodnosci.
>> Jakies pole jednej firmie wydaje sie niepotrzebne i go nie ma,
>> a w drugiej firmie jest bardzo wazne.
>
> Ale to już dotyczy pól niewymagalnych albo dodatkowych.

Dla Ciebie dodatkowych, dla firmy byc moze kluczowych :-)

> Pola wymagalne są wypełniane - np. NIP, daty, kwoty.
> Bez Jeśli pole wymagalne jest puste (zdarza się), to najczęściej jest
> zgłaszany błąd.

A rabat - wymagany, dodatkowy ? :-)

>> Albo glupia nazwa firmy - jedno pole, czy dzielone na kilka linii,
>> bo niektorzy to maja naprawde dlugie nazwy :-)
>
> W Optimie wygląda to tak, że przy imporcie przez EDI karta kontrahenta musi
> być wcześniej założona. Dane kontrahenta są pobierane z GUS albo VIES.
> Tak więc takie dane, jak przypadkowo są sformatowane (albo i nie) w tych
> bazach, w taki sposób trafiają do Optimy.

Jest to jakies ujednolicenie, ale jesli kontrahent z dalszego kraju ?

> Nie chce mi się teraz sprawdzać w CDN-XL ani Enovie.
> Natomiast w pliku EDI linie z nazwą kontrahenta są sklejane:

To w XML, a sa inne formaty jak widac :-)
Gdzie potrafi byc limit dlugosci na pole :-)

>>>>>>> Jakie sysyemy by nie były, bez względu, czy to jakieś małe, czy większe ERP
>>>>>>> (typu Optima, Enova, Comarch XL), czy też najbardziej znane (SAP) gadają ze
>>>>>>> sobą bez problemu.
>>>>>>
>>>>>> Na ile sie orientuje - to wlasnie sa problemy.
>>>>>> I z nich zyja swietnie firmy posredniczace w wymianie.
>>>>>> Co zreszta widac po ilosci standardow.
>>>>>
>>>>> EDI "handlowy" jest OIMW jeden, z modyfikacjami polegającymi na dodatkowych
>>>>> polach, które mogą być ignorowane przez parser.
>>>>
>>>> Co masz na mysli pod "handlowy"?
>>>> W EDIFACT jest INVOIC, jest VDA4906, itp.
>>>
>>> EDI jest zaszyty przez producentów oprogramowania na stałe, nigdy się nie
>>> interesowałem tym głębiej w takim aspekcie, jak piszesz.
>>
>> Ale dopisz - przez kilku znanych mi polskich (?) producentow.
>
> Nie tylko polskich, bo bywają transakcje wewnątrzunijne.

No to masz szczecie, ze kontrahenci nie uzywaja tych innych formatow
:-)

>>>>> Ja nie zajmuję się całokształtem dystrybucji ze wszelkimi jej odmianami,
>>>>> więc też nie stykam się bezpośrednio z różnymi zagadnieniami, jak np.
>>>>> systemy WMS, zaawansowane systemy produkcji itp.
>>>>> Czasem piszę coś dla klientów, jak np. kilka lat temu program do obsługi
>>>>> mobilnych terminali magazynowych (kolektor danych). Kolektor skanuje kod
>>>>> GS1, wyciąga z niego kod towaru i numer seryjny i to pompuje do Comarch XL.
>>>>> Czyli mamy dostawę bądź wydanie konkretnych towarów, identyfikowanych po
>>>>> numerze seryjnym.
>>>>
>>>> A tu jedna firma w ogole nie uzywa numerow seryjnych, a inna musi
>>>> uzywac ...
>>>>
>>> Takie dodatki to pisze się najczęściej pod konkretnego klienta.
>>> W tym przypadku to hurtownia sprzętu komputerowego. Przed zapaletowaniem
>>> wysyłki są skanowane towary i wysyłane do dokumentu WZ. Analogicznie na
>>> jednej z bram towary przychodzące.
>>
>> I byloby pieknie, tylko hurtownia ma pewnie dostawy z wielu zrodel,
>> jedne maja nr seryjne, inne nie ... jeszcze inne na cale partie/pudla.
>>
>> A zalozmy, ze hurtownia wysyla to do sklepu, gdzies tam sobie w WZ
>> zapisala te nr seryjne, sklep chetnie przejmie, ale niestety - co
>> hurtownia, to jakos inaczej zamieszczone.
>>
>> Choc moze racja, ze to lepiej nie przejmowac, tylko zeskanowac ...
>> ale moze jedno i drugie - i zglosic rozbieznosci ...
>>
> Oj, to nie jest hurtownia typu "Józek i Zośka w garażu".
> To hurtownia dystrybucujna, biorąca towar wprost od kilku tylko producentów

ale od kilku.

> i rozprowadzająca dalej dystrybutorom, hurtowniom i większym odbiorcom,
> którzy mają podpisaną umowę. Zwykły sklep u nich nie kupi.
> Wszystkie towary są okodowane w GS1.

A ci klienci maja swoje systemy :-)

J