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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Minutes of Pacific UBL TC call 14 December 2004


MINUTES OF PACIFIC UBL TC MEETING
00H30 - 02H30 UTC TUESDAY 14 DECEMBER 2004
   16h30 - 18h30 Mon San Francisco
   19h30 - 21h30 Mon Washington
   08h30 - 10h30 Tue Hong Kong, Singapore, Perth, Beijing
   09h30 - 11h30 Tue Seoul, Tokyo
   11h30 - 13h30 Tue Sydney
   #############################################
   STANDING INFORMATION FOR UBL CONFERENCE CALLS
   U.S. domestic toll-free number: (866)839-8145
   Int. access/caller paid number: (865)524-6352
   Access code: 5705229
   #############################################

ATTENDANCE

   Jon Bosak (chair)
   Micah Dubinko
   Tim McGrath
   Betty Harvey
   Sylvia Webb

STANDING ITEMS

   Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm)

      TimM: William Chan has questions about hosting the meeting
      in Beijing.

      JonB to follow up with William, copy to Tim.

   Liaison reports (if any)

      SylviaW: The Indirect Tax WG of the Tax XML TC has completed
      the first draft of a candidate reference model (regarding
      tax information in messages between the participants
      involved in most business transactions).  The next step is
      to prepare a UBL data model and schema.  After internal
      review, this will be submitted to UBL directly in EF, with
      spreadsheets produced from the EF model.  The goal is to
      discuss this in Sydney the first week in February.  The WG
      is aware of our deadlines.

   Subcommittee reports (if any)

      None.

   Team reports (if any)

      See above.

ISSUES FOR DISCUSSION THIS MEETING

   BEA objection to UBL 1.0 NDR standardization

      http://lists.oasis-open.org/archives/voting/200412/msg00000.html
      http://lists.oasis-open.org/archives/voting/200412/msg00001.html

   Background for above

      http://lists.oasis-open.org/archives/ubl-comment/200410/msg00000.html
      http://lists.oasis-open.org/archives/ubl-comment/200410/msg00001.html

   Agreed that this seems to be taking care of itself (see further
   comments posted in the thread linked above).  The negative vote
   will indeed mean that we have to go through a pro forma
   decision process after the OASIS vote for standardization is
   complete in January.

UBL 1.1 CONTENT WORK

   Agreed that TimM will serve as the discussion leader for these
   content-related work sessions.

   We reviewed the items on the worklist (note that they have
   since been reordered in the spreadsheet following this
   discussion).

      Party types: raises a basic philosophical issue about the
      extent to which UBL will be usable out of the box... This
      issue will require much discussion.

      Inspection date: The question is, how do we deal with adding
      things to UBL structures (regardless of whether we think
      this item is sufficiently general to be added to the
      library).  We have to provide a methodology for adding
      it....  Inspection date applies to the item level of an
      invoice; every item must have a date at which it was
      certified as being acceptable.  This is very common in
      manufacturing, but not commonly put on the invoice if
      inspection dates have been entered on other documents such
      as the manifest.  We need to have the definition of
      Inspection Date to ascertain whether this is the same thing
      we typically find in manufacturing.

      Proposals from Sweden: See the document included in the
      first message from Anders Tell; the list of proposed
      additions begins on p. 3.  We note that in addition to the
      question of what to put in the base set is the question of
      what to tell people to do in cases like this if we decide to
      leave the items out of the base set (i.e., how to extend the
      base set).  Probably most things added will be optional, and
      we need to tell people how exactly to make an optional thing
      mandatory for a given context.  It's also possible that we
      will accept the requirements implied by a request like this
      but will decide to implement the solution differently.

      StephenG's request for profile codes: We seem to remember
      that we discussed this earlier in the TC and decided that
      the profile info should be in a standard header.  Unless we
      hear differently, we're going to remove this one from the
      worklist.

      Invoice type codes: The underlying question is how we create
      a document like a credit note or any other new UBL document.
      This one relates back to party type, and we need to check
      against the requests from Sweden to see whether the same
      need is expressed there.  This item raises two issues: (1)
      How do you produce a credit note and (2) is this solution
      (to simply add type codes) the right way to do it.  We need
      to be very careful about adding a code to circumvent the
      creation of new doc type.

      Certificate of Origin: This is explicitly a new doc type.
      Note that the document is actually the CO application, not
      the CO itself (which is a formal document issued by the
      government); so it has info about the applicants and the
      issuing authority as well.  The CO was created as part of
      the APEC project by Crimson Logic for the government of
      Singapore.  They already developed a web form for this and
      now want a messaging version.  TimM is dealing with CL on
      this.  They have identified the library structures that need
      to be added and the ones that can be reused.  This is truly
      an extension of UBL that gets us into international trade.
      Target is early January; it's still at the white board
      stage.

      Digital signatures: This is described incorrectly in the
      (October) worklist.  The requirement is not for additional
      functionality but just for metadata relating to the method
      used to sign an application.  To be folded into the CO work
      item.

      Tax info: Indirect taxation is one of three projects in the
      OASIS Tax XML TC, the other two being the certificate of
      residence and the inclusion of XBRL data.  The submission
      for indirect taxation will be in to us by the April
      deadline.  We need to see the proposal relating to XBRL data
      before we can figure out how best to deal with it.

   Overall, it appears that the content items to be resolved fall
   into two groups: those that relate to specific business
   processes (invoicing, taxation, international trade) for which
   we need to provide support in the UBL data model, and those
   that raise more general questions about modeling methodology.
   [See the revised worklist for new groupings that reflect this
   division.]

   Agreed that we should attack the data model first and then work
   on the more general questions after the business requirements
   are clear.  We will start with the items relating to invoicing
   while CO and taxation are being worked on outside the TC.  If
   everything goes according to plan, we will be done with the
   invoice-related items just as COML is coming in mid-January and
   then do taxation in mid-February following the Tax XML meeting
   in Sydney.

   Agreed that we will meet 2004.12.20/21, skip 2004.12.27/28 and
   2005.01.03/04, and resume meeting 2005.01.10/11.

   BettyH to corral the invoice requests from Sweden plus
   inspection date into one document for delivery by Monday
   morning.

   JonB to ask the xml-dev list for input.



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