Providing accounting software application as enterprise services

Abstract

Methods and apparatus, including systems and computer program products, for a services architecture design that provides enterprise services having accounting functionality at the level of an enterprise application. The design includes a set of service operations, process components, and optionally deployment units. Suitable business objects are also described.

Description

BACKGROUND

This specification relates to data processing systems implemented on computers, and more particular to data processing systems providing services in the nature of web services.

Enterprise software systems are generally large and complex. Such systems can require many different components, distributed across many different hardware platforms, possibly in several different geographical locations. Thus, the architecture of a large software application, i.e., what its components are and how they fit together, is an important aspect of its design for a successful implementation.

Web services are one technology for making the functionality of software applications available to other software, including other applications. A web service is a standards-based way of encapsulating the functionality of an application that other applications can locate and access. A service-oriented architecture is a distributed software model within which functionality is defined as independent web services. Within a service-oriented architecture, web services can be used in defined sequences according to business logic to form applications that enable business processes.

SUMMARY

This specification describes a services architecture design that provides enterprise services having accounting functionality at the level of an enterprise application. Enterprise services are web services that have an enterprise-level business value.

In its various aspects, the invention can be embodied in systems, methods, and computer program products. For example, a system in one embodiment implements a services architecture design that provides enterprise services having accounting functionality at the level of an enterprise application. The design includes a set of service operations, process components, and optionally deployment units. Suitable business objects are also described.

The subject matter described in this specification can be implemented to realize one or more of the following advantages. Effective use is made of process components as units of software reuse, to provide a design that can be implemented reliably in a cost effective way. Effective use is made of deployment units, each of which is deployable on a separate computer hardware platform independent of every other deployment unit, to provide a scalable design. Service interfaces of the process components define a pair-wise interaction between pairs of process components that are in different deployment units in a scalable way.

Details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and in the description below. Further features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A, 1B, 1C, and 1D collectively illustrate a high-level view of a software architectural design and implementation of a suite enterprise software services having accounting functionality.

FIGS. 2A, 2B and 2C are block diagrams collectively showing a project processing process component.

FIGS. 3A, 3B, 3C, 3D and 3E are block diagrams collectively showing an accounting process component.

FIG. 4 is a block diagram of a costing process component.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIGS. 1A, 1B, 1C, and 1D collectively illustrate a high-level view of a software architectural design, and of application software implementations of the design, that provides a suite of enterprise service operations, which can be organized into interfaces, having accounting application functionality.

The elements of the architecture include the business object, the process component, the service operation (or simply, the operation), the service interface, the message, and the deployment unit. The elements can also include process agents and reuse service components. These will be generally described below.

In one implementation, the software is implemented to be deployed on an application platform that includes a foundation layer that contains all fundamental entities that can used from multiple deployment units. These entities can be process components, business objects or reuse service components. A reuse service component is a piece of software that is reused in different transactions. A reuse service component is used by its defined interfaces, which can be, e.g., local APIs (Application Programming Interfaces) or service interfaces.

The architectural design is a specification of a computer software application, and elements of the architectural design can be implemented to realize a software application that implements enterprise application service interfaces. The elements of the architecture are at times described in this specification as being contained or included in other elements; for example, a process component is described as being contained in a deployment unit. It should be understood, however, that such operational inclusion can be realized in a variety of ways and is not limited to a physical inclusion of the entirety of one element in another.

The architectural elements include the business object. A business object is a representation of a type of a uniquely identifiable business entity (an object instance) described by a structural model. Processes operate on business objects.

A business object represents a specific view on some well-defined business content. A business object represents content, and instances of business objects include content, which a typical business user would expect and understand with little explanation. Whether an object as a type or an instance of an object is intended by the term is generally clear from the context, so the distinction will be made explicitly only when necessary. Properly implemented, business objects are implemented free of redundancies.

Business objects are further categorized as business process objects, master data objects, mass data run objects, dependent objects, and transformed objects. A master data object is an object that encapsulates master data (i.e., data that is valid for a period of time). A business process object, which is the kind of business object generally found in a process component, is an object that encapsulates transactional data (i.e., data that is valid for a point in time). A mass data run object is an application object that executes an algorithm for a particular mass data run. An instance of a mass data run object contains a particular set of selections and parameters. A mass data run object implements an algorithm that modifies, manages, and/or processes a large amount of data in multiple transactions, possibly but not necessarily with parallel processing. A dependent object is a business object used as a reuse part in another business object. A dependent object represents a concept that cannot stand by itself from a business point of view. Instances of dependent objects only occur in the context of a non-dependent business object. A transformed object is a transformation of multiple business objects for a well-defined purpose. It transforms the structure of multiple business objects into a common structure. A transformed object does not have own persistency.

