WO2007112947A2

WO2007112947A2 - Providing logistics execution application as enterprise services

Info

Publication number: WO2007112947A2
Application number: PCT/EP2007/002833
Authority: WO
Inventors: Shai Alfandary; Klaus Bahr; Achim Clemens; Renzo Colle; Sabine Deimel; Thomas Friedrich; Achim Heger; Matthias Heinrichs; Stephan Hetzer; Jochen Hirth; Martin Schmidt; Henning Schmitz; Jochen Steinbach; Silke Storch; Martin Wilmes; Hao Zheng; Guimei Zhang; Asaaf Ezov; Elad Heart; Ziv Holzman
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2006-03-30
Filing date: 2007-03-29
Publication date: 2007-10-11
Anticipated expiration: 2008-09-30

Description

PROVIDING LOGISTICS EXECUTION APPLICATION AS ENTERPRISE

SERVICES

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 logistic execution management 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 logistics execution 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

FIG. 1 illustrates a high-level view of a software architectural design and implementation of a suite enterprise software services having logistic execution functionality.

FIGS. 2 A and 2B are block diagrams collectively showing an inbound delivery processing process component. FIGS. 3A and 3B are block diagrams collectively showing a production process component.

FIGS. 4 A and 4B are block diagrams collectively showing a site logistics processing process component.

FIG. 5 is a block diagram of an outbound delivery processing process component. FIGS. 6 A and 6B are block diagrams collectively showing a production model processing process component.

FIG. 7 is a block diagram showing a confirmation and inventory process component. FIG. 8 is a block diagram of a physical inventory processing process component. FIG. 9 is a block diagram of an engineering change order processing process component.

FIG. 10 is a block diagram of an installed base data processing process component. Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

FIG. 1 illustrates a high-level view of a software architectural design, and of application software implementations of the design, that provides a suite of enterprise service operation, which can be organized into interfaces, having logistic execution 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 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. When deployed on separate computer platforms, the fundamental entities of the foundation layer should appear the same across all platforms. To achieve this, the foundation layer entities are synchronized across the platforms on which the foundation layer is deployed. Any convenient conventional technique of data record or object synchronization can be implemented to accomplish the synchronization.

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 and master data 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, hi 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.

As shown in FIG. 1, a Logistics Execution deployment unit 102 includes an Inbound Delivery Processing process component 104, a Product process component 106, a Confirmation and Inventory process component 108, an Outbound Delivery Processing process component 110, a Site Logistics process component 112, an Inbound Delivery Processing process component 114, a Material Inspection Processing process component 116, and an Execution Material Flow View transformed object 118.

The Inbound Delivery Processing process component 104 includes an Inbound Delivery Request business object 120, an Inbound Delivery business object 122, and a Confirmed Inbound Delivery business object 124.

The Production process component 106 includes a Production Request business object 126, a Production Order business object 128, a Production Task business object 130, a Production Confirmation business object 132, and a Production Lot business object 134. The Confirmation and Inventory process component 108 includes a Goods and

Activity Confirmation business object 136, an Inventory business object 138, and an Identified Logistic Unit master data object 140.

The Outbound Delivery Processing process component 110 includes an Outbound Delivery request business object 142, an Outbound Delivery business object 144, and a Confirmed Outbound Delivery business object 146.

The Site Logistics process component 112 includes a Site Logistics Request business object 148, a Site Logistics Order business object 150, a Site Logistics Task business object 152, a Site Logistics Confirmation business object 154, and a Site Logistics Lot business object 156. The Inbound Delivery Processing process component 114 includes a Physical Inventory task business object 158 and a Physical Inventory Count business object 160. In some cases, a deployment unit can use process components that are part of an underlying foundation layer, for which no separate logical deployment unit is defined. The Logistics Execution Deployment Unit 102 uses four: an Engineering Change Processing process component, an Installed Base Data Processing process component, a Site Logistics Model Processing process component, and a Production Model Processing process component.

FIGS. 2 A and 2B are block diagrams collectively showing an Inbound Delivery Processing process component 104 (FIG. 1). The Inbound Delivery Processing process component 104 constitutes logistics execution driven by an inbound delivery request for receiving goods from a vendor. The Inbound Delivery Processing process component 104 combines all tasks concerning the inbound delivery process (preparation and triggering of execution), and enables communication with the vendor and invoicing. As shown in FIG. 2 A, a Logistics Execution Control process component 202 and an external Outbound

Delivery Processing at Supplier process component 204, which are not part of the process component being described, are included for convenience in describing this process component. The Logistics Execution Control process component 202 controls and monitors on a macro logistics level the supply chain execution activities necessary for the fulfillment of an order (e.g. sales order, purchase order) and sends information to logistics execution to trigger the necessary supply chain execution activities, receives information about the supply chain execution progress, and updates data relevant for both fulfillment and supply and demand planning. The Outbound Delivery Processing at Supplier process component 204 constitutes logistics execution driven by an outbound delivery request for shipping goods to a product recipient at a supplier and it combines all tasks concerning the outbound delivery process (preparation and triggering of execution), and enables communication with the product recipient and invoicing; however, while the external software can be implemented as such process components, these are not required.

The Inbound Delivery Request business object 120 is a document in the inbound delivery process containing all the relevant logistics data from the initiator of the inbound delivery process (such as the purchase order, for example). The inbound delivery request is used to validate an inbound delivery and an advanced shipping notification, and to prepare inbound logistics for receiving the goods. In this example, the Logistics Execution Control process component 202 sends an update to a Maintain Inbound Delivery Request operation 206 that is included in a Fulfillment In interface 208. The Maintain Inbound Delivery

