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

Taki SAP potrafi wyprodukowac XML ?

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

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

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

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

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

J.