ARAP Enterprise Viewpoint

Accounts Receivable/Accounts Payable Facility
( AR/AP Facility )
Enterprise Viewpoint Draft - Part 2
Netaccount AS - June 28, 2001
T. Boyle

PART 1:
1a. Introduction

1. ISO RM-ODP viewpoint approach
2. Purpose of the AR/AP Facility
3. Scope - Five root ledger requirements
4. AR/AP environment and communities
5. Scope Limitations
6. AR/AP Facility Terminology

1b. Functional domains (jobs) within accounting and AR/AP

1. Fiscal Control (Controller)
2. Cash Control / Cash Flow Management (Treasury)
3. Accounts Payable (Accounting)
4. Accounts Receivable (Accounting)
5. Transaction Taxes (Accounting)
6. Financial Reporting (Controller)

PART 2:
2a. Introduction to general use cases

Global AR/AP community
List of enterprise objects (parties and systems)
Community common objectives and implied contract

2b. General cases between Company, internet BSP, trading partner, and AR/AP Facility

1. Setup and metadata mapping:
a. Use case: Company creates a ledger in ARAP Facility
b. Use case: Company creates a ledger within an ARAP BSP
c. Use case: Company edits ledger definition in AR/AP facility
d. Use case: BSP obtains ledger configuration with ARAP facility

2. Reference List Synchronization:

a. Use case: AR/AP facility resolves party and product identifiers to their meaning within a remote BSP
b. Use case: BSP queries AR/AP facility for party, product, etc. record

3. Transaction Execution:

a. Use case: Generalized case of BSP executing a transaction with a TP (trading partner) on behalf of the Company
b. Use case: BSP submits detailed transaction content to AR/AP facility
c. Use case: BSP submits summary transaction to AR/AP facility using control accounts
d. Use case: BSP submits correction of an error to AR/AP facility
e. Use case: Company posts transaction to AR/AP facility
f. Use case: TP requests Credit or Debit adjustment from Company's AR/AP facility
g. Use case: Company posts Credit or Debit memo to his AR/AP facility and notifies TP

4. Queries and Reports:

a. Use case: TP (trading partner) queries Company's AR/AP facility for his account data
b. Use case: BSP queries AR/AP facility for an inventory movement
c. Use case: Company drills back into detail entry of transaction on BSP
d. Use case: Company displays transaction document provided by BSP

2a. Intro to General Cases

This section defines the general use cases or patterns that appear frequently in AR/AP communities, that are reusable prototypes which make other, more specific use cases easier to produce. The vocabulary used is ODP Enterprise Language described in Part 1.

Global AR/AP community

A community is a collection of actors united around a single objective. The global AR/AP community is united by a high-level objective of automation of administration and settlement aspects of their mutual balances, within constraints such as not reducing the amounts collectible on receivables. Communities within all of the general and specific use cases for AR/AP exhibit common behaviors, i.e. an implied contract which we attempt to describe below. This is not prescriptive but rather, deductive and tautological, i.e. if two parties share the objective of reconciling the content of two lists, then they apparently have a willingness that the content of the two lists must be accessible to a software object which identifies omissions or differences between the lists.

List of enterprise objects (parties and systems)

An actors may be a party, a system, hardware or other enterprise object. Enterprise objects are actors when they perform roles in particular communities. The following is a list of enterprise objects which frequently perform roles (i.e appear as Actors) in AR/AP communities.

Actor: ARAP

"ARAP" is defined as any AR/AP Facility. In other words, ARAP is a software object instantiated in a computer having a service interface. Since these are use cases, ARAP will always be shown as an Actor performing a role in a community, such as receiving transaction data or responding to requests for reports. ARAP implements the policies of its owner. In accordance with the OMG RFP, ARAP is a server, a service, without specifying anything further about the nature of its user interface such as a physical screen, keyboard, etc.

Actor: the Company

"Company" is defined as the individual or business entity whose general ledger, AR/AP etc. transactions are maintained in the ARAP. The "Company" Actor is usually an employee or agent, performing a role such as legally binding the Company in purchases or sales. Note there is no systematic requirement that only transactions of the "Company" are contained in the ledger(s) instantiated by a Company. But in these use cases, "Company" is the principle party named as subject in the content of the ledger in the ARAP, i.e. the GL entries in the example usecases are the Company's ledger.