Request operation 206 receives delivery fulfillment requests from the Logistics Execution Control process component 202. As shown, the Maintain Inbound Delivery Request operation 206 triggers a Maintain Inbound Delivery Request inbound process agent 210 to update the Inbound Delivery Request business object 120. The update in the Inbound Delivery Request business object 120 triggers a Confirm Fulfillment of Inbound Delivery Request to Logistics Execution Control outbound process agent 212 to invoke a Confirm Fulfillment operation 214 in a Fulfillment Out interface 216. The Confirm Fulfillment operation 214 then sends a delivery fulfillment confirmation to the Logistics Execution Control process component 202. As shown in FIG 2B, the Supplier Invoice Processing process component 230 is not part of the process component being described, but has been included for convenience in describing this process component. The Supplier Invoice Processing process component 230 includes the supplier invoice and supplier invoice request. The supplier invoice is a document that states the recipient's (usually the purchaser's) obligation to pay the supplier for goods received or services rendered. An invoice is normally created after the goods and service acknowledgment has been confirmed. The supplier invoice request is a document that is sent to invoice verification, advising that an invoice for specified quantities and prices. While the external software can be implemented as such process components, the Supplier Invoice Processing process component 230 is not required. The Confirmed Inbound Delivery business object 124 is a confirmation that the specified goods have actually been received by the intended product recipient. The Confirmed Inbound Delivery business object 124 is the basis for the Proof of Delivery. It helps to identify any discrepancies between an order and a delivery, and it serves as the basis for the supplier invoice verification. In this example, the Confirmed Inbound Delivery business object 124 triggers a Request Invoicing from Confirmed Inbound Delivery to Supplier Invoice Processing outbound process agent 238. The Request Invoicing from Confirmed Inbound Delivery to Supplier Invoice Processing outbound process agent 238 invokes a Notify of Invoicing Due operation 240 in an Invoice Notification Out interface 242. The Notify of Invoicing Due operation 240 sends an invoice due notification to the Supplier Invoice Processing process component 230.

FIGS. 3A and 3B are block diagrams collectively showing a Production process component 106 (FIG. 1). The Production process component 106 combines all the activities required to manage the production execution process on the manufacturing shop floor. Production requests are received from planning which are converted into production orders, production lots, and production tasks during the production preparation phase. The production order describes the production process. The production lot collects all actual data for the production process. The production tasks are used to dispatch self-contained work items to the operators on the shop floor. During the production execution and finalization phases, production confirmations are created which update inventory, finance, and planning. A Production Trigger and Response process component 302 and an Accounting process component 304, which are not part of the process component being described, are included for convenience in describing this process component. The Production Trigger and Response process component 302 provides an interface to production from a supply planning perspective. It contains all the tasks necessary for creating and changing production requisitions. Furthermore, it receives information about the production progress from production and updates the production requisitions and stock data according to this information. The Accounting process component 304 records all relevant business transactions in financial accounting. However, while the external software can be implemented as such process components, these are not required. As shown in FIG. 3 A, the Production process component 106 includes the Production

Order business object 128, the Production Task business object 130, the Production Request business object 126, and the Production Confirmation business object 132. The Production Order business object 128 is an object that is used to model and to describe the production process down to the execution level. Production flow is modeled using operations and activities that are executed in sequence, in parallel or alternatively. In particular, the production order defines which components and resources are required to produce a material.

The Production Task business object 130 is an object that reflects the work organization on the shop floor. Production tasks subdivide the manufacturing process into self-contained work items. They are to be executed by one or more persons working on the shop floor or by an automation system involved in the manufacturing process. The workers receive all the instructions they need to execute a task via the user interface and are requested to input actual data.

The Production business object 126 is a request from planning to manufacturing to produce a certain quantity of a certain product at a certain time. In this example, the

Production Trigger and Response process component 302 sends an update to a Production Request operation 306 that is included in a Producing In interface 308. The Maintain Production Request operation 306 maintains production trigger and response requests production. As shown, the Maintain Production Request operation 306 triggers a Maintain Production Request inbound process agent 310 to update the Production business object 126. The update in the Production business object 126 triggers a Confirm Production Request to Production Trigger and Response outbound process agent 312 to invoke a Confirm Production Request operation 314 in a Producing Out interface 316. In some embodiments, the Confirm Production Request operation 314 then sends a production request confirmation to the Production Trigger and Response process component 302 to acknowledge the receipt of the production request, quantities and delivery dates.

The Production Confirmation business object 132 is a document that collects actual data that was posted with reference to a production order (for example, inventory changes, services, reporting point documents, plan fulfillment documents). The production confirmation updates inventory, finance and planning. In this example, an update to the Production Confirmation business object 132 triggers a Notify of Production Process to Production Trigger and Response outbound process agent 318 to invoke a Notify of Production Progress operation 320 in the Producing Out interface 316. The Notify of Production Progress operation 320 notifies the Production Trigger and Response process component 302 about inventory changes and fulfillment of production orders. An update to the Production Confirmation business object 132 can also trigger a Notify of Production Progress from Production Confirmation to Accounting outbound process agent 322. The Notify of Production Progress from Production Confirmation to Accounting outbound process agent 322 may invoke either a Notify of Inventory Change and Activity Confirmation operation 324 or a Notify of Inventory Change and Activity

Confirmation Cancellation operation 326 in an Inventory and Activity Accounting Out interface 328. The Notify of Inventory Change and Activity Confirmation operation 324 notifies the Accounting process component 304 about an Inventory change or an action consumption posting. The Notify of Inventory Change and Activity Confirmation Cancellation operation 326 notifies the Accounting process component 304 about a cancellation of an inventory change or production activity.

