RE: [ubl-psc] Re: Punchout in UBL 2.0

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

All,

All:

All:

A few comments on "punch-out" and on associated roles. First, it is good to
see punch-out represented in the UBL model, if perhaps rather tentatively,
which I presume sets the stage for further progress. My comments have to do
with the role of punch-out as well as its intersection with "roles." 

In the purchasing transaction cycle, the originator (requisitioner) in a
conventional non-production purchasing process creates a requirements
transaction - typically a requisition with rather informal content. The
requisitioner uses whatever information he or she has available, which might
include a quote as an attachment, but requisitioners would rarely be so
diligent as to incorporate all the detail into the requisition. 

(The quote step is referenced in the UBL process as associated with the
originator, but if supplier selection is an open issue, often the buyer
would issue the request for quote).  

In punch-out, the "originator" punches out to the target supplier web site
in order to create the body of the requisition. The user's interaction with
the supplier's site in effect "bundles" the creation of requisition content
(e.g., how many widgets the user wants, when etc.) and the supplier's
content - part numbers, price, etc.) into a unified (and standardized)
return XML document. Both xCBL and cXML as well as OBI 3.0 long ago each
defined such a document.  

Although the term catalog (catalogue) is used in the UBL process
description, punch-out is strongly aligned with configurators and other
dynamic content - e.g., a product may not be configurable, but the logistics
aspects may require choices, there may be comments regarding environmental
matters, etc.

Note that within the punchout dialog the originator is dynamically
integrating requisition data and supplier pricing and nomenclature and
perhaps handling instructions, etc. into a single XML document. This is an
exceedingly important "use case" fact, because what is a major service
requirement is that nobody be asked to rekey any of this data. The benefit
of this unified document is that as the punchout-originated transaction data
flows through the customer's purchase to pay process and the seller's order
to cash process, all downstream process synchronize smoothly.

What OASIS-UBL can help accomplish is the standardization of what I term the
inter-entity aspects of this dialog. The statement in 3.1.3 that punchout is
tightly coupled to the specific catalog operation is not true. Indeed, it
cannot be true, because all substantial sellers have had to interact with
multiple implementations. 

What all prior standards-setting art did was to define the user session
handoff (outbound) and the user and user document return. It is in that
domain that we need an update to replace xCBL and cXML, and OBI (and Rosetta
Net I believe has such a "PIP." OASIS UBL is in effect the inheritor of OBI
and xCBL.

Note that punchout is a "big deal" in terms of what it can accomplish and
its future potential. On the other hand, it is a "little deal" from the
perspective of the work required to create the appropriate UBL constructs.
Today's environment can be leveraged as a source of best practice.

One comment on your description of role shifts. 

In punch-out and, for that matter, in much ordinary in-house catalog
ordering, the "originator" (requisitioner) may click on buttons to commit
the transaction, but rarely becomes the "buyer." Indeed, under the division
of responsibility ordinarily enforced in SAP MM and like products, those
roles are kept distinct. That separation is also important from various
regulatory perspectives - cost center control, environmental controls, etc. 

I suggest that rather than describing roles reverting to the "originator,"
a more accurate description is that the roles are automated - performed via
workflow (the same being true on the sellers side). Buyer's roles (typically
vendor selection, pricing management, contract terms and conditions)  and
the enforcement of spending authority is performed by automated workflow,
and the people filling those reviewer roles deal with exception cases.
Workflow is therefore acting as a proxy for the buyer (or other reviewing
parties). 

Below I put in two links regarding this subject. The first has more
information on punchout/OBI/Roundtrip. 

The second has to do with some larger "trans-enterprise" workflow
opportunities reaching beyond buying and selling. Punchout is probably the
major exemplar today of mass "trans-enterprise" workflow. In some contexts
outside the scope of eBusiness it has great potential to solve challenging
information management processes involving fine-grained, high risk privacy
and security constraints.


						Fulton Wilcox
						Colts Neck Solutions LLC



. 








http://www.xmloptimization.com/OBIdialog1.html

http://www.xmloptimization.com/ISE1.html 

http://www.coltsnecksolutions.com/needknow1.html

-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Tuesday, September 27, 2005 10:20 AM
To: arundgren@rsasecurity.com
Cc: ulf.palmgren@abc.se; fulton.wilcox@coltsnecksolutions.com;
ubl-psc@lists.oasis-open.org
Subject: [ubl-psc] Re: Punchout in UBL 2.0

I agree that punchout is not particularly included in the process
model document but I think it has had much consideration over
the past few cycles of UBL. A punchout-like scenario was one reason
to include both BuyerID and SellerID in documents such as Order.
The problem, in my view, is that 'punchout' is a loose term. I'd
value further use case information on what aspects aren't catered
for. Perhaps the use case implied is more one of marketplace than
'punchout' and here we are indeed aware that customisations may
be required - for the well considered reason that here there is more
impact of the 'blackbox' business system on the document interface.

All the best

Stephen Green


>>> Tim McGrath <tmcgrath@portcomm.com.au> 27/09/05 14:58:49 >>>
thanks for the comment,  but i  am not sure that we  are leaving 
interoperability as "someone else's problem".  it is that we see punch 
out as a tightly coupled activity that is outside UBL's scope as a 
document exchange standard.   we certainly try to address 
interoperability at the document exchnage level.

in case i missed something i will pass this onto our procurement 
subcommittee who may have more to add.

Rundgren, Anders wrote:

>http://lists.oasis-open.org/archives/ubl/200507/msg00033.html 
>
>It is a bit pity that the UBL people disregard close to
>ten years of experience with "punchout" schemes that have
>showed that interoperability of this part is pretty hard,
>including agreeing on security issues (buyer authentication
>is indeed an integral part of such schemes).
>
>Even the now defunct OBI standard, in its earliest (96-97)
>incarnations, addressed both catalog interoperability and
>security, while UBL leaves those thorny issues for
>"somebody else to fix".
>
>But, OTOH a "genuine" punchout scheme would IMHO not build
>on simply recasting a few messages because then you would
>not be able to unleash the full power of the "punchout"
>process.
>
>regards
>Anders Rundgren
>Principal Engineer
>RSA Security
>
>
>  
>

-- 
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://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E
-22FF8CA5641F&ttype=2&tid=10476