Actor: TP (Trading Partner)

Trading partner is defined as anybody other than the Company, or his own BSP or ARAP. A trading partner is usually but not always, an user signed onto his account in his own BSP, sufficiently authenticated that the Company will read or accept transactions from TP. However, a trading partner may be an unknown or unauthenticated sender of email, or anonymous visitor to a website, from whom some business message is received such as a purchase order, requiring credit check or other verifications before posting any transaction. TP is usually the same party named as reciprocal party (i.e. named as a debtor or creditor in AR or AP). However, in these use cases TP may also be a 3rd party such as an intermediary or settlement agent. This is different from "Company" who is always the subject of the transactions in the ARAP ledger. See 1a4a in part 1 for more discussion of subject-object.

Actor: Application

An Application for purposes of this document, is defined as any business software application owned by the Company, having a user interface, such as a point of sale system, invoicing system, etc. which creates, edits, deletes, reads, etc. business transaction data which is the content in an ARAP, and having an interface to an ARAP. An Application is an enterprise object which enables humans to conduct business with each other, or to enter data to record the transaction agreed between parties who have conducted business.

Actor: BSP

A BSP is an internet Business Service Provider. A BSP is a software application owned by someone other the Company which performs a role or roles in business processes. A BSP's role may be initiated by, or triggered by Company or TP, or another application or BSP. A BSP may act as an agent, or on behalf of, the TP, the Company, or its Owner, or anybody else. But a BSP most frequently appears in these use cases performing roles an agent for the Company, implementing the policies of the Company, under a contract between the Company and the owner of the BSP.

A BSP may serve only the Company, e.g. timesheets. A BSP may further provide a human or service interface to TP enabling them to conclude transactions. A typical BSP maintains an offer such as a webstorefront and waits for TP to record acceptance of the offer. Examples of BSPs which create transactions include:

web storefront selling products or services for the Company,
payment services provider (PSP), executing payments on behalf of a Company,
bill payment provider, paying incoming bills on behalf of an Company,
travel expense data entry site for employees who travel,
time & billing or project website, where the Company creates transaction data for itself,
accounting BSP where the Company creates, edits orders, invoices, payments, accounting adjustments, etc.
payroll service paying salaries and taxes on behalf of the Company, etc.

Examples of BSPs having roles in business processes without creating transactions include catalogs, list repositories, messaging or calendar services, XML transformation services, etc.

Actor: ARAP-Application

A composite object having an Application and an ARAP Facility. When ARAP has a user interface enabling a Company (or its bookkeeper) to view entries, post adjustments, print reports etc. directly, without the use of any other system, the composite object will be called an ARAP-Application.

Actor: ARAP-BSP

A composite object having a BSP and an ARAP Facility. When the ARAP application is owned by anybody other than the Company, this composite object will be called an ARAP-BSP. For purposes of this specification, all ARAP-BSPs are also ARAPs having the native interfaces and behavior of an ARAP as well as a user interface provided by an ARAP-BSP.

AR/AP Community Implied Contract

This community is held together by a common interest in saving time and money in settlement of their mutual balances. Automating these things requires surrendering some of maintaining the freedom to modify your own data that has historically existed. The AR/AP implied contract is as follows.

1. Purpose - The purpose of the AR/AP community is to automate the downstream administration, reconciliation and settlement of AR/AP, making all processing subsequent to Companys' buy/sell or settlement decisions reflect their decision in a fully automatic way without errors or inadvertent or unintended change in their economic position.

2. Sovereignty - Participants agree that there are both rights and obligations involved in successful automation of AR/AP with respect to a particular trading partner. The establishment of an AR/AP relationship is at the discretion of participants, with respect to any reciprocal trading partner or group of trading partners. The agreement to automate AR/AP with any particular trading partner(s) does not imply any loss of sovereignty by the participant. The agreement to exchange AR/AP data with any particular trading partner, does not imply any obligation to exchange AR/AP information with any other party(ies).

