PROVIDING SUPPLIER RELATIONSHIP MANAGEMENT SOFTWARE APPLICATION AS ENTERPRISE SERVICES
Methods and apparatus, including systems and computer program products, for a services architecture design that provides enterprise services having supplier relationship management 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.
Latest Patents:
- SYSTEMS AND METHODS FOR IMPROVING THE PERFORMANCE OF CEREAL USING A SILK FIBROIN SOLUTION AND POWDERS CONTAINING SILK FIBROIN
- MEDICAL TISSUE ADHESIVE AND PREPARATION METHOD THEREOF
- DISPLAY SUBSTRATE AND DISPLAY DEVICE
- METHOD FOR SECURING COMMUNICATION BETWEEN A COMMUNICATION SYSTEM OF A VEHICLE AND A VEHICLE-EXTERNAL SERVER
- DISPLAY DEVICE
This application is divisional application of and claims priority under 35 USC §121 to U.S. application Ser. No. 12/233,520, filed on Sep. 18, 2008, the entire contents of which are incorporated herein by reference.
BACKGROUNDThis 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.
SUMMARYThis specification describes a services architecture design that provides enterprise services having supplier relationship 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 supplier relationship management 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.
Like reference numbers and designations in the various drawings indicate like elements.
DETAILED DESCRIPTIONThe 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 some implementations, 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 “object” is generally clear from the context, so the distinction will be made explicitly only when necessary. Also, for convenience and brevity, an object instance may be described in this specification as being or including a real world event, activity, item, or the like; however, such description should be understood as stating that the object instance represents (i.e., contains data representing) the respective event, activity, item, or the like. Properly implemented, business objects are implemented free of redundancies.
Business objects are further categorized as business process objects and, 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 embodies or 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 its own persistency. The term business object will be used generically to refer to a business process object and a master data object, unless the context requires otherwise. Properly implemented, business objects are implemented free of redundancies.
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 includes the ability to perform all or parts of particular kinds of 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 optionally 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 implement multiple interfaces. In some implementations, an interface will have only inbound or outbound operations, but not a mixture of both. One interface can include 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 outbound process agent will generally perform some processing of the data of the business object instance whose change triggered the agent or caused the agent to be called. 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 to 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
The Purchase Order Processing process component 104 handles the creation and maintenance of purchase orders and purchase order confirmations. The Purchase Order Processing process component 104 includes a Purchase Order business object 106 and a Purchase Order Confirmation business object 108.
The Purchase Request Processing process component 110 handles the creation, changing, and processing of purchase requests to locate appropriate external sources of supply. The Purchase Request Processing process component 110 includes a Purchase Order Creation Run business object 111 and a Purchase Request business object 112.
The Purchasing Contract Processing process component 114 handles the creation and maintenance of purchasing contracts. The Purchasing Contract Processing process component 114 includes a Purchasing Contract business object 116.
The Goods and Service Acknowledgement process component 118 handles a confirmation by an employee of goods received or services rendered. The Goods and Service Acknowledgement process component 118 includes a Goods and Service Acknowledgement business object 120.
As shown in
As shown in
The RFQ Processing process component 202 can send a message to the Purchase Order Processing process component 104. The message can be received in a Create Purchase Order based on Winning Quote operation 212. The operation 212 creates a purchase order from an accepted supplier quote. The operation 212 is included in a Quote Award Notification In interface 214. The Create Purchase Order based on Winning Quote operation 212 uses an asynchronous inbound process agent 216 to update the Purchase Order business object 106. The Purchase Order business object 106 represents a request from a request from a buyer to a seller to deliver a specified quantity of material, or perform a specified service, at a specified price within a specified time.
The RFQ Processing process component 204 can send a message to the Purchase Order Processing process component 104. The can be received in a Create Purchase Order based on Winning Quote operation 218. The operation 218 can create a purchase order based on the data contained in a winning supplier quote. If the supplier quote refers to a purchase request, data from the purchase request items can be added by the operation to complete the purchase order.
The notification can be sent using an asynchronous inbound process agent 222 to update the Purchase Order business object 106. The Create Purchase Order based on Winning Quote operation 218 is included in a Quote Award Notification interface 220. An External Procurement Trigger and Response process component 206 can send a message to the Purchase Order processing component 104. The message can be received in a Change Purchase Order based on Delivery Values operation 224. The operation 224 can change a purchase order based on a delivery value by adding the quantity of a confirmed inbound delivery to the cumulated delivered quantity in node Item Actual Values of a purchase order. The operation can also add the reference to a the confirmed inbound delivery document to the purchase order. The notification can be sent using an asynchronous inbound process agent 228 to update the Purchase Order business object 106. The Change Purchase Order based on Delivery Values operation 224 is included in a Fulfillment In interface 226.
A Supplier Invoice Processing process component 124 can send a message to the Purchase Order processing component 104. The message can be received in a Change Purchase Order based on Invoiced Values operation 230. The operation 230 can change purchase order based on invoice values by adding the quantity and amount of a supplier invoice to the cumulated invoiced quantity and amount in node Item Actual Values of a purchase order. The operation also adds the reference to the supplier invoice document to the purchase order. The notification can be sent using an asynchronous inbound process agent 234 to update the Purchase Order business object 106. The operation 230 is included in Invoice Verification In interface 238.
An Inbound Delivery Processing third party process component 210 can send a message to the Purchase Order processing component 104. The message can be received in a Change Purchase Order based on Inbound Delivery Request 236. The operation 236 can create a purchase order based on migrated data. The notification can be sent using an asynchronous inbound process agent 240 to update the Purchase Order business object 106. The operation 236 is included in Purchase Order Inbound Delivery In 238.
The Sales Order Processing at Supplier process component 210 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
The Purchase Order business object 106 can receive updated information and can send the updated information into other components to perform further operations. The Purchase Order business object 106 is a request from a purchaser to an external supplier to deliver a specified quantity of goods, or services at a specified price within a specified time period. As shown in
An asynchronous outbound process agent 244 can invoke a Notify of Invoicing Due operation 246. The operation 246 notifies the Supplier Invoice Processing process component 124 about an invoice due, and when a Purchase Order has been created, changed or cancelled. The Notify of Invoicing Due operation 246 is included in an Invoice Verification Out interface 248.
An asynchronous outbound process agent 252 can invoke a Notify of Expected Delivery operation 254. The Notify of Expected Delivery operation notifies of an expected delivery. The request can be sent to the Supplier Invoice Processing process component 124. The Notify of Expected Delivery operation 254 is included in a Purchase Order Inbound Delivery Out interface 256.
An asynchronous outbound process agent 260 can invoke a Request Purchase Order Change operation 262. The operation 262 requests a change of a purchase order that was formerly ordered at the supplier. The request can be sent to the Sales Order Processing at Supplier process component 270. The asynchronous outbound process agent 260 can also invoke a Request Purchase Order Cancellation operation 264. The Request Purchase Order Cancellation operation 264 requests a cancellation of the purchase order that was formerly ordered at the supplier. The request can be sent to the Sales Order Processing at Supplier process component 270. The asynchronous outbound process agent 252 can also invoke a Request Purchase Order Creation operation 266. The Request Purchase Order Creation operation 266 requests a purchase order from the supplier. The request can be sent to the Sales Order Processing at Supplier process component 270. The Request Purchase Order Change operation 262, the Request Purchase Order Cancellation operation 264, and the Request Purchase Order Creation operation 266 are included in an Ordering Out interface 268.
The Sales Order Processing at Supplier process component 270 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
As shown in
An asynchronous outbound process agent 273 can also invoke the Notify of Purchase Order operation 275. The asynchronous outbound process agent 273 can send the notification about the purchase order to the Project Processing process component 278.
An asynchronous outbound process agent 274 can also invoke the Notify of Purchase Order operation 275. The asynchronous outbound process agent 274 can send the notification about the purchase order to the Internal Request Processing process component 132.
An asynchronous outbound process agent 280 can invoke a Notify of Purchase Order operation 281. The operation 281 notifies about created, changed, or cancelled purchase orders. The operation 281 is included in a Sales and Purchasing Accounting Out interface 282. The asynchronous outbound process agent 280 can send the notification about the purchase order to the Accounting process component 283.
An asynchronous outbound process agent 284 can invoke a Notify of Purchase Order operation 285. The asynchronous outbound process agent 284 can send a notification about the purchase order that has been created, changed, or canceled to the Time and Labor Management process component 287. The Notify of Purchase Order operation 285 is included in an Employee Time Confirmation View or Service Transaction Document Management Out interface 286.
An asynchronous outbound process agent 288 can invoke a Request Supplier Invoice Request operation 289. The operation 289 can request supplier invoice request migration based on the migrated purchase order data and/or purchase order delivery values. The operation 289 is included in a Supplier Invoice Request Migration Out interface 290. The asynchronous outbound process agent 288 can send the notification about the purchase order to the Supplier Invoice Processing process component 124.
A Sales Order Processing at Supplier operation 292 can send a message to the Purchase Order Processing process component 104. The message can be received in a Create Purchase Order Confirmation operation 293. The operation 293 is included in an Ordering In interface 294. The Create Purchase Order Confirmation operation 293 creates a purchase order confirmation according to the confirmation, partial confirmation, or proposed changes sent from the seller to the buyer concerning the requested delivery of product to trigger the creation of a purchase order confirmation. The operation 293 uses an asynchronous inbound process agent 295 to update the Purchase Order Confirmation business object 108. The Purchase Order Confirmation business object 108 represents a confirmation from a seller to deliver a specified quantity of goods, or perform a specified service, at a specified price within a specified time.
The Sales Order Processing at Supplier process component 292 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
The RFQ Processing process component 302 can send a message to the Purchase Request Processing process component 110. The message can be received in a Change Purchase Request operation 304. The operation 304 can change purchase request based on request for quote execution. The operation 304 is included in a Request for Quote In interface 306. The Change Purchase Request operation 304 can use an asynchronous inbound process agent 308 to update the Purchase Request business object 114. The purchase request business object 114 represents a request or instruction to the purchasing department to purchase specified goods or services in specified quantities at a specified price within a specified time.
The Internal Request Processing process component 132, the External Procurement Trigger and Response process component 312, or the Project Processing process component 314 can send a request message to the Maintain Purchase Request process component 316. A Maintain Purchase Request operation 316 can create or update a request from a requestor to a purchaser to (externally) procure materials and/or services, i.e. create or update a purchase request. The operation 316 uses an asynchronous inbound process agent 320 to update the Purchase Request business object 114. The Maintain Purchase Request operation 316 is included in a Purchasing In interface 318.
As shown in
An asynchronous outbound process agent 328 can receive updated information from the Purchase Request business object 114 and invoke a Confirm Purchase Request operation 330. The Confirm Purchase Request operation 330 confirms the creation, change or cancellation of a purchase request to the requestor. The asynchronous outbound process agent 328 can invoke the operation 330 to update the Internal Request Processing process component 132, the External Procurement Trigger and Response process component 312, or the Project Processing process component 314. The Confirm Purchase Request operation 330 is included in a Purchasing Notification Out interface 332.
As shown in
A Change Purchasing Contract based on RFQ Execution operation 416 can also receive a message from the RFQ Processing process component 302. The operation 416 can confirm the creation of an RFQ and maintain the reference of the newly created request for quote in the purchasing contract. The operation 416 is included in a Request for Quote In interface 418. The Change Purchasing Contract based on RFQ Execution operation 416 can use an asynchronous inbound process agent 420 to update the Purchasing Contract business object 118.
The Data Migration System process component 401 can send a message to the Purchasing Contract Processing process component 118. The message can be received in a Create Purchasing Contract operation 404. The operation 404 creates a purchasing contract based on migrated data. The operation 404 is included in the Migration In interface 406. The Create Purchasing Contract operation 404 can use an asynchronous inbound process agent 408 to update the Purchasing Contract business object 118.
The Supplier Invoice Processing process component 124 can send a message to the Purchasing Contract Processing process component 116. The message can be received in a Maintain Purchasing Contract Release operation 422. Also, the Purchasing Scheduling Agreement process component 402 can be received in the Maintain Purchasing Contract Release operation 422. The operation 422 creates or updates releases in the purchasing contract. The operation 422 is included in a Contract Release In interface 424. The Maintain Purchasing Contract Release operation 422 can use an asynchronous inbound process agent 426 to update the Purchasing Contract business object 118.
The Purchasing Contract business object 118 can receive updated information and send the update into other components to perform further operations. As shown in
An asynchronous outbound process agent 428 can invoke a Notify of Purchase Schedule Agreement operation 430. The operation 430 can notify if there is a purchase scheduling agreement. The asynchronous outbound process agent 428 can invoke the operation 430 to update the Purchase Scheduling Agreement process component 402. This process component is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system. The Notify of Purchase Schedule Agreement operation 430 is included in a Purchase Schedule Agreement Replication Out interface 432.
An asynchronous outbound process agent 434 can invoke a Request Request for Quote Execution operation 436 or a Request Request for Quote Cancellation operation 438. The Request Request for Quote Execution operation 436 creates a request for quote request from a purchasing contract that is in the negotiation process or inform existing request for quote requests about a canceled negotiation process. The Request Request for Quote Cancellation operation 438 requests the cancellation of a request for quote for a running purchasing contract negotiation process. For example, the outbound process agent 434 can invoke the operation 436 to send a message to the RFQ Processing process component 302 or the outbound process agent 434 can invoke the operation 438 to send a message to the RFQ Processing process component 302.
An asynchronous outbound process agent 442 can invoke a Notify of Product Catalog operation 444. The operation 444 can notify if there is a product catalog. The asynchronous outbound process agent 442 can invoke the operation 444 to update the Product Catalog Authoring process component 448. This process component is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system. The Notify of Product Catalog operation 430 is included in a Product Catalogue Authoring Out interface 446.
An asynchronous outbound process agent 450 can invoke a Notify of Invoicing Due operation 452. The operation 452 creates a new supplier invoicing request or updates an existing supplier invoice request from a released purchasing contract. For example, the outbound process agent 450 can invoke the operation 452 to send a message to the Supplier Invoice Processing process component 124. The Notify of Invoicing Due operation 452 is included in an Invoice Verification Out interface 454.
An asynchronous outbound process agent 456 can invoke a Notify of Purchasing Contract operation 458. The operation 458 can notify the supplier about a purchasing contract when it is released and is used in operational purchasing processes. For example, the outbound process agent 456 can invoke the operation 458, in a Contracting Notification Out interface 460, to send a message regarding the purchasing contract to a Sales Contract Processing at Supplier process component 462. This process component is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
An asynchronous outbound process agent 464 can invoke a Notify of Project Task Assignment operation 466. The operation 466 can notify of purchasing contract project task assignments. For example, the outbound process agent 464 can invoke the operation 466 to send a message regarding a project task assignment to a Supplier Invoice Processing process component 124. The Notify of Project Task Assignment operation 466 is included in a Project Task Assignment Notification Out interface 468.
An asynchronous outbound process agent 470 can invoke a Confirm Purchasing Contract operation 472. The operation 472 can confirm a purchasing contract creation and/or update. For example, the outbound process agent 470 can invoke a Confirm Purchasing Contract operation 472 to send a message regarding confirmation of a new creation of a purchasing contract to a Supplier Invoice Processing process component 124. The Confirm Purchasing Contract operation 472 is included in a Purchasing Contract Out interface 474.
A synchronous outbound process agent 476 can invoke a Request Project Task Accountability Information operation 478. The operation 478 can check the project task accountability. For example the synchronous outbound process agent 476 can evoke a Request Project Task Accountability Information operation 478 to send a message regarding the project task accountability information to a Project Processing process component 314. The Request Project Task Accountability Information operation 478 is included in Project Task Accountability Out interface 480.
As shown in
The Internal Request Processing process component 132 can send a message to the Goods and Service Acknowledgement process component 120. The message can be received in a Create Goods and Service Acknowledgement operation 510. The operation 510 creates a goods and service acknowledgement based on time recording or express confirmation in internal request processing. An update regarding the created acknowledgement can be sent to the Goods and Service Acknowledgement business object 122 using the asynchronous inbound process agent 508. The Cancel Goods and Service Acknowledgement operation 506 and the Create Goods and Service Acknowledgement operation 510 are included in an Internal Acknowledgement In interface 512. The Goods and Service Acknowledgement business object 122, in some implementations represents a document that reports the receipt of goods and services.
The Goods and Service Confirmation at Supplier process component 514 can send a message to the Goods and Service Acknowledgement process component 120. The message can be received in a Create Goods and Service Acknowledgement operation 510. The operation 516 can create a goods and service acknowledgement. A creation acknowledgement can be sent to the Goods and Service Acknowledgement business object 122 using the asynchronous inbound process agent 520. The Create Goods and Service Acknowledgement operation is included in an Acknowledgement In interface 518.
As shown in
An asynchronous outbound process agent 521 can invoke a Notify of Project Expense operation 522. The outbound process agent 521 can send a notification on a project expense for items in a purchase order. The notification can be sent to the Customer Project Invoice Preparation processing component 526. This process component is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system. The Notify of Project Expense operation 522 is included in a Project Expense Notification interface 524.
An asynchronous outbound process agent 528 can invoke a Notify of Invoicing Due operation 530. The outbound process agent 528 can send a notification of an invoice due for goods and services in a purchase order. The notification can be sent to the Supplier Invoice Processing process component 124. The Notify of Invoicing Due operation 530 is included in an Invoice Verification Out interface 532.
An asynchronous outbound process agent 534 can invoke a Notify of Goods and Service Acknowledgement operation 536. The operation 536 can notify a financial accounting about delivered goods and rendered services of a goods and service acknowledgement. The notification can be sent to the Accounting process component 283. The asynchronous outbound process agent 534 can also invoke a Notify of Goods and Service Acknowledgement Cancellation operation 538. The operation 538 can notify a financial accounting about goods and services acknowledgement cancellation. The notification can be sent to the Accounting process component 283. The Notify of Goods and Service Acknowledgement operation 536 and the Notify of Goods and Service Acknowledgement Cancellation operation 538 are included in a Goods and Service Accounting Out interface 540.
An asynchronous outbound process agent 542 can invoke a Confirm Goods and Service Acknowledgement operation 544. The operation 544 can confirm a goods and services acknowledgement. The notification can be sent to the Goods and Service Confirmation at Supplier process component 514. This process component is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system. The Confirm Goods and Service Acknowledgement 544 is included in a Acknowledgement Out interface 546.
A Maintain Invoice Request operation 614 can send information using an asynchronous inbound process agent 618 to update the Supplier Invoice Request business object 126. The Supplier Invoice Request business object 126 can be a request sent to invoice verification advising that a supplier invoice for specified quantities and prices is expected or is to be created through evaluation settlement. The operation 614 can create or update a reference object in the Supplier Invoice Processing deployment unit 122 in order to perform invoice verification with reference to a purchase order for example without having to access other deployment units. The reference object is used for checks against the preceding documents and to make proposals for invoice entry. The operation 614 can send a request to update the Supplier Invoice Request business object 126 if one or more messages are received from the Purchase Order Processing process component 104, the Inbound Delivery Processing process component 201, the Goods and Service Acknowledgement process component 122, or the Purchasing Contract Processing process component 116. The Maintain Invoice Request operation 614 is included in an Invoice Verification In interface 616.
A Create Supplier Invoice Request operation 608 can send information using an asynchronous inbound process agent 612 to update the Supplier Invoice Request business object 126. The operation 608 can create a supplier invoice request based on a migrated purchase order and/or based on migrated actual values of the migrated purchase order. The Create Invoice operation 608 is included in an Supplier Invoice Request Migration In interface 610.
An asynchronous outbound process agent 684 can invoke a Notify of Invoice Values operation 685. The outbound process agent 684 can send a notification to the Purchase Order that at least parts of it have already been invoiced. The notification can be sent to the Purchase Order Processing process component 104. The Notify of Invoice Values operation 685 is included in an Invoice Verification Out interface 686.
As shown in
The Supplier Invoice Verification Exception business object 129 represents a group of related issues arising during a supplier invoice verification process. The issues causing the exception are bundled according to certain business criteria. A complex follow-up clarification process is used to resolve the issues.
The Supplier Invoice Verification Exception business object 129 can receive updated information and send the update into other components to perform further operations. An asynchronous outbound process agent 691 invokes a Request Exception Resolution operation 692. The Request Exception Resolution operation 692 requests the clarification of a supplier invoice verification exception from an external party. The asynchronous outbound process agent 691 can use the Request Exception Resolution operation 692 to update the Supplier Invoice Verification Exception Resolution at Processor process component 694. The Request Exception Resolution operation 692 is included in an Exception Resolution Out interface 693.
A Create Invoice operation 624 can send information using an asynchronous inbound process agent 628 to update the Supplier Invoice business object 128. The operation 624 can create supplier invoices from legally binding claims or liabilities for delivered goods and rendered services. The Create Invoice operation 624 is included in an Internal Invoicing In interface 626.
The Internal Request Processing process component 620 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
A Create Invoice operation 630 can send information using an asynchronous inbound process agent 634 to update the Supplier Invoice business object 128. The operation 630 can create supplier invoices from legally binding claims or liabilities for delivered goods and rendered services. The Create Invoice operation 630 is included in an Invoicing In interface 632.
A Create Invoice based on Attachment operation 636 can send information using an asynchronous inbound process agent 640 to update the Supplier Invoice business object 128. The operation 620 can send a supplier invoice request to update the Supplier Invoice business object 128 if one or more messages is received from the Customer Invoice Processing at Supplier process component 622. The Create Invoice operation 636 is included in an Image Recognition Invoicing In interface 638.
The Customer Invoice Processing at Supplier process component 622 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
The Supplier Invoice Request business object 126 can receive updated information and send the update into other components to perform further operations. The Supplier Invoice Request business object 126 represents a recipient's (usually the purchaser's) obligation to pay the supplier for goods received or services rendered. As shown in
As shown in
An asynchronous outbound process agent 660 can invoke a Notify of Invoice operation 662. The outbound process agent 660 can send a notification to the due item processing system about payments and taxes that are due based on a posted supplier invoice. The notification can be sent to the Due Item Processing process component 668. The asynchronous outbound process agent 660 can also invoke a Notify of Invoice Cancellation operation 664. The outbound process agent 660 can send a notification to the due item processing system about a previously posted supplier invoice that is canceled. The notification can be sent to the Due Item Processing process component 668. The Notify of Invoice operation 662 and the Notify of Invoice Cancellation operation 664 are included in a Receivables Payables Out interface 666.
An asynchronous outbound process agent 642 can invoke a Notify Billing Due operation 644. The notification can be sent to the Customer Invoice Processing process component 650. The Notify Billing Due operation 644 is included in a Invoice Verification Out interface 645. An asynchronous outbound process agent 643 can invoke a Notify of Project Expense operation 646. The notification can be sent to the Customer Project Invoice Preparation process component 652. The Notify of Project Expense operation 646 is included Project Expense Notification Out interface 648.
An asynchronous outbound process agent 669 can invoke a Confirm Invoice operation 670. The notification can be sent to the Customer Invoice Processing at Supplier process component 622. The Confirm Invoice operation 670 is included in an Invoicing Out interface 671.
An asynchronous outbound process agent 672 can invoke a Request ERS Invoice operation 673. The outbound process agent 672 can inform the seller party about a supplier invoice created by the buyer party using the credit memo procedure (Evaluated Receipt Settlement). The notification can be sent to the Customer Invoice Processing at Supplier process component 622. The Request ERS Invoice operation 673 is included in an ERS Invoicing Out interface 674.
An asynchronous outbound process agent 675 can invoke a Notify of Contract Release operation 676. The outbound process agent 675 can notify the purchasing system about the posting of a supplier invoice that contains a reference to a purchasing contract. The notification can be sent to the Purchasing Contract Processing process component 606. The Notify of Contract Release operation 676 is included in an Contract Release Out interface 677.
An asynchronous outbound process agent 678 can invoke a Notify of Invoice operation 679. The operation 679 can notify the foreign payment processing system about a posted supplier invoice. The notification can be sent to the Balance of Foreign Payment Management process component 682. Also, the asynchronous outbound process agent 678 can invoke a Notify of Invoice Cancellation operation 680. The notification can be sent to the Balance of Foreign Payment Management process component 682. The Notify of Invoice operation 679 and the Notify of Invoice Cancellation operation 680 are include in a Foreign Receivable Payable Notification interface 681.
As shown in
The Purchase Order Processing process component 104 can send a message to the Internal Request Processing process component 132. The message can be received in a Change Internal Request based on Purchase Order operation 710. The operation 710 is included in an Ordering Notification In interface 712. The operation 710 can change an internal request based on the notification of the buyer that informs the requestor about the progress of procurement, meaning changing of follow-on documents, for example, the creation of goods and service acknowledgement including the amount of received goods as well as the creation of supplier invoices. The Change Internal Request based on Purchase Order operation 710 uses an asynchronous inbound process agent 714 to update the Internal Request business object 134 about a changed internal request.
The In-House Requirement Processing process component 702 can send a message to the Internal Request Processing process component 132. The message can be received in a Change Internal Request Based on Fulfillment Confirmation operation 716. The operation 702 uses an asynchronous inbound process agent 722 to update the Internal Request business object 134. Also, a Change Internal Request based on Availability Update operation 718 uses the asynchronous inbound process agent 722 to update the Internal Request business object 134. The Change Internal Request Based on Fulfillment Confirmation operation 716 and the Change Internal Request based on Availability Update operation 718 are included in an Internal Fulfillment In interface 720.
As show in
The In-House Requirement Processing process component 702 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
As shown in
An asynchronous outbound process agent 740 can invoke a Request GSA based on Delivery Confirmation operation 742. The operation 742 can request express confirmation of goods and services for an internal request item. The Request GSA based on Delivery Confirmation operation 742 is included in an Internal Acknowledgement Out interface 744. The Request GSA based on Delivery Confirmation operation 742 can send an update notification to the Goods and Service Acknowledgement process component 122.
An asynchronous outbound process agent 746 can invoke a Request Invoicing based on Invoice Acceptance operation 748. The operation 748 can send a request for an invoice based on various invoice acceptance terms. The Invoice Acceptance operation 748 is included in an Internal Invoicing out interface 750. The operation 748 can send an update notification to the Supplier Invoice Processing process component 124.
The Supplier Invoice Processing process component 124 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
An asynchronous outbound process agent 752 can invoke a Request In-House Requirement Reservation and Fulfillment operation 754. The operation 754 can send a request for a requirement, reservation, and fulfillment from in-house. The Request In-House Requirement Reservation and Fulfillment operation 754 is included in an Internal Fulfillment Out interface 756. Request In-House Requirement Reservation and Fulfillment operation 754 can send updates to the In-House Requirement Processing process component 702.
The In-House Requirement Processing process component 702 is drawn with dashed lines to indicate that it is used to represent an external system in describing interactions with the external system; this should be understood to require no more of the external system than that it be able to produce and receive messages as required by the process component that interacts with the external system.
The Purchase Request Processing process component 110 can send a message to the RFQ Processing process component 800. The message can be received in a Maintain RFQ Request operation 802 or a Cancel RFQ Request operation 804. The Maintain RFQ Request operation 802 creates an RFQ request from business documents that are involved in the bidding process or in the negotiation process. The Cancel RFQ Request operation 804 can cancel an RFQ request and cancels the corresponding bidding process (this is, the operation cancels the corresponding request for quote if one has been initiated). The operations 802, 804 are included in a Request for Quote In interface 806. The operations 802, 804 can use an asynchronous inbound process agent 808 to update the RFQ Request business object 810. The RFQ Request business object 810 represents a request to the purchasing department to prepare a request for quote.
The RFQ Request business object 810 uses an asynchronous outbound process agent 811 to invoke a Confirm RFQ Request operation 812. The operation 812 confirms execution of the request for quote. The operation 812 is included in a Request for Quote Out interface 814. The Confirm RFQ Request operation 812 can send an update to the Purchase Request Processing process component 110 and the Purchasing Contract Processing process component 116.
The Purchasing Contract Processing process component 116 (
As shown in
The Supplier Quote business object 822 can use an asynchronous outbound process agent 832 to invoke a Request Purchase Order from Winning Quote operation 838. The operation 838 can request a purchase order based on the awarded respective winning supplier quote. The operation 838 is included in a Quote Award Notification Out interface 840. The Request Purchase Order from Winning Quote operation 838 can send an update message to the Purchase Order Processing process component 104.
The Supplier Quote business object 136 can use a Request Purchasing Contract from Supplier Quote to Purchasing Contract Processing asynchronous outbound process agent 842 to invoke a Request Contract from Winning Quote operation 844. The operation 844 creates or updates a purchasing contract based on an accepted supplier quote. The Request Contract from Winning Quote operation 844 is included in a Purchasing Contract Out interface 846. The operation 844 can send an update message to the Purchasing Contract Processing process component 114.
The Supplier Quote business object 822 can use an asynchronous outbound process agent 848 to invoke a Request Quote Change operation 850. The operation 850 can request the change of the customer quote. The Supplier Quote business object 822 can also use the asynchronous outbound process agent 848 to invoke a Notify of Quote Award operation 854. The operation 854 can notify the bidder either about supplier quote items for which the quotation from the bidder has been awarded, including extending the award or about a rejection if the quotation from the bidder is not successful. The operations 850, 854 are included in a Quote Processing Out interface 856. The operations 850, 854 can send an update message to the Opportunity/Customer Quote Processing at Supplier process component 824.
As shown in
The Request for Quote business object 858 can also use an asynchronous outbound process agent 866 to invoke a Notify of Project Task Assignment operation 868. The operation 868 can notify of a request for quote project task assignment. The Notify of Project Task Assignment operation 868 is included in a Project Task Assignment Notification Out interface 870. The operation 868 can send messages to the Project Processing process component 278.
Furthermore, the Request for Quote Business object 858 can also use an asynchronous outbound process agent 872 to invoke a Request Quote Creation operation 874, a Notify of Request for Quote Cancellation operation 876, or a Notify of Request for Quote Change operation 878. The Request Quote Creation operation 874 can request the participation of the supplier in a bidding process. The Notify of Request for Quote Cancellation operation 876 can notify the supplier about the cancellation of a request for quote. The Notify of Request for Quote Change operation 878 can notify the supplier about changes to a request for quote. The operations 874, 876, and 878 are included in a Request Quote Processing Out interface 880. The operations 874, 876, and 878 can be used to send an update to the Opportunity/Customer Quote Processing at Supplier process component 824.
As shown in
The Purchase Order Processing process component 104 can send a message to a Supplier Performance Assessment process component 900. The message can be received in a Maintain Supplier Transaction Assessment operation 912. The operation 912 can use an asynchronous inbound process agent 916 to update the Supplier Transaction Assessment business object 910. The Maintain Supplier Transaction Assessment operation 912 is included in a Ordering Notification In interface 914.
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 specific implementation details, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as illustrating 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 readable medium including program code for providing message-based services using a service-oriented methodology for implementing an instance of a deployment unit, the medium comprising:
- program code for storing an instance of a supplier invoicing deployment unit for the management and volume processing of supplier invoices, including exception handling and approval, where the supplier invoicing deployment unit defines the limits of an application-defined transaction for the management and volume processing of supplier invoices, including exception handling and approval by a set of actions that have atomicity, consistency, isolation, and durability in a database, and wherein the actions associated with the application-defined transaction are performed by one or more process components contained in the supplier invoicing deployment unit, wherein each process component comprises a software package realizing a business process and exposing its functionality as one or more service operations, wherein the supplier invoicing deployment unit comprises: a create supplier invoice request operation, a notify billing due operation, a notify of contract release operation, an update supplier invoice verification exception operation, a confirm invoice operation, a create invoice operation, a notify of invoice operation, a request Evaluated Receipt Settlement (ERS) invoice operation, a notify of invoice operation, a notify of invoice operation, a create invoice based on attachment operation, a notify of invoice values operation, a request exception operation, a resolution operation, a notify of supplier invoice operation, a maintain invoice request operation, a create invoice operation, a first notify of invoice cancellation operation, a second notify of invoice cancellation operation, and a third notify of invoice cancellation operation; wherein the service operations of the supplier invoice processing deployment unit are packaged together to be deployed on a single computer system; and program code for executing the application-defined transaction for the management and volume processing of supplier invoices, including exception handling and approval; and program code for presenting data associated with the executed application-defined transaction for the management and volume processing of supplier invoices, including exception handling and approval to a graphical user interface.
2. The medium of claim 1, wherein the supplier invoice deployment unit further comprises a supplier invoice processing process component.
3. The medium of claim 2, wherein the supplier invoice processing process component implements the create supplier invoice request operation, the notify billing due operation, the notify of contract release operation, the update supplier invoice verification exception operation, the confirm invoice operation, the create invoice operation, the notify of invoice operation, the request ERS invoice operation, the notify of invoice operation, the notify of invoice operation, the create invoice based on attachment operation, the notify of invoice values operation, the request exception operation, the resolution operation, the notify of supplier invoice operation, the maintain invoice request operation, the create invoice operation, the first notify of invoice cancellation operation, the second notify of invoice cancellation operation, and the third notify of invoice cancellation operation.
4. The medium of claim 2, wherein the supplier invoice processing process component comprises a supplier invoice request business object, an ERS run business object, a supplier invoice business object, and a supplier invoice verification exception business object.
5. The medium of claim 1, wherein the services operations are grouped into service interfaces, the service interfaces comprising:
- a supplier invoice request migration in interface that includes the create supplier invoice request operation;
- an invoice verification out interface that includes the notify billing due operation;
- a contract release out interface that includes the notify of contract release operation;
- an exception resolution in interface that includes the update supplier invoice verification exception operation;
- an invoicing out interface that includes the confirm invoice operation;
- an invoicing in interface that includes the create invoice operation;
- a receivables payables out interface that includes the notify of invoice operation;
- an ERS invoicing out interface that includes the request ERS invoice operation;
- an invoice accounting out interface that includes the notify of invoice operation;
- a foreign receivable payable notification out interface that includes the notify of invoice operation;
- an image recognition invoicing in interface that includes the create invoice based on attachment operation;
- an invoice verification out interface that includes the notify of invoice values operation;
- an exception resolution out interface that includes the request exception resolution operation;
- a customer project expenses notification out interface that includes the notify of supplier invoice operation;
- an invoice verification in interface that includes the maintain invoice request operation;
- an internal invoicing in interface that includes the create invoice operation;
- an invoice accounting out interface that includes the first notify of invoice cancellation operation;
- a foreign receivable payable notification out interface that includes the second notify of invoice cancellation operation; and
- a receivables payables out interface that includes the third notify of invoice cancellation operation.
6. The medium of claim 1, wherein the single computer system comprises a single physical hardware platform.
7. A computer readable medium including program code for providing message-based services using a service-oriented methodology for implementing an instance of a deployment unit, the medium comprising:
- program code for storing an instance of a requisitioning deployment unit for the management and processing of internal requests from employees, where the requisitioning deployment unit defines the limits of an application-defined transaction for the management and processing of internal requests from employees by a set of actions that have atomicity, consistency, isolation, and durability in a database, and wherein the actions associated with the application-defined transaction are performed by one or more process components contained in the requisitioning deployment unit, wherein each process component comprises a software package realizing a business process and exposing its functionality as one or more service operations, wherein the requisitioning deployment unit comprises: a request availability information operation, a change internal request based on purchase request operation, a request availability information and provisional reservation operation, a request in-house requirement reservation and fulfillment operation, a request purchasing operation, a change internal request based on purchase order operation, a request Goods and Services Acknowledgment (GSA) based on delivery confirmation operation, a change internal request based on availability update operation, a change internal request based on fulfillment confirmation operation, and a request invoicing based on invoice acceptance operation; wherein the service operations of the requisitioning deployment unit are packaged together to be deployed on a single computer system; and
- program code for executing the application-defined transaction for the management and processing of internal requests from employees; and
- program code for presenting data associated with the executed application-defined transaction for the management and processing of internal requests from employees to a graphical user interface.
8. The medium of claim 7, wherein the requisitioning deployment unit further comprises an internal request processing process component.
9. The medium of claim 8, wherein the internal request processing process component implements the Request Availability Information operation, the Change Internal Request based on Purchase Request operation, the Request Availability Information and provisional Reservation operation, the Request In-house Requirement Reservation and Fulfillment operation, the Request Purchasing operation, the Change Internal Request based on Purchase Order operation, the Request GSA based on Delivery Confirmation operation, the Change Internal Request based on Availability Update operation, the Change Internal Request based on Fulfillment Confirmation operation, and the Request Invoicing based on Invoice Acceptance operation.
10. The medium of claim 8, wherein the internal request processing process component comprises an internal request business object.
11. The medium of claim 7, wherein the services operations are grouped into service interfaces, the service interfaces comprising:
- an internal fulfillment out interface that includes the request availability information operation;
- a purchasing in interface that includes the change internal request based on purchase request operation;
- an internal fulfillment out interface that includes the request availability information and provisional reservation operation;
- an internal fulfillment out interface that includes the request in-house requirement reservation operation and the fulfillment operation;
- a purchasing out interface that includes the request purchasing operation;
- an ordering notification in interface that includes the change internal request based on purchase order operation;
- an internal acknowledgement out interface that includes the request GSA based on delivery confirmation operation;
- an internal fulfillment in interface that includes the change internal request based on availability update operation and the change internal request based on fulfillment confirmation operation; and
- an internal invoicing out interface that includes the request invoicing based on invoice acceptance operation.
12. The medium of claim 7, wherein the single computer system comprises a single physical hardware platform.
Type: Application
Filed: Mar 6, 2012
Publication Date: Jul 5, 2012
Applicant:
Inventors: Karina Herrmann (Weinheim), Andreas Brossler (Leingarten), Torsten Reichardt (Malsch), Markus Biehler (Landau), Hueseyin Haybat (Mannheim), Christoph Jungkind (Heidelberg), Pascal Hochwarth (Muehlhausen), Amrish Singh (Pittsburgh, PA), Karin Brecht-Tillinger (Edingen-Neckarhausen), Zeno Rummler (Stutensee-Friedrichstal), Peter Fitz (Waldsee), Ralf Sievers (Walldorf), Antonia Gross-Tarakji (Nussloch), Brit Panzer (Mannheim), Tobias Hoppe-Boeken (Wiesbaden), Paola Sala (Heidelberg), Andre Wagner (Sinsheim), Giovanni Deledda (Rauenberg), Robert Reiner (Waghaeusel-Kirrlach), Benjamin Klehr (Rastatt), Tilo Reinhardt (Waghausel), Gregor Tielsch (Mannheim), Gururaj C S (Bangalore)
Application Number: 13/413,069
International Classification: G06Q 30/04 (20120101);
