RE: [ubl-psc] New issues from Northern European Subset group

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

Just to clarify:

A receiving party can receive invoices used in different context/BP. If there exists an electronic order (business process
order-to-invoice) created in a procurement system, the invoice is to be delivered there and processed with minimal manual
intervention and perhaps approved for payment without any users involved. If the invoice belongs to a context/BP where it is sent
stand alone, without any electronic references, it should be passed on to a workflow for manual authorization.

Further more, the first invoice might apply schematron rules not required for the second invoice. If the contexts are very
different, there even might be need for two differently restricted schemas.

It is also possible that a supplier sends invoices based on the two contexts, depending on the products or services, to one buyer.
The invoices are transported via ftp/smtp/http to the same end-point. The buyer must be able to seperate the documents for internal
transportation to the correct system.

Depending on how comprehensive the subset is (depending on how many contexts it covers), there can be need for defining subsets of a
subset. So there it is not enough with just stating what subset is used, but also what context of the subset. A stand alone invoice
based on SBS will have different processing requirements than the invoice in business process: order-to-invoice+framework agreement.

Thats why we see a need of the Document Context Identifier, where we can drill down to the right level of granuality:
NES:StandAloneInvoice (North europe=geopolitical + StandAloneInvoice=business process) or SBS:OrderToInvoice (Industry Context or
System capabilities context? + Business Process). 

Regards,
Martin Forsberg


-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: den 12 mars 2006 19:37
To: martin.forsberg@amnis.se
Cc: ubl-psc@lists.oasis-open.org
Subject: Re: [ubl-psc] New issues from Northern European Subset group

Why does the party receiving have to know what subset is used, just as long as the same namespace is adhered to and the document is
valid.
The semantics are all the same. All that changes is that the system knows it will be getting what it can understand. I've answered
my own question though; Yes the receiving system can then know that it won't be getting anything outside of its capability to
process as long as it has a guarantee (by the statement of the subset used) that the subset it wants is actually being applied. Yes,
sorry Martin, I now agree with you fully. It took me a while to get there :-)

I'd just add that we need to put the requirement to use the subset (hence the SBS addition of a urn for the subset) in the trading
partner agreement so it can apply before a message is sent...

***
...since it is the receiver who needs to know 1. that both a certain subset will be used and 2. as Martin points out, that the
subset * has * been used and the sender needs to know 1. and be able to ensure 2.
***

All the best and many thanks,

Steve

On 12/03/06, Martin Forsberg <martin.forsberg@amnis.se> wrote:
> Regardless of subsetting-method, as long as the namespace is not 
> changed, we have to have a BIE that states the context/subset. Even if 
> CPA/BPSS/Envelope can solve the issue, we can't (in Sweden at least) 
> require all public and private parties to use it. We will have to accept that FTP is used between VANs (Value added networks),
ebMS peer to peer and perhaps ws-* when communicating cross border in some cases.
>
> Regards
> Martin Forsberg
>
>
>
> -----Original Message-----
> From: Stephen Green [mailto:stephengreenubl@gmail.com]
> Sent: den 12 mars 2006 19:11
> To: ubl-psc@lists.oasis-open.org
> Subject: Re: [ubl-psc] New issues from Northern European Subset group
>
> Just to mention that with the SBS subset design, the subset document 
> is actually an ordinary UBL document, with the same UBL namespace so 
> these issues don't apply. The issue related to these that does apply 
> is that the sender may wish to signal somehow to the sender that they 
> need the responding document to be compliant with the subset (though it would nonetheless be a vanilla UBL document all the same).
Essentially the naespace is plain old UBL so another mechanism is required for the SBS other than that suggested. The emphasis is
not on the document being semt but on the subset used for the document to be received.
> It may be, importantly, that the document received, which has to be 
> subsetted to be properly understood (by machine), is not the response 
> to a previously sent document (e.g. it might be a notification process document such as invoice) so this entails another mechanism
such as ebXML.
>
> All the best
>
> Steve
>
> On 11/03/06, Martin Forsberg <martin.forsberg@amnis.se> wrote:
> >
> >
> > There is definitely something wrong with the comment-page. I 
> > received a strange error message a couple of hours after posting an 
> > issue. I re-post it here and perhaps Betty can file it in the appropriate list.
> >
> >
> >
> > After looking at Peters issue list I see that my post is partly 
> > covered by one of Peter's. Perhaps my suggestion and description can 
> > give some further information.
> >
> >
> >
> >
> >
> > *******************************************************
> >
> > Name: Martin Forsberg
> > Organization: On behalf of Northern European Subset Group Regarding
> > Specification: UBL2.0
> >
> > In the ongoing work within the Northern European Subset group on 
> > e-procurement an issue has come up that we need to find a solution 
> > for. We are developing and defining a subset for a couple of common 
> > business processes and business rules. The problem, in a nutshell, 
> > is that we can't, by just looking at a document instance, see what 
> > business process/context the instance belongs to. We need to 
> > identify the context by looking at the instance to decide what 
> > business rules (schematron), subset schema and optionally what work flow to apply.
> > The Small Business Subset SC has developed a great method of 
> > defining context specific subsets, but the document instance (e.g. the invoice) doesn't reflect it.
> >
> > Suggested solutions:
> >
> > A new BIE called "Document Context Identifier" of type Identifier is 
> > added on document level (0..1).
> >
> > By adopting the UN/CEFACT context drivers or other suitable keys, an 
> > Identifier can be built.
> >
> > Example:
> > For the Order to Invoice process defined in the northern European 
> > subset, the identifier could be: NES:OrderToInvoice (Geo political 
> > context + Business process context)
> >
> > Without this BIE, the only solution (as we see it) is to define 
> > specific namespaces for every business process and that will give a 
> > very negative impact on interoperability.
> >
> > Best Regards
> > Martin Forsberg
> > SFTI (Single Face To Industry, Sweden)
>
>