3. Informality - The agreement to exchange AR/AP data with any particular trading partner(s) may be formalized in contract, but there is no formal requirement to establish or discontinue any AR/AP relationship. The exchange of information for the purpose of improving efficiency of AR/AP reconciliation and settlement does not imply any strengthening or weakening of the rights or duties of the parties in their dealings beyond whatever rights and obligations were established in the original transaction or other events prior to the exchange of AR/AP data. The implied AR/AP contract means only that the original arithmetic amounts and descriptive language will be used as the starting point for subsequent accounting. Prescribed behaviors in this implied contract apply on a best-effort basis only, and do not confer any economic or legal rights whatsoever on the reciprocal party. Any dispute between two parties automatically cancel this implied contract with respect to each other.

4. Language - Participants agree that whatever language they are using for executing electronic transactions with their trading partners is also sufficient for automating their downstream bookkeeping. AR/AP automation naturally implies a general agreement to use the amounts and terms from the initial transaction as the starting point for downstream AR/AP automation.

5. Debit/Credit memos - Participants agree that whenever they make adjustments or changes to amounts due to or due from reciprocal parties, Credit/Debit memos will be generated and made available to reciprocal parties uniquely identifying the original document and the item being adjusted. Adjustments shall identify the particular quantity of product or service at the same level of aggregation or specification as the original entry.

6. Six shared data elements - Participants agree in principle, that the following six facts are the shared property of both parties at the moment of execution of their mutual money transactions.

   Amount
   Transaction Date/time
   Party Ids
   What was bought/sold
   Due date
   Financing terms such as interest and early payment discounts

Participants surrender the freedom to establish in their payables and receivables systems, different values for these six facts from the values maintained by their trading partner. This is common sense; you cannot expect AR and AP values to be automatically settled if there is a built-in disparity between the two parties' books at date of execution.

7. Continuity - Participants agree that once they enter a dialog with a reciprocal party by sending any transaction or notification, they will continuously send all entries related to that reciprocal party until they terminate the AR/AP relationship. (not just send random subset, omit items etc.)

8. Recordkeeping - Participants agree to listen to reciprocal party transaction documents, as well as signals acknowledging receipt, acceptance, rejection, etc.) and faithfully store them.

9. Level of Grain - Participants agree to maintain copies of all external party transactions in complete detail, at the same level of granularity as existed on the original transaction without aggregation, from the moment of the original transaction until the later of two dates; the date/time agreed in their ledger definition, or the date/time both parties agree that all stages of the business process (i.e. payment of mutual AR/AP items) have been concluded. In other words, they agree to maintain AR/AP records for reference purposes until matters are settled.

10. Responsiveness - Participants agree to respond to reciprocal party requests for copies of all AR/AP items, in order that the reciprocal party can reconcile their mutual AR/AP corresponding with participant's AR/AP.

2b. General Cases between Company, internet BSP, trading partner, and AR/AP Facility

1. Setup and metadata mapping:

a. Use case: Company creates a ledger in an ARAP Facility
Community:


Actor: Company	Actor: ARAP	Actor: Application
as role: owner	as role: system	as role: system

Goal/Postcondition
A new ledger has been created inside the ARAP.
The new ledger contains no transactions.
Company has admin rights to one or more new ledgers in the ARAP Facility owned by the Company.
The new blank ledger(s) implement the initial default ledger definition requested by the Company, i.e. either the internal default of ARAP Facility design i.e. a blank ledger and chart, or alternatively, for example,
- a default ledger definition provided by the Application the Company is using, for example, having default national currency or a vertical industry chart of accounts necessary to work with the Application, or
- a custom ledger definition containing particular ledger structure, chart of accounts, periods, currencies, and other options desired by the Company.

Roles
Company as owner of an ARAP
ARAP as system
Application as system

Preconditions
A standard AR/AP Facility exists and is running in a computer, maintained by a Company.
Company has a software application capable of connecting to the ARAP, such as another Corba financials application.
Company has used the client software application to enter the necessary ledger name, and optionally, prepared a custom ledger definition.

