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

do góry

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.

do góry

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

do góry

"Eneuel Leszek Ciszewski" sf70v0$10pc$...@g...aioe.org

> F-S ma krótszą klawiaturKę, co nieco spowalnia proces ;) wklepywania
> danych... [i zabranych (czyli korekt?) też] Brakuje klawisza zwanego
> plusem, ale 'szarym plusem'... ;) Plus rzecz jasna jest, ale ,,biały

Bezczelność trolli powala!!! -- nikt nie zaszczekał czegoś na kształt:
- Co ma kolor do funkcji, idioto?!

Muszę tedy odpowiedzieć sam sobie...
https://pl.wikipedia.org/wiki/Enter

Na większości klawiatur znajdują się dwa Entery: jeden w bloku
alfanumerycznym, używany najczęściej, a drugi (tzw. szary) w bloku
numerycznym. Oba klawisze są rozróżnialne dla systemu operacyjnego,
więc ich działanie może być różne (domyślnie jest takie samo).

Takoż z plusem...
https://en.wikipedia.org/wiki/Model_M_keyboard#/medi
a/File:IBM_Model_M_1391403_keyboard.jpg

> plus'' domaga się shiftu, co mocno komplikuje sprawę...


> w zamian ruchu palcem po toCZpadzie, co spowalnia pracę... Nadto nie
> mam tu półprzewodnikowego dysku SSD

Niby można użyć penflaszki wpiętej do USB... ;)

--
_._ _,-'""`-._ .`'.-. ._. .-.
(,-.`._,'( |\`-/| .'O`-' .,; o.' e...@g...com '.O_'
`-.-' \ )-`( , o o) `-:`-'.'. `\.'.' '~'~'~'~'~'~'~'~'~'~'~'~'~' o.`.,
-bf- `- \`_`"'-.o'\:/.d`|'.;.p \ ;' http://www.eneuel.w.duna.pl ;\|/...

do góry

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 ?

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

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

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

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

Albo glupia nazwa firmy - jedno pole, czy dzielone na kilka linii,
bo niektorzy to maja naprawde dlugie nazwy :-)

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

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

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

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

J.

do góry

Hello, Adam.
On 18.08.2021 14:54 you wrote:

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

Angole?
https://pl.m.wikipedia.org/wiki/SAP_(przedsi%C4%99bi
orstwo)


--
Pete

do góry

Dnia Wed, 18 Aug 2021 19:49:19 +0200, Pete napisał(a):

> Hello, Adam.
> On 18.08.2021 14:54 you wrote:
>
> > 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.
>
> Angole?
> https://pl.m.wikipedia.org/wiki/SAP_(przedsi%C4%99bi
orstwo)

SAP jako taki, to tak.

Ale siedziba korporacji, o której pisałem, jest w GB. W Polsce jest tylko
(aż?) siedziba oddziału zarządzającego w Europie Wschodniej oraz sieć
punktów.
Natomiast tematy związane z IT, a w zasadzie z SAPem przechodzą przez GB,
bo mają jednolity system na całym świecie oparty na dziesiątkach dodatków,
które są przypisane do poszczególnych loginów.


--
Pozdrawiam.

Adam

do góry

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

do góry

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

do góry

"Kviat" sduq0e$1sqv$...@g...aioe.org

>>>>> Brakuje daty sprzedaży

> Nie ma już daty sprzedaży!
> Ludzie, do cholery, czytajcie przepisy!

> Art. 106e. 1. Faktura powinna zawierać:
> 1) datę wystawienia;
> (...)
> 6) datę dokonania lub zakończenia dostawy towarów lub wykonania
> usługi lub datę otrzymania zapłaty, o której mowa w art. 106b
> ust. 1 pkt 4, o ile taka data jest określona i różni się od
> daty wystawienia faktury;
> KONIEC CYTATU

> Nie ma żadnego punktu w którym wymieniona by była data sprzedaży.

> Albo weźcie sobie do ręki jakąś fakturę wystawioną przez kogoś
> normalnego (przecież macie jakieś koszty i bierzecie faktury!)
> i na tych fakturach jest jak wół: "Data zakończenia
> dostawy/usług" - albo podobnie..., A NIE DATA SPRZEDAŻY.

https://isp-modzelewski.pl/serwis/daty-zawarte-na-fa
kturze/

--
_._ _,-'""`-._ .`'.-. ._. .-.
(,-.`._,'( |\`-/| .'O`-' .,; o.' e...@g...com '.O_'
`-.-' \ )-`( , o o) `-:`-'.'. `\.'.' '~'~'~'~'~'~'~'~'~'~'~'~'~' o.`.,
-bf- `- \`_`"'-.o'\:/.d`|'.;.p \ ;' http://www.eneuel.w.duna.pl ;\|/...

do góry