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


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

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

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

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.


--
Pozdrawiam.

Adam