Steps
Optionally, the company composes a custom ledger definition, containing for example, a chart of accounts, etc. using any application or XML editor before starting to create a ledger in ARAP.
Company connects with the ARAP using some piece of software.
Company invokes the function provided in the ARAP for creating one or more new ledgers.
Company supplies the ledger name and other information required to create a ledger(s)
Company executes the function of the Application designed for the purpose of sending these parameters and information to ARAP and invoking the ARAP function to create a ledger(s).

Trigger
The trigger is when a function is executed within the client application such as a clicking on a CREATE button at a GUI, which invokes the "Create Ledger" function on the ARAP Facility.

Main Success Scenario
A new ledger was created by ARAP Facility.
Company's employee logins in successfully upon his first effort using the ARAP using some client application.
Company's application works immediately upon its first effort connecting programmatically, with the ARAP to use ledger interfaces.
The design or implementation of the AR/AP Facility imposed no unnecessary requirement for any technical skill, accounting skill, or expenditure of time or labor by any Company or ARAP owner to get the blank ledger started up.

Extensions
Test Specification
Open Issues

b. Use case: Company creates a ledger within an ARAP BSP:
Community:


Actor: Company	Actor: ARAP-BSP owner
as role: subscriber	as role: publisher

Goal/Postcondition
Company has admin rights to one or more new blank ledgers in ARAP-BSP.
The new blank ledger contains no transactions.
The new blank ledger(s) implement one of two options: the internal default of ARAP Facility design i.e. a blank ledger and chart, or the a ledger definition requested by the Company, such as the following examples.
- a default ledger definition provided by ARAP-BSP for example, having default national currency or a vertical industry chart of accounts, or,
- a custom ledger definition containing particular ledger structure, chart of accounts, periods, currencies, and other options desired by the Company.

Roles
Company as subscriber, creating a new ledger.
ARAP-BSP owner as publisher, creating and granting admin rights to a new ledger.

Preconditions
A BSP satisfying the business and technical etc. requirements of the Company exists.
A standard AR/AP Facility exists, running in a computer, owned by a BSP.
Company wants to start using the ARAP-BSP to maintain a ledger.
A communications channel exists between ARAP-BSP and the Company sufficient to pass administrative control of the ledger from the ARAP-BSP to Company, and exclude unauthorized access, etc.
A user interface such as a browser or dedicated client, is provided by the BSP for the purpose of collecting the ledger name and optionally, the ledger definition from the Company and pushing these data into the BSP's AR/AP Facility.

Steps
Company contacts owner of the ARAP-BSP by some means and establishes the rights to use the BSP, for example, by paying the BSP.
Company connects with the ARAP-BSP as administrator, using some piece of software, for example, a browser, or accounting application provided by the ARAP-BSP.
Company invokes the function provided by the client application ARAP-BSP for creating one or more new ledgers.
Company supplies the ledger name required to create a ledger(s), and other information optionally allowed to create a ledger(s)
Company executes the function on the user interface provided by the ARAP-BSP designed for the purpose of sending these parameters to ARAP and for invoking the ARAP function to create a ledger(s).
ARAP-BSP owner responds by creating one or more new ledgers in the ARAP facility.
ARAP-BSP returns success or failure acknowledgement to its client application inside the BSP
The BSP application hurls an HTML page or other response to the browser or other client operated by the Company.
ARAP-BSP provides Company access to the new ledger(s) in a language or technology appropriate between the immediate ARAP client inside the BSP and that client application owned by the Company, for example, by sending an HTML message providing a company ID, userID and password to the Company's browser.

Trigger
The trigger is when a function is executed within the client application such as a clicking on a CREATE button at a GUI, which invokes the "Create Ledger" function on the ARAP Facility.

Main Success Scenario
Blank ledger was created and provided by ARAP-BSP owner.
Company's employee logins in successfully upon his first effort using the ARAP-BSP.
Company's application works immediately upon its first effort connecting programmatically, with the ARAP.
The design or implementation of OMG compliant AR/AP Facility imposed no unnecessary requirement for any technical skill, accounting skill, or expenditure of time or labor by any Company or ARAP owner to get the blank ledger started up.

