RE: POs considered harmful for dependent demands

[Bob Haugen <linkage@interaccess.com>]

Andrew Chilcott wrote:
>Can we not combine the concept of a purchase order and a lightweight release
>mechanism by first looking from 10,000 feet at a business transaction and
>then looking at the 0.00001 inch view. At a high level, the business
>transaction may take many forms from long-term contracts with drawdown at
>one extreme to one-off purchases from an unknown customer at the other. At
>the lowest level of granularity these transactions all involve a simple
>process which initiates the provision of goods or services by one party to
>another which, subject to various conditions, will be settled/closed at a
>time determined by the parties by a transaction of equal and opposite value
>between them. 

I have been advocating the definition of that lowest level of granularity
or simple exchange process, as a core component that could be linked
to the extensible attributes you describe below.  (Actually, I am not
sure yet which of the groups it would belong to, BP or Core.  Core
components listed so far appear to be simple data elements,
whereas this one would be more complex.  But it is repeated in
each of the many EDI documents specifying demands.)

The only difference I would have with your description is
trying to combine the simple core process with the purchase
order, which I believe would be better off as an optional add-on.
(Let me know if I misunderstood your point...)

>Such a transaction initiation message should have various extensible
>attributes and should be triggered by a variety of events which determines
>which party initiates the message. The attributes might be:
>	PriceAgreed; ContractTermsAgreed; CreditAgreed; DeliveryConfirmed;
>etc etc
>The lightweight material release would, by accessing persistent data, have
>all of the attributes set to positive and would therefore flow through the
>system without impediment or additional overhead. The purchase order with
>one or many of the attributes set to negative would incur the additional
>overhead by having to be diverted into a series of sub-processes that
>enabled each of the attributes to be set to positive. Thus the message would
>be enriched as it passed down the virtual production line with the end
>process being a trigger to initiate the equal and opposite transfer of value
>to complete the transaction. Complex transactions would be described as
>collections of these simple transactions. 

I like your descriptions, especially the reciprocal transaction.
But (if I understand correctly) you are not describing
purchase orders as I know them from EDI documents
or ERP systems.
The purchase orders I know are complex documents
with at least a header and usually multiple line items that may 
aggregate demands from many consuming processes.  
The lightweight material release I want is structurally much simpler,
stands on its own (no header or sibling line items),
and is more focused, that is, satisfies one consuming process. 

If you mean an independent line item flowing through the
system with an attribute that says whether or not it is
connected to a purchase order document, that would
work for me. 

Thanks for your evocative feedback,
Bob Haugen