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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

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


Subject: RE: [ubl-psc] Rationalizing Related Document, Billing Document and Document Reference.


Title: Re: [ubl-psc] Rationalizing Related Document, Billing Document and Document Reference.
Mark,
 
While your comments are valid, I gave you a real business scenario that is quite common in the US. UBL 2.0 needs to support this use case.
 
One of our responsibilities as standards developers is to develop messages that support existing business scenarios independently of our opinion of those practices. If we, as receivers of data, do not want to support this type of use case, we create implementation documentation to specify our best practices to our trading partner community. 
 
The original question was "Does it give a meaning on document level to have 0..n reference to an order or an despatch advice." The answer is yes. It is needed to support existing business practices.
 
Companies and entities who want automated matching will not use the 0..n reference to an order or despatch advice at the header level for all of the reasons you mention. Those have partially automated processes may have other needs.
 
Regards,
Sylvia

From: Mark Leitch [mailto:ml@tritorr.com]
Sent: Wednesday, December 07, 2005 10:24 AM
To: Sylvia Webb; ubl-psc@lists.oasis-open.org
Subject: Re: [ubl-psc] Rationalizing Related Document, Billing Document and Document Reference.

Sylvia,

Using your scenario (attached also as a doc to make it easier to read), my comments in red.

·       I have placed several purchase orders to receive 500 fire extinguishers each week.  Back ordered product against previously placed PO's is to be accumulated and shipped only when there is a full pallet load.
o   PO1          Line 1                    500 extinguishers
o   PO2          Line 1                    500 extinguishers
o   PO3          Line 1                    500 extinguishers
o   PO4          Line 1                    500 extinguishers  
·       The last four PO's have been shipped short.
o   Despatch Advice 1                    PO1          Line 1                    Qty200
o   Despatch Advice 2                    PO2          Line 1                    Qty325
o   Despatch Advice 3                    PO3          Line 1                    Qty300
o   Despatch Advice 4                    PO4          Line 1                    Qty275
o   Outstanding                                                                              Qty900
·       I receive a Despatch Advice that the backordered fire extinguishers for two open orders are in transit on a single pallet as agreed.
o   Despatch Advice 5                                                  Qty200
o   Despatch Advice has (0..n) Order Reference (see Procurement Library)
o   Despatch Advice refers to PO3 and PO4
·    at this point we don’t know which of the POs the quantity of 200 applies to
o   Despatch Advice has (1..n) Despatch Lines (see Procurement Library)
·    there are two possible scenarios here; one makes sense of the process, the other does not
o    the ‘bad’ scenario involves a single Despatch Line with a quantity of 200 and reference to PO3 and PO4; this scenario perpetuates the ambiguity from Header to Line level and neither PO can be closed off in the Buyer system because we don’t know which quantities apply
o    the ‘good’ scenario uses two Despatch Lines each referring the quantities to the appropriate PO (see next point for further clarification)

o   Despatch Line has (1..n) Order Line References (see Procurement Library)
·    we have a problem here in the Procurement Library because
1.  the Despatch Line can have many Order Line References but
2.  an Order Line Reference can have (0..n) Order References, so
3.  in the ‘bad’scenario the Despatch advice could say
o    Despatch Advice 5                                        Qty200
o    Despatch Line 1          PO Line Ref 1          Qty50
o                                        PO Line Ref 1          Qty150
o    and we still don’t know which PO is which
o    even in the ‘good’ scenario the Despatch Advice could say:
o    Despatch Advice 5                                        Qty200
o    Despatch Line 1          PO Line Ref 1          Qty50
o    Despatch Line 2          PO Line Ref 1          Qty150
o    and again we don’t know which PO is which

o   The only way I can see to resolve this is to say
1.  Despatch Line has (1..1) Order Line References and
2.  Order Line Reference has (1..1) Order References i.e.the Order Line can only come from one Order (which seems sensible)
o   If this were the case the Despatch Advice would say
o    Despatch Advice 5                                        Qty200
o    Despatch Line 1          PO Line Ref 1 (PO Ref 3)                    Qty50
o    Despatch Line 2          PO Line Ref 1 (PO Ref 4)                    Qty150
o    and we would the know that the outstanding quantities against POs 3 and 4 are 150 and 75 extinguishers respectively
·       The shipment arrives and I verify the quantities and inspect for damage.
o   OK
·       I return a Receipt advice that references at the header level the Despatch Advice No., and the two open purchase orders that the shipment was against.
o   same problem with the Receipt Advice as with the Despatch Advice; we don’t know which order(s) we’re talking about
·       At the detail level, I reference a single line item with the part number and associated details of the fire extinguisher that was shipped.
o    see ‘bad’ scenario above
The example scenario above assumes that each of the POs only has one Line.  In cases where the POs have more than one Line, the ambiguity is compounded many-fold.
This is the reason that I have been pushing for matching at the line level throughout the process.  I recognize that there is a 1.0 legacy to manage in this respect, but we have also to manage our way forward.  I have already had questions around Zanzibar along the lines of “will OGC’s adopted standard cater for SAP and Oracle sub-line functionality”? ; at this stage I think this is a bit over the top but I also recognize that header matching is two steps removed from the question.

