[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] -------- Original Message --------
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]