As shown in FIG. 3B, the Production process component 106 also includes the Production Lot business object 134. The Production Lot business object 134 is an object that is used to execute production. It collects all actual data for a homogeneous production process and documents its progress. By using a production lot, actual quantities are aggregated, confirmation documents are created and plan reductions are calculated. The production lot forms the basis for the integration with a financial institution and for a process-oriented genealogy. In this example, an update to the Production Lot business object 134 triggers a Notify of Production Lot to Accounting outbound process agent 330 that invokes a Notify of Production Lot Status Change operation 332 in a Production Accounting Out interface 334. The Notify of Production Lot Status Change operation 332 then informs the Accounting process component 304 (FIG. 3A) about a status change of a production lot.

FIGS. 4A and 4B are block diagrams collectively showing the Site Logistics Processing process component 112 (FIG. 1). The Site Logistics Processing process component 112 supports all preparing and execution tasks concerning internal inventory movements. It also provides stock information including special stocks. It enables decision making through exception and alert information. The Logistics Execution Control process component 202, a Supply and Demand Matching process component 404, and the Accounting process component 304, which are not part of the process component being described, are included for convenience in describing this process component. The Logistics Execution Control process component 202 controls and monitors on a macro logistics level the supply chain execution activities necessary for the fulfillment of an order (e.g. sales order, purchase order). It sends information to logistics execution to trigger the necessary supply chain execution activities, receives information about the supply chain execution progress, and updates data relevant for both fulfillment and supply and demand planning. The Supply and Demand Matching process component 404 combines all the tasks necessary to ensure that sufficient material receipt elements exist to cover material demand while taking available capacity into account. It collects all the various material demands from customer requirement processing, in-house requirement processing, demand forecast processing, and sales scheduling agreement processing. It tries to assign all the already-existing material receipts and plans the internal or external procurement of further material receipts where necessary. However, while the external software can be implemented as such process components, these are not required.

As shown in FIG. 4A, the Site Logistics Processing process component 112 also includes the Site Logistics Request business object 148, the Site Logistics Confirmation business object 154, the Site Logistics Order business object 150, the Site Logistics Task business object 152, and the Site Logistics Lot business object 156.

The Site Logistics Request business object 148 is a request to perform site logistics operations supporting outbound, inbound and site internal logistics activities at a certain time. In this example, the Logistics Execution Control process component 202 can invoke a

Maintain Site Logistics Request operation 406 in a Site Logistics Processing In interface 408. The Maintain Site Logistics Request operation 406 maintains site logistics processing request creation or update. As shown, the Maintain Site Logistics Request operation 406 triggers a Maintain Site Logistics Request inbound process agent 410 to update the Site Logistics Request business object 148. The update in the Site Logistics Request business object 148 triggers a Confirm Site Logistics Request to Logistic Execution Control outbound process agent 412 to invoke a Confirm site Logistics Request operation 414 in a Site Logistics Processing Out interface 416. In some embodiments, the Confirm Site Logistics Request operation 414 then sends confirmation receipts of request and acknowledges quantities and delivery dates to the Logistics Execution Control process component 202. The Site Logistics Confirmation business object 154 is a document that collects actual data posted with reference to a site logistics order or site logistics request. The site logistics confirmation updates inventory, finance and planning. In this example, an update in the Site Logistics Confirmation business object 154 triggers some or all of: a Notify of Site Logistics Confirmation to Logistic Execution Control outbound process agent 418, a Notify of

Inventory Change from Site Logistics Confirmation to Accounting outbound process agent 422, or a Notify of Inventory Change from Site Logistics Confirmation to Supply and Demand Matching) SDM 430 (FIG. 4B). If the Notify of Site Logistics Confirmation to Logistic Execution Control outbound process agent 418 is triggered, then the Notify of Site Logistics Confirmation to Logistic Execution Control outbound process agent 418 invokes a Notify of Site Logistics Request Progress operation 420 in the Site Logistics Processing Out interface 416. In some embodiments, the Notify of Site Logistics Request Progress operation 420 then informs the Logistics Execution Control process component 202 about inventory changes and fulfillment of site logistics processing. If the Notify of Inventory Change from Site Logistics Confirmation to Accounting outbound process agent 422 is triggered, then the Notify of Inventory Change from Site Logistics Confirmation to Accounting outbound process agent 422 invokes a Notify of Inventory Change and Activity Provision operation 424 or a Notify of Inventory Change and Activity Provision Cancellation operation 426 in an Inventory and Activity Accounting Out interface 428. If the Notify of Inventory Change and Activity Provision operation 424 is invoked, it sends an inventory change accounting notification to the Accounting process component 304. If the Notify of Inventory Change and Activity Provision Cancellation operation 426 is invoked, it sends a request of inventory change and activity provision cancellation to the Accounting process component 304. As shown in FIG. 4B, if the Notify of Inventory Change from Site Logistics

Confirmation to SDM outbound process agent 430 is triggered, then a Notify of Inventory Change operation 432 in an Inventory Changing Out interface 434 is invoked. The Notify of Inventory Change operation 432 then sends an inventory change planning notification to the Supply and Demand Matching process component 404. The Site Logistics Order business object 150 is an object that is used to describe the site logistics process down to the execution level. The logistics flow is modeled using operations and activities that are executed in sequence, in parallel or alternatively. In particular, the site logistics order defines which resources are required to perform the activities.

The Site Logistics Task business object 152 is an object that reflects the organization of work in a site or warehouse. Site logistics tasks divide the site logistics process into self- contained work items. The tasks are to be executed by one or more persons, or by an automation system, involved in the site logistics process. The workers receive all the instructions they need to execute a task via the user interface, and are requested to input actual data.

