Patent Application
20070156428
Internal requests in organizations for goods and/or services have been automated to some extent in prior systems. Such systems may require users to have an understanding of the purchase orders. Casual users, such as normal employees of a company, were not able to easily use such systems to create purchase orders if they had a specific request for material or services. They were not able to enter all relevant data for purchase orders or internal requisitions, and were not able easily handle complicated navigation of such services.
In some prior applications that were designed to allow casual users to request goods or services, user interfaces, such as electronic shopping carts and code for implementing functions were combined in a same application. Changes to the code or the user interface may have directly affected other parts of the application, requiring their modification.
A system and method for ordering goods in a distributed message based business management system uses an internal request business object that identifies parties involved, items, status of items, and identification and administrative information of an internal request. The internal request business object includes actions comprising the ability to submit action for the creation of follow-on documents, trigger a check for correctness and completeness of the internal request, and start an approval action that initiates an approval process of the internal request.
In the following description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific embodiments which may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that structural, logical and electrical changes may be made without departing from the scope of the present invention. The following description is, therefore, not to be taken in a limited sense, and the scope of the present invention is defined by the appended claims.
The functions or algorithms described herein are implemented in software or a combination of software and human implemented procedures in one embodiment. The software comprises computer executable instructions stored on computer readable media such as memory or other type of storage devices. The term “computer readable media” is also used to represent carrier waves on which the software is transmitted. Further, such functions may be implemented in objects with attendant methods. The methods may be implemented in modules, which are software, hardware, firmware or any combination thereof. Multiple functions are performed in one or more modules as desired, and the embodiments described are merely examples. The software is executed on a digital signal processor, ASIC, microprocessor, or other type of processor operating on a computer system, such as a personal computer, server or other computer system.
An internal request business object is used for the procurement of materials or services in a distributed message based business management system. In one embodiment, the internal request object is used to create and manage internal requests from employees in a business, and contains identification of the parties involved, the items and their status. Furthermore, it contains identification and administrative information corresponding to the internal request. The internal request object provides the ability of employees to directly request materials and services without the need to understand the processes and formalities used in the creation of purchase orders normally handled by a specialized purchasing department. The internal request object may be used to enable user interface functions to be separately implemented, such as by different objects than the internal request object. Still further, constraints, in the form of business rules may be applied to the internal request object to implement desired constraints on the ability of employees to purchase goods and services directly.
In one embodiment, employees of a company may be enabled to declare the need of materials or services very easily. The internal request object may be used to facilitate the creation of a lean material and service requests. Such materials and services may be selected from a product catalog, product master, or entered directly by a user. Recurrent requirements can be saved in a template for frequent reuse.
Whether a request will be fulfilled via an external procurement process or an internal deliver from stock may be automatically determined by the system based on business rules. Users do not need to enter extensive data fields. Basic data, such as item description and quantity may be sufficient. In an easy example, items are selected from a catalog, and the user is done. They are not forced to handle complicated screens or struggle with complicated navigation concepts.
An application platform business objects layer 220 comprises multiple business objects which provide business functionality. An internal request business object resides in this layer in one embodiment. Other objects may include purchase order and invoice related objects to name a very few. A services layer 230 provides the ability to retrieve, update, and delete these objects. One or more user interfaces obtain data from the business objects and provide a user interface to users of the system. Such interfaces may be different for different types of users, such as large company users 235, medium size company users 240 and small company users 245. The amount of functionality provided may be varied depending on the type of user. Vertical slices of functionality may be selected for different size companies as well by selecting various components and business objects from a large group of components and objects.
An internal request is a request for the procurement of goods and services. Goods may include materials. A generic term for goods, materials and services may be referred to as items. The internal request may be fulfilled via different objects, such a purchase request or an in-house requirement object. An in-house requirement object is a requirement object that expresses a demand from an internal customer within an organization. A purchase request object expresses a request to a purchasing department to purchase items in specified quantities within a specified time.
Many business functions may be implemented in the internal request object at various levels. The internal request object 110 may implement several functions related to an internal request document. Some of such functions include the ability to create internal request documents manually for the user or for another user. Templates may be created to enable quick creation of requests for frequently requested items. In one embodiment, all users may use templates that have been created. While a user is working on a document, a system check for correctness and completeness of entered data can be triggered to indicate open to-dos. The system may also check an internal request prior to ordering automatically. Incomplete requests may be saved so that a user can return to finish the request at a later time.
In one embodiment, the internal request provides data to enable the display or printing of the internal request. If no follow-on documents exist, it should be possible to modify or delete a request. No further processing of deleted requests should be allowed. Descriptions for internal requests may be entered. Archiving of internal requests that have completed a life cycle may be done. A change history may also be provided for display. Automatic budget checks may also be performed. Internal requests may also deliver data for analytical reporting.
The internal request business object 110 may also implement functions related to approval of an internal request. In one embodiment, an internal request may provide data to enable display of an approval preview, such as who will be responsible approvers. The status of the approval may also be checked. An approval note may also be added by a requester, approver or reviewer. A budget driven approval may also be available, as well as spending limits wherein spending limit controls who will approve which amount. Internal request may also be approved offline, such as from an in box for electronic mail.
In one embodiment, approvers may be added ad-hoc. Approvers may be able to accept, reject, display, and return internal requests. Further, requestors may return internal requests to an approver for reconsideration, and change and display the internal request during the approval process.
In a further embodiment, the internal request is extensible, such as by adding customer fields, transferring added customer fields to follow-on documents and also to offer customers the possibility for individual and modification-free adjustments.
In yet a further embodiment, an internal requests and internal request items may be adjusted to local requirements of different countries and jurisdictions.
Several functions may be implemented by internal request business objects on an item level. These may include things like adding items manually, from a catalog, from internal request templates, from existing internal requests, via copying to add new items which are similar, and deleting items even if follow-on documents exists, provided such documents can be deleted.
Further functions in dealing with items include using items to represent nodes within a hierarchy. Service items for temporary labor may be represented by such a hierarchy. Further, it may be possible add material and service product items. Items may also be added via free text descriptions. Items may be added without specifying an exact price. A maximum limit for service items may be defined, as well as an expected value or flat rate. Limits for expenses for service items and overtime may also be specified. Skill profiles may also be added. Several different catalogs may be used to select items.
Still further functions include the ability to search for existing sources of supply and assigning sources. After a final approval of an internal request, an item may be transferred into a follow-on document, such as a purchase request or in-house requirement. Configuration of which follow-on documents will be created may also be done. Further, a check if material is in stock may be made. A pricing engine in an application platform may be integrated to allow the determination of prices. Integration to a tax engine in the application platform may also be done to determine taxes.
In one embodiment, approvers may reject individual line items in a request containing many items. Approvers may also approve only items for which they are responsible. An acknowledgement may also be posted via an internal request. A supplier invoice may also be posted via the internal request in one step. The internal request may provide data to enable the status of each item and the display of follow-on documents. Additionally, in one embodiment, the internal request may provide data to enable display of change history of items.
Further functions are related to the parties involved with internal requests. The internal request may identify a recipient of the items, a ship-to address, service agents, supplier, preferred supplier, location, purchasing organization, and purchasing group. In addition, in one embodiment, partner schemas may be configured for the internal request which will be forwarded to follow-on documents.
A further set of functions relates to attachments. It may be possible to attach files to an internal request item. Attachments may be added for external use by a supplier. Attachments may be classified to be visible for internal use only. An internal request provides data to enable the display of documents. Attachments may be deleted, and may have versions created. Document management functionality may be used to check in or out a version of an attachment.
Text may also be used in internal requests. It is possible to add descriptions for external use by suppliers or for internal use only. Configurable text may also be stored at an internal request item level, and various schemas may be identified. Text may also be selectively forwarded to follow-on documents.
Some functions relate to account assignment. An account assignment to different accounting objects may be possible for internal request items. For example, cost center, order, fund, funds center, etc., may be assigned. Further the account assignment may be maintained manually. Costs may also be distributed by percentages, quantity or value. Still further the creation of account assignments for multiple line items may be facilitated by copying account assignments and inserting them to and from a clipboard. This may be implemented on top of a user interface platform which is independent from the internal request business object.
Search functions may also be provided for internal requests, such as the ability to search for internal requests and internal request templates. Search criteria may be entered by a user to find such requests and templates.
Internal request business object 300 includes an internal request 310 includes one or more items 311, a status 312, one or more parties 313 and a description 314. Items 311 is associated with item status 315, item party 316, item product 317, item delivery terms 318, item procurement cost upper limit 319, item product tax 320, item pricing condition 321, item accounting object set assignment 322, item location 323, item reference 324, item actual value 325, item attachment 326 and item description 327.
Item party 316 further comprises item product recipient party 328, item service agent party 329, item requestor party 330, item purchasing organization party 331, item purchasing group party 332, item seller party 333, item preferred seller party 334, item logistical division party 335 and item buyer party 336.
Item location 323 comprises an item ship to location 337. Item reference includes item purchasing contract client reference 338, item purchase request client reference 339 and item in-house requirement client reference 340. Party 313 further comprises buyer party 362 and requestor party 363.
Business partner object 301 comprises a business partner 341, and employee 343. Organizational center object 302 comprises an organizational center 344 which includes several business objects: company 345, logistics division 346, shipping point 347 and purchasing unit 348. Product object 303 includes a product 349, which further includes material 350 and service product 351. Product category hierarchy object 304 comprises a product category hierarchy 352 and product category 353.
Product catalog object 305 includes a product catalog 354 and item 355. Purchasing contract object 306 includes a purchasing contract 356 and item 357. In-house requirement 307 includes an in-house requirement 358 and item 359. Purchase request object 308 includes a purchase request 360 and item 361. There may be relations between some of these objects, such as from product catalog 354 to purchasing contract item 357 and purchase request item 361.
Several lines are drawn between objects 301-308 and the internal request object 300. These lines represent communications between elements in the objects that communicate, invoke functions and transfer data. For instance, product material 350 is coupled to item product 317. An item product (generic) may be represented by a material, a service product, a product category or a catalog item.
Messages to and from the internal request business object are described with reference to
In one embodiment, an internal request 410 may initiate a synchronous ATP (available to promise) check as indicated at 420. This results in a provisional reservation 422 being sent by internal fulfillment_out being sent to in-house requirement processing 424.
The message change internal request based on procurement progress updates the internal request 410 and gives information about the progress of procurement, meaning changes of follow on documents e.g., the creation of purchase orders 430, the creation of goods and services acknowledgement 440 including the amount of received goods, and the creation of supplier invoices 450. The operation is based on message type purchase request confirmation which is derived from a business object purchase request.
The message request purchasing 432 is sent to a process component 434 that handles the creation of a purchase request
A message notify of goods and services acknowledgement 442 creates a message which is sent to the process component 444 handling creation of a goods and service acknowledgement for delivered goods and rendered services. In one embodiment, a one-click action sends a message of type goods and services acknowledgement notification. This may automatically create a goods and services acknowledgement without manual interaction and therefore helps to streamline organizational processes.
In house requirements may also notify about updates from the in-house requirement at 555 and confirm fulfillment from in-house requirements at 556. These updates and confirmations are encapsulated in messages via an internal fulfillment out interface 560, and sent to an internal fulfillment in interface 656 in the internal request business object 510, which result in updating of the internal request 525 by a change internal request based on availability update 570 and change internal request based on fulfillment confirmation 572.
A block diagram of a computer system that executes programming for performing the above functions, such as a local deployment unit, is shown in
Computer-readable instructions stored on a computer-readable medium are executable by the processing unit 1102 of the computer 1110. A hard drive, CD-ROM, and RAM are some examples of articles including a computer-readable medium. The term “computer readable medium” is also used to represent carrier waves on which the software is transmitted. For example, a computer program 1125 capable of providing a generic technique to perform access control check for data access and/or for doing an operation on one of the servers in a component object model (COM) based system according to the teachings of the present invention may be included on a CD-ROM and loaded from the CD-ROM to a hard drive. The computer-readable instructions allow computer 1110 to provide generic access controls in a COM based computer network system having multiple users and servers.
The Abstract is provided to comply with 37 C.F.R. §1.72(b) to allow the reader to quickly ascertain the nature and gist of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
