OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-psc] [Fwd: [UNCEFACT-TBG17 - 355] Update of the RSM document of the Cross industry invoice]


Dear all,
 
Here are some comments on the reasons why TBG1 created an update of the RSM.
 
The Cefact approach lacks today clear guidelines on how to assemble messages, and this is the back ground reason for Freddy De Vos to send an updated version of the RSM to TBG17 (the RSM contains class diagrams and spread sheets representing the information requirements identified in the BRS). In the New Delhi meeting TBG6 successfully generated schemas (eTendering) and they got the status "Candidate release". TBG1's approach on assembly of messages differs from the TBG6 approach and no Cross Industry Invoice schema was generated by ATG2. The TBG1's RSM is now (the updated version) aligned with the strategy that TBG6 used and this should mean that also Cross Industry Invoice can result in a "Release Candidate". The biggest difference between TBG6's RSM and TBG1's RSM is that all header BBIEs are located in a Header ABIE in TBG6 and in the Cross Industry Invoice they are located directly under the document (like UBL).
 
The discussion on assemblies involves a couple of questions;
* How should the Document assemble ASBIEs and BBIEs?
* Should the Document be allowed to assemble only ASBIEs or also BBIEs (like UBL)?
* What is the Document - is it an ABIE (based on an ACC) or is it a new concept - container or assembly?
* Are Invoice Line, Invoice Payment, Product (Item in UBL), Product Unit (Item Instance in UBL) ABIEs or should they be treated as "containers" not part of the BIE library and not based on ACCs? (The argument for this is that they only relates to the Invoice and/or that they differs to greatly between contexts and therefore need to be more extendable (Product/Product Unit)
* The Containers are supposed to give greater extensibility for industries and other contexts. The steel industry can extend the Product without bother with harmonizing with other industries (through TBG17). That would be necessary if the Product was an ABIE.
 
Some of the above questions have impact on schema and xml instances and some have not. They have a bigger impact on how the Cefact schemas are supposed to be used and also how Cefact internally works with harmonization between TBGs and also between different industry groups that want to extend the containers to meet their requirements.
 
A container seems to be an open type of BIE that can be extended by user groups. The CII only defines the least common denominator (Item identification and Name in case of Product). The rest is up to the user group to define. This differs of course a lot from UBL where we have a library approach and the user group restricts rather than extends. This naturally has an impact on interoperability and also more technical consequences on e.g. use of namespaces. (if I extend a type (in a customization) I will have a problem validating the instance with the standard schemas)
 
To my knowledge, TBG6 only uses assembly/container on document level (to assemble the documents ASBIEs).
 
I don't know if TMG (Cefact's Methodology group) and ATG2 (applied technology group) will accept the TBG6 approach or if there will be changes in the next release. It should however be noted that the current NDR from ATG2 directly supports the TBG6 approach, whereas the use of containers is a new concept that requires amendments to the NDR. Furthermore CEFACT has established a separate project within TMG to define its future Message Assembly Methodology.
 
The above is based on my interpretation of the current situation and there might be new decisions and strategies that I'm not aware of.
 
The consequences of the new RSM on the GAP-analysis should be small. We are working on BRS-level (searching for gaps in business requirements) and only highlight modeling-related gaps if they have an impact on business requirements. If all header BBIEs are located directly under the document or if they are assembled in an Header ABIE, associated from the document, is a small gap compared to other findings. We will need to go through the changes of course at the next three day meeting scheduled next month.
 
The results from the convergence work will be input to a new version of the BRS. So there will be no RSM reflecting our findings until the new BRS is approved.
 
Best regards
Martin Forsberg
SFTI, Single Face To Industry, Sweden


From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: den 25 oktober 2006 03:03
To: ml@tritorr.com
Cc: ubl-psc@lists.oasis-open.org
Subject: [ubl-psc] [Fwd: [UNCEFACT-TBG17 - 355] Update of the RSM document of the Cross industry invoice]

Can you explain how this relates to your convergence work?  Are the results including in this new submission?

-------- Original Message --------
Subject: [UNCEFACT-TBG17 - 355] Update of the RSM document of the Cross industry invoice
Date: Tue, 24 Oct 2006 13:24:59 +0200
From: De Vos Freddy <F.De_Vos@EUROFER.BE>
Reply-To: * * UNCEFACT TBG17 * * <UNCEFACT-TBG17@LISTS.UNECE.ORG>
To: UNCEFACT-TBG17@LISTS.UNECE.ORG


Dear TBG17 members,

After the UN/CEFACT meeting of New Delhi the Bureau and the FMG  decided 
that the XML schema of the Cross Industry Invoice (CII) should be made 
available by the end of October 2006 as agreed at the Un/CEFACT 
Vancouver meeting.  Due to the fact that the TBG1 approach of the ABIEs 
and the XML schema generation is different from the TBG6 approach, and 
the fact that still the CCMA specification is missing, we (ATG2, TBG17 
and TBG1) decided to align the RSM of the CII to the TBG6 approach.  
This will avoid that in the new library there are different approaches 
for the same concepts.

The changes to the new canonical model together with the drafting of new 
candidate core components has taken a lot of days.
Have enclosed the new RSM of the CII.  The RSM document the candidate 
Core Components in chapter ).
Due to the Bureau and FMG decision, may I ask to give priority to the 
harmonization of the new submitted Core Components.

Kind regards,
Freddy


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]