The architectural elements also include the process component. A process component is a software package that realizes a business process and generally exposes its functionality as services. The functionality contains business transactions. A process component contains one or more semantically related business objects. Any business object belongs to no more than one process component.

Process components are modular and context-independent. That they are context-independent means that a process component is not specific to any specific application and is reusable. The process component is the smallest (most granular) element of reuse in the architecture.

The architectural elements also include the operation. An operation belongs to exactly one process component. A process component generally has multiple operations. Operations can be synchronous or asynchronous, corresponding to synchronous or asynchronous process agents, which will be described below. An operation is the smallest, separately-callable function, described by a set of data types used as input, output, and fault parameters, or some combination of them, serving as a signature. For convenience in supporting use of the operations supported by a system implementing elements of the design, such a system can optionally include a repository of service descriptions that includes a standards-based description of each of the supported service operations.

The architectural elements also include the service interface, which may be referred to simply as an interface. An interface is a named group of operations. Each operation belongs to exactly one interface. An interface belongs to exactly one process component. A process component might contain multiple interfaces. In one implementation, an interface contains only inbound or outbound operations, but not a mixture of both. One interface can contain both synchronous and asynchronous operations. All operations of the same type (either inbound or outbound) which belong to the same message choreography will preferably belong to the same interface. Thus, generally, all outbound operations to the same other process component are in one interface.

The architectural elements also include the message. Operations transmit and receive messages. Any convenient messaging infrastructure can be used. A message is information conveyed from one process component instance to another, with the expectation that activity will ensue. An operation can use multiple message types for inbound, outbound, or error messages. When two process components are in different deployment units, invocation of an operation of one process component by the other process component is accomplished by an operation on the other process component sending a message to the first process component.

The architectural elements also include the process agent. Process agents do business processing that involves the sending or receiving of messages. Each operation will generally have at least one associated process agent. A process agent can be associated with one or more operations. Process agents can be either inbound or outbound, and either synchronous or asynchronous.

Asynchronous outbound process agents are called after a business object changes, e.g., after a create, update, or delete of a business object instance.

Synchronous outbound process agents are generally triggered directly by a business object.

An output process agent will generally perform some processing of the data of the business object instance whose change triggered the event. An outbound agent triggers subsequent business process steps by sending messages using well-defined outbound services to another process component, which generally will be in another deployment unit, or to an external system. An outbound process agent is linked to the one business object that triggers the agent, but it is sent not to another business object but rather to another process component. Thus, the outbound process agent can be implemented without knowledge of the exact business object design of the recipient process component.

Inbound process agents are called after a message has been received. Inbound process agents are used for the inbound part of a message-based communication. An inbound process agent starts the execution of the business process step requested in a message by creating or updating one or multiple business object instances. An inbound process agent is not the agent of a business object but of its process component. An inbound process agent can act on multiple business objects in a process component.

Synchronous agents are used when a process component requires a more or less immediate response from another process component, and is waiting for that response to continue its work.

Operations and process components are described in this specification in terms of process agents. However, in alternative implementations, process components and operations can be implemented without use of agents using other conventional techniques to perform the functions described in this specification.

The architectural elements also include the deployment unit. A deployment unit includes one or more process components and, optionally, one or more business objects, that are deployed together on a single computer system platform. Conversely, separate deployment units can be deployed on separate physical computing systems. For this reason, a deployment unit boundary defines the limits of an application-defined transaction, i.e., a set of actions that have the ACID properties of atomicity, consistency, isolation, and durability. To make use of database manager facilities, the architecture requires that all operations of such a transaction be performed on one physical database; as a consequence, the processes of such a transaction must be performed by the process components of one instance of one deployment unit.

The process components of one deployment unit interact with those of another deployment unit using messages passed through one or more data communication networks or other suitable communication channels. Thus, a deployment unit deployed on a platform belonging one business can interact with a deployment unit software entity deployed on a separate platform belonging to a different and unrelated business, allowing for business-to-business communication. More than one instance of a given deployment unit can execute at the same time, on the same computing system or on separate physical computing systems. This arrangement allows the functionality offered by a deployment unit to be scaled to meet demand by creating as many instances as needed.

Since interaction between deployment units is through service operations, a deployment unit can be replaced by other another deployment unit as long as the new deployment unit supports the operations depended upon by other deployment units. Thus, while deployment units can depend on the external interfaces of process components in other deployment units, deployment units are not dependent on process component interactions (i.e., interactions between process components involving their respective business objects, operations, interfaces, and messages) within other deployment units. Similarly, process components that interact with other process components or external systems only through messages, e.g., as sent and received by operations, can also be replaced as long as the replacement supports the operations of the original.