The Site Logistics Lot business object 156 is an execution document used to collect all actual data for a site logistics process and record its progress. The site logistics lot collects all actual information reported during the physical fulfillment of a site logistics operation. By using a site logistics lot, actual quantities are aggregated, confirmation documents are created, and plan reductions are calculated. The site logistics lot forms the basis for a process-oriented genealogy.

FIG. 5 is a block diagram of the Outbound Delivery Processing process component 110. The Outbound Delivery Processing process component 110 constitutes logistics execution driven by an outbound delivery request for shipping goods to a product recipient. It combines all tasks concerning the outbound delivery process (preparation and triggering of execution), and enables communication with the product recipient and invoicing. An Inbound Delivery Processing at Customer process component 502, a Customer Invoice Processing process component 504, and the Logistics Execution Control process component 202, which are not part of the process component being described, are included for convenience in describing this process component. The Inbound Delivery Processing at Customer process component 502 constitutes logistics execution driven by an inbound delivery request for receiving goods from a vendor at a customer. It combines all tasks concerning the inbound delivery process (preparation and triggering of execution), and enables communication with the vendor and invoicing. The Customer Invoice Processing process component 504 is used to charge a customer for the delivery of goods or services. However, while the external software can be implemented as such process components, these are not required.

As shown, the Outbound Delivery Processing process component 110 includes the Outbound Delivery Request business object 142, the Outbound Delivery business object 144, and the Confirmed Outbound Delivery business object 146.

The Outbound Delivery Request business object 142 is a document in the outbound delivery process containing all the relevant logistics data from the initiator of the outbound delivery process (such as the sales order, for example). The outbound delivery request is used to prepare outbound logistics for shipping the goods, hi this example, the Logistics Execution Control process component 202 can send an update to a Maintain Outbound Delivery Request operation 508 in a Fulfillment hi interface 510. After receiving a delivery fulfillment request from the Logistics Execution Control process component 202, the Maintain Outbound Delivery Request operation 508 then triggers a Maintain Outbound Delivery Request inbound process agent 512 to update the Outbound Delivery Request business object 142. The update in the Outbound Delivery Request business object 142 triggers a Confirm Fulfillment of Outbound Delivery Request to Logistics Execution Control outbound process agent 512. The Confirm Fulfillment of Outbound Delivery Request to Logistics Execution Control outbound process agent 512 then invokes a Confirm Fulfillment operation 514 in a Fulfillment Out interface 516. The Confirm Fulfillment operation 514 sends Delivery Fulfillment Confirmation to the Logistics Execution Control process component 202.

The Outbound Delivery business object 144 is a document containing the delivery note which additionally records the goods that have actually been received by the goods recipient. In this example, an update in the Outbound Delivery business object 144 can trigger a Notify of Outbound Delivery to Inbound Delivery Processing at Customer outbound process agent 518 and/or a Request Invoicing from Outbound Delivery to Customer Invoice Processing outbound process agent 524. The Notify of Outbound Delivery to Inbound Delivery Processing at Customer outbound process agent 518 invokes a Notify of Outbound Delivery operation 520 in a Delivery Notification Out interface 522 to send a dispatched delivery notification to the Inbound Delivery Processing at Customer process component 502. The Request Invoicing from Outbound Delivery to Customer Invoice Processing outbound process agent 524 invokes a Request Invoicing operation 526 in a Request Invoicing Out interface 528 to send a request of invoicing of service contract from the Customer Invoicing Processing process component 504.

The Confirmed Outbound Delivery business object 146 is a confirmation from the intended product recipient that the specified goods have actually been received. The confirmed outbound delivery, which is based on the proof of delivery sent by the product recipient, helps identify any discrepancy between an order and a delivery and can serve as the basis for customer invoicing and billing adjustments. The confirmed outbound delivery is not mandatory, hi this example, the Inbound Delivery Processing at Customer 502 can send a message to update the Confirmed Outbound Delivery business object 146.

FIGS. 6 A and 6B are block diagrams collectively showing a Production Model Processing process component 600 of the foundation layer. The Production Model Processing process component 600 combines all the tasks required to maintain master data for the planned production order and the production order. An External Production Model Processing process component 602, which is not part of the process component being described, is included for convenience in describing this process component. The External Production Model Processing process component 602 is a process component external to the architectural design that combines all the tasks required to maintain master data for the planned production order and the production order; however, while the external software can be implemented as such process components, this is not required.

As shown in FIG. 6A, the Production Model Processing process component 600 also includes a Production Bill of Material business object 610. The Production Bill of Material business object 610 is a complete and structured list that defines and describes the components that are required in the production of a material or family of similar materials. The Production Bill Of Material business object 610 can be used for configurable and non- configurable materials and is used in planning and execution, hi this example, the External Production Model Processing process component 602 can send updates to a Create Production Bill of Material operation 604 in a Production Bill of Material Transmission Receiving In interface 606. The Create Production Bill of Material operation 604 can trigger a Create Production Bill of Material inbound process agent 608 to update the Production Bill of Material business object 610. An update in the Production Bill of Material business object 610 triggers a Confirm Production Bill of Material Transmission outbound process agent 612 to invoke a Confirm Production Bill of Material Transmission operation 614 in a Production Bill of Material Transmission Receiving Out interface 616. The Confirm Production Bill of Material Transmission operation 614 sends a message to the External Production Model Processing process component 602 to confirm transmission of updates to the Production Bill of Material business object 610. As shown in FIG. 6B, the Production Model Processing process component 600 also includes a Production Model 634, a Production Segment 636, a Released Planning Production Model 633, and a Released Execution Production Model 635.

