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:
>>>> Dnia Mon, 16 Aug 2021 00:26:11 +0200, J.F napisał(a):
>>>>> On Sat, 14 Aug 2021 10:47:27 +0200, Adam wrote:
>>> [...]
>>>>>>> >> Oczywiście, że nie skaner, tylko usługa OCR:
>>>>>>> >> https://www.comarch.pl/erp/ocr/ Jak coś źle robi, to się zgłasza i
>>>>>>> >> chłopaki poptawiają. Zresztą tego typu usług jest sporo, np.
>>>>>>> >> program Zygmunta: https://www.cti.org.pl/cti_optima_kancelaria.html
>>>>>>> > A Niemce sobie organizuja jakies serwisy krajowe do e-faktur, zeby
>>>>>>> > mozna bylo sciagnac dane elektroniczne, a nie skanowac.
>>>>>>> U nas już puka do drzwi.
>>>>>>>
>>>>>>> https://ksiegowosc.infor.pl/podatki/vat/faktura/4712
291,
>>>>>>> Centralny-Rejestr-Faktur-od-2021-r-Co-czeka-podatnik
ow.html
>>>>>>
>>>>>> Ale przecież system jako taki działa już od ponad 20 lat.
>>>>>>
>>>>>> https://mfiles.pl/pl/index.php/Systemy_EDI
>>>>>
>>>>> Problem w tym, ze to "systemy". Niekompatybilne ze soba :-)
>>>>
>>>> Masz jakieś przykłady?
>>>> Nic mi nie wiadomo, aby EDI nie działało z EDI.
>>>
>>> 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
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 ;)
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.

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 ;)

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


>
>>>> Swego czasu bodajże Makro Cash and Carry wymyśliło swoje komunikaty GS1,
>>>> ale to nie zaprzecza standardowi.
>>>> Zobacz:
>>>> https://www.gs1pl.org/kontakt/wytyczne-techniczne/ed
i-uzgodnione-dokumenty/komunikaty-edi
>>>
>>> A Miele ... obsluguje VDA i EDIFact, czy mieszanke?
>>> https://www.miele.pl/m/edi-369.htm
>>>
>> Ale to nie dotyczy dokumentów handlowych.
>
> Istotnie. Miele nie chce faktur przez EDI?

Nie wiem, nie mam chyba nikogo, kto by z nimi współpracował.

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

>
>>>>>> https://pl.wikipedia.org/wiki/Elektroniczna_wymiana_
danych
>>>>>>
>>>>>> Tyle, że w Polsce (i nie tylko) trzyma na tym łapę kilka firm, przez
>>>>>> których serwery są przesyłane te pliki. Kosztuje to stosunkowo dużo, w
>>>>>> zamian dostaje się archiwum (wymagane ustawą o księgowości), automaty do
>>>>>> samoczynnego wymieniania się dokumentami, frontend przes https itd.
>>>>>>
>>>>>> 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.
Są przygotowania do OCR dla dokumentów handlowych, ale jeszcze nie mam
żadnych informacji na ten temat.

>
>> Comarch EDI czyta pliki XML albo podpina się go bezpośrednio pod bramkę.
>
>>>> Natomiast w module albo programie księgowym ustawia się wzorce księgowań
>>>> dla poszczególnych typów dokumentów, dla poszczególnych pozycji na
>>>> dokumencie czy też w jeszcze bardziej skomplikowany sposób, np. przy
>>>> podwójnej księgowości.
>>>>
>>>> A jeśli czegoś brakije, to można się zwrócić choćby do Jacka po odpowiedni
>>>> konwerter:
>>>>
>>>> https://www.konwerter.com.pl/programy-handlowe
>>>
>>> I mowisz, ze bez problemu :-)
>>>
>> To powyższe odnosi się tylko do migracji dokumentów z programu handlowego
>> (których w Polsce jest dużo) do programu księgowego (których w Polsce też
>> jest dużo) i ewentualnie do zaczytywania informacji zwrotnej (np.
>> rozliczenia dokumentów dokonane w księgowości, które powinny wrócić do
>> programu handlowego, aby na fakturach było widać, że są rozliczone).
>> Oczywistym jest, że nie wszystkie programy gadają ze wszystkimi - wtedy
>> przydaje się konwerter, celem dostosowania/przekształcenia formatu
>> wyjściowego do formatu wejściowego innego programu.
>
> O to to to :-)
>
>> 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.


--
Pozdrawiam.

Adam