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 invoice header changes (UBL-8 Jira)


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 



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