Interactions between process components that occur only within a deployment unit are not constrained to using service operations. These can be implemented in any convenient fashion.

In contrast to a deployment unit, the foundation layer does not define a limit for application-defined transactions. Deployment units communicate directly with entities in the foundation layer, which communication is typically not message based. The foundation layer is active in every system instance on which the application is deployed. Business objects in the foundation layer will generally be master data objects. In addition, the foundation layer will include some business process objects that are used by multiple deployment units. Master data objects and business process objects that should be specific to a deployment unit are preferably assigned to their respective deployment unit.

FIGS. 1A, 1B, 1C, and 1D collectively illustrate a high-level view of a software architectural design and implementation of a suite enterprise software services having accounting functionality.

As shown in FIG. 1A, a Project Management deployment unit 102 includes a Project Processing process component 104, a Project Request business object 106, a Project business object 108, a Project Snapshot business object 110, a Project Simulation business object 112, a Project Purchase Request 113, and a Project Template master data object 114.

As shown in FIG. 1B, a Financial Accounting deployment unit 116 includes: an Accounting process component 118, a Costing process component 120, a Time Based Accrual business object 122, an Accounting View on Project business object 124, an Overhead Cost Sheet business object 126, an Overhead Cost Assessment Rule business object 128, a Financial Accounting Master Data Management process component 167, and a General Ledger Account Balance business object 130.

The Costing process component 120 includes a Material Cost Estimate business object 132 and a Project Cost Estimate business object 134. The Project process component 104 includes two interfaces with operations, several business objects as well as multiple business process objects. The first interface is a General Ledger Account interface 136 that includes a General Ledger Account operation 138. The second interface is an Accounts Receivable/Payable Ledger Account interface 140 that includes an Accounts Receivable Payable Ledger Account operation 142 and a Tax Ledger Account operation 144.

The Accounting process component 118 includes eleven business objects: a Purchase Ledger Account business object 146, a Cash Ledger Account business object 148, an Accounting Document business object 150, a Sales Ledger Account business object 152, an Accounting Notification business object 154, an Accounting Entry business object 156, a Material Ledger Account business object 158, a Purchase Production Account business object 160, an Other Direct cost Ledger Account business object 162, a Fixed Asset business object 164, and an Overhead Cost Ledger Account business object 166.

As shown in FIG. 1C, the Accounting process component 118 also includes seventeen business process objects: a Fixed Asset Depreciation Run business process object 168, an Inventory Price Change Run business process object 170, a Work In Progress Clearing Run business process object 172, a Production Ledger Account Overhead Cost Calculation Run business process object 174, a Goods Receipt Invoice Receipt Clearing Run business process object 176, a Sales Ledger Account Overhead Cost Calculation Run business process object 178, a Sales Ledger Account Accruals Run business process object 180, an Accounts Receivable Payable Ledger Account Discounting Run business process object 182, an Accounts Receivable Payable Ledger Account Regrouping Run business process object 184, a Balance Carry Forward Run business process object 186, a General Ledger Account Assessment Run 188, a General Ledger Account Distribution Run business process object 190, an Accounts Receivable Payable Ledger Account Foreign Currency Re-measurement run business process object 192, a Cash Ledger Account Foreign Currency Re-measurement Run business process object 194, an Overhead cost Assessment Run business process object 196, an Overhead Cost Distribution Run business process object 198, and an Overhead cost Ledger Account Overhead Cost Calculation Run business process object 199.

The Project Request business object 106 is a specialization of a project simulation. The Project Request business object 106 can be used to simulate several alternative project setups. For example, an operational project is a copy of one selected project request.

The Project Simulation business object 112 is a specialization of a project that is used for “what-if” simulations, once the operational project is executed, to find out about the effect of changes on the operational project. Project simulations can be reconciled with the operation projects.

The Project Purchase Request business object 113 is a request to purchasing for procurement of products from a project, or with reference to a project. The request may provide a detailed description of the products that are to be procured, the quantities required, or the time at which the products need to be available. The Project Purchase Request business object 113 may also monitor procurement documents.

The Project Template master data object 114 defines the structure and non-operational data of a project. The Project Template master data object 114 can be used for a standardized project planning an execution. For example, a new project may be generated from a project template.

As shown in FIG. 1D, the Financial Accounting Master Data Management process component 167 includes eight business objects: a Service Product Valuation Data business object 169, a Material Valuation Data business object 171, a Resource Valuation Data business object 173, an Overhead Cost Scheme business object 175, a Financial Accounting View of Project business object 177, an Overhead Cost Assessment Rule business object 179, a General Ledger Account Balance Distribution Run business object 181, and a Time Based Accrual business object 183.

