Re: [ebxml-bp] [ebBP] 7/29/2004: WI-39 re: Acceptance Ack [RSD]

["Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>]

Sorry for my late pitch in.

There was discussion that Business Signals should replace OAGI ConfirmBOD
when Business Protocol is used. In IV&I a typical scenario would consist of
SyncQuantityOnHand (SyncQOH), AdvanceShipNotice (ASN), and DeliveryReceipt
(DR). In the first phase of POC, only SyncQOH is used, followed with
ConfirmBOD (note synchronous SOAP is used to signal any transport error).
The ConfirmBOD is used to indicate whether application successfully
processes the SyncQOH. It can have a value of Success, Fail, and Partial
Success (e.g., some line items are succeesfully updated some are not). I
wonder if BPSS is used whether Business Signals should (be able to) replace
the ConfirmBOD or ConfirmBOD should still stay. In the first case, one then
can model the ASN as a Business Response for the SyncQOH (in a single BTA)
and a DR in another BTA as an info broadcast. each of the BOD above. In the
later case, the ConfirmBOD is a response for each of the BODs in 3 separate
BTAs.

In my view, BPSS signals should be able to replace the ConfirmBOD. Hence, I
think that the Acceptance Ack should mean that the application has
successfully process the request. It is making a decision or awaiting
further information before sending the business response.

Well, after I wrote the paragraph above I see a problem as SyncQOH can
occurs many times before an ASN occurs (for Min/Max it occurs when inventory
falls close or below the Min).....so we may need to model SyncQOH and ASN in
separate BTAs.

Well, some 2 cents from me.

- serm




----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Dale Moberg" <dmoberg@cyclonecommerce.com>
Cc: <anderst@toolsmiths.se>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Friday, July 30, 2004 4:34 PM
Subject: Re: [ebxml-bp] [ebBP] 7/29/2004: WI-39 re: Acceptance Ack [RSD]


>
> >Moberg: Maybe we should try to tie terminology to the kind of state
alignment
> >that is attained through the use of these formerly-known-as-Acceptance
signals.
> >Maybe JJ or John Y. could come up with terminology satifactory to all?
> >
> mm1: This was my original question on what new names could apply. Thanks.
>
> >>Please leave UNCITRAL out of the discussion since it has nothing to do
> >>with BT and its current construction.
> >>
> >>
> >mm1: I believe Dale meant that the guiding principles we have
> >historically looked to in the UMM map to legal recommendations [1] (and
> >hopefully are in line with UNCITRAL). Are you saying that the BT is not
> >in line with legal and business ecommerce constructs?  Can you please
> >explain?
> >
> >[1] UN Recommendations 26 and 31.
> >
> >Dale> I used UNCITRAL because I, perhaps mistakenly, thought it to be the
origin of some of the BT patterns that BPSS was calling out. The signal
stuff is, of course, part of BPSS state alignment augmentation for the eb
part of ebXML. Anders is right that it has nothing to do with UNCITRAL (as
far as I know-- maybe John Yunker could provide background here). However,
in Martin's current approach to patterns and signals (from 3 !! f2fs ago in
SantaClara), each pattern has its signal envelopes defined _within the
pattern.
> >
> UNECE coordinates with UNCITRAL (per web site) and CEFACT is part of the
> former. The UMM maps to UN (legal) recommendations 26 and 31 and UMM
> defines the patterns that include 'acknowledgment of receipt' and
> 'acknowledgment of acceptance.' The signals are expressions of these two
> acknowledgments so the signal and pattern association is appropriate. I
> am a layman and would welcome some clarification of what hiearchy needs
> to be understood to know the guiding principle. Thanks.
>
>
>
>
>
>