I hope that all makes sense.

Regards, M


Mark Leitch





From: Sylvia Webb <swebb@gefeg.com>
Organization: GEFEG
Reply-To: <swebb@gefeg.com>
Date: Wed, 7 Dec 2005 05:08:58 -0800
To: <ubl-psc@lists.oasis-open.org>
Subject: RE: [ubl-psc] Rationalizing Related Document, Billing Document and Document Reference.

Mark,

  1. I have placed several purchase orders to receive 500  fire extinguishers each week.  Back ordered product against  previously placed PO's is to be accumulated and shipped only  when there is a full pallet load.  
  2. The last four PO's have been shipped short.   
  3. I receive a Despatch Advice that the backordered fire  extinguishers for two open orders are in transit on a single pallet as  agreed.
  4. The shipment arrives and I verify the quantities and  inspect for damage.
  5. I return a Receipt advice that references at the  header level the Despatch Advice No., and the two open purchase orders  that the shipment was against.
  6. At the detail level, I reference a single line item  with the part number and associated details of the fire extinguisher that was  shipped.
Regards,
Sylvia

From: Mark Leitch [mailto:ml@tritorr.com]
Sent: Tuesday, December 06, 2005 7:36 AM
To: Sylvia Webb; ubl-psc@lists.oasis-open.org
Subject: Re: [ubl-psc] Rationalizing Related Document, Billing Document and Document Reference.

Sylvia,

I’m having trouble understanding your point, particularly the multiple document references for a single line item.
Please can you illustrate your points with real examples.

Thanks, Mark

Mark Leitch






> From: Sylvia Webb <swebb@gefeg.com>
> Organization: GEFEG
> Reply-To: <swebb@gefeg.com>
> Date: Tue, 6 Dec 2005 07:17:07 -0800
> To: <ubl-psc@lists.oasis-open.org>
> Subject: RE: [ubl-psc] Rationalizing Related Document, Billing Document and
> Document Reference.
>
> From my experience, a Receipt Advice can be related to multiple previous
> documents. This can be true if any single line item is a consolidated
> shipment from multiple previous orders.  Further, if the receipt advice is
> only for 1 line item, it is appropriate to have multiple document references
> at the header level.
>
> Regards,
> Sylvia
>
> -----Original Message-----
> From: Peter Larsen Borresen [mailto:plb@itst.dk]
> Sent: Tuesday, December 06, 2005 6:25 AM
> To: ubl-psc@lists.oasis-open.org
> Subject: SV: [ubl-psc] Rationalizing Related Document, Billing Document and
> Document Reference.
>
> Dear all
>
> We need to take a look at the document references at document level for
> ReceipAdvice (and perhaps also more documents). Does it give a meaning on
> document level to have 0..n reference to an order or an despatch advice.
> From Marks perspective there can only be 0..1, otherwise they most be on
> line level. Can I correct this?
>
> /Peter
>
> -----Oprindelig meddelelse-----
> Fra: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
> Sendt: 6. december 2005 06:38
> Til: ubl-psc@lists.oasis-open.org
> Emne: [ubl-psc] Rationalizing Related Document, Billing Document and
> Document Reference.
>
>
> On Monday's PSC call I was given the task to rationalize the various ways we
> have used to relate documents to other documents.  This was because it
> appeared that we had several structures for performing similar functions.
>
> The main issue was why we had Related Document and Billing Document when
> both had a similar set of associations.  (see attached
> DocumentreferenceCurrent class diagram)
>
> The way I approached this was to recognize that we had Invoice Line, Debit
> Line and Credit Line (aka the Billing Documents) that may reference other
> documents.  We also had Statement Line and Remittance Line (the advisory
> documents) that may also reference other documents.
>
> My rationalization (see attached class diagram)  was primarily to rename
> "Related Document" to be "Accounting Document Reference" and combine this
> with the old "Billing Document" structure.  In effect Accounting Document
> Reference is an extension of Document Reference for "accounting" documents.
> The qualification of what type of accounting document is then given by the
> name of the role in the association to Document Reference.
>
> Some other effects of this were:
> * "Related Document Line" becomes "Accounting Document Reference Line"
> * By creating two possible associations to "Accounting Document Reference
> Line" (one called Debit and one called Credit) we dont need to DebitLine or
> CreditLine in the Remittance Advice Line or the Statement Line.  This is
> because these documents are reflecting (or summarizing) the accounting
> transactions of the Accounting Document Reference.  Their 'amounts' are
> duplications of those other values.
> * Line Reference may associate with either a Document Reference or an
> Accounting Document Reference.
>
> Overall, this gives us a symmetry with the way both billing documents and
> advisory documents show references to other documents and their
> transactions.
>
> If no-one has any objections to this  then perhaps Peter can build it into
> draft 11 for review of Friday's call?
>
>
> --
> regards
> tim mcgrath
> phone: +618 93352228  
> postal: po box 1289   fremantle    western australia 6160
>
> DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business
> Informatics and Web Services
> http://www.docengineering.com/
>
>
>
>
>



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