The top layer of the frameworks contains the Core Business Processes. The objective for this layer is to create a sound architecture and highly extensible objected-oriented implementation for the basic structure and behavior which any application provider delivering a solution in the selected application domains would require. On top of this basic structure and behavior we implement a very limited set of application functionally so that the frameworks will actually do something as they come out of the box. Feedback from the software vendors we have worked with tells us that the combination of CBO and the Core Business Processes will approximate 40% of a typical working application. It is anticipated that the application provider will in all cases extend the frameworks to add their user interface, country and industry specific requirements, business rules, competitive differentiators, and complementary application functions. The extension points at which application providers will add or replace business logic are carefully defined during the frameworks design phase.

The application domains which have been addressed in the initial requirements and design phases for the San Francisco project include business financials (accounts payable, accounts receivable, and general ledger), order management (sales orders and purchase orders), and warehouse management (movement of material into and out of warehouse(s)). Figure 2 shows the framework structure of the Core Business Processes Layer. The initial toolkit for San Francisco contains the General Ledger framework, several Common Business Objects, and the Base infrastructure. Additional frameworks and business objects will be staged overtime, based on customer requirements.

The Accounts Receivable and Accounts Payable Ledger frameworks provide the structure and default behavior related to recording and processing accounts receivable and accounts payable items. An example of one of the business tasks included is Payment, which supports both receiving payments from and creating payments to business partners. Another example is the business task Transfer Item, which supports the transfer of an item to a different account or a different business partner.

The General Ledger framework contains the structure and default behavior related to managing the accounts on the general ledger for a company or hierarchy of companies. Examples of business tasks that are supported include Journaling (create, validate, process, and post GL journals) and Closing (close the books for a GL accounting period and/or year).

The Sales Order Management framework contains the structure and default behavior related to managing quotations, sales orders, and sales order contracts throughout their respective lifecycles. Support is included for business tasks such as determining Pricing and Discounts (maintain, retrieve or calculate sales prices and discounts) and establishing Sales Contracts (create and maintain sales contracts, track customer compliance).

The Purchase Order Management framework contains the structure and default behavior related to creating and managing purchase orders and supply contracts throughout their respective lifecycles. This includes support for business tasks such as establishing Purchase Orders(create, maintain, and confirm purchase orders) and management of Back to Back Orders (manage Purchase Orders directly linked to specific sales orders).

The Order Management framework provides an abstract model and default behavior for those aspects of order processing that are common across several order related processes (eg. sales orders, purchase orders, quotations). For example, the Order Data Interchange is an abstract model for managing order data interchange between several sources. It enables preprocessing to select and normalize data before passing it to where the actual processing will take place.

The Warehouse Management framework supports warehouse logistics tasks. For example, the Internal Replenishment task supports recommendations for stock movements between warehouses. Support for Kit Assembly tracks the stock activity and movements associated with kit assembly. An example of a business object supported is the Product, which includes base product definition, as well as structure and behavior for areas such as product policies, leadtime, and reserves/balances.