RE: [ubl-psc] UBL 2.0 Update proposals

["Martin Forsberg" <martin.forsberg@ecru.se>]

The cardinality of line is 0..n so it can't be done in the current version

/Martin

> -----Original Message-----
> From: Roberto Cisternino [mailto:roberto@javest.com]
> Sent: den 23 november 2007 12:20
> To: Martin Forsberg
> Cc: 'Peter Borresen'; ubl-psc@lists.oasis-open.org
> Subject: RE: [ubl-psc] UBL 2.0 Update proposals
> 
> Hello,
> can the OrderResponse without line items interpreted as a full
> acceptance ?
> 
> It will be just an ACK.
> 
> Roberto Cisternino
> 
> > I agree that it is unclear how to use an OrderResponse as a full
> > acceptance,
> > but I think it's because the lack of some code values or
> alternatively a
> > new
> > indicator. I don't agree that OrderResponseSimple should be the only
> way
> > of
> > giving full acceptance/rejection.
> >
> > I don't think it is a good idea to change message type just because
> you
> > accept 10 of 10 lines, and another message type when accepting 9 of
> 10
> > lines. So by giving the OrderResponse ability to clearly indicate
> full
> > acceptance (on document level and/or on each line) UBL would align
> better
> > to
> > both existing systems and to existing standards like EDIFACT. That
> would
> > also make conversion easier since you don't have to change message
> type if
> > 10 out of 10 lines in the EDIFACT message are accepted.
> >
> > I see the two message types (OrderResponse/OrderResponseSimple) as
> > responses
> > used in different types of order processes.
> >
> > /Martin Forsberg
> > Ecru Consulting
> >
> >> -----Original Message-----
> >> From: Peter Borresen [mailto:plb@itst.dk]
> >> Sent: den 23 november 2007 11:43
> >> To: Martin Forsberg; ubl-psc@lists.oasis-open.org
> >> Subject: SV: [ubl-psc] UBL 2.0 Update proposals
> >>
> >> Martin,
> >>
> >> I am not sure you agree.
> >>
> >> I said there are two ways of doing it:
> >>
> >> 1) A generic OrderResponse document that can be used both as
> response
> >> the
> >> lines and the order as a whole
> >> 2) Two seperate documents, one for each purposes.
> >>
> >> I think you go for 1, where I think 2 is the most simple solution.
> >>
> >> If you go for number, you must specify business rules that handles
> the
> >> conflics I mentioned below.
> >>
> >> /Peter
> >>
> >> -----Oprindelig meddelelse-----
> >> Fra: Martin Forsberg [mailto:martin.forsberg@ecru.se]
> >> Sendt: 22. november 2007 15:59
> >> Til: Peter Borresen; ubl-psc@lists.oasis-open.org
> >> Emne: RE: [ubl-psc] UBL 2.0 Update proposals
> >>
> >> Peter,
> >>
> >> I agree - there is something missing in OrderResponse to make a
> clear
> >> statement whether you accept or not. In EDIFACT and in the future
> >> cefact
> >> order, you have a response type on header-level (document level) and
> on
> >> line
> >> level where the status is given.
> >>
> >> /Martin
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Peter Borresen [mailto:plb@itst.dk]
> >> > Sent: den 22 november 2007 15:08
> >> > To: Martin Forsberg; ubl-psc@lists.oasis-open.org
> >> > Subject: SV: [ubl-psc] UBL 2.0 Update proposals
> >> >
> >> > Hi Martin
> >> >
> >> > Then, maybe you can help me anwering a question: How can you tell
> >> > whether nothing has changed from the Order to the OrderRepesponse?
> >> > When are two instances of theese to different messages alike?
> >> >
> >> > An acknowledging ordering flow must end with an
> OrderResponseSimple.
> >> > To my mind OrderResponseSimple is not a simple version of
> >> > orderResponse, but a document, that ends the ordering process.
> >> >
> >> > Putting an AcceptIndication into OrderResponse will redefine both
> >> > documents.
> >> > I am not sure we agreed on this in NES (becaused we sticked to the
> >> > orderResponseSimple), but I am sure that I managed to convince
> Mark
> >> > that There was a need for OrderResponseSimple, or orderResponse
> >> > Stupid, as he called it.
> >> >
> >> > Let's say that we have an AcceptIndicator in OrderReponse. If that
> >> one
> >> > is set to true and one of the lines has changed. What does it
> means?
> >> > Or opposite if the AcceptIndicator is false and nothing has
> changed?
> >> > Accepting or rejecting the Order as a whole is a diffenrent scope
> >> than
> >> > the OrderResponse, which really is an OrderLineRespose Sample.
> >> >
> >> > Kind regards
> >> >
> >> > Peter
> >> >
> >> > -----Oprindelig meddelelse-----
> >> > Fra: Martin Forsberg [mailto:martin.forsberg@ecru.se]
> >> > Sendt: 22. november 2007 14:23
> >> > Til: Peter Borresen; 'Tim McGrath'; ubl-psc@lists.oasis-open.org
> >> > Emne: RE: [ubl-psc] UBL 2.0 Update proposals
> >> >
> >> > Hi Peter,
> >> >
> >> > I must disagree with your disagreement :)
> >> >
> >> > *****
> >> > PLB: I disagree with this because, it conflicts with the use of
> >> > OrderResponse. OrderReponse is allways used when something in the
> >> > order is not accepted, otherwise the OrderResponseSimple
> (OrderAccept
> >> > + OrderReject´as one document) is used.
> >> > *****
> >> >
> >> > You can make a full accept with OrderResponse (no changes on any
> >> lines
> >> > or accept with changes). If the seller substitutes an item, based
> on
> >> > the buyers proposal, then I would say the OrderResponse is an
> >> > acceptance. Or does it say somewhere that only OrderResponseSimple
> >> can
> >> > be used for full accept/reject? I know we've had this discussionen
> in
> >> > NES, but I can't remember the outcome.
> >> >
> >> > /Martin
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > To unsubscribe from this mail list, you must leave the OASIS TC
> that
> >> > generates this mail.  You may a link to this group and all your
> TCs
> >> in
> >> > OASIS
> >> > at:
> >> > https://www.oasis-
> >> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs
> in
> > OASIS
> > at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> 
> 
> --
> UBL ITLSC
> co-chair
> Roberto Cisternino