Extensions
Test Specification
Open Issues

c. Use case: Company edits a ledger definition in ARAP
Community:


Actor: Company	Actor: ARAP
as role: user	as role: publisher

Goal/Postcondition
The capabilities of ARAP for handling transactions for a particular ledger are defined differently from their definition at the beginning of the configuration session.
- The accounting periods, and/or accounts in the chart of accounts, and/or allowable currencies for an entity's ledger may have been revised.
- The optional data elements that are 1) permitted and/or 2) required in transaction header and entry rows may have been revised.
ARAP is capable of responding to interrogations for the ledger definition by correctly expressing the Company's entire setup, chart of accounts, supported data elements, etc. in an ArapXML ledger definition document to achieve the following business purposes:
- The owner can export the entire structure of the ledger and its associated transactions to another ARAP facility at any time, and
- BSPs or other ARAPs can inquire through a service interface as to what data elements and attribute values this ledger supports, in order to successfully connect with this ledger and submit transactions to it.
ARAP is able to support the Company in five requirements of the root ledger (AR/AP management, cash management, financial statements, tax compliance, and fiscal control.) which are stated objectives of the AR/AP facility.
ARAP is capable of storing accounting transactions in a way that enables reporting on the results of operations and the financial position of the Company in accordance with GAAP.
ARAP is capable of delivering a trial balance in XBRL format, i.e. summed or grouped by XBRL accounting classifications as well as by chart of accounts.
E-Commerce goals:
- the Company is able to accumulate transactions from multiple unrelated BSPs in a single ARAP
- the Company is not limited to conducting business in a single controlled marketplace.
- the Company is not limited to its own customer list, or any other fixed scheme for party, productOrService, location, geographic, and other identifiers.
- the Company can store transactions with party, productOrService, etc. identifiers which are members of any scheme having a URI.
- it is not necessary that a full URI be included with every party or product etc. code in an ARAP facility.
- an author of ARAP transactions can inform the recipient unambiguously of the URI or namespace declaration associated with scheme names or XML namespaces to be applied to identifiers for each dimension in data.
- ARAP ledgers have a standard way of disambiguating identifiers when they have NO namespace qualifiers, or when they have only an alias or namespace prefix.
- any ARAP or BSP emulating an ARAP has an unambiguous way of informing other ARAPs of the namespaces it supports.
- the following sequence is impossible: a BSP interrogates an ARAP for its ledger definition, the ARAP Facility to responds by providing its ledger definition, the BSP submits a transactionSet to the ARAP complying with the ledger definition, i.e. using only valid accounts identifiers, transactions dated within the allowable period(s), and having values only for data elements declared as permitted in the ledger definition, and having data which is valid, i.e. conforming with the standard ARAP schema and specifications for each data element, but the ARAP rejects the transactionSet as invalid for the ledger it is addressed to.

Roles
Company as user of a ledger.
ARAP as publisher, managing and storing ledger information.

Preconditions
Company has admin rights to a ledger, such as a blank ledger or ledgers, sufficient to configure the ledger(s).
Company knows enough about the company to define its fiscal yearend, chart of accounts and any other required setup correctly.
IF the Company wishes to change the structure of the ledger by adding or deleting support for any of the optional element in ARAP then the ledger must have no transactions.
IF the ledger has no transactions then, conversely, the Company may add support for any additional element and/or delete support for any previously existing element in the ARAP for this company.
The design of the ledger definition schema provides a hierarchy of elements sufficiently complete to define precisely every particular behavior that can exist in any ledger in any ARAP that might be different from any other ledger in any ARAP.

The ledger definition schema is also simple and intuitive enough to be understood by most software developers of basic level of skill
and the ledger of the Company, within one message, without ambiguity.

Steps
The way to change the ledger definition of a ledger in an ARAP is to invoke the interface of the ARAP provided for the purpose of modifying the ledger definition, and pass it a valid ledger definition instance containing the desired change, such as adding an account to the chart of accounts, modifying the structure of the ledger, etc. :

