RE: [ubl-lcsc] [QA] 11/6/2002: Revisions to Scope Document

[Terry Schager <tschager@earthlink.net>]

All,

Businesses frequently issue purchase orders for a period of time, say a
month, with multiple planned releases during the period.  The pulp and paper
industry is an example of one of these industries where this practice is
common.  An order will be sent from a publisher on the 15th of the month for
shipments to be processed in the following month and the cycle repeats
itself every month.  This industry has the luxury of a fairly predictable
cycle of usage and orders are fairly consistent, where quantities ordered
will be similar for a given month when compared to the same month over a
3 -5 year period.  This histogram is used by mill management and product
schedulers to measure predicted usage and to estimate production cycles for
various product grades, sizes, etc.

If I'm reading the proposal and position correctly, you are saying that if I
create an order, generated on the 15th of the month (say July 15th for
August shipments, and we're into the 10th of August) you would re-generate
the order completely if I have changes for a 14th and 20th release - even
though it's the 10th and shipments would have been released against the
original order.

This practice is not uncommon and is, in fact, the norm in this business.  I
would suspect that in a JIT environment, orders with multiple line items
representing releases over a period of time would be even more common.
These are not blanket orders, by the way, so we can't just say "that's a
blanket order and we'll deal with it in another transaction".

Are we looking at real business practices and the associated ERP or legacy
applications that support them?  If the goal is to create a library of data
elements available for industries to model transactions like this after,
that's good enough.  We just need to make sure the tools are given to the
practitioners to be able to build these transactions and their usages.

Terry Schager
Principal
Aeon Consulting
322 Pleasant Hill Rd.
Landrum, SC 29356
864.468.5429 (H)
864.360.1549 (M)
tschager@earthlink.net



-----Original Message-----
From: Monica Martin [mailto:mmartin@certivo.net]
Sent: Wednesday, November 06, 2002 4:35 PM
To: Bill Meadows; ubl-lcsc@lists.oasis-open.org
Subject: [ubl-lcsc] [QA] 11/6/2002: Revisions to Scope Document


I agree with Lisa's suggestion, as partial orders are often used.  Note
that the change would be a separate business transaction within the
business collaboration.

Thanks.
Monica J. Martin
Program Manager
Business Development Manager
Drake Certivo, Inc.
208.585.5946


-----Original Message-----
From: Bill Meadows [mailto:Bill.Meadows@Sun.COM]
Sent: Wednesday, November 06, 2002 1:57 PM
To: ubl-lcsc@lists.oasis-open.org
Subject: Re: [ubl-lcsc] [QA] Revisions to Scope Document



 We said at Burlington, that any change no matter how big or small,
would
mean a complete resend of all fields.  I believe that is what that
sentence is
trying to convey.  Your suggested addition does not impact that it is a
complete
resend of the message.  I am OK with your suggested addition.  We might
need to
clarify that all items, fields, will be resent.

just my $.02

Bill


> Date: Wed, 06 Nov 2002 12:59:07 -0600
> From: Lisa Seaburg <xmlgeek@gmi.net>
> Subject: [ubl-lcsc] [QA] Revisions to Scope Document
> To: Ubl-Lcsc <ubl-lcsc@lists.oasis-open.org>
> MIME-version: 1.0
> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> X-Priority: 3
> X-MSMail-priority: Normal
> List-Owner: <mailto:ubl-lcsc-help@lists.oasis-open.org>
> List-Post: <mailto:ubl-lcsc@lists.oasis-open.org>
> List-Subscribe: <http://lists.oasis-open.org/ob/adm.pl>,
<mailto:ubl-lcsc-request@lists.oasis-open.org?body=subscribe>
> List-Unsubscribe: <http://lists.oasis-open.org/ob/adm.pl>,
<mailto:ubl-lcsc-request@lists.oasis-open.org?body=unsubscribe>
> List-Archive: <http://lists.oasis-open.org/archives/ubl-lcsc/>
> List-Help: <http://lists.oasis-open.org/elists/admin.shtml>,
<mailto:ubl-lcsc-request@lists.oasis-open.org?body=help>
> List-Id: <ubl-lcsc.lists.oasis-open.org>
>
>  Suggestions for changes to the Order Change Section:
>
> Order Change
>
> [existing]The Order Change is sent from the Buyer to the Seller as a
complete
replacement Order.
>
> Are we saying that this can only be this one scenario?  Experience
tells us
that this is used as partial changes also, or do we not even want to go
there.
Discussion??
>
>
> [add] Buyers can initiate a change to a previously accepted order.
Buyers may
change an order for various reasons such as changing the ordered items,
quantity, delivery date, ship-to address, etc.  Suppliers can accept or
reject
the change order using the order response document.  [end of add]
>
>
>
> Referenced documents:   PIP3A4: Purchase Order Change Message. Version
1.1
RosettaNet.; CHGORD: Purchase Order Change 99A. UNEDIFACT; 860: Purchase
Order
Change.  X12 v 4020; AIA Implementation Guides & Use Cases.
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> Lisa Seaburg
> AEON Consulting
> Website: http://shell.gmi.net/~xmlgeek/
> Email:  xmlgeek@gmi.net
> Alternative Email: xcblgeek@yahoo.com
> Phone: 662-562-7676
> Cellphone: 662-501-7676
>
> "Remember that great love and great achievements involve great risk."
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>