The Service Product Valuation Data business object 169 represents internal prices for the valuation of business transactions related to a service product or a service product group and for cost estimation. These attributes and prices may depend on organizational units and other Financial Accounting entities such as a Set Of Books or an Accounting Period.

The Material Valuation Data business object 171 represents internal prices for the valuation of business transactions related to a material or a material group, for material inventory valuation and for cost estimation. These attributes and prices may depend on organizational units, orders with reference to a material such as a sales order, production lot, project and other Financial Accounting entities.

The Resource Valuation Data business object 173 represents attributes and internal cost rates for the valuation of business transactions related to a resource and for cost estimation.

The Overhead Cost Scheme business object 175 represents a set of rules for the calculation of overhead charges. The rules define the base data and the corresponding overhead rates. The overhead cost scheme consists of a language-dependent description of one or more lines along with rate rules and offsetting rules used in the lines.

The Financial Accounting View of Project business object 177 represents a Financial Accounting project and its structure. A Financial Accounting View Of Project contains only the elements and characteristics of a project relevant to Financial Accounting. The project data may be kept in Financial Accounting centrally in order to assign the values of business transactions and costing to projects in Financial Accounting.

The Overhead Cost Assessment Rule business object 179 specifies which costs are to be allocated, the receivers and the assessment base to calculate the charges. The Overhead Cost Assessment Rule business object 179 may be used for the assessment of overhead cost to the proper originators.

The General Ledger Account Balance Distribution Run business object 181 specifies which balances accrued on Profit And Loss or Balance Sheet Accounts are to be distributed. It also defines receivers of the amount and the distribution base to calculate the charges. The General Ledger Account Balance Distribution Run business object 181 may be used to assign profit centers, or to distribute revenues and balance sheet items according to key figures.

The Time Based Accrual business object 183 represents an assignment of revenues or expenses relating to services provided over a period to the correct periods in terms of accepted accounting practice. Accruals are created when the payment transaction and the effect on net income occur in different reporting periods. Period-based accruals occur when the service provided and the corresponding effect on net income relate to the same period. Accruals relate to a deferral when an effected payment is not reported as income until a subsequent period, whereas accruals relate to an accrual when payment is reported as income before it has been made.

FIGS. 2A, 2B and 2C are block diagrams collectively showing the Project Processing process component 104 (FIG. 1A). For convenience in describing this process component, a number of other process components are shown in the figures; these other process components are not part of the process component being described. These other process components are a Purchase Request Processing process component 202, a Purchase Order Processing process component 204, a Time and Labor Management process component 206 and an Expense and Reimbursement Management process component 208. These other process components are used to represent software external to the process component in describing its interactions with the external software; however, while the external software can be implemented as such process components, this is not required.

A Change Project based on Purchase Request Confirmation operation 210 sends a purchase request confirmation using a Change Project based on Purchase Request Confirmation asynchronous outbound process agent 214 to update the Project business object 108. For example, the operation 210 can send a purchase request confirmation to update the Project business object 108 if input is received from the Purchase Request Processing process component 202.

A Change Project based on Purchase Order operation 212 sends a purchase order notification using a Change Project based on Purchase Order asynchronous outbound process agent 216 to update the Project business object 108. For example, the operation 212 can send a purchase order notification if input is received from the Purchase Order Processing process component 204.

The Project based on Purchase Request Confirmation operation 210 and the Change Project based on Purchase Order operation 212 are included in a Purchasing In asynchronous interface 218. The Purchasing In asynchronous interface 218 informs about the creation of a purchase order for an external resource that was ordered by the project manager.

A Change Project based on Employee Time Calendar operation 220 sends a project task confirmation notification using a Change Project based on Employee Time Calendar asynchronous outbound process agent 222 to update the Project business object 108. For example, the operation 220 can send a confirmation notification if input is received from the Time and Labor Management process component 206.

The Change Project based on Employee Time Calendar operation 220 is included in a Project Task Confirmation In interface 224. The Project Task Confirmation In interface 224 confirms working time for a project task. For example, the confirmation can contain working times and additional information such as status, short text, or remaining work.

A Check Project Task Availability for Accounting operation 225 sends an accounting coding block check request using a Synchronous Check Project Task Availability for Accounting outbound process agent 226 to update the Project business object 108. For example, the operation 224 can send a check request if input is received from the Expense and Reimbursement Management process component 208. The Check Project Task Availability for Accounting operation 224 is included in a Project Task Availability In interface 228.