Company establishes a connection to ARAP with appropriate access rights, using any application having capability to invoke the maintain-ledger-definition interface of the ARAP.
Company requests the ledger definition of the ledger.
ARAP responds by returning the ledger definition to the application used by the Company.
The Company modifies the ledger definition in the desired way, and sends the revised definition to the ARAP as follows:
IF the revised definition instance contains the entire new ledger definition desired, then, it is sent to the replace-definition interface.
IF the revised definition instance contains only incremental changes, then one of the following two methods is used.
- IF values or parameters are to be added or changed (ie overwritten), then the new values to be inserted or which replace previous parameters are simply included in the instance enclosed in the appropriate tags, and the instance is sent to the update-definition interface.
- IF existing values need to be dropped from the ledger definition then the previously existing values to be dropped are included in the instance enclosed in the appropriate tags, and the instance is sent to the delete-definition interface.

Trigger
Company having composed its desired changes, invokes a user interface on an application connected to the ARAP, causing the application to invoke the appropriate ledger definition modification interface on the ARAP and passing the correctly composed instance containing the ledger definition change.

Main Success Scenario
The Company is able to understand the user interface of the Application interface or BSP that he is using to compose the changes to his ledger definition, and that Application or BSP faithfully invokes the ledger definition interfaces on the ARAP, and returns a success acknowledgement message that results in the Company knowing their step was completed correctly.
The Company is able, immediately, to use the newly implemented change, and any BSP or other application who interrogates the ARAP from that moment in time for the ledger definition of this ledger, will receive a correctly updated ledger definition instance.
No loss of data is possible by use of the interfaces for modification of a ledger definition.
- the following sequence is impossible: a Company invokes the update or delete definition interfaces of an ARAP to modify the ledger definition of a ledger containing transaction data, and the ARAP Facility responds by implementing any change in the ledger definition, including modifications to chart of accounts or other foreign keys in the transaction data, which change the content or the meaning of the information in the ledger (i.e. loss of data.)

Extensions
Test Specification
Open Issues

d. Use case: BSP establishes a ledger configuration with a ledger in ARAP
Community:


Actor: BSP	Actor: ARAP
as role: requester	as role: responder

Goal/Postcondition
BSP achieves a state in which it can compose AR/AP transactions which are valid for a particular ledger in the ARAP without failure.

Roles
BSP as Requester
ARAP as Responder

Preconditions
The ledger in the ARAP has been configured at least up to a state where it is capable of accepting transactions (i.e. it has at least one account in the chart of accounts, has at least one date element on the transaction or entry level, supported data elements, etc. of the Company in XML, in an ArapXML ledger definition document.
The ledger definition is capable of expressing all necessary business integration requirements of the BSP within one message, without ambiguity
BSP is of a type which executes transactions with third parties on behalf of Companys. i.e. not just a search engine, etc.
BSP has a sufficient cognitive ability and data infrastructure to produce all of the associated elements of monetary transactions for both sides of the commercial exchange ie. both the money side, and the offsetting movement such as products/services bought or sold, and other details of the transaction such as VAT or sales taxes sufficient to assemble correct accounting entries.
BSP is capable of maintaining this complete information from the moment of transaction execution until it is successfully handed off to the ARAP.
If the BSP does not maintain transaction data natively in classic double-entry accounting (CDEA) structure, then
either a. BSP is capable of transforming the data from its native format to CDEA format at the time of submitting it to the ARAP, or
b. ARAP is capable of transforming the BSP's native data format into CDEA for posting.
If the BSP does not maintain an interface for drillback into historical transactions, then, it informs the ARAP to ensure drillback is provided by AR/AP.
BSP is capable of understanding the AR/AP ledger definition of the Company's AR/AP sufficiently to perform the limited customization requested in the ledger definition.
The BSP must either have a pre-existing service contract for the same Company as the ARAP subscriber, or, the ARAP must accept submissions of AR/AP information from BSPs other than the Company's BSP. (reciprocal party's BSP)

