[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: UBL invoice header changes (UBL-8 Jira)
Hi Kees Your example is very good. However in a less-than-perfect world, many users don't have access to (or fully utilize) such sophisticated ERP systems as can manage this level of detail in an efficient manner. Take perfect engineering logic with lots of pieces of information that fit neatly together, and then add the human factor. What you get is errors and wasted resources. In environments where billing is still mostly a manual process, the simpler solution may sometimes be the better and more efficient choice. Best regards, Kenneth On 8/6/14, 11:57 AM, "Duvekot, Kees" <kduvekot@Wehkamp.nl> wrote: >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]