RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS andRestricted Data Types

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

All:

In the context of boundary management between what are UBL opportunities and
obligations versus what is trading partner internal particularity, I put
together the following comments on "filtering." I suggest that generally
UBL-level filtering is at a high risk of being: 1) irrelevant 2) duplicative
of other, more authoritative filters, 3) have the opposite effect from
"future-proofing" by inadvertently ruling out new uses of UBL or
complicating version upgrades.

To add some specifics:

1. From a flow perspective, transactions originate from events that occur in
a sender's particular environment and the sender-receiver's particular
trading relationship.

For example, perhaps a seller has shipped a product and needs to invoice the
supplier, or the buyer's inventory level has dropped and the buyer needs to
order from the seller. Such transactions originate in the sender's own
"particularity" and, once replicated to the receiver's environment, live
within the receiver's own particularity. In transit, the transactions
presumably live as UBL standard transactions.

With respect to transaction life cycle in terms of logical steps:

a) after detecting the "event," the sender's processes must extract relevant
transaction details, with its particularity intact, 
b) the sender flows the data through what I will term the sender's
de-particularizing process to emerge as UBL-ready content, 
c) the sender's processes flows the UBL-ready data through a packaging
process to create one (or perhaps more) standard UBL documents/objects, 
d) the UBL transaction flows through the transport process, 
e) on being received, the receiver processes the transaction through an
unpackaging process, 
f) the unpackaged UBL inputs then flows through the receiver's own
particularizing preprocessors, and
g) the now particularized data flows into the receiver's internal processes,
presumably passing the receiver's essential edits.

In implementation, the above steps may not be kept distinct although it is
better from an evolutionary perspective if they are. In any case, my
assumption is that only the substance of what I describe as steps 1c, d and
e are within the UBL standards envelope. 

The question at hand is whether to inject more "filters" into UBL
transaction schemas and, by extension, into what I refer to as
packaging/unpackaging. 

2. In the end-to-end flow from sender "particularity" to receiver
"particularity" four sorts of exception conditions can arise: 

a) exceptions occur that are irrelevant in practice, because the receiver
discards the affected incoming data anyway. For example, given a part number
or customer number, often the receiving-side process effectively will ignore
related "master data" that travels with the transaction (e.g., product
description, customer name), in which how long the strings or other
characteristics does not matter.

b) exceptions occur that the receiver's processes can resolve automatically,
either from prior experiential rules or based on exiguous data from
collaboration protocols, trading partner agreements, etc. 

c) exceptions occur that the receiver's system itself cannot resolve
automatically, but that people on the receiving side can and will handle,
and 

d) exceptions occur that render the transaction inoperable to the receiver
and that must be rejected and, perhaps, subject to a retransmit request.

Filters such as pre-specifying UBL field lengths are of no practical benefit
for cases 2a and 2b, of some benefit in case 2c and are fully applicable to
case 2d. However, "applicable" does not necessarily mean beneficial.

3. Filter specifics as well as the impact of incorporating a new filter
within a succession of filters (those within the sender's and receiver's
systems) may create waste, difficult to anticipate backpressures and
unwanted blockages.

a) Excessively fine-mesh filters can create enough "false positives" to
negate the filters value, while loose-mesh filters permit excessive "false
negatives." Therefore, effective filter design requires a lot of analysis
and "just right" design choices which a standards body generally cannot
undertake.

b) There is risk at the transaction level from the interaction of a
multiplicity of filters. For example, if there are 10 constraints applied to
a given UBL transaction, and each of those constraints are set at, say, at
the 95th percentile, then 40% of the transactions will be blocked ( 1 - .95
to the 10th power, assuming independent distribution). Lack of standards
adoption often results from having to jump too many editing hurdles.

c) Intermediate filters usually duplicate the "truth" filter at that exists
at step 1g - the receiver's import of received "reparticularized" data into
the receiver's internal process. In a fully automated environment, it costs
little for a reject to occur at the "truth" level, while it costs a lot to
resolve an in-network false positive filtering event (e.g., an order is
shortstopped because of a benign field length mismatch).

d) As an analogy, a router can switch millions of packets per second, while
an x.25 switch can switch only a few thousand packets per second because,
unlike the x.25 switch, the router is not performing deep inspection of
individual packets nor asking for retransmits from the prior switch. Today's
technology makes it cheaper and more effective to reserve deep inspection to
the end device, which then can ask for a retransmission.

4. Anticipating preventing unwanted particularity at some thoughtfully
engineered confidence level -e.g., the 95% level - takes one into some
complex analysis and fact-finding. For those who want a feel for
"particularity" below is an ongoing dialog from and SAP-related discussion
site. The standards groups need to facilitate trading partners, but simply
cannot afford to predict and filter out their "bad" habits, which in fact
might not be that bad.

Therefore, I suggest that minimal filtering be done as part of UBL - only
that which has predicable, net value-added results. For very large subsets
(e.g., all "small businesses") much the same holds.


					Fulton Wilcox
					Colts Neck Solutions LLC



Query

My business users want to do the following on a single SAP purchase order

1) pay for the equipment purchased in USD
2) for installation, pay for transportation in various currencies. 
3) pay service charges in local currency.

Response

To do this on one purchase order...

Enter the default currency (i.e. USD) in Vendor Master (T-Code MK02,
Purchasing Org data -> Purchasing data -> Conditions -> Order Currency). 
Include a condition type for "Installation Charges". 
Use M/08 to change pricing procedure. "Item Condition" check box of the
condition type must be TICKED to allow you to enter the rate/currency in
line item. 
If you want to pay the installation charges to a vendor other than the PO
vendor, then the condition category should be "B" . select the condition
line and click on the magnifying glass icon. Change the vendor/ currency on
the next screen. Also TICK the split IV check box. 
Use M/06 to change/ create condition type.









-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Wednesday, May 10, 2006 11:03 AM
To: Stephen Green
Cc: ubl-dev@lists.oasis-open.org
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and
Restricted Data Types

Stephen, 

I follow your thoughts here.   

We're actively re-visiting on which pieces of the CAM template should be
required and which non-normative / extensible. 

Right now the <DataValidation> and <ExternalMapping> are optional.  Also
in jCAM Martin has implemented Maven with these so they are fully
extensible - but obviously that is then non-normative - but I have not
yet updated the spec' to reflect that change.  It's a critical
direction - the realization that you cannot perscribe everything for
everyone - and that instead - you provide normative tools for those
parts people expect the standard to - while giving flexiblity - but in
a known and predictable and re-usable way - for those peices they
traditionally expect to have control over.

The other normative sections are of course tailorable to match the
particular implementors vision and can include only those feartures and
parts that suit (it's just XML markup!). 

What I would expect is that the CAM template would be a base-line one -
that implementors could then refine and extend to their own local
needs.  This I think is inline with the notion of SBS - having a
jump-start kit that people can quickly use by default - and then refine
and extend in practice.  Use of <include> is critical to provide
separation between such base-line templates and local extensions. And
then context is vital for people to understand the use model for each
template.

DW


 asis-open.org/join/