Steps
BSP connects with the ARAP and invokes the interface requesting the ledger definition of a ledger.
ARAP implements the policy of the Company with respect to giving away the ledger definition to BSP. This may require the BSP to notify the Company by email, or the application of reviews and checks against the BSP or the trading partner initiating the ARAP request inside the BSP.
ARAP delivers the ledger definition to the BSP
The BSP stores the subscriber specific elements such as chart of accounts sufficiently to implement them in all AR/AP transactions submitted for this subscriber.

Trigger
BSP needs to submit transactions to an ARAP

Main Success Scenario
BSP gets sufficient integration data to allow successful submission of transactions to an ARAP
Neither the BSP nor ARAP require manual configuration.

Extensions
Test Specification
Open Issues

2. Reference List Synchronization:

3. Transaction Execution:

a. Generalized case of BSP executing a transaction with a TP (trading partner) on behalf of the Company


Actor: BSP	Actor: TP
as role: executor for the Company	as role: executor for the TP

Goal/Postcondition
A purchase, sale, fulfillment, payment, etc. has been successfully concluded between BSP acting on behalf of Company, and the Company's TP.

Roles
BSP as executor of a transaction
TP as executor of a transaction

Preconditions
Company has a contract with a BSP delegating authority to conclude sales, purchase, etc. with Trading Partners.
Company has defined policies or specific terms to the BSP including prices and the manner and timing of buying, selling, etc.
TP has decided to conclude a purchase, sale etc. (TP wants to do business with the Company, and knows about the BSP i.e. the discovery and negotiation phase of business have been concluded.)

Steps
TP initiates communication with the Company's BSP,
    or in response to communication from the Company, the Company's BSP initiates communication with the TP.
A contract is composed by one actor or the other.
The terms of the contract (monetary amount, consideration, dates, etc.) become available to both parties.
A computer record is captured of the complete list of whatever was committed in both directions in the contract, and both parties' consent to the contract.

Trigger
A TP and a BSP acting on behalf of a Company got to the point in their interaction where a purchase, sale or other commitment exists requiring to be submitted to ARAP.

Main Success Scenario
TP and the Company thru its BSP, were able to conclude a contract, commitment or transaction for a monetary amount, product or service to their mutual satisfaction.   This is a generalized case, where any transaction involving a Company's BSP is successfully concluded.

Extensions
Test Specification
Open Issues

b. Generalized case of BSP submitting detailed transaction content to ARAP


Actor: BSP	Actor: ARAP
as role: submitter	as role: recipient

Goal/Postcondition
A transaction record has been successfully transmitted from a BSP to an ARAP for the correct company, without loss of information.

Roles
BSP as submitter of a transaction
TP as recipient of a transaction

Preconditions
BSP and ARAP have been setup properly as above.
Company has a contract with a BSP delegating authority to conclude sales, purchase, etc. with Trading Partners.
Company has defined policies or specific terms to the BSP including prices and the manner and timing of buying, selling, etc.
TP has decided to conclude a purchase, sale etc. (TP wants to do business with the Company, and knows about the BSP i.e. the discovery and negotiation phase of business have been concluded.)

Steps
TP initiates communication with the Company's BSP,
    or in response to communication from the Company, the Company's BSP initiates communication with the TP.
A contract is composed by one actor or the other.
The terms of the contract (monetary amount, consideration, dates, etc.) become available to both parties.
A computer record is captured of the complete list of whatever was committed in both directions in the contract, and both parties' consent to the contract.

Trigger
A TP and a BSP acting on behalf of a Company got to the point in their interaction where a purchase, sale or other commitment exists requiring to be submitted to ARAP.

Main Success Scenario
TP and the Company thru its BSP, were able to conclude a contract, commitment or transaction for a monetary amount, product or service to their mutual satisfaction.   This is a generalized case, where any transaction involving a Company's BSP is successfully concluded.

Extensions
Test Specification
Open Issues

4. Queries and Reports:

work/HTML scraps

Goal/Postcondition
BSP

Roles
BSP

Preconditions
ARAP

Steps
BSP

Trigger
BSP

Main Success Scenario
BSP

Extensions
Test Specification
Open Issues

CDEA Transaction Pattern:
AR/AP entries of the settlement agent, relieving himself of Debtor's debt:

Ledger

TransactionSet

SettleAgentA

TransactionDate

2001/07/28

