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