The Project business object 108 can receive updated information and send the update into other components to perform further operations. As shown in FIG. 2B, multiple process agents can receive information from the Project business object 108.

A Request Service from Project to Purchase Request Processing asynchronous outbound process agent 230 invokes a Request Service operation 232, which is a request from a project manager asking a buyer to procure external resources or services. The Request Service operation 232 is included in a Purchasing Out interface 234. As an example, the operation 230 can then send a purchase request to a Purchase Request Processing process component 202.

A Notify of Project to Time and Labor Management asynchronous process agent 236 invokes a Notify of Project operation 238, which publishes or un-publishes project tasks with assigned human resources. The Notify of Project operation 238 is included in a Project Task Confirmation Out interface 240. As an example, the operation 238 can then send a notification to a Time and Labor Management process component 202.

A Notify of Project to Accounting asynchronous outbound process agent 242 invokes a Notify of Project operation 244, where accounting document processing is informed about the creation or the change of project elements that may be accounted. The Notify of Project operation 244 is included in a Project Accounting Out interface 246. As an example, the operation 244 can then send a notification to the Accounting process component 118.

A Request Project Cost Estimate from Project to Costing asynchronous outbound process agent 248 invokes a Request Project Cost Estimate operation 250, where document processing is requested to perform a synchronous project costing simulation. The Request Project Cost Estimate operation 250 is included in a Project Costing Out interface 252.

Information can also be sent from the Project Snapshot business object 110. The Project Snapshot business object 110 sends information to a Request Project Cost Estimate from Project Snapshot to Costing asynchronous outbound process agent 254, which invokes the Request Project Cost Estimate operation 250. As an example, the operation 250 can then send an estimate to the Costing process component 120.

As shown in FIG. 2C, a Synchronous Request project Cost Estimate Situation from Project to Costing outbound process agent 256 invokes a Request Project Cost Estimate Simulation operation 258 where costing document processing is requested to perform a synchronous project costing simulation. A Synchronous Query Project Cost Estimate from Project to Coding outbound process agent 260 invokes a Query Project Cost Estimate operation 262. In addition, a Synchronous Query Project Cost Estimate from Project Snapshot to Coding outbound process agent 264 can also invoke the Query Project Cost Estimate operation 262. As an example, the operation 262 can then send an estimate to the Costing process component 120.

FIGS. 3A, 3B, 3C, 3D and 3E are block diagrams collectively showing the Accounting process component 118 (FIG. 1B). For convenience in describing this process component, a number of external process components are shown in the figures; these other process components are not part of the process components being described. These other process components are a Production process component 302, the Purchase Order Processing process component 204, a Customer Return Processing process component 304, a Customer Complaint Processing process component 306, a Service confirmation Processing process component 308, a Service Contract Processing process component 310, a Service Request Processing process component 312, a Service Order Processing process component 314, a Sales Order Processing process component 316, the Project Processing process component 104, a Goods and Service Acknowledgement process component 318, a Confirmation and Inventory process component 320, a Site Logistics Processing process component 322, a Payment Processing process component 323, a Customer Invoice Processing process component 324, a Due Item Processing process component 325, a Supplier Invoice Processing process component 326, and an Expense and Reimbursement Management process component 327.

As shown in FIG. 3A, several business objects are included in the Accounting process component, but are not shown in the interactions. These include an Accounting Adjustment Run business object 328: an automatic valuation of, or an automatic value changing processing for a set of ledger accounts using the appropriate methods at a specified key date; a General Ledger Account business object 330: a view of the value of assets, liabilities, equity, revenues and expenses for financial accounting purposes; a Fixed Asset business object 332: a view of one or more objects, rights, or other items owned by the enterprise that is intended for long-term use, and can be identified individually in the financial statements; a Sales Ledger Account business object 334: a view of sales activities defined for financial accounting purposes; an Accounts Receivable Payable Ledger Account business object 336: a record of valuated payables and receivables of a Company for a specific business partner; a Tax Ledger Account business object 338: a summary of tax liabilities defined for financial accounting purposes; a Cash Ledger Account business object 340: a record of the valuated liquid assets of a company; and an Other Direct Cost Ledger Account business object 342: a record of debit and credit entries belonging to a company that shows the effect of business transactions on costs as a result of a particular job or activity.

A Create Accounting Entry operation 344 is included in an Accounting Document Accounting In interface 346. The Create Accounting Entry operation 344 can receive an accounting document from an instance of the Accounting process component 118. A Create Accounting Entry based on Accounting Document outbound process agent 348 receives information from the operation 344 and updates an Accounting Entry business object 350. The Accounting Entry business object 350 is used to directly enter business transactions in Financial Accounting for one or several sets of books. An Accounting Entry does not affect any operational component, therefore, it can be used for General Ledger entries, cost accounting reassignments, revaluations and other transactions without operational aspects.