Account	Dr/Cr	Amount	Party	EntryDoc	DueDate
AP	D	1100	CreditorCo	DebtorCompanyInc owes CreditorCo.	2001/07/28
AP	C	-1100	SettleAgentB	DebtorCompanyInc owes CreditorCo. This constitutes my promissory note, etc.	2001/07/28

The draft standard chart of accounts (arapXML taxonomy for commerce) is as follows.

Cash
AR
Inventory
Fixed Assets
Accum Depreciation
Other Assets

AP
Tax Payable
Other Liabilities
Intercompany payable/receivable

Capital
Retained earnings

Sales
Other Operating Income
COGS (Cost of Goods Sold)
Salaries/Wages
Goods Purchases
Services Purchases
Other Operating Expense
NonOperating Income/Expense

Note that applying any of these standard account codes to a transaction is completely independent of the debit/credit indicator or the +/- sign applied to the numeric amount. (In ArapXML, positive numbers are debits, and negative numbers are credits respectively.)

ArapXML requires that either the debitOrCredit indicator or +/- sign is applied to every entry line, independently of the normal sign of account codes. The management of signs in reports and query responses to users is a responsibility of report and GUI designers.

LedgerDef   conceptual listing of what will be in it. 
==========================================================
arapFacility
   facilityUri
   facilityLegalName
   facilityPartyRecord (idType+)
   protocols .. etc. 

entity
   entityLegalName
   ledger (idType+)     
   ledgerName
   ledgerUri
   fiscalYearEnd
   openPeriodsFromDate
   openPeriodsToDate
   firstTransactionDate
   minHistoryRetention (date from which ARAP is prohibited from expunging data.)
   maxHistoryRetention (date earlier than which ARAP is prohibited from retaining data.)
   allowDeletion  ( withTrail/ withoutTrail )  -without trail means the ARAP is permitted to delete permanently.
   allowEdit  ( withTrail/ withoutTrail ) -these two parameters may not be changed after a ledger has transactions.
   functionalCurrency
   debitOrCreditIsRequired ( boolean ) (most ledgers will use +/- as d/c indicator)
   
   language
   jurisdiction (idType*) usually includes nation, etc.

relatedCompanies (complexType ~ "companies")
   entityId (idType*)
   ledgerUri
   fiscalYearEnd
   orgStructure  (idType) in other words you have to have a 'scheme' in a document on disk, BSP, registry, etc.)
     
chartOfAccounts
   xbrlTaxonomy
   chartOfAccounts (idType+)  You can either hammer them all in here, or just provide uri?
   chartOfAccountsUri (type uriReference)

arapElementSupported
   party ('required' or 'permitted' or 'notAllowed') (schema: uri)+  just telling the ARAP the meaning of a uri
   productOrService ('required' or 'permitted' or 'notAllowed')
  ...etc. ten other dimensions in the arapXML schema. 
  ...the namespace:value pairs (schema:uri)+  just tell the ARAP the meaning of one or more aliases so 
    that the whole uri doesn't have to be included in every transaction entry line.  Yeah the result is that
    globally, if any goofballs use the same schema name then whoever gets to an ARAP first has the 
    privilege of using its alias unmodified.  The second user of lets say "DUNS" as a scheme name
    can't push it into the ARAP with their own URI, and they have two choices: make up a new scheme
    name or include their whole uri in every entry line to disambiguate the scheme name.

    what this feature means to developers is that every ARAP must maintain a namespace table for
    each dimensions supported within each of the ledgers in the facility.  If you want to use multiple
    global namespaces then, this is logically unavoidable.

arapDateTimeQualifiersSupported
   submitted  ('required' or 'permitted' or 'default' or 'notAllowed')
   posted    (default)  ('required' or 'permitted' or 'notAllowed')
   reversed    ('required' or 'permitted' or 'notAllowed')
   approved        "        "
   paymentDue        "        "
   settled        "        "
   cleared        "        "
   cancelled        "        "

arapAmountQualifiersSupported
   original (default)  ('required' or 'permitted' or 'notAllowed')
   base   ('required' or 'permitted' or 'notAllowed')