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:
>>>> Dnia Tue, 17 Aug 2021 14:26:53 +0200, J.F napisał(a):
>>>>> On Mon, 16 Aug 2021 09:03:40 +0200, Adam wrote:
>>>>> [...]
>>>>> Zobacz np
>>>>> https://en.wikipedia.org/wiki/EDIFACT
>>>>> https://www.edi-plus.com/resources/message-formats/v
da/
>>>>> https://www.edidev.net/edidev-ca/help/Sample_Files/S
ampleX12EdiFiles.htm
>>>>>
>>>>> Golym okiem widac roznice, a przeciez to tylko poczatek.
>>>>>
>>>>> A przeciez to nie wszystkie formaty
>>>>> https://en.wikipedia.org/wiki/Electronic_data_interc
hange
>>>>
>>>> W handlu używa się formatów dla handlu, np. invoice.
>>>> Format pliku to XML, którego zaletą jest to, że jest on "elastyczny" -
>>>
>>> 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.

>
>> sporadycznie się zdarza, aby coś nie wskoczyło. Bywa, że swoim odbiorcom
>> też wysyłają EDI. Moi klienci to głównie Optima, a inne firmy miewają
>> najprzeróżniejsze programy.
>>
>>> 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.

>
>> 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.

>
>> 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.

Nawet inne dane, które były w najprzeróżniejszych formatach (czyli rejestry
VAT, dokumenty handlowe czy magazynowe, dane z RCP, dane do modułów
płacowych, rozliczenia itd) są migrowane z różnych formatów czy to
binarnych, czy dbf/txt/csv do XML.
Że nie wspomnę o JPK ;)

>
>>>> 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>
>>>> <InvoicePaymentTerms>30</InvoicePaymentTerms>
>>>> <DocumentFunctionCode>O</DocumentFunctionCode>
>>>> <Remarks/>
>>>> <Delivery>
>>>> <DeliveryLocationNumber>5909000000030</DeliveryLocat
ionNumber>
>>>> <DeliveryDate>2021-01-29</DeliveryDate>
>>>> <DespatchNumber>1507</DespatchNumber>
>>>> <DespatchDate>2021-01-27</DespatchDate>
>>>> <Name>JAKAŚ TAM FIRMA</Name>
>>>> <StreetAndNumber>ul. Nowa 22</StreetAndNumber>
>>>> <CityName>Warszawa</CityName>
>>>> <PostalCode>01-234</PostalCode>
>>>> <Country>PL</Country>
>>>> </Delivery>
>>>> </Invoice-Header>
>>>> <Invoice-Parties>
>>>> <Buyer>
>>>> <ILN>5909000800000</ILN>
>>>> <TaxID>5270207000</TaxID>
>>>> <AccountNumber/>
>>>> <Name>NAZWA FIRMY</Name>
>>>> <StreetAndNumber>Znów jakaś ulica</StreetAndNumber>
>>>> <CityName>WARSZAWA</CityName>
>>>> <PostalCode>01-567</PostalCode>
>>>> <SamochodBossaFirmy>Bentley</SamochodBossaFirmy>
>>>> <KolorSamochodu>Przezroczysty</KolorSamochodu>
>>>> <Country>PL</Country>
>>>> </Buyer>
>>>>
>>>> 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.
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.

>
> 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.
Nie chce mi się teraz sprawdzać w CDN-XL ani Enovie.

Natomiast w pliku EDI linie z nazwą kontrahenta są sklejane:

<Seller>
<ILN>8015555555555</ILN>
<TaxID>222-22-22-222</TaxID>
<AccountNumber/>
<CodeByBuyer/>
<Name>Grzegorz Brzęczyszczykiewicz Spółka Jawna i Ukryta oraz Komandytowa
Pod Zarządem Tajnym i Nielegalnym Prowadzonym z Domy Wypoczynkowego "Pod
Stalowymi Kratkami" we Wronkach </Name>
<StreetAndNumber>Chrząszczyżewoszyce 13A/7</StreetAndNumber>
<CityName>Wąwodółka Żuławska</CityName>
<PostalCode>13-913</PostalCode>
<Country>PL</Country>
<UtilizationRegisterNumber/>
<CourtAndCapitalInformation/>
</Seller>