A Maintain Subledger Account operation 352 is included in a Production Accounting In interface 354. The Maintain Subledger Account operation 352 receives order accounting notifications from production. The notification is to inform accounting processing about creation, change or deletion of production orders. A Maintain Production Ledger Account inbound process agent 356 updates an Accounting Notification business object 358. The Accounting Notification business object 358 is a common input channel for all kinds of operational business transactions into Financial Accounting that is called by operational components in order to record the business transactions in Financial Accounting.

As shown in FIG. 3B, several process components may give input to the Maintain Subledger Account operation 352. These include the Purchase Order Processing process component 204, the Customer Return Processing process component 304, the Customer Complaint Processing process component 306, the Service Confirmation Processing process component 308, the Service Contract Processing process component 310, the Service Request Processing process component 312, the Service Order Processing process component 314, and the Sales Order Processing process component 316.

The operation 352 is included in an Order Accounting In interface 359 and uses a Maintain Subledger Account based on order asynchronous inbound process agent 360 to update the Accounting Notification business object 358.

As shown in FIG. 3C, the Project Processing process component 104 may give input to a Maintain Subledger Account operation 352 that receives order accounting notifications from process components. The notification is to inform accounting processing about the creation, change or deletion of any kind of order business objects. The operation 352 is included in a Project Accounting In interface 361 and uses a Maintain Accounting View On Project and Ledger Account asynchronous inbound process agent 362 to update the Accounting Notification business object 358.

A Goods and Service Accounting In interface 363 includes a Create Accounting Document operation 364 and a Cancel Accounting Document operation 365. The Create Accounting Document operation 364 can receive goods movement resource consumption notifications from the Goods and Service Acknowledgement process component 318. The Cancel Accounting Document operation 365 can receive goods movement resource consumption cancellation requests from the Goods and Service Acknowledgement process component 318. Both operations use a Maintain Accounting Document based on Goods and Service Acknowledgement asynchronous inbound process agent 366 to update the Accounting Notification business object 358.

An Inventory and Activity Accounting In interface 367 includes a Create Accounting Document operation 364 and a Cancel Accounting Document operation 365. The Create Accounting Document operation 364 receives inventory change accounting notifications from the Confirmation and Inventory process component 320, the Site Logistics Processing process component 322 or the Production process component 302. The Cancel Accounting Document operation 365 receives inventory change accounting cancellation requests from the Confirmation and Inventory process component 320, the Site Logistics Processing process component 322, or the Production process component 302. Both operations use a Maintain Accounting based on Inventory and Activity asynchronous inbound process agent 368 to update the Accounting Notification business object 358.

As shown in FIG. 3D, a Service Provision Accounting In interface 369 includes a Create Accounting Document operation 364 and a Cancel Accounting Document operation 365. The Create Accounting Document operation 364 receives resource consumption notifications from the Service Request Processing process component 312, the Service Confirmation Processing process component 308, or the Time and Labor Management process component 206. The Cancel Accounting Document operation 365 receives resource consumption cancellation requests from the Service Request Processing process component 312, the Service Confirmation Processing process component 308, or the Time and Labor Management process component 206. Both operations use a maintain Accounting Document based on Service Provision asynchronous inbound process agent 370 to update the Accounting Notification business object 358.

An Invoice Accounting In interface 371 includes a Create Accounting Document operation 364 and a Cancel Accounting Document operation 365. The Create Accounting Document operation 364 creates an accounting document for a customer invoice or a supplier invoice. The accounting document records payables, receivables, expenses and revenues for the Invoice in Financial Accounting. The Cancel Accounting Document operation 365 receives Invoice Accounting cancellation requests from the Customer Invoice Processing process component 324 or the Supplier Invoice Processing process component 326. Both operations use a Maintain Accounting Document based on Invoice asynchronous inbound process agent 372 to update the Accounting Notification business object 358.

As shown in FIG. 3E, a Payment Accounting In interface 373 includes a Create Accounting Document operation 364 and a Cancel Accounting Document operation 365. The Create Accounting Document operation 364 receives payment accounting notifications from the Payment Processing process component 323 or the Due Item Processing process component 325. Both operations use a Maintain Accounting based on Payment asynchronous inbound process agent 374 to update the Accounting Notification business object 358.

