[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: SV: SV: SV: [ubl-psc] Meeting in the UBL PSC
Hi, Kees, what you describe is pretty much the process that we have in mind. However, we have also non-itemized products (with that I mean products/services that are not identified by IDs) in scope for the process. This may be used for ordering services or items not previously defined. We could of course offer all item elements as optional (IDs, description, name, item properties) and have business rules that enforce that at least one of them are used. But bottom line is that this requirement comes up when we are syntax binding to UBL, it doesn't come from our process analysis. But I can definitively take this back to the group and see if it is acceptable. The consequence of the order response then being "self-contained" could be useful... /Martin -----Ursprungligt meddelande----- Från: ubl-psc@lists.oasis-open.org [mailto:ubl-psc@lists.oasis-open.org] För Duvekot, Kees Skickat: den 18 november 2012 20:18 Till: ubl-psc@lists.oasis-open.org Ämne: RE: SV: SV: SV: [ubl-psc] Meeting in the UBL PSC Martin, If I understand your situation correctly you have the following process: You receive an UBL Order document from a buying party. You process this UBL Order document in your ERP system You want to respond with a UBL OrderResponse document that only contain changed information. If the Item is NOT changed/substituted you would like to NOT send the Item element in the response. Based on the OrderLineReference the original buying party should know enough to correctly process the UBL OrderResponse message. Correct? If you look at the Item element then none of the elements inside it are mandatory (based on the XSD). So you then say that an empty element can be used, but the NDR says that this should not happen. So that leaves you with 2 options: Try to send the minimum amount of information or violate the NDR. If you look at the "minimum amount of information" option then I would suggest the following: Populate the cac:SellersItemIdentification element with only the ID of the item that you have inside the ERP system that you processed the original order in. Yes, this could be different from what was contained in the original UBL Order message, but then it also has value for the recipient of the response. They now know your (changed) internal item number so they can store that on their order in their ERP system (most ERP systems that I know allow you to store this link between your own internal item number and the sellers external item number). You could even argue that most likely this item number would also appear on the actual items/packaging when you ship the items to the buyer. So they can also use that information when the are going to process the receipt of the items. (the same kind of argument could also be used if you would like to send back the cac:BuyersItemIdentification) So it would require a little more information in the OrderResponse message, but it is all information that is already contained in the ERP system. Kees ________________________________________ Van: ubl-psc@lists.oasis-open.org [ubl-psc@lists.oasis-open.org] namens G. Ken Holman [gkholman@CraneSoftwrights.com] Verzonden: zondag 18 november 2012 19:46 To: ubl-psc@lists.oasis-open.org Onderwerp: Re: SV: SV: SV: [ubl-psc] Meeting in the UBL PSC Then does having a new "OrderLineSimple" with a minimum subset of the full OrderLine, added to "OrderResponseSimple", sound useful? Or do you need almost all of the existing OrderLine available to you? You obviously don't need the full OrderResponse because of the mandatory line item, but that might continue to make sense for other users for a full response. Perhaps your "simpler" requirements are so simple that it might work to augment the "simple" response with what you need. I'm just throwing out these ideas to try and find a way to keep your instances "honest". Please be patient with me. . . . . . . . Ken At 2012-11-18 18:36 +0000, Martin Forsberg wrote: >Hi Ken, > >We are actually using the line information in the order response to >report changes to order lines (like quantity, substitution of item, >price) so we need the Order Response message. >The issue is rather that in cases where we accept/reject/change an >order line, we only report the changed values and refer to the >corresponding order line. We don't restate the item information that >the seller submitted in the order. > >/Martin > >-----Ursprungligt meddelande----- >Från: ubl-psc@lists.oasis-open.org >[mailto:ubl-psc@lists.oasis-open.org] För G. Ken Holman >Skickat: den 18 november 2012 19:18 >Till: ubl-psc@lists.oasis-open.org >Ämne: Re: SV: SV: [ubl-psc] Meeting in the UBL PSC > >Then would it be easier to approach your situation, Martin, using >OrderResponseSimple instead of OrderResponse? That has an order >reference but no line or item information. > >http://docs.oasis-open.org/ubl/prd2-UBL-2.1/mod/summary/reports/UBL-All >Documents-2.1.html#Table_OrderResponseSimple > >Is it possible that if OrderResponseSimple is insufficient as it is >then adding minimal information to that document model might be >preferable to making major changes in the full OrderResponse? > >If not for the long term, could you get by with OrderResponseSimple >until a future UBL 2.2 has addressed this issue? > >Of course I don't know your requirement, but this came to mind as a way >of avoiding violating the empty element rule for your OrderResponse >with empty Item elements. From my outsider perspective it seems that >you don't need the full OrderResponse and you want a simpler version of >it, so then just add missing information to the OrderResponseSimple. > >I hope this is helpful. > >. . . . . . . . . Ken > >At 2012-11-17 09:37 +0000, Martin Forsberg wrote: > >Hi Ken, > > > >I think you pin point the issue in you observations. The creation of > >the order response is done after the order data has been imported and > >acted on in the suppliers ERP system. The instance XML document > >received is no longer available when the order has been processed. > >The supplier is populating the order response with the information > >that is relevant and available in their system. So it is (often) not > >possible to copy the XML from the order. > > > >The mandatory item would then require the supplier to populate the > >Item-elements with information available for him. That would possibly > >mean that slightly different values are used. The buyer would then > >need to evaluate each order response line to see if any > >changes/updates have been done to the item information. > > > >I can definitely appreciate the elegant solution to "mirror/copy" the > >item information from the order onto the order response, but we > >cannot add this extra obstacle to the user community where many > >solutions are dependent on inhouse formats and conversions. > > > >Best regards > >Martin Forsberg > > > >-----Ursprungligt meddelande----- > >Från: ubl-psc@lists.oasis-open.org > >[mailto:ubl-psc@lists.oasis-open.org] För G. Ken Holman > >Skickat: den 16 november 2012 15:18 > >Till: ubl-psc@lists.oasis-open.org > >Ämne: Re: SV: [ubl-psc] Meeting in the UBL PSC > > > >I like Kees's observation that the original order's line item could > >be copied into the order response's line item. > > > >At 2012-11-16 06:45 +0000, Martin Forsberg wrote: > > >The issue occurs in the OrderResponse, where a line doesn't restate > > >the Item, only refer to the order. When accepting an orderline we > > >refer to the order line, use a code saying accept and that's it. > > > >Would that not violate a practice (not a > >principle!) that UBL documents are somewhat self-contained? Is there > >a burden in copying the original order's item details into the order > >response? In my naïveté I would think the original element and all > >its descendants could just be copied. > > > >Then the order response would be more standalone (and useful?) > >allowing someone to act on the items of the order response without > >having to dereference the original order. > > > >Of course there are times when we have to make a reference and not > >copy all of the information, but I think this is a case where the > >order response's copy of the order's line item information is useful > >and could preclude the need to dereference the referenced original order. > > > >I worry about making too many things > >optional. I get the impression interoperability is promoted when all > >parties are obliged to enter more of a minimum of information. > > > >Good luck in your PSC meeting today! > > > >. . . . . . . . . . Ken -- Contact us for world-wide XML consulting and instructor-led training Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-psc-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-psc-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-psc-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-psc-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]