[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]