[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Unprocessed PRD3 doc/pkg issues for review in this week's TC calls
Hello UBL TC,
Following is an undigested list of documentation/packaging issues for
PRD3. Some of these items have already been dealt with and can be taken
off the list; some are already in process; some need further
explanation; and all of the "live" ones need to be assigned to someone
for further work. We will be going through the list together in this
week's TC calls, beginning with the Pacific call and then revisiting any
items needing further explanation in the Atlantic call.
Jon
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
PRD3 DOCUMENTATION/PACKAGING ISSUES LIST FOR EDITORIAL REVIEW AND DISPOSITION
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
From minutes of the TC meeting in Stockholm:
Walkthrough of UBL 2.1 PRD 2 documentation
We agreed that section 2.1 should be shortened and focus on common
structures such as the document ABIE template structures.
Section 2.2 the text needs to match the overview
diagram. e.g. replenishment, catalogue and quotations
Section 2.8 needs to explain billing methods as a matrix with Primary
Doctype and Discrepency Doctype as the two column headings.
Section 2.8.1. "an Invoice defines the financial consequences of a
business transaction".
Section 2.8.1. should describe invoice calculation model (as per BII)
Section 2.8.4. needs updating to reflect new status messages
Section 2.9. terminology needs updating in text and diagram
Section 2.10. include ' An invoice depends on one or more utility
statements$(B
(B Section 2.11. should be titled 'Payment Notification$(B n(Bot 'Payment$(B
(B Section 2.11.1 Statement of Account is just called Statement
Section A.6. Taxation Rules should be moved to section 2.
Section 2.14 needs to explain price break in terms of
item/location/quantity
Section 2.15 need additions for transport rules.
Remove NDR annex from 2.1 documentation
Action: Arianna - Make above list into an issue for PRD3
Action: Arianna - add 'symbology$(B f(Bor barcodes (etc.) to Item
Identification.
Action: Ken - section 1.2. Normative References $(H c(Bheck the
latest genericode version
[In progress; see gkh 6/20/2011]
Action: Anyone with domain knowledge should review the tables in
2.18 Document Types and 2.19 Party Roles to ensure that these
align and are complete.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
PRD3 issues for discussion in Stockholm (sent to TC 30 May 2011):
PRD3 ISSUES RELATING TO CONTENT
1. Missing document-level signature ASBIE:
UBL-CallForTenders-2.1
UBL-CatalogueRequest-2.1
UBL-CertificateOfOrigin-2.1
UBL-ContractAwardNotice-2.1
UBL-ContractNotice-2.1
UBL-PriorInformationNotice-2.1
2. Requirement from Spain for withholding tax on invoices.
3. Programmatic correction of the ASBIE definitions.
4. Addition of backordering functionality (probably by adding
"backordered" to the code list for line status).
5. Start date for RFQs
http://lists.oasis-open.org/archives/ubl-dev/201104/msg00000.html
http://lists.oasis-open.org/archives/ubl-dev/201104/msg00001.html
http://lists.oasis-open.org/archives/ubl-dev/201104/msg00002.html
http://lists.oasis-open.org/archives/ubl-dev/201104/msg00003.html
From TC minutes of 4/18:
TM: The issue is whether we want to expand RFQ to look like RFP;
the difference is in the formality of the process. An RFQ usually
comes after an RFP and is more specific; an RFQ does not usually
lead into tendering, whereas an RFP does -- but this is different
in different countries.
6. New document types for CatalogueTemplate and PurchaseConditions.
PRD3 ISSUES RELATING TO DOCUMENTATION
1. Specific questions for Stockholm:
a. In 2.15, the first paragraph doesn't mention air; is this
intentional?
b. Most of the process diagrams are lacking labels for source and
destination; should they be supplied? (Note that in several cases
this means distinguishing between two versions of a figure that
would otherwise be identical; see sections 2.13.3.4 through
2.13.3.8.)
c. In section 2.15.5, the name "Transport Progress Status" needs
further discussion.
d. The language in 2.16 needs to reflect a federated distribution
of status (not just the Freight Forwarder).
e. The entry for Transportation Status in 2.18 needs to reflect the
federated distribution of status.
f. The entry for Certificate of Origin in 2.18 needs to amplify the
difference between the UBL COO document type and an actual COO.
The current description does not explain this.
g. The third paragraph in 2.19 mentions "qualifying party," but no
such entry appears on the following table; also, there is no
mention of the party whose role is Transportation Network Manager
or Transport Regulator.
2. Possible reorganization of the hub document (from TM 5/23):
Page 76 Table 1. - how hard would it be to link the document names to
their schemas? we can then remove section 3.1. now we duplicate
(and potential get out of synch.)
Generally can we move the Context/Process descriptions to separate
documents? This means readers get to the thing they most want to see
(the document types and schema links) quicker. We could publish
CPFR, VMI, Procurement, Intermodal Freight, etc as separate
documents.
[Recommend that we deal with these issues in Kars - JB]
3. NDR issues (from GKH 5/22):
a. recorded NDR rule GTD2 states xsd:anyType MUST NOT be
used, yet we use it for extensions; I thought we had covered this
off earlier with text like "except for the extension mechanism,
...." as I see for GXS1 ... I don't know if this is a problem in
NDR a problem transcribing the NDR to this document
b. I see that NDR GXS1 has an unresolved link and out-of-context text
c. I see all NDR DOCx rules, and GXS4, NMS4, NMS5 and possibly others
not listed here, have out-of-context text
d. NDR ELD13 and ELD14 makes references to UBLSubsetID (which hasn't
existed in any of UBL 2) and the pair of rules are not consistent
with the four BBIEs that must follow the extensions element (in
order): UBLVersionID, UBLCustomizationID, UBLProfileID and
UBLProfileExecutionID.
e. NDR GXS11 - xsd:union no longer applicable, especially for code
lists now that code lists are not part of normative UBL
f. NDR GXS14 - we are, in fact, using xsd:processContents="lax" based
on Ken Vaughn's valuable contribution
g. NDR GXS13 is out of order, but I'm not sure it applies as
descriptive rather than its prescriptive nature ... we don't
extend complex types, and our complex types for BBIEs have simple
contents that extend our UDT simple types ... I think we need to
remove this
h. NDR NMC1 sounds just wrong; based on my understanding of "fully
qualified path", it is impossible for NMC1 to be enforced because
of ABIE reuse through ASBIE referencing.
j. NDR SSM18 seems nonsensical - it happens we have one (QDT) but it
isn't that we "must" have one ... this probably original was "must
not" which is no longer true
[Recommend that we turn this list over to the NDR team - JB]
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
From Andrea 6/15/2011:
I'd like to add that both our our profiles, when using XAdES, can be
compliant with the Commission Decision 2011/130/UE that will be in
effect starting Aug 1st.
All European public administration has to support it and an open source
code for verification of documents signed in compliance to this
commission decision will be made available from the EU Commission.
So I think it's worth to add this in our profile to introducing it in
the first sentence of clause 6.3 as follows:
"A compliant implementation of XAdES guarantees wide acceptance in
implementing legal regulations, such as EC Directive [1999/93/EC] and
the Commission Decision [2011/130/UE],"
And then add the following informative reference:
"[2011/130/UE] Commission Decision 2011/130/UE of the European
Commission of 25 February 2011 on establishing minimum requirements for
the cross-border processing of documents signed electronically by
competent authorities under Directive 2006/123/EC of the European
Parliament and of the Council on services in the internal market
[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:01:EN:HTML].";
Neither of which substantively changes the specification (if I
understand it correctly).
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Other documentation or packaging issues:
Prune the DocBook directory structure
Add UML diagrams for individual models
Final disposition of the transport contract issue (PRD2 was a stopgap)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
From minutes of 20110525:
ACTION for PRD3: GKH to fix RNG converter so that the signature
extension will validate.
[In progress; see gkh 6/20/2011]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]