The Production Model business object 634 is a released version of a Production Model in a production center that contains all details from the production bill of operations and production bill of material necessary for the planning of a production process. The released planning production model is used to create planned production orders. The released planning production models for a production model are versioned. A released planning production model contains the version of the master data of a production model available when the released planning production model was created. The Production Segment business object 638 is part of a production process in a production center specified by a network of operations and assigned materials for the production of a material. It creates a link between the master data of the Production Bill Of Operations business object 638 and the Production Bill Of Material business object 632. One or more production segments can be assigned to a production process model. An individual production order is created in production for every assigned production segment.

The Production Bill of Operations business object 638 is a detailed description of how a product is to be produced. The production bill of operations consists of operations with attached execution instructions.

The Released Planning Production Model business object 633 is a released version of a Production Model that contains all Bill of Operations and Bill of Material data required for the execution of the production process. The Released Planning Production Model contains master data that is required for production planning. A Released Execution Production Model business object 633 is used to create Production Requests and Production Orders and contains all the necessary master data from the Production Model. The Released Execution Production Models for a Production Model are versioned.

The Released Execution Production Model business object 635 is a released version of a Production Model in a production center that contains all details from the Production Bill Of Operations business object 638 necessary for the planning of a production process. The Released Planning Production Model is used to create planned production orders. FIG. 7 is a block diagram showing a Confirmation and Inventory process component

108. The Confirmation and Inventory process component 108 combines all the tasks required to confirm inventory changes and provided activities. It provides services to maintain current stock and allocations. The Accounting process component 304 and the Supply and Demand Matching process component 404, which are not part of the process component being described, are included for convenience in describing this process component. The Service Confirmation Processing process component 706 is used to handle services rendered for a service order. This includes reporting back working times, materials used, as well as any expenses incurred during the service activities. These particulars are used as a basis for keeping track of working times, updating stock levels for spare parts, processing invoices, and cost accounting. However, while the external software can be implemented as such process components, these are not required.