Ja wpisałem do programu następująco:

Grzegorz Brzęczyszczykiewicz
Spółka Jawna i Ukryta oraz Komandytowa
Pod Zarządem Tajnym i Nielegalnym
Prowadzonym z Domy Wypoczynkowego
"Pod Stalowymi Kratkami" we Wronkach

>
>>>>>> 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.

>
>> Jestem leniem ;) więc wystarczy mi, że to działa.
>> Już trochę za stary jestem na doktoryzowanie się z rzeczy "niepotrzebnych"
>> ;)
>> Interesuje mnie to tylko o tyle, że np. czasem ktoś chce zaczytać dodatkowe
>> informacje z pliku, jak np. numer świadectwa, zdolność kiełkowania, numer
>> zezwolenia itd.
>> Wtedy jest dopisywana dodatkowa obsługa takiego pliku.
>
> I IMO zaczynaja sie kolejne problemy - np jedna faktura obejmuje kilka
> WZ, kazda WZ ma liste swiadectw itp ...

Dokument wprowadza się tak, jak przyszedł dokument od dostawcy, czyli jeśli
od dostawcy przyszedł jego WZ, to wprowadza się jako PZ, a później jedną
lub wiele PZ przekształca się do jednej faktury FZ.
Natomiast jak od dostawcy przychodzi faktura (u niego też może być
"sklejona" z wielu WZ), to wprowadza się jako fakturę zakupu.

Ale takich problemów raczej nie ma, wszystko staram się ustalić i
doprecyzować przed zrobieniem dodatku pod konkretne potrzeby.

>
>>>>>>>> Natomiast większość (jak nie wszystkie) znane mi systemy do obsługi firm w
>>>>>>>> zakresie tzw. "GM" (gospodarki materiałowej, czyli Handel, Sprzedaż itd)
>>>>>>>> obsługuje EDI, a mniejsze firmy przesyłają sobie pliki bezpośrednio mailem
>>>>>>>> albo ftp/sftp nie ponosząc kosztów EDI Connector czy innych tego typu
>>>>>>>> rozwiązań.
>>>>>>>
>>>>>>> Ale to niekoniecznie sie nadaje do automatycznego ksiegowania.
>>>>>>>
>>>>>> Nie wiem, czy nie mylisz pojęć.
>>>>>> Księgowanie najczęściej idzie z programu/modułu handlowego do programu bądź
>>>>>> modułu księgowego.
>>>>>> Natomiast dokument EDI może zawierać większość informacji potrzebnych do
>>>>>> zaksięgowania, ale to w programie handlowym ustawia się, co ma się dziać i
>>>>>> w jaki sposób z poszczególnymi pozycjami faktury oraz jak ją rozliczać w
>>>>>> aspekcie modułu kasa/bank i ewentualnie w powiązaniu z kursami walut.
>>>>>
>>>>> Comarch np
>>>>> https://www.comarchedi.pl/rozwiazania-edi/
>>>>>
>>>>> wspiera faktury w formacie pdf. Dostajesz taka fakture ... i co dalej?
>>>>
>>>> W formacie PDF do Comarch OCR.
>>>
>>> Hm, po co OCR z PDF ... no ale wyciagnie rozne teksty z faktury ... i
>>> dobrze zakwalifikuje co gdzie jest ?
>>
>> Już pisałem wcześniej w tym wątku - OCR aktualnie jest do faktur kosztowych
>> i dane, które zaczytuje, wprowadza do rejestrów VAT. Dopiero w rejestrach
>> robi się dalszą "obróbkę", jak np. przypisywanie kategorii do dokumentu lub
>> jego pozycji.
>
> Ale ja na razie o podstawach - dobrze program rozpozna wszystkie
> istotne liczby i dane na fakturze?
>
> A jak bedzie dopisek "swiadectwo kielkowania nr 12345.02" to nie
> pomysli, ze to kwota?

OCR Comarchu i od CTI umie takie rzeczy omijać - są algorytmy, które uczy
się "layoutu" strony, aby wiedziały, gdzie czego szukać.
Nie wiem dokładnie, to nie moja działka.
Jeśli klient ma problem z fakturą, to ją wysyła do programistów i oni z tym
walczą.

>
>>>> 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
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.


--
Pozdrawiam.

Adam