Re: [ubl] Comment (Procurement)

[Tim McGrath <tmcgrath@portcomm.com.au>]

Thanks for keeping us honest and provided a valuable sanity check.

At this stage we want to avoid making changes to schemas that would 
require implementators using PRD2 schemas to change their applications.  
This is what OASIS classifiy as a significant change and as such would 
require a third public review.  We will only do this is the schemas in 
PRD2 are actually broken (not implementable).  This means most content 
changes will be deferred to the next release.

The imminent second public review is only an opportunity for the public 
to comment on changes between PRD1 and PRD2.  New issues will roll into 
post UBL 2.0.  Of these, issues which do not break backward 
compatibility will be candidates for UBL 2.1, issues which break 
backward comatibility will be candidates for discussion in our 
collaboration with UN/CEFACT.

As to where to submit comments, the UBL TC list is fine (or the PSC list 
if you are a member).  As a member of the UBL-TBG1 collaboration team 
you also have the opportunity to express your views in that forum. 

So keep them coming!

I have specific responses to your first issue in-line below...

Stephen Green wrote:

>Hi UBL
>
>I'm not sure to whom I should post this or other similar
>comments; to UBL, to PSC, to Comments or even to TBG1.
>
>I've been looking some more at the SBS and mapping it
>between UBL 1.0 SBS and UBL 2 and am coming across many
>questionable issues such as the following so I'd kind of
>regard these as potential comments from inside the TC
>so how would such be handled. Will there be any scope
>to revise UBL 2 at all or are all changes suggestions 
>to be carried forward to the TBG equivalent(s) of 'UBL 3'?
>
>Here is my issue for procurement:
>OrderLine - there is now just the one OrderLine ASBIE for
>the Order document, OrderResponse and Order Change. This
>presents a particular challenge for subsets of course but
>that's beside the point. The point is it doesn't have an
>ID (neither did it have one in UBL 1.0) and I wonder how
>accurate or otherwise this makes the OrderLineReferences
>if they are refering to an OrderLine which doesn't have
>an ID, presumably by actually referencing the LineItem
>which does have an ID. The LineItem is not the same since
>there could be for one OrderLine both LineItem and some
>kind of SubstituteLineItem so there is a loss of both
>accuracy and precision when refering to an OrderLine by
>referencing the respective LineItem. This is complicated
>even more if LineItem is virtually empty and something
>like even to QuotationLineReference is used for the data.
>Admittedly the LineItem is mandatory as is its ID, so at 
>least there must always be a LineItem/ID for every 
>OrderLine. Just that there are other ID's that might be being
>used instead or as well - a headache perhaps for implementers. 
>
>  
>
As you point out, an OrderLine must have one (and only one) LineItem and 
this LineItem must have one (and only one) ID, the ID of the LineItem is 
effectively the same as the ID of the OrderLine.  The reason we use 
OrderLineReference is so that you are able to identify any other 
LineReferences (such as Catalogue) and DocumentReferences.  Remember 
that although an OrderLine may have one (and only one) LineItem, a 
LineItem does not know which OrderLine refers to it and some LineItems 
are not from Orders.

I suspect the fact other IDs (such as 
BuyerProposedSubstituteLineItem/ID) may be used as well is not 
problematic.  Yes, it could be the same value as the LineItem/ID but it 
is put there to provide for when it differs.  Common sense would suggest 
you wouldn't repeat it.

If you are suggesting we need an ID for OrderLine then this wouldn't 
this make matters worse?

>I've a good few further issues to come so I'd appreciate
>a ruling on how to submit them as a TC member.
>
>All the best   
>
>Stephen Green
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath