Patent Application
20070276755
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain advantages and principles of the invention. In the drawings:
The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several exemplary embodiments and features of the invention are described herein, modifications, adaptations and other implementations are possible, without departing from the spirit and scope of the invention. For example, substitutions, additions, or modifications may be made to the components illustrated in the drawings, and the exemplary methods described herein may be modified by substituting, reordering, or adding steps to the disclosed methods. Accordingly, the following detailed description does not limit the invention. Instead, the proper scope of the invention is defined by the appended claims.
An application platform can provide a foundation for modeling, analyzing, and controlling flows of values among business objects. The values may include values of, for example, raw material, products, parts, or personnel. The business objects are data structures that represent providers or consumers of values, such as activities involving those values. The data structure is a data container that organizes related items of information. For example, the data structure may be organized as a hierarchical tree having nodes. In one embodiment, the application platform can universally model all phases of, for example, designing and producing a product or service, ranging from standard cost estimates and cost center accounting, such as planning and simulation, through product cost by order or period, such cost object controlling and profitability. Further, users may create new specialized applications without having to use a conventional programming language.
In accordance with one embodiment, by using the application platform, a user may simulate any activity, such as activities that occur in the life cycle of creating and producing a new product or service. For example, when developing a new product, an individual or group may first have a design concept. This first step involves developing the initial design concept to the point that the product is defined in at least a rudimentary fashion. The next step may be to refine the design concept, which is done in a detailed design phase. During the detailed design phase, the specifics of the desired product are determined. This may include deciding not only the specifications of the product, such as size, shape, and components, but also selecting the particular materials or parts that will be used to create the product. The next step is to establish the supply chain, which refers to distributors that a business will use to obtain materials for the product, as well as the process that the business will use to actually create the product. This may involve, for example, creating assembly lines for large products and selecting workers to assemble products. Actual production of the product follows, which includes creating the product and bringing it to market for the lifetime of the product. Other costs may occur after and during this production phase, such as maintenance and service of machines that carry out the production process.
Application platform 100 may use metadata to define BO types, assignment types, and/or the tables in the value flow environment. As will be appreciated by those skilled in the art, metadata is data that describes other data. For example, metadata may describe how, when, and by whom a particular set of data was collected, as well as how the data is formatted. Individual instances of the BOs 110a, 110b, and assignments can each be associated with data in the form of attributes. The attributes may be freely defined or can be selected at the time of configuration from data elements stored in a database. Such attributes may comprise, for example, values, characteristics, or key figures (i.e., numerical values).
The attributes of BOs 110a, 110b may comprise master data and/or transactional data 120a, 120b. The master data is essential data that is related to its BO. The master data may include, for example, a production order identification (ID) or produced materials. The transactional data, on the other hand, is periodic data related to the operation of an application on the BO that is associated with the transactional data. The transactional data may include, for example, a confirmation that specified steps have been performed.
Application platform 100 may comprise an assignment creation engine (ACE) 140 to manage the generation of the assignments for BOs 110a, 110b. The assignments may also be referred to as “edges.” Each of the assignments is a directed link from a first BO, referred to as the sender BO, to a second BO, referred to as the receiver BO. The sender BO may be a provider of a value and the receiver BO may be a consumer of the value such that there is a flow of the value from the sender BO to the receiver BO. The value may be a value of, for example, money or resources such as materials, parts, or labor. The sender BO may be, for example, a cost center or project. The receiver BO may be, for example, a production order.
The assignment may include one or more attributes, such as characteristics or key figures, that describe the value flow. In one example, the sender BO is a cost center or project, and the receiver BO is a production order. In this example, one of applications 130a, 130b triggers ACE 140 to create an assignment between the sender BO and the receiver BO to contain a calculated overhead surcharge associated with the flow of a quantity of material from the cost center or project to the production order.
ACE 140 is used to create assignment creation definitions (ACDs) 150 that define how the assignments are to be automatically generated. When one of applications 130a, 130b is executed, that application can trigger ACE 140 to assign ACDs 150 to particular instances of BOs 110a, 110b selected by the application, and evaluate ACDs 150 for those instances of BOs 110a, 110b. ACDs 150 can be evaluated based on the master data and/or transactional data 120a, 120b of those instances of BOs 110a, 110b. Application platform 100 may also include a BO wrapper 160 to interface between ACE 140 and BOs 110a, 110b. The BO wrapper 160 can comprise data 170 about BOs 110a, 110b and metadata 180 about the BO types to facilitate exchange of information between ACE 140 and BOs 110a, 110b.
Application platform 100 may further comprise a formula and derivation tool 190 to manage formulas 200. Formulas 200 may comprise, for example, formulas, rules, or instructions. Formulas 200 may be executed by applications 130a, 130b or ACE 140. For example, formulas 200 may include the formulas used by ACD 150 to determine partner BOs in relation to a base BO. Formula and derivation tool 190 may comprise a formula environment 210 to define formulas 200. Formula environment 210 may comprise a user interface, such as a GUI, through which an operator, such as a human operator, can enter formulas 200.
In addition, application platform 100 may comprise application interfaces 215, such as a function library 220 to store functions 230 that can operate on the attributes of BOs 110a, 110b. These functions may comprise, for example, algorithms, formulas, rules, pointers, or other functions.
ACE 140 may include a creator 240 to create one or more of ACDs 150, each of which comprises executable “lines” that generate assignments upon execution. For example, an operator, such as a human operator using a GUI, may use ACE 140 to construct an ACD that will generate assignments containing desired attributes whose values are evaluated at the time of execution. The lines may have columns that define cells for each of the lines. The lines and columns of the ACD may together be referred to as a “template.” For example, the lines of ACDs 150 may identify partner BOs and specify functions in an abstract form to generate the attributes. ACDs 150 may exist in an assignment creation environment 250, which may also support ACDs 150 by providing background information. For example, assignment creation environment 250 may contain rules and/or tables with particularized data. ACDs 150 may also interact with customizing data 260 to further adapt ACDs 150 to particular applications.
Individual ACDs 150 may comprise a series of lines, each of which can be executed when ACD 150 is evaluated. Each of the lines may include a plurality of columns that define cells of the line. ACDs 150 can be represented in a tabular form wherein the different lines share columns from top to bottom and form rows of the table, such as that represented by the exemplary template shown in Table 1 below. Further, each of the lines may include an associated line identifier (ID), as shown in Table 1.
The lines of ACD 150 may also have a “Line Type” column. The individual Line Type cells may designate whether the individual lines are generation lines, which generate assignments upon execution, or non-generation lines, which do not generate assignments upon execution. For example, the Line Type cell of a generation line may contain a “Cost Center” element and the Line Type cell of a non-generation line may contain a “Calculation Row” element, as shown in the example of Table 2 below. The “Calculation Row” lines are executed to evaluate a formula such that a numerical value resulting from the formula can later be used by a generation line such as one of the “Cost Center” lines. Each of the “Cost Center” lines is executed to retrieve calculations from the “Calculation Row” lines and/or perform its own calculation in order to create an assignment between base BO and partner BOs. In addition, the Line Type cell may include a “Sub-ACD” element that re-uses an existing ACD as a component in the present ACD.
In addition, the individual lines may have a “Line Activation” cell that makes execution of the line conditional upon a logical expression. If the Line Activation cell is empty or not present, then the line may be executed unconditionally. However, if the Line Activation cell is present and contains a logical expression, then the logical expression is evaluated: if the logical expression returns a TRUE value, then the line is executed; but if the logical expression returns a FALSE value, then the line is not executed.
The next column shown in Table 1 is a “Comment” column, which can be used to include a textual comment in a line to describe that line to an operator, such as a human operator. For example, the Comment cell of a line may describe the purpose of the line for the benefit of the human operator.
Furthermore, the lines may comprise an “Object” column to refer to a partner object to which the generated assignment will relate. The Object cell may contain a unique identifier (ID) that is a static ID, such as a project ID, or a rule that is to be evaluated to identify the partner object. If the line has a Line Type cell that contains “Sub-ACD,” then the Object cell may contain an identifier of another ACD that is being used as a component of the present ACD containing this line.
The lines may also comprise one or more “Attribute” columns. The Attribute cell of each line may contain a function that can be evaluated to determine a value of an attribute. When the ACD comprises multiple lines, then the Attribute column may comprise a plurality of functions that are arranged to be computed sequentially. For example, the Attribute columns may include one or more “Characteristics” columns that contain characteristics and/or “Key Figures” columns that contain key figures. In the example shown in Table 2, the Characteristics column is an “Account” column, and the Key Figures column is a “Costs” column.
A particular example of an ACD, corresponding to the template of Table 1, is shown as Table 2 below. In this example, the application that will trigger the ACE to derive this ACD is an overhead surcharge application. A quantity flows from sender objects, which are cost centers in this example, to a receiver object, which may be a production order in this example. This exemplary ACD is receiver-based since the overhead surcharge application triggers the derivation of the ACD based on attributes of the production order that has been entered. The object column lists partner objects that are the cost centers, such as a materials cost center (MatSC), labor cost center (LabSC), administrative cost center (AdmSC), and sales cost center (SaISC).
The Attribute cells, such as the Account and Costs cells, may contain functions to determine needed values of the attributes for the assignments. For example, for the example of Table 2, the following three functions are provided by assignment creation environment: CostComponentValue( ), GetSurchargeAccounfforPlant( ), and GetSurchargePercentage( ). The functions GetCellValue( ) and SumCellValues( ) retrieve and sum, respectively, values from other cells of the template that are specified by line and column.
In addition, ACE 140 may comprise a deriver 270 to assign one of ACDs 150 to a base BO, which may be a sender BO or receiver BO. The ACD may be identified based on the type of application 130a, 130b that triggered ACE 140. Upon execution, one of applications 130a, 130b selects the base BO as needing an assignment to a partner BO.
The applications 130a, 130b may also pass an identifier of the selected base BO to ACE 140, which uses rules to identify one or more of ACDs 150 that are to be assigned to the base BO based on the attributes of the base BO. These rules may comprise rules and/or filters, and may be stored in the assignment creation environment. A plurality of rules may be defined in relation to a single base BO. For example, each of the rules may be adapted to operate on a base BO that has a particular BO type. Furthermore, each of the rules can use one or more of the attributes of the base BO to assign a particular one of ACDs 150 to that base BO.
Deriver 270 may further identify the ACD based on a directionality of the assignments to be generated. Each of ACDs 150 can be characterized as either sender-based or receiver-based, meaning that the base BO from which each of the particular ACDs 150 is derived is either a sender BO or a receiver BO, respectively. Deriver 270 determines whether the base BO is a sender BO or a receiver BO. If the base BO is a sender BO, then deriver 270 assigns a sender-based ACD. If the base BO is a receiver BO, then deriver 270 assigns a receiver-based ACD. Correspondingly, for a sender-based ACD, the partner BO is a receiver BO; for a receiver-based ACD, the partner BO is a sender BO.
Two examples of rules that assign the ACDs to the base BOs are shown below as Tables 3a and 3b. In this example, rule m operates on base BOs of BO type 1, and rule n also operates on base BOs of BO type 1. However, rule m examines attribute x of the base BO, whereas rule n examines both attribute y and attribute z of the base BO. Based on the values of attributes x, y, and z, rule m assigns an ACD to the base BO and rule n assigns another ACD to the base BO. For example, a base BO of BO type 1, having attribute x with a value of “x.1,” attribute y with a value of “Y2,” and attribute z with a value of “Z2,” would be assigned ACD1 and ACD2.1.
ACE 140 may further comprise an evaluator 280 to evaluate ACD 150 on a line-by-line basis. For example, ACE 140 may sequentially read the lines of ACD 150, such as from top to bottom in Table 2 above, and execute each of the lines. ACD 150 may be evaluated to determine the partner BOs. For example, the partner BOs may be determined based on the identifiers or rules in the Object cells.
Evaluator 280 may also evaluate the functions in the Attribute cells to determine values of attributes that will be associated with the generated assignments. These attribute values may be stored in an internal result table before being associated with the assignments that are to be generated between the base BOs and the partner BOs. ACE 140, using ACD 150, may evaluate the formulas using one or more of the attributes of the base BOs and/or the attributes of the partner BOs to determine the values of attributes of the relevant assignment that is to be generated. For example, the formulas may be evaluated to calculate the values of characteristics and key figures.
One or more of the functions in the ACD may refer to tables of the value flow environment to retrieve data, such as to obtain reference data, such as numerical constants. These tables may be managed by the assignment creation environment. An example of such a table, corresponding to the exemplary tables above, is shown as Table 4 below.
An example of the determined partner BOs and evaluated attribute values, corresponding to the exemplary tables above, is shown in as the internal result table labeled Table 5 below. The results of the non-generation lines (i.e., “Calculation Row” in this example) are shown in the rows that do not list a partner BO. The results of the generation lines (i.e., “Cost Center” in this example) are shown in the rows that do list a partner BO. However, the results from the non-generation lines are incorporated into the calculations that are present in the generation lines and thereby affect the outcome of the assignments that are ultimately generated.
ACE 140 comprises a generator 290 to create an assignment between the base BO and each of the partner BOs determined by the evaluator 280. For example, the individual lines may be designated as either generation lines, which generate assignments upon execution, or non-generation lines, which do not generate assignments upon execution. Each of the generated assignments has the attributes whose values have been determined by the evaluator 280. The assignments may also inherit the directionalities that have been determined by deriver 270, meaning that each of the assignments specifies a sender BO and a receiver BO.
ACE 140 may further return the attribute values to the application that triggered ACE 140. For example, the application may further process the assignment results, such as by posting the contents of the assignment results. An example of the assignment results, posted as three line items in a costing journal, is shown as Table 6 below. In this example, three assignments are shown: (i) an assignment between a receiver BO identified as “PO 100000” and a sender BO identified as “CC MatSC,” having an Account attribute with a value of 610000 and a Costs attribute with a value of 300.00; (ii) an assignment between the same receiver BO and a sender BO identified as “CC LabSC,” having an Account attribute with a value of 611000 and a Costs attribute with a value of 1,000.00; and (iii) an assignment between the same receiver BO and a sender BO identified as “CC AdmSC,” having an Account attribute with a value of 612000 and a Costs attribute with a value of 645.00.
Exemplary data structures of assignment 340, base BO 310, and partner BO 320 are shown in part. In the example of
When an operator decides to enable the automatic creation of assignments, the operator creates the ACD, as shown by step 400. As described above, the ACD contains lines that are executable in relation to a base BO to identify one or more partner BOs and to determine values of one or more attributes of the assignments. This newly created ACD can be stored for multiple derivation and evaluation steps based on the ACD. The operator next creates the rules that will be used in the derivation process to identify the appropriate ACDs for evaluation, as shown by step 410.
When an application is executed, the application may trigger the ACE to initiate a derivation process that identifies particular ACDs and assigns the ACDs to a plurality of sender and/or receiver BOs. Particular sender and/or receiver BOs may be selected by the application as BOs that should potentially be assigned ACDs. The ACE selects one of those BOs, as shown by step 420, as part of the ACD derivation process. The ACE uses the rules that were previously created to determine which ACD should be assigned to the BO based on the attributes of the BO and the directionality, as shown by step 430.
When an ACD has been derived for the BO, the BO is referred to as a base BO, and the ACD can be evaluated on a line-by-line basis in preparation for generating the assignments between this base BO and partner BOs. The ACE selects a line of the ACD, as shown by step 440. The selected line is evaluated to determine values of attributes of the line, as shown by step 450. If the selected line is not the last line of the ACD, as shown by conditional branch 460, then the evaluation process is repeated for the next line, as shown by step 470. However, if the selected line is the last line of the ACD, then the evaluation process can be terminated.
Based on the results of the evaluation process, assignments can be generated between the base BOs and the partner BOs, as shown by step 480. If the line is a generation line, such as a “Cost Center” line, then an assignment is generated. The assignment may include the attribute having the value determined during the evaluation process. The assignment may further inherit a directionality that is determined based on whether the base BO is a sender BO or a receiver BO.
If the BO is not the only remaining BO to be assigned an ACD, as shown by conditional branch 490, then the ACD derivation process is repeated for the next BO to assign an ACD to that BO, as shown by step 500. However, if the BO is the only remaining BO that should potentially be assigned an ACD, then the derivation process is terminated, as shown in
The methods and systems disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database. Moreover, the above-noted features and other aspects and principles of the present invention may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various processes and operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general-purpose machines may be used with programmable instructions written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus to perform the required methods and techniques.
The line is first checked for a Line Activation cell, as shown by step 510. Further evaluation of the line proceeds if either (i) the Line Activation cell is present or (ii) the Line Activation cell is present and the logical expression contained therein returns a TRUE value. If the line type is “Sub-ACD,” as shown by conditional branch 520, then the sub-ACD is evaluated, as shown by step 530. Otherwise, if the line type is “Calculation Row,” as shown by conditional branch 540, then the Attribute columns (indexed in this example as ‘i’ through ‘j’) are evaluated, as shown by step 550. An internal result table is filled with the line ID and the values of the Attribute columns, as shown by step 560.
If the line type is neither “Sub-ACD” nor “Calculation Row,” then the line is presumed to be a generation line and partner BOs are determined, as shown by step 570. The first partner BO is selected, as shown by step 580. The Attribute columns are evaluated in relation to that partner BO, as shown by step 590. The internal result table is filled with the line ID and the values of the Attribute columns in relation to that partner BO, as shown by step 600. Steps 590 and 600 are repeated for each of the partner BOs, as shown by step 610.
An exemplary embodiment of the process of deriving and evaluating ACDs, corresponding to
The methods, systems, and computer readable media described herein enable the generation of assignments for particular BOs based on ACDs that have been created as abstract templates. Furthermore, the ACDs can be derived and evaluated based on attributes of either sender BOs, which are the sources of value flows, or receiver BOs, which are the recipients of value flows.
The foregoing description of possible implementations and embodiments consistent with the present invention does not represent a comprehensive list of all such implementations or all variations of the implementations described. The description of only some implementations should not be construed as an intent to exclude other implementations or embodiments. One of ordinary skill in the art will understand how to implement the invention in the appended claims in other ways, using equivalents and alternatives that do not depart from the scope of the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06290880.1 | May 2006 | EP | regional |
