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.
- From: "Sylvia Webb" <swebb@gefeg.com>
- To: <ubl-psc@lists.oasis-open.org>
- Date: Wed, 7 Dec 2005 19:17:47 -0800
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
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,
-
- 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.
-
-
- The
last four PO's have been shipped short.
-
-
- I
receive a Despatch Advice that the backordered fire extinguishers for
two open orders are in transit on a single pallet as agreed.
-
-
- The
shipment arrives and I verify the quantities and inspect for damage.
-
-
- 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.
-
-
- 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]