An Expense Accounting In interface 375 includes a Create Accounting Document operation 364 and a Cancel Accounting Document operation 365. The Create Accounting Document operation 364 receives expense accounting notifications from the Expense and Reimbursement Processing process component 327. The Cancel Accounting Document operation 365 receives expense accounting cancellation requests from the Expense and Reimbursement Processing process component 327. Both operations use a Maintain Accounting based on Document Expense asynchronous inbound process agent 375 to update the Accounting Notification business object 358.

FIG. 4 is a block diagram of the Costing process component 120. The Project Processing process component 104 is used to show exemplary input sources. A Material Cost Estimate business object 401 is included as part of the Financial Accounting deployment unit.

A Simulate Project Cost Estimate operation 402 can be invoked by the Project Processing process component 104. The Simulate Project Cost Estimate operation 402 occurs when costing document processing is requested to perform a synchronous project costing simulation and return the new calculated costing results. The estimate is sent using a Synchronous Simulate Project Cost Estimate message agent to update a Project Cost Estimate business object 406. A Query Project Cost Estimate operation 408 may also be invoked where a project cost estimate is requested and the operation is returning the costing results of a project. Both operations 404 and 408 are included in a Project Costing In interface 412.

The Project Processing process component 104 can also invoke a Maintain Project Cost Estimate operation 414 where costing document processing is informed about the creation or the change of project elements that are costing relevant, and carry out a new cost estimate for the project and creates a project accounting view, if required. The Maintain Project Cost Estimate operation 414 is included in the Project Costing In interface 412. A Maintain Project Costing asynchronous outbound process agent 416 updates the Project Cost Estimate business object 406.

The subject matter described in this specification and all of the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more computer programs tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

The subject matter described in this specification can be implemented in a computing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

While this specification contains many specifics, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as an exemplification of preferred embodiments of the invention. Certain features that are described in this specification in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be provided in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

The subject matter has been described in terms of particular variations, but other variations can be implemented and are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims.

Claims

