OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] State Alignment


Sally,
 
I agree.  I think it was Anders who first raised this issue over the naming
of iLbing.
 
I think Dale or JJ came up with an alternate name.  I believe renaming it
is clealry the right path.
 
Thanks, DW
----- Original Message -----
Sent: Monday, July 26, 2004 9:20 AM
Subject: Re: [ebxml-bp] State Alignment

David
 
After talking with an attorney friend he reminded me that in our jurisdiction the burden is on the store. That is it is their responsibility to make sure their agent (the cashier) enforces their offer of BOGO. This conversation segued my thinking to the issue of isLegallyBinding.
 
There are nuances in the law in different jurisdictions. Our objective I believe should be to provide the means to enable a contractual arrangement. We should not take on the responsibility of insuring that the transaction is legal or anything that implies that.
 
I am not suggesting the situation I described is big. In fact just the opposite. Its simplicity and commonness makes it easier to see & understand the issue. When that happens more people can participate and propose ideas that will lead to a solution.
 
Sally

David RR Webber <david@drrw.info> wrote:
Sally,
 
Ah yes - but - and its big "but" - in the world of BPSS and ebMS -
there is a thread ID in the envelope header so you know that the
Vit E does not go with the Vit A, but is starting a new transaction.
 
BTW - with BOGOs I always make sure I stack "like items" on
the check-out stand on top of each other.
 
Dare I say - case closed?  ; -)
 
A much more interesting store use case model is reverse
shoplifting - that I first learned from Jeff Duntemann of
PC Techniques fame - but that's another whole story...
 
Basically this is taking something into the store that
they do not sell - and then presenting it at the check out
and paying for it - (works best with magazines).  The fun
does not really start till their backend accounting
tries to reconcile receivables with payables and inventory...
 
DW
----- Original Message -----
Sent: Sunday, July 25, 2004 10:06 PM
Subject: [ebxml-bp] State Alignment

 
Hi all
Just an FYI
 

This morning I went out  to pick up the Sunday paper. And 2 coffees & a muffin. The super market sales for this week included vitamins --buy one get one free. I bought 2 multi-vitamins @ $5.29 and 2 vitamin E @ $6.49.

The stuff was rung up in this order: coffee1, coffee2, muffin, 1 multivitamin, 1 VitaminE, 1 multivitamin, 1 vitamin E, and a newspaper. The fine print of a buy-one get-one deal is that you pay the higher price and get the lower priced item free. So in this transaction I got credit for 2 $5.29 transactions, even though I bought two identical pairs. This transaction cost me $1.20 more than I expected.

The store I purchased this at has an internet channel (Pea Pod). Assuming they use the same checkout software, they have a state alignment problem. Unless they are willing to rely on human intervention.

 

I obviously had a problem which I addressed by going to the customer service counter. I will spare you the details. However a copy of my receipt is available for viewing, or I can provide the details.

 

I would suggest this is a real world approximation of Anders Purchase Order example.

 

No I did not point out that there was a state alignment issue to the guy behind the counter. My pointing out the physical evidence & the obvious inconsistency on the register receipt caused enough confusion.

 

Sally



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]