2.1 Documentation issues/questions

[Jon Bosak <bosak@pinax.com>]

Hello UBL PSC and TSC,

Please forgive the mixing of issues here; I'm rushing to get this
incomplete list to you in advance of your meetings this week.  I believe
the only issue here for TSC is the last one, 13.c., but it will require
coordination with PSC.

The issues/questions that follow arose from the document revision
currently in progress.  These all came up in the process of reorganizing
the hub document; I have not actually begun an editorial review per se
yet.  There will probably be more issues after I've finished that, and
then I will be asking everyone to carefully review the draft.  I'm not
asking for that level of review yet, just pointing to some issues and
questions.

I've attached a snapshot of the PDF in progress; note the new set of
tables for doctypes in section 3.1.  This PDF is a work in progress and
not intended to serve as more than a reference point for what follows,
so please don't circulate it further.

1. In the descriptions of document types in the new section 3.1,
   information is still missing for 3.1.3, Awarded Notification; 3.1.19,
   Exception Criteria; 3.1.20, Exception Notification; 3.1.21 Forecast;
   3.1.22 Forecast Revision; 3.1.27, Instruction For Returns; 3.1.28,
   Inventory Report; 3.1.30, Item Information Request; 3.1.37,
   Performance History; 3.1.38, Prior Information Notice; 3.1.39,
   Product Activity; 3.1.45, Retail Event; 3.1.49, Stock Availabilty
   Report; and 3.1.54, Trade Item Location Profile.

2. 2.4.2.5 Punchout

   The current draft says:

      Punchout is a technological innovation whereby an Originator is
      able to directly access a Seller’s application from within
      their own procurement application.

   Does "their own procurement application" refer to the Originator or
   the Seller?

3. Continuing under Punchout:

      Originators leave (“punch out” from) their system and
      interact with the Seller’s catalogue to locate and order
      products, while their application transparently gathers pertinent
      information.

   Does "their application" refer to the application of the Originator
   or the application of the Seller?

4. 2.12 CPFR

    The description beginning on page 44 of the current draft says:

      As shown above, the seller and the buyer employ four main
      activities in order to improve the overall performance of the
      supply chain.

    It then goes on to list those four activities, which are Strategy and
    Planning; Demand and Supply Management; Execution; and Analysis.
    However, these four activities bear no relationship to the referenced
    figure, which divides CPFR into three activities called Planning,
    Forecasting, and Replenishment.  The tripartite division in the
    figure fits the later discussion of individual processes (I think),
    but the overview language does not.  Someone with a working knowledge
    of CPFR needs to rework this section.

5. 2.12.1 (CPFR)

   Current language:

      The first step of the CPFR Process continues with the exchange of
      messages containing purchase conditions. (In this initial OASIS
      public review build, these are assumed to be generic purchase
      condition messages. A UBL document type for Purchase Conditions is
      planned for addition in the second public review cycle.)

   Whatever happened with the proposed Purchase Conditions message?  (I
   seem to remember that we decided it wasn't necessary; please
   confirm.)

6. 2.12.3 (just before 2.13)

   Current language:

      During this exception monitoring time, Buyer also waits for a
      possible Termination message indicating the end of the
      collaboration. The Termination message is not mentioned by the
      CPFR guidelines but is included in UBL to indicate the successful
      termination of the CPFR collaboration.

   There is no Termination document type in the set.  Is this missing,
   or is the reference to some form of the Exception Notification?

7. 2.13.2.7

   Current language:

      In the event of a change, either inside an item belonging to the
      CRP catalogue or the relationship of an item to the CRP catalogue,
      information about the change is sent to the retailer.

   I'm changing this to

      In the event of a change, either inside an item belonging to the
      CRP catalogue or the relationship of an item to the CRP catalogue,
      information about the change is sent to the retailer by sending an
      updated Catalogue document.

   Is this correct?  How does the receiving party extract the changes
   from the updated Catalogue?

8. 2.13.3.3

      (Figure 54)

   The diagram shows use of a document type called Change Order Response
   that is not in the UBL schema set.  Is this supposed to be Order
   Change?

9. 3.3.1 Application Response and 3.3.2 Attached Document

   For "processes involved" we have "any" -- but Application Response
   does not appear in all of the process diagrams, and Attached Document
   appears (I think) in none of them.

10. 3.1.6 Catalogue

    "Processes involved" lists only Catalogue, but in fact the doctype is
    used in a number of processes.  Similar comments apply to Despatch
    Advice (which lists only Fulfilment) and several others.

11. A.5 Expected Additions in PRD3

    Current language:

      Two additional document types, CatalogueTemplate and
      PurchaseConditions, are expected to be added to UBL 2.1 following
      this second public review (PRD2), that is, in the third public
      review cycle (PRD3).  Note that the names of these document types
      may change before their inclusion in PRD3.

    What's the status of this?

12. (Throughout)

   The document types Document Status, Document Status Request, Item
   Information Request, and Performance History appear nowhere in the
   process diagrams and in most cases have no apparent users or use.

13. 2.18 Party Roles

    The table needs a complete revision.  Here are three issues I ran
    across in working with the reorganization.

    13.a. A document called Account Response is referenced in the
          entries for Customer Party/Accounting Customer and Supplier
          Party/Accounting Supplier in the table of Party Roles, but no
          such document type exists.

    13.b. The party role for Party/Receiver is described as:

             The party receiving a document. The party receiving a
             Catalogue. Catalogue items may never be ordered, so the
             recipient of the Catalogue is not an Originator or a Buyer.

          The first and second sentences appear to contain some redundancy.

    13.c. The table of Party Roles appears to contain no information
          regarding the parties and document types involved in the
          Intermodal Transport processes.

Attachment: 20111004-opt-UBL-2.1.pdf
Description: Adobe PDF document