Metamodel example v 3

[Bob Haugen <linkage@interaccess.com>]

This is the third draft of the first ebXML-BP metamodel example.
(Previous drafts were circulated in the metamodel work group.)
Square brackets mark [Metamodel Classes].

Read this example in the context of the ebXML-BP metamodel
diagram, which was sent as an attachment to the list yesterday
by Kasten Reimer.  It should also become available from the
BP group's work page, once that gets set up:
http://www.ebxml.org/working/project_teams/business_process/ 

This example is not "final" in any way.  The intention is for this 
example to develop along with the ebXML project until it is fully
populated with functional test data, and also to be accompanied
by several other examples illustrating different scenarios.

Suggestions for improvement are always welcome.
Issues (example concepts missing from metamodel)
are marked {1} etc where found, and listed at the end.

_Automobile component procurement_

The reasons for starting with this process include:
* it is a supply chain component procurement example,
  instead of the usual office supply purchase;
* the business practices cover most of the metamodel;
* the business practices are well documented 
  by an industry-wide group, AIAG;
* the business practices are similar to supply chain
  relationships in other industries, e.g. appliances and retail.

[Market]:
    Automotive
[Parties]:
    Huge Auto Company (CUST)
    Big Component Supplier (SUP)
    Intermediate Consignee (INTER) {6} {7}
    Shipping Service (SHIP) {6}
    Payment Service [PAY] {6}
[Community]:
    Huge Auto Supply Chain?
[Partners]:
    the same [Parties], as members of the [Community]
    (with some additional properties)
[Partner Roles]:
    Customer: CUST
        CUST Release Issuer {1}
        CUST Ship To {1}
    Supplier: SUP 
        SUP Ship From {1}
    Intermediate Consignee: INTER {6} {7}
    Shipper: SHIP {6}
    Payment Service: PAY {6}

[Process Categories]: (recursive)
    Component Procurement, which includes:
        [Contract] Definition
        [Contract] Formation
        Forecasting, which includes:
            Long-range Forecasts
            Middle-range Forecasts
            Short-range Forecasts
        Delivery Authorization
        Delivery
        Payment

[Business Processes]:
    [Contract] Definition:
        CUST defines and registers [Contract Types] 
        in [Community] repository:
            Negotiated Yearly Component [Contract Type]
            Auctioned Yearly Component [Contract Type]
        Each [Contract Type] defines its [Business Processes]
            for formation and [fulfillment]. {2} {3}
        Contracts may be for component family [Economic Resource Type],
        not specific component until released. {4}

    [Contract] Formation:
        Negotiated [Contract]:  an Offer/Acceptance process pattern.
            CUST sends Component engineering documents
            and pricing agreements [Economic Resource Type info] {3}
            to SUP along with a proposed Yearly [Contract] (the Offer).
            SUP responds either with an Acceptance or a Counter-Offer.
            When agreement is reached, the [Contract] is [executed].
            Each collaboration step is a [Business Transaction].
    Forecasting:  
        Long-range forecasts are just for planning information,
           and are not contractual commitments.
        Middle-range forecasts are [Contracts] 
            authorizing SUP to purchase materials.
        Short-range forecasts are [Contracts]
            authorizing SUP to fabricate components.
        All forecasts are constrained by the Yearly [Contract].
        All forecasts are transmitted using [Business Transactions].
    Delivery Authorization:
        Uses one of the following [Business Processes]:
            Delivery Schedules
            Sequenced Schedules
            Kanbans
            Pickup sheets 
                (supplier stages material for pickup by customer carrier)
        All are transmitted using [Business Transactions].
    Delivery:
        Deliveries are signaled by Advanced Shipment Notifications
            transmitted by [Business Transactions].
        The components shipped are  [Economic Resources].
        The deliveries [fulfill] the Delivery Schedule [Contracts].
        Each ASN consitutes an initiating [Economic Event]:
            an outflow for SUP, an inflow for CUST.
            Since there is no [Dual] event yet, 
                SUP has a claim against CUST for the payment
                (e.g. a Receivable).
        (The details of how and where ownership of the components 
        changes hands are specified in the contract.
        A CUST Receiver may need to be transmitted back to SUP to
        confirm the delivery [Economic Event].)
        Deliveries may involve Intermediate Consignees. {6} {7}
    Payments:
        Payment authorization may use any of the following processes:
            evaluated receipts settlement
            pay on production
            pay to the ASN
            invoices
        Payments are transmitted using [Business Transactions]
            and Secure Flows.
       Payments may be mediated by a Payment Service. {6}
       Payments are  [Economic Resources].
       Each payment constitutes a terminating [Economic Event],
            that resolves the corresponding delivery [Economic Event] 
            [Duality] relationships.
    Almost all transmittals will carry [Business Envelopes] holding
        [Business Documents] including [Information Entities] composed
        of [Fundamental Information Entities].  The [Information Entities]
        include [Contract Types], [Economic Resource Types], [Contracts],
        [Economic Resources], and [Economic Events]. {5}

_Issues_
{1}  Should "Ship To" etc. be modeled as Parties, or Partner Roles, 
      or attributes of Parties?
      If Party, then organizational relationships between Parties
      must be added to the metamodel.
      If Partner Role, what is the Partner?
      If attribute, should this issue be deferred to Common Components?
{2}  Would the business processes specified in Contract Types 
      be [Business Collaboration] definitions?
      Is another Type Object required here?
{3}  It is clear that Contract Types and Contracts are complex objects.
      Likewise Economic Resource Types.
      Should their decomposition be part of the metamodel, or deferred
      to Common Components? 
      (Same issue applies to any other complex objects.)
{4}  Product Families requires adding a recursive relationship among
      Economic Resource Types for family membership.
{5}  The relationships between [Information Entities] and other 
      metamodel classes are not specified in the metamodel.
{6}  It is not clear how to model three-[Partner] relationships.
      These may require including more of the REA ontology
      into the metamodel, to fully represent economic relationships
      between multiple [Partners].
{7}  Intermediate Consignees may require two relationships between
      [Partners] and Economic Resources]: [owns], which exists
      in the metamodel, and "custody", which does not.  
      These relationship distinctions may be needed to determine
      who owns what when.
      If only those two relationships are required, "custody" could
      be explicitly added.
      If more relationships are required, [Partner Role] might be
      usable in this context, otherwise a different [Role] subclass
      may need to be added.

Please send feedback of any kind, especially suggestions
for improvement.

Regards,
Bob Haugen
Thanks for improvements from:
Sally Fuger of Ford
Brian Hayes of Commerce One
Bill McCarthy of Michigan State University