Re: [ubl-dev] Request for Quotation and Order error responses

[Stephen Green <stephengreenubl@gmail.com>]

I sympathise with your disappointment at not finding the
fields you need, Jeremy, in the OrderResponse. I put in
a reminder comment on this to UBL-comment (you're
welcome to make comments / fix requests like you have

done there - though UBL TC asks that it not be used for
questions more appropriate to ubl-dev of course). I say
'reminder' because I had made the same request a long
time back but I'm not sure it got rpeserved so as to get

fixed in UBL 2.1.

I would suggest (like I say I cannot 'recommend' as I 
haven't tried it) using ApplicationResponse for all your
responses unless the trading agreements dictate
otherwise - at least until such changes can be made in

the OrderResponse document type.

Historically there are differences in how documents
respond to other documents which are persisted in
UBL but I agree that the 'tradition' of having a document
called 'OrderResponse' specific to Order but no equivalent

for other responses does show inconsistency. Clearly,
it seems to me, with UBL, this is because there is the
special case of the process of Order whereby traditionally
lines in an order can be substituted in various ways. This

is the main reason for having OrderResponse as a special
document type. Likewise there is another traditional special
case for Order in that it is a legal document which plays a
special role in creation of a contract which requires a kind

of non-repudiation at application level (as well as, perhaps,
at messaging level) such that the Seller signals acceptance
of the order which then starts the creation of a contract.
This is the primary reason for the OrderResponseSimple.

These two document responses tend to be used as 'either/or'
since if the order is not accepted in full (or rejected in full)
with OrderResponseSimple then it is the case that there are
lines which individually need rejecting or substituting. So

OrderResponse is used instead with indication of which
lines need rejecting or substituting. 

You'd might need to check that legally it is acceptable to
accept/party accept/reject an Order with the Application

Response document though.

Best regards


---
Stephen D Green
Document Engineering Services Ltd

2009/7/14 Marzka, Jeremy <JMarzka@kaydon.com>

Any idea why the responses are so inconsistent?

Request for Quotation doesn't have a response document so the only
option is to return a Quotation. The Quotation doesn't provide any
header status information and minimal detail status information.

Orders have 2 response documents. The Order Response Simple makes
perfect sense to me with the Accepted Indicator and Rejection Note
fields but doesn't have the detail I need. The Order Response has the
detail I need but doesn't have the Accepted Indicator and Rejection Note
fields. To me it would also make sense to have the Accepted Indicator
and Rejection Note fields on the detail lines.

I am struggling with this because we have the following common errors
from our trading partners for both Quotations and Orders:

Header Errors:
       - Invalid address id
       - Invalid carrier code
       - Invalid FOB code
       - Mandatory data missing
       - Duplicate order

Line Errors
       - Item mismatch
       - Non-catalog item
       - Non-stocked item
       - Price mismatch

I understand that I could use the Order Response Simple to handle the
header errors, but what about the Request for Quotation header errors?

For the lines does it make sense to set the Line Status Code to an error
and populate a note?

       Line Status Code = Line is Disputed
       Note: Non-stocked item

Is it acceptable to use custom codes for the Line Status Code

       Custom Codes:
               - IM: Item mismatch
               - PM: Price mismatch
               - NC: Non-catalog item
               - NS: Non-stocked item

My goal would be to handle header and line errors for Quotations and
Orders in the same manner.

Ken I like your idea of using an Application Response document for the
Quotation error response and I wonder if that would work for my order
header error handling.

Does anyone have any more ideas?

Thanks
Jeremy

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
Sent: Tuesday, July 14, 2009 9:55 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Request for Quotation and Order error responses

At 2009-07-14 09:24 -0400, Marzka, Jeremy wrote:
>What is the recommended way to handle errors processing Request for
>Quotation and Order error responses?

Again, don't call the below "recommended", but this is what I found
looking in the model.  And I now see that Stephen has already
suggested the use of ApplicationResponse.

>For example how could I respond to a trading partner that the item
>they sent on a Request for Quotation is invalid (ex: We only allow
>stocked items over B2B)?

  <ar:ApplicationResponse>
    <cbc:ID>234</cbc:ID>
    <cbc:Note>We only allow stocked items over B2B</cbc:Note>
    <cac:SenderParty>
      ...
    </cac:SenderParty>
    <cac:ReceiverParty>
      ...
    </cac:ReceiverParty>
    <cac:DocumentResponse>
      <cac:Response>
        <cbc:ReferenceID>Stocking</cbc:Reference>
        <cbc:Description>Stocking problem</cbc:Description>
      </cac:Response>
      <cac:DocumentReference>
        ...
      </cac:DocumentReference>
      <cac:LineResponse>
        <cac:LineReference>
          <cbc:LineID>123</cbc:LineID>
          <cbc:LineStatusCode>Cancelled</cbc:LineStatusCode>
        </cac:LineReference>
        <cac:Response>
          <cbc:ReferenceID>123</cbc:ReferenceID>
          <cbc:Description>Out of stock</cbc:Description>
        </cac:Response>
      </cac:LineResponse>
    </cac:DocumentResponse>
  </ar:ApplicationResponse>

>How could I respond to a trading partner that the specified
>CustomerAssignedAccountID under the BuyerParty on an Order is invalid?

  <ar:ApplicationResponse>
    <cbc:ID>234</cbc:ID>
    <cbc:Note>We only allow stocked items over B2B</cbc:Note>
    <cac:SenderParty>
      ...
    </cac:SenderParty>
    <cac:ReceiverParty>
      ...
    </cac:ReceiverParty>
    <cac:DocumentResponse>
      <cac:Response>
        <cbc:ReferenceID>CustomerAssignedAccountID</cbc:Reference>
        <cbc:Description>Invalid account identifier</cbc:Description>
      </cac:Response>
      <cac:DocumentReference>
        ...
      </cac:DocumentReference>
    </cac:DocumentResponse>
  </ar:ApplicationResponse>

>I have read on this forum that I should use OrderResponseSimple for
>any processing errors but what if 1 out of 10 lines have an error?
>Is there anywhere to specify a message like "Non-stocked item" at
>the line level?

I would think that OrderResponse would be what you would use:

  <or:OrderResponse>
    <cac:OrderLine>
      <cbc:Note>Non-stocked item</cbc:Note>
      <cac:LineItem>
        <cbc:ID>123</cbc:ID>
        <cbc:Quantity>5</cbc:Quantity>
        <cac:Item>
          <cbc:Description>Gizmo</cbc:Description>
        </cac:Item>
      </cac:LineItem>
      <cac:SellerSubstitutedLineItem>
        <cbc:ID>123</cbc:ID>
        <cbc:Quantity>0</cbc:Quantity>
        <cac:Item>
          <cbc:Description>Gizmo</cbc:Description>
        </cac:Item>
      </cac:SellerSubstitutedLineItem>
    </cac:OrderLine>
  </or:OrderResponse>

I hope this helps.  And I hope it solicits critiques from other list
members.

. . . . . . . . . . . . . . . . Ken

--
XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org





---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org