RE: [ubl-dev] Map EDI Invoice to UBL

["Véronique Testa" <veronique.testa@cegedim.fr>]

Belle journéeHi,
I agree with you about the EDI that allows partners to do anything in a
common acceptance (classic EDI).
The problem is that we have to support them even if we try to promote others
formats, models.

The invoice w/o Line is an invoice for transport charge, taxable. (I saw the
same special case for a credit note).The Invoice includes at invoice level,
charge description, taxable amount and tax rate applicable for the charge.
The foot mentions, as expected in all invoices, the Total taxe and taxable
amount for the transport charge.

This case is supported by GS1 and is one of their test case for their
attestation.
Thanks for your help...

 -----Message d'origine-----
De : Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com]
Envoyé : lundi 23 janvier 2006 17:59
À : 'Véronique Testa'; ubl-dev@lists.oasis-open.org
Objet : RE: [ubl-dev] Map EDI Invoice to UBL


  Véronique,

  With respect to an invoice without a line item, can you provide an example
of a use case?

  With respect to an actionable invoice as opposed to, say, some follow-up
reminder or statement, I suggest that every invoice should have at least one
line item in order to convey unit price, units, line item descriptions, etc
as opposed to either not conveying line item information at all or conveying
some or all of that information as part of the header.

  Although the seller generating the invoice may not need that data, the
receiver or various third parties often need it either to process the
invoice or for their data warehouse functionality or for corporate
governance purposes or for all three. Actionable invoice transactions should
convey enough to fit all three sets of needs, one can hope with zero need
for human intervention, as they relate to inbound invoices. Note that there
is a symmetry with PO transactions, sales order transactions, shipping
advices etc. which also should contain line items.

  If instead the transaction you have in mind is not an actionable invoice
transaction to be processed through the buyer's payables process, but rather
is some sort of non-actionable advice, it probably should not use the
invoice transaction format.

  One of the difficulties that we inherit from the EDI days is that the EDI
standard offers n ways of doing almost anything, where n is often
substantially greater than 1. The result is that trading partners can then
do things in fundamentally incompatible ways even though both are both
conforming to the EDI rules.




Fulton Wilcox


Colts Neck Solutions LLC


Colts Neck, NJ USA






----------------------------------------------------------------------------
--

  From: Véronique Testa [mailto:veronique.testa@cegedim.fr]
  Sent: Monday, January 23, 2006 4:11 AM
  To: ubl-dev@lists.oasis-open.org
  Subject: [ubl-dev] Map EDI Invoice to UBL



  Considering that UBL is a reality in electronic business context, we build
our EInvoicing project on UBL 1.0 Invoice model.
  However, I've got some questions about mapping EDI elements to UBL. In
fact, the EDI invoice allows to identify more party DTM 3035 than UBL. I
could not find equivalence for some of them (GS1 allows to define a NAD+LC
party for Tax representative, NAD+CO for head office if different from Buyer
or Seller , NAD+DL for Factor..). With UBL 1.0 it is not possible to add Sub
Party (with name, address...) to the main one to describe the reality (Party
Cardinality is set to 1 max).



  The second point is that EDI Invoice can exists (see GS1 specifications
for D96a) without InvoiceLine. UBL 1.0 doesn't allow this (Invoice Line is 1
to unbounded). We've got such invoices.



  Always with EDI Invoice definition, GS1 permits to exchange information
between trading partners in free text rather than encoded data. So in
invoice header, you can find in lot of cases : FTX segment to transfer in
free text Payment Conditions (FTX+AAB, FTX+PMD) government reference
(FTX+REG) and reference text in case of Exemption (FTX+SIN). How is it
possible to transmit all those informations in the invoice Header. The
cbc:Note could not be duplicate and even so, there is no way to distinguish
the different text (no qualifier references).



  I imagine that someone has already asks you about these points and I'm not
the only one working with EDI partners which send/receive GS1 D96a Invoices.

  Is it possible to get in UBL an exhaustive Invoice from EDI format and all
data (mandatory or not) ?



  So, is there something I didn't see in UBL 1.0 to take in charge my
business reality, should I wait for UBL 2.0 model that implements all
answers. Finaly, is the only way in UBL scheme extension ? I'm afraid in
this case to be no more Universal ...



  Thx for all comments, help.



  Véronique Testa

  Project Manager