1. A computer program product encoded on a tangible, non-transitory, machine-readable storage device for, providing message-based services using a service-oriented methodology, the medium comprising: program code for implementing a project management deployment unit including:a project request business object is used to simulate several alternative project setups; a project business object is characterized by a unique set of conditions and structured by phases and tasks;a project snapshot business object is a copy of the whole project at a certain point in time;a project simulation business object is used to find out about the effect of changes on an operational project;a project purchase request business object is used to monitor procurement documents; anda project template business object is used for standardizing a new project execution;wherein the project management deployment unit further includes instructions for executing service operations including: a change project based on purchase request confirmation operation operable to send a confirmation to a requester of the extent to which a requisition has been fulfilled;a change project based on purchase order operation operable to notify the project about the creation of a purchase order for an external resource;a change project based on employee time calendar operation operable to send a confirmation of working time for a project task;a check task availability for accounting operation operable to notify of task availability;a request service operation operable to request a buyer to procure external resources or services;a notify of project operation operable to inform accounting about a creation or change of project elements;a request project cost estimate operation operable to inform accounting about a creation or change of project elements that are costing relevant;a request project cost estimate simulation operation operable to request to perform a synchronous project costing simulation; anda query project cost estimate operation operable to query costing for the last costing result for project elements;program code for implementing a financial accounting deployment unit including an overhead cost sheet object including a set of rules for the calculation of overhead charges, a time based accrual business object including the specification for accrual methods, an overhead cost assessment rule business object used for the assessment of overhead cost to the proper originators, an accounting view on project business object representing the project structure in financials, a general ledger account distribution run business object including an automatic periodically-executed rule-based posting assistant, an overhead cost ledger account overhead cost calculation run business object including an automatic calculation run to calculate and post the overhead costs at period end, an overhead cost assessment run business object including an automatic rule-based calculation of collected amounts and quantities in overhead cost ledger accounts based on key figures or keys, an accounts receivable payable ledger account foreign currency re-measurement run business object including an automatic period-end re-measurement of foreign currency amounts, a work in process clearing run business object including an automatic clearing of work in process at period end, a sales ledger account business object including a view of sales activities defined for financial accounting purposes, a production ledger account overhead cost calculation run business object including an automatic calculation run to calculate and post the overhead costs at period end, a sales ledger account overhead cost calculation run business object including an automatic calculation run to calculate and post the overhead costs at period end, a fixed asset depreciation run business object including an automatic depreciation of asset values for a set of fixed assets, a balance carry forward run business object including an automatic carry forward of year end balances for all general ledger accounts and fixed assets to the following fiscal year, an inventory price change run business object including a change to the inventory price, an accounts receivable payable ledger account regrouping run business object including an automatic transfer posting of valuated receivables and payables for a set of accounts receivable payable ledger accounts, an accounting entry business object used to directly enter business transactions in financial accounting, an accounting document business object representing a business transaction in financial accounting, a goods receipt invoice receipt clearing run business object including an automatic calculation of price variances between the valuated goods received and the related invoice received at period end, an overhead cost distribution run business object including an automatic periodically-executed rule-based posting assistant, a general ledger account assessment run business object including an automatic rule-based calculation of collected amounts and quantities in general ledger accounts, an other direct cost ledger account including a record of debit and credit entries showing an effect of business transactions on costs as a result of a particular job or activity, an accounting notification business object including a common input channel for all kinds of operational business transactions into financial accounting, a sales ledger account accruals run business object including an automatic valuation of sales transactions for a set of sales ledger accounts at period end, an accounting adjustment run business object including an automatic valuation of a set of ledger accounts, an accounts receivable payable ledger account discounting run business object including an automatic discounting of valuated payables and receivables, a cash ledger account foreign currency re-measurement run business object including an automatic re-measurement of foreign currency amounts, a purchase ledger account business object including a view of purchasing activities defined for financial accounting purposes, a cash ledger account business object including a record of the valuated liquid assets of a company, a material ledger account business object including a record of materials assets in a company that are relevant to valuation, a production ledger account business object including a view of production related business transactions defined for financial accounting purposes, a chart of accounts business object used to chart account status, a general ledger account business object including a view of the value of assets, liabilities, equity, revenues and expenses for financial accounting purposes, an overhead cost ledger account business object including a record of the costs incurred by the provision of resources, a fixed asset business object including a view of one or more objects, rights, or other items owned by the enterprise that is intended for long-term use, a tax ledger account business object including a summary of tax liabilities defined for financial accounting purposes, an accounts receivable payable ledger account business object including a record of valuated payables and receivables of a company for a specific business partner, a project cost estimate business object including a listing of the elements of a project that incur costs, a service product valuation data business object representing internal prices for valuation of business transactions related to a service product or a service product group and for cost estimation, a material valuation data business object representing internal prices for the valuation of business transactions related to a material or a material group, for material inventory valuation and for cost estimation, a resource valuation data business object representing internal prices for the valuation of business transactions related to a material or a material group, for material inventory valuation and for cost estimation, an overhead cost scheme business object representing a set of rules for the calculation of overhead charges, a financial accounting view of project business object representing a financial accounting project and its structure, an overhead cost assessment rule business object specifying costs to be allocated and the assessment base to calculate charges, a general ledger account balance distribution run business object specifying balances accrued on profit and loss and balance sheet accounts to be distributed, a time based accrual business object representing an assignment of revenues or expenses relating to services provided over a period to the correct periods in terms of accepted accounting practice, and a material cost estimate business object including a listing of the elements involved in the procurement or production of a material that incur costs, wherein the financial accounting deployment unit further includes instructions for executing service operations including: a create accounting entry operation operable to receive an accounting document from another instance of accounting;a maintain subledger account operation operable to receive a project accounting notification from project processing;a create accounting document operation operable to receive an expense accounting notification from expense and reimbursement processing;a synchronous valuate product and resource operation operable to synchronize access to price information for products;a maintain project cost estimate operation operable to inform costing document processing about the creation or change of project elements that are costing relevant;a cancel accounting document operation operable to receive an expense accounting notification from expense and reimbursement processing; anda simulate project cost estimate operation operable to request performance of a synchronous project costing simulation and response;wherein each of the said project management and financial accounting deployment units are deployable and executable.

2. A computer program product encoded on a tangible, non-transitory, machine-readable storage device for providing message-based services using a service-oriented methodology, the medium comprising: a change project based on purchase request confirmation operation operable to send a confirmation to a requester of the extent to which a requisition has been fulfilled;a change project based on purchase order operation operable to notify the project about the creation of a purchase order for an external resource;a change project based on employee time calendar operation operable to send a confirmation of working time for a project task;a check task availability for accounting operation operable to notify of task availability;a request service operation operable to request a buyer to procure external resources or services;a notify of project operation operable to inform accounting about a creation or change of project elements;a request project cost estimate operation operable to inform accounting about a creation or change of project elements that are costing relevant;a request project cost estimate simulation operation operable to request to perform a synchronous project costing simulation;a query project cost estimate operation operable to query costing for the last costing result for project elements;a create accounting entry operation operable to receive an accounting document from another instance of accounting;a maintain subledger account operation operable to receive a project accounting notification from project processing;a create accounting document operation operable to receive an expense accounting notification from expense and reimbursement processing;a synchronous valuate product and resource operation operable to synchronize access to price information for products;