As shown in FIG. 7, the Confirmation and Inventory process component 108 includes the Inventory business object 138 and the Goods and Activity Confirmation business object 136. The Inventory business object 138 is a representation of an inventory in a stock keeping location. It provides services to query stock. The Goods and Activity Confirmation business object 136 is an object that contains all actual data reflecting an "ad-hoc" executed work (e.g., scrapping, goods issue for account assignment, change of stock category. In this example, a change in the Goods and Activity Confirmation business object 136 can trigger a Notify of Inventory Change from Goods and Activity Confirmation to Accounting outbound process agent 708 and a Notify of Inventory change from Confirmation to Supply and Demand Matching outbound process agent 714. The Notify of Inventory Change from Goods and Activity Confirmation to Accounting outbound process agent 708 invokes a Notify of Inventory Change and Activity Confirmation operation 79 and a Notify of Inventory Change and Activity Confirmation Cancellation operation 710 in an Inventory and Activity Accounting Out interface 712. An update may be sent to the Accounting process component 304. A Notify of Inventory Change operation 716 in an Inventory Changing Out interface may send an update to the supply and Demand Matching process component 404.

FIG. 8 is a block diagram of a Physical Inventory Processing process component 114 (FIG. 1). The Physical Inventory Processing process component 114 manages the execution of inventory counting within a logistic site, from the request for counting operation, through the actual inventory counting results gathering and its final confirmation. As shown, the Physical Inventory Processing process component 114 includes the Physical Inventory Task business object 158 and the Physical Inventory Count business object 160.

The Physical Inventory Task business object 158 is either a count or a count-approval work operation in the organization. Physical inventory tasks divide the physical inventory process into self-contained work items. Each task can be executed by one or more workers, or by an automated system. The user interface enables a worker to receive the instructions necessary to execute a task and to input actual data into the system when prompted during the task. The Physical Inventory Count business object 160 is a document that records all data gathered when counting inventory, holds quantities available in inventory when counting, and instructs inventory adjustments.

FIG. 9 is a block diagram of an Engineering Change Processing process component 900 of the foundation layer. The Engineering Change Processing process component 900 performs the definition and processing of change management parameters for business objects in the product lifecycle phases engineering and manufacturing. As shown, the Engineering Change Processing process component 900 includes an Engineering Change Order business object 902. The Engineering Change Order business object 902 is an object that controls the alteration of possibly different objects over time and their usage by means of other parameters. FIG. 10 is a block diagram of an Installed Base Data Processing process component 1000 of the foundation layer. The Installed Base Data Processing process component 1000 enables a company to manage and structure business objects within installations by their logical or physical location concerning functional aspects. An installation collects business objects (e.g., personal computers or parts of a software installation) to identify them in later service or maintenance processes. As shown, the Installed Base Data Processing process component 1000 includes an Installed Base business object 1002 and an Installation Point business object 1004.

The Installed Base business object 1002 is a container that holds structured information of business components and their compositions as well as their business features. Installed base components carry properties of business objects (e.g., material or individual material) which have been assigned to an installed base. They can be multi-level structured, are time dependent and contain descriptive information about their corresponding business component. For example, the content of an installed base component might be the address and/or application specific extensions. Examples of use include a service provider's view of installed products at the customer site (e.g., CRM-service) and in-house administration of business objects for internal and external service.

The Installation Point business object 1004 describes the time-dependent assignment of a business component to installed bases. The installation point contains time-dependent descriptive information of its assigned business component and can have relationships with other installation points within a hierarchical structure. The contents stored at installation point level for its corresponding business component could be, for example, an address and/or application-specific extensions.

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, hi certain implementations, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims. What is claimed is:

Claims

CLAJMS

1. A system comprising: a computer system comprising one or more hardware platforms for executing computer software;

5 computer software deployed on the computer system, the computer software implementing a plurality of service operations, the service operations comprising: a create production bill of material operation operable to send a notification to create a production bill of material; and a confirm production bill of material transmission operation operable to send a o notification to confirm a transmission of a production bill of material.

2. The system of claim 1, wherein the service operations further comprise: a maintain inbound delivery request operation operable to send a notification to maintain inbound delivery request; a confirm fulfillment operation operable to send a notification to confirm fulfillment 5 of operation; a notify of received inbound delivery operation operable to send a notification about a reception of an inbound delivery; a notify of invoicing due operation operable to send a notification about an invoicing due; 0 a confirm production request operation operable to send a notification to confirm production request; a notify of production progress operation operable to a notification about production progress; a notify of inventory change and activity confirmation operation operable to send a 5 notification to confirm inventory change and activity; a notify of inventory change and activity confirmation cancellation operation operable to send a notification to cancel an inventory change and activity confirmation; a notify of production lot status change operation operable to send a notification about a change in production lot status; a maintain site logistics request operation operable to send a notification to maintain site logistics request; a confirm site logistics request operation operable to send a notification to confirm a site logistics request; a maintain production request operation operable to send a notification to maintain production request; a notify of site logistics request progress operation operable to send a notification about progress of a site logistics request; a notify of inventory change operation operable to send a notification about an inventory change; a notify of inventory change and activity provision cancellation operation operable to send a notification to cancel inventory change and activity provision; a maintain outbound delivery request operation operable to send operable to send a notification to maintain a delivery request; a notify of outbound delivery operation operable to send operable to send a notification about an outbound delivery; and a request invoicing operation operable to request an invoice.

3. The system of claim 1 or 2, wherein the service operations are grouped into service interfaces, the service interfaces comprising: a production bill of material transmission receiving in interface that includes the create production bill of material operation; a released execution production model transmission receiving out interface that includes the confirm released execution production model transmission operation; a production bill of material transmission receiving out interface that includes the production bill of material confirms its creation success to the external production model processing operation; a production bill of material transmission receiving out interface that includes the confirm production bill of material transmission operation; a fulfillment in interface that includes the maintain inbound delivery request operation; a fulfillment out interface that includes the confirm fulfillment operation; a delivery notification out interface that includes the notify of received inbound delivery operation; an invoice verification out interface that includes the notify of invoicing due operation; a producing in interface that includes the maintain production request operation; a producing out interface that includes the confirm production request and the notify of production progress operations; a production accounting out interface that includes the notify of production lot status change operation; a site logistics processing in interface that includes that maintain site logistics request operation; a site logistics processing out interface that includes the confirm site logistics request and the notify of site logistics request progress operations; a fulfillment in interface the includes the maintain outbound delivery request operation; a fulfillment out interface the includes the confirm fulfillment operation; a delivery notification out interface the includes the notify of outbound delivery operation; and a request invoicing out interface the includes the request invoicing operation.

4. The system of any one of claims 1 to 3, wherein the computer software deployed on the computer system comprises: a plurality of process components, each of the process components being a package of software deployed and executing on the computer system and implementing a respective and distinct business process, the plurality of process components including: an inbound delivery processing process component, a site logistics processing process component, an outbound delivery processing process component, a material inspection processing process component, a confirmation and inventory process component, a physical inventory processing process component, an engineering change processing process component, an installed base data processing process component, and a production model processing process component; and wherein: the inbound delivery processing process component implements the maintain inbound delivery request, the confirm fulfillment, the notify of received inbound delivery, and the notify of invoicing due service operations; the production process component implements the maintain production request, the confirm production request, the notify of production progress, the notify of inventory change and activity confirmation, the notify of inventory change and activity confirmation cancellation, and the notify of production lot status change service operations; the site logistics processing process component implements the maintain site logistics request, the confirm site logistics request, the notify of site logistics request progress, the notify of inventory change and activity provision, the notify of inventory change and activity provision cancellation, and the notify of inventory change service operations; the outbound delivery processing process component implements the maintain outbound delivery request, the confirm fulfillment, the notify of outbound delivery, and the request invoicing service operations; the material inspection processing process component implements services for quality inspection steps which have to be performed to check that a material fulfills its specified requirements; the confirmation and inventory process component implements the notify of inventory change and activity confirmation, the notify of inventory change and activity confirmation cancellation, and the notify of inventory change service operations; the physical inventory processing process component implements services that manages the execution of inventory counting within a logistic site; the engineering change processing process component implements services that perform the definition and processing of change management parameters for business objects in the engineering and the manufacturing product lifecycle phases; the installed base data processing process component implements services to manage and structure business objects within installations by their logical or physical location; and the production model processing process component implements the computer software implementing the create release execution production model, the cancel release execution production model, the create release planning production model, the cancel release planning production model, the confirm released execution production model transmission, and the confirm released execution production model transmission service operations.

5. The system of any one of claims 1 to 4, wherein the computer software deployed on the computer system comprises: a logistics execution deployment unit to process logistics operation, the deployment unit being a package of software packaged together to be deployed on a single physical hardware platform; wherein: the logistics execution deployment unit implements the maintain inbound delivery request, the confirm fulfillment, the notify of received inbound delivery, the notify of invoicing due, the maintain production request, the confirm production request, the notify of production progress, the notify of inventory change and activity confirmation, the notify of inventory change and activity confirmation cancellation, the notify of production lot status change, the maintain site logistics request, the confirm site logistics request, the notify of site logistics request progress, the notify of inventory change and activity provision, the notify of inventory change and activity provision cancellation, the notify of inventory change, the maintain outbound delivery request, the confirm fulfillment, the notify of outbound delivery, the request invoicing, and the notify of inventory change service operations.

6. The system of any one of claims 1 to 5, further comprising: a repository of service descriptions, the repository including a standards-based description of each of the plurality of service operations.

7. A computer program product encoded on a tangible machine-readable information carrier for implementing a plurality of services, the product comprising computer software operable to implement service operations on a computer system, the service operations comprising: a confirm production bill of material transmission receiving out operation operable to confirm its creation success to the External Production Model Processing; a create production bill of material operation operable to send operable to send a notification to create a production bill of material; and a confirm production bill of material transmission operable to send operable to send a notification to confirm a transmission of a production bill of material.

8. The product of claim 7, wherein the service operations further comprise: a maintain inbound delivery request operation operable to send a notification to maintain inbound delivery request; a confirm fulfillment operation operable to send a notification to confirm fulfillment of operation; a notify of received inbound delivery operation operable to send a notification about a reception of an inbound delivery; a notify of invoicing due operation operable to send a notification about an invoicing due; a maintain production request operation operable to send a notification to maintain production request; a confirm production request operation operable to send a notification to confirm production request; a notify of production progress operation operable to send a notification about production progress; a notify of inventory change and activity confirmation operation operable to send a notification to confirm inventory change and activity; a notify of inventory change and activity confirmation cancellation operation operable to send a notification to cancel an inventory change and activity confirmation; a notify of production lot status change operation operable to send a notification about a change in production lot status; a maintain site logistics request operation operable to send a notification to maintain site logistics request; a confirm site logistics request operation operable to send a notification to confirm a site logistics request; a notify of site logistics request progress operation operable to send a notification about progress of a site logistics request; a notify of inventory change and activity provision operation operable to send a notification about inventory change and activity provision; a notify of inventory change and activity provision cancellation operation operable to send a notification to cancel inventory change and activity provision; a notify of inventory change operation operable to send a notification about an inventory change; a maintain outbound delivery request operation operable to send a notification to maintain a delivery request; a confirm fulfillment operation operable to send a notification to confirm a fulfillment of a delivery request; a notify of outbound delivery operation operable to send a notification about an outbound delivery; a request invoicing operation operable to send requesting an invoice; and a notify of inventory change operation operable to send a notification about an inventory change.

9. The product of claim 7 or 8, wherein the computer software comprises: a plurality of process components, each of the process components being a package of software deployed and executing on the computer system and implementing a respective and distinct business process, the plurality of process components including: an inbound delivery processing process component, a site logistics processing process component, an outbound delivery processing process component, a material inspection processing process component, a confirmation and inventory process component, a physical inventory processing process component, an engineering change processing process component, an installed base data processing process component, a production model processing process component; and wherein: the inbound delivery processing process component implements the maintain inbound delivery request, the confirm fulfillment, the notify of received inbound delivery, and the notify of invoicing due service operations; the production process component implements the maintain production request, the confirm production request, the notify of production progress, the notify of inventory change and activity confirmation, the notify of inventory change and activity confirmation cancellation, and the notify of production lot status change service operations; the site logistics processing process component implements the maintain site logistics request, the confirm site logistics request, the notify of site logistics request progress, the notify of inventory change and activity provision, the notify of inventory change and activity provision cancellation, and the notify of inventory change service operations; the outbound delivery processing process component the maintain outbound delivery request, the confirm fulfillment, the notify of outbound delivery, and the request invoicing service operations; the material inspection processing process component implements services for quality inspection steps which have to be performed to check that a material fulfills its specified requirements ; the confirmation and inventory process component implements the confirmation and inventory process component implements the notify of inventory change and activity confirmation, the notify of inventory change and activity confirmation cancellation, and the notify of inventory change service operations; the physical inventory processing process component manages the execution of inventory counting within a logistic site; the engineering change processing process component implements services that perform the definition and processing of change management parameters for business objects in the engineering and the manufacturing product lifecycle phases; the installed base data processing process component implements services to manage and structure business objects within installations by their logical or physical location; and the production model processing process component implements the computer software implementing the create release execution production model, the cancel release execution production model, the create release planning production model, the cancel release planning production model, the confirm released execution production model transmission, and the confirm released execution production model transmission service operations.

10. The product of any one of claims 7 to 9, wherein the computer software comprises: a logistics execution deployment unit to process logistics operation, the deployment unit being a package of software packaged together to be deployed on a single physical hardware platform; wherein: the logistics execution deployment unit includes a confirmed inbound delivery, an inbound delivery request, an inbound delivery, a production task, a production order, a production request, a production confirmation, a production lot, a site logistics task, a site logistics confirmation, a site logistics lot, a site logistics order, a site logistics request, a confirmed outbound delivery, an outbound delivery request, an outbound delivery, an inventory, a goods and activity confirmation, a physical inventory task, and a physical inventory count business object, and wherein: the confirmed inbound delivery business object is a confirmation that the specified goods have been received by the intended product recipient; the inbound delivery request business object is a document in the inbound delivery process containing relevant logistics data; the inbound delivery business object is a document containing delivery notes from the supplier; the production task business object reflects the work organization on the shop floor; the production order business object is used to model and to describe the production process down to execution level; the production request business object is a request for producing a certain quantity of product at a certain time; the production confirmation business object is a document that collects data with posted reference to a production order; the production lot business object is used to execute production; the site logistics task business object reflects the organization of work in a site or a warehouse; the site logistics confirmation business object is a document that collets data with posted reference to a site logistics order or site logistics request; the site logistics lot business object is an execution document used to collect data for a site logistics process and record its process; the site logistics order business object is used to describe the site logistics process down to the execution level; the site logistics request business object is a request to perform logistics operations; the confirmed outbound delivery business object is a confirmation from the intended product recipient that specified goods have been received; the outbound delivery request business object is a document in the outbound delivery process containing relevant logistics data from an initiator of a delivery process; the outbound delivery business object is a document containing delivery notes; the inventory confirmation business object represents an inventory in a stock keeping location; the goods and activity confirmation business object contains data reflecting an executed work that is not pre-planned; the physical inventory task business object is either a count or a count- approval work operation; and the physical inventory count business object is a document that records all data gathered when counting inventory.

11. The product of claim 9, wherein: each of the plurality of process components is assigned to no more than one deployment unit among multiple deployment units, and each deployment unit is deployable on a separate computer hardware platform independent of every other deployment unit; and all interaction between a process component in one deployment unit and any other process component in any other deployment unit takes place through the respective service operations of the two process components.

12. The product of claim 11, wherein the deployment units comprise: a logistics execution deployment that includes the inbound delivery processing process component, the site logistics processing process component, the outbound delivery processing process component, the material inspection processing process component, the confirmation and inventory process component, the physical inventory processing process component, the engineering change processing process component, the installed base data processing process component, and the production model processing process component.

13. The product of claim 9, further comprising: a logistics execution deployment that implements the maintain inbound delivery request, the confirm fulfillment, the notify of received inbound delivery, the notify of invoicing due, the maintain production request, the confirm production request, the notify of production progress, the notify of inventory change and activity confirmation, the notify of inventory change and activity confirmation cancellation, the notify of production lot status change, the maintain site logistics request, the confirm site logistics request, the notify of site logistics request progress, the notify of inventory change and activity provision, the notify of inventory change and activity provision cancellation, the notify of inventory change, the maintain outbound delivery request, the confirm fulfillment, the notify of outbound delivery, the request invoicing, and the notify of inventory change service operations.

14. The product of claim 9, wherein: the inbound delivery processing process component includes a confirmed inbound delivery, an inbound delivery request, and an inbound delivery business object, wherein: the confirmed inbound delivery business object is a confirmation that the specified goods have been received by the intended product recipient; the inbound delivery request is a document in the inbound delivery process containing relevant logistics data; and the inbound delivery business object is a document containing delivery notes from the supplier; the production processing process component includes a production task, a production order, a production request, a production confirmation, and a production lot business object, and wherein: the production task business object reflects the work organization on the shop floor; the production order business object is used to model and to describe the production process down to execution level; the production request business object is a request for producing a certain quantity of product at a certain time; the production confirmation business object is a document that collects data with posted reference to a production order; and the production lot business object is used to execute production; the site logistics processing process component includes a site logistics task, a site logistics confirmation, a site logistics lot, a site logistics order, and a site logistics request business object, wherein: the site logistics task business object reflects the organization of work in a site or a warehouse; the site logistics confirmation business object is a document that collects data with posted reference to a site logistics order or site logistics request; the site logistics lot business object is an execution document used to collect data for a site logistics process and record its process; the site logistics order business object is used to describe the site logistics process down to the execution level; and the site logistics request business object is a request to perform logistics operations; the outbound delivery processing process component includes a confirmed outbound delivery, an outbound delivery request, and an outbound delivery business object, wherein: the confirmed outbound delivery business object is a confirmation from the intended product recipient that specified goods have been received; the outbound delivery request business object is a document in the outbound delivery process containing relevant logistics data from an initiator of a delivery process; and the outbound delivery business object is a document containing delivery notes; the confirmation and inventory process component includes an inventory and a goods and activity confirmation business object, wherein: the inventory confirmation business object represents an inventory in a stock keeping location; and the goods and activity confirmation business object contains data reflecting an executed work that is not pre-planned; and the physical inventory processing process component includes a physical inventory task and a physical inventory count business object, wherein: the physical inventory task business object is either a count or a count- approval work operation; and the physical inventory count business object is a document that records all data gathered when counting inventory.

15. The product of any one of claims 7 to 14, wherein: each of the process components includes one or more business objects; and none of the business objects of any one of the process components interacts directly with any of the business objects included in any of the other process components.

16. The product of claim 15, wherein the business objects comprise a business process object.

17. The product of claim 15 or 16, wherein: none of the business objects included in any one of the process components is included in any of the other process components.

18. The product of any one of claims 7 to 17, further comprising: a plurality of process agents, each process agent being either an inbound process agent or an outbound process agent, an inbound process agent being operable to receive a message from an inbound operation, an outbound process agent being operable to cause an outbound operation to send a message, and each process agent being associated with exactly one process component; wherein: the inbound process agents comprise a first inbound process agent operable to start the execution of the step requested in a first inbound message by creating or updating one or more business object instances; and the outbound process agents comprise a first asynchronous outbound process agent that is called after a business object that is associated with the first outbound process agent changes.

19. A method for providing services from a computer system having logistics execution functionality, the method comprising: providing services through the sending of messages, the messages including: a notification to create release of an execution production model; a notification to cancel release of an execution production model; a notification to create release of a planning production model; a notification to cancel release of a planning production model; a confirmation of transmission of a released execution production model; a confirmation of transmission of a released planning production model; a notification to create a production bill of material; and a notification to confirm a transmission of a production bill of material.