OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] UBL invoice header changes (UBL-8 Jira)


We have discussed this issue previously.  Digging back through the archives it appears UBL 1.0 had this as “0..n”.  But in May 2005 the PSC agreed to a suggestion from Freddy DeVos (the then head of CEFACT’s TBG1 group) to change the cardinality from “0..n” to “0..1”.  So UBL 2.0 and 2.1 have this as “0..1”.  Freddy’s argument at the time was:

> Why is the cardinality 0..*.  If products of different orders or order items are invoiced on the same invoice the reference to the Order and if needed to the Order item should be provided  at  the Invoice line.
> Cardinality should be limited to 0..1 
> 

Which is similar to that proposed by Kees.  So reverting back to “0..n” would be a reversal of that decision.

Before we go down that road, isn’t it possible to use the current structure to achieve the same result (many-to-many references)  through an implementation guideline?

On 7 Aug 2014, at 12:53 pm, JAVEST by Roberto Cisternino <roberto@javest.com> wrote:

> Hello all,
> actually the requirement comes from the Italian government specification of the Public Administration Invoice (FatturaPA).
> 
> Splitting is more common in the delivery of the goods but I understand that todays commercial software provides different capabilities like those described by Kees
> In any case I do not see any limit in the UBL Invoice line items.
> 
> I can associate a line item to more than 1 order as I can reference the POs provided in the header using the OrderReference identifier as follows:
> 
> <cac:OrderLineReference>
>     <cbc:LineID>1</cbc:LineID>
>     <cac:OrderReference>
>         <cbc:ID>PO-1</cbc:ID>
>     <cac:OrderReference>
> </cac:OrderLineReference>
> <cac:OrderLineReference>
>     <cbc:LineID>5</cbc:LineID>
>     <cac:OrderReference>
>         <cbc:ID>PO-2</cbc:ID>
>     <cac:OrderReference>
> </cac:OrderLineReference>
> 
> After all this is not too verbose if someone want this level of reference.
> 
> Anyway I see this all a topic for implementation profiles.
> 
> UBL syntax should only provide the sufficient cardinality and maybe a methodology.
> 
> Hope this helps.
> Roberto
> 
> Il 06/08/2014 18.57, Duvekot, Kees ha scritto:
>> Kenneth and others,
>> 
>> Let's work out an example:
>> 
>> Party A has placed 2 orders with each having 2 lines each for BEER and SODA
>> 
>> Order 1
>> 	Line 1.1
>> 		6 cases of BEER
>> 	Line 1.2
>> 		4 cases of SODA
>> 
>> Order 2
>> 	Line 2.1
>> 		6 cases of SODA
>> 	Line 2.2
>> 		4 cases of BEER 
>> 
>> These orders have been send to Party B and have been delivered in whole. So 10 Cases each has been delivered.
>> So now Party B would like to invoice Party A for this
>> 
>> Invoice 2014-001
>> 	Invoice Line 1
>> 		10 cases of BEER
>> 			OrderLineRef 1.1
>> 			OrderLineRef 2.2
>> 	Invoice Line 2
>> 		10 cases of SODA
>> 			OrderLineRef 1.2
>> 			OrderLineRef 2.1	
>> 
>> By setting up the invoice like this it gives party A enough information to check what has been delivered and what is being invoiced in his systems.
>> I would go even further and I would split the invoice in 4 lines each. Because how do you know how many is invoiced on each line of the order? Is it split 5/5 against both orders?
>> In this case the total equals what has been ordered .. but if there a deviations, or backorders etc .. then how do you know what to check and how to validate?
>> 
>> If the invoice would look like this:
>> 
>> Invoice 2014-001
>> OrderRef 1
>> OrderRef 2
>> 	Invoice Line 1
>> 		10 cases of BEER
>> 	Invoice Line 2
>> 		10 cases of SODA
>> 
>> Then you only have a order reference ... but you know even less.
>> 
>> This is why I feel it is always in everybody's interest to be specific and always reference back to the individual lines.
>> And when you are dealing with fluctuating prices (between orders, or even between deliveries) then it becomes even more important to have a correct reference or when the price on the invoice is different then what has been agreed on the order etc etc etc
>> 
>> It could also be that the recipient of the invoice is using a different form of inventory valuation that is requiring them to link each and every invoice to the individual receipts. Because you can never be sure, again it would be wise to always reference back to the individual lines.
>> Also in the systems of Party B both orders are separate orders (otherwise you can now know which ones to invoice) so if they are a copy of the original order you also know exactly what has been delivered on each line and what to charge the customer.
>> 
>> Actually by omitting al these details in the invoice you take away a lot of knowledge from your customer and you increase the rules in the invoicing system (that needs to know if an order is being completely invoiced or not etc etc)
>> 
>> It would also be interesting to see if one of the largest users/processor  of UBL Invoices (TradeShift) has found it limiting that on a header level you can only specify one orderreference and not multiple...
>> 
>> Kees
>> 
>> 
>> 
>> -----Oorspronkelijk bericht-----
>> Van: 
>> ubl@lists.oasis-open.org [mailto:ubl@lists.oasis-open.org
>> ] Namens Kenneth Bengtsson
>> Verzonden: woensdag 6 augustus 2014 17:52
>> Aan: G. Ken Holman; 
>> ubl@lists.oasis-open.org
>> 
>> Onderwerp: Re: SV: [ubl] Agenda for Atlantic UBL TC call 6 August 2014 14:00UTC
>> 
>> Dear Ken/Roberto/all
>> 
>> We too have users (several actually) who require to reference more than one purchase order from an invoice. It is a convenience both for the buyers and suppliers to be able to bill products and services from several purchase orders in one big invoice. They argue that it simplifies their payment processes. We even have a user (at least one) where the relation between purchase orders and invoices is many to many.
>> 
>> We use the AdditionalDocumentReference element to support these processes.
>> 
>> We haven't had a requirement from these users to automatically match invoice items to order items.
>> 
>> Best regards,
>> 
>> Kenneth
>> 
>> 
>> On 8/6/14, 10:22 AM, "G. Ken Holman" 
>> <gkholman@CraneSoftwrights.com>
>>  wrote:
>> 
>> 
>>> At 2014-08-06 10:05 +0200, JAVEST by Roberto Cisternino wrote:
>>> 
>>>> I see Peter,
>>>> but I could not have that level of detail.
>>>> 
>>>> The requirement is simply to support the case where an invoice is 
>>>> related to one or more purchase orders.
>>>> 
>>> I understand you see this as a simple requirement, Roberto, but may I 
>>> ask you, please, to elaborate how such a change would be exploited by 
>>> users?
>>> 
>>> During today's teleconference the point was raised that the header 
>>> reference is used as a kind of default for the line items that do not 
>>> have a specific reference.  If more than one order is allowed to be 
>>> referenced at the header level, the absence of a line reference would 
>>> be ambiguous and prevent processing software to reliably match invoice 
>>> items to order items.
>>> 
>>> I've recognized your requirement in the committee's JIRA project:
>>> 
>>>   
>>> https://issues.oasis-open.org/browse/UBL-8
>>> 
>>> 
>>> Meanwhile, could you either comment there (your committee membership 
>>> should be enough credentials) or here on the list?
>>> 
>>> Thanks for this input!
>>> 
>>> . . . . . . Ken
>>> 
>>> 
>>> --
>>> Contact us for world-wide XML consulting and instructor-led training | 
>>> 
>>> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/video.htm
>>>  |
>>> Crane Softwrights Ltd.            
>>> http://www.CraneSoftwrights.com/o/
>>>  |
>>> G. Ken Holman                   
>>> mailto:gkholman@CraneSoftwrights.com
>>>  |
>>> Google+ profile:      
>>> http://plus.google.com/+GKenHolman-Crane/about
>>>  |
>>> Legal business disclaimers:    
>>> http://www.CraneSoftwrights.com/legal
>>>  |
>>> 
>>> 
>>> ---
>>> This email is free from viruses and malware because avast! Antivirus 
>>> protection is active.
>>> 
>>> http://www.avast.com
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> 
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>> 
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
>> 
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>  
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> 
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>  
>> 
>> 
>> 
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG - 
>> www.avg.com
>> 
>> Versione: 2014.0.4716 / Database dei virus: 3986/7993 -  Data di rilascio: 06/08/2014
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Cordiali saluti
> 
> Roberto Cisternino
> <fefcbgjj.png>
> JAVEST By Roberto Cisternino 
> 
> P.IVA: IT01290640117 
> C.F.: CSTRRT68M06E463H 
> 
> Document Engineering Services, Director Associate 
> OASIS Member
> TESISQUARE Partner 
> 
> Mobile: +39 328 2148123 
> Skype: roberto.cisternino.ubl-itlsc
> <roberto.vcf>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-----------------
Regards 
Tim McGrath
tim.mcgrath@documentengineeringservices.com
Fremantle, Western Australia
http://www.documentengineeringservices.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]