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

[JAVEST by Roberto Cisternino <roberto@javest.com>]

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

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

begin:vcard
fn:Roberto Cisternino  
n:Cisternino;Roberto
org:JAVEST
adr:;;Via Europa, 33/F;Follo;La Spezia;19020;ITALY
email;internet:roberto.cisternino@javest.com
tel;cell:+39 328 2148123
url:htttp://www.javest.com
version:2.1
end:vcard