Six, elastic domain ( Flexfield )
The so-called "elastic domain" technology is the first thing that people always think of when they mention the advanced technology of ORACLE products. It is also the first thing that many beginners (especially those with "business background") may feel a little "out of control" when they start to contact . One of the reasons is that it has a strong technical flavor. But in fact, if you understand it from the perspective of application, there is not much mystery about it.
We have mentioned earlier that "form" is one of the most important basic elements that make up the EBS system, and each form is composed of "header and body lines". What the system displays on the UI interface is the "standard display" of the form. Although this "standard display" may already contain those common information fields ( Segment ) suitable for all walks of life, it is always possible for different companies There will be situations where it is necessary to add some information fields that are specifically required by the enterprise, which is usually called "custom form fields" from a system perspective. The so-called "elastic domain" technology of EBS actually came into being to solve this common system application problem. For beginners, it is much easier to simply understand it as "custom form field".
As shown in Figure 15 and Figure 16 below, there is a "box" ("【 】") in the UI interface (corner) of the "Standard Display" part of the header part, and there is also a A "box" ("【】"). When the system user needs to enter special information, click the "box", and the system will pop up an interface box containing several custom information lines (equivalent to expanding several columns of fields for the form) for the user to input some information. special information.
Figure 15 shows the "elastic field" box and pop-up interface of the PR header of the purchase requisition . Users can enter some custom supplementary information about the PR , such as "applying department, application purpose" and so on.
Figure 16 shows the "Flexible Field" box and the pop-up interface of the PR form body row of the purchase requisition. Users can enter some custom supplementary information about the PR line, such as "length, width, height, color" and so on about the purchased materials.
It should be noted that the above-mentioned "custom form fields" are "system-level" rather than "user-level", which means that only system administrators can make related settings, while ordinary users can only use them in actual work. The "flexfield" used in EBS is divided into two categories: one is the so-called " key flexfield" ( Key Flexfield ) , and the other is the so-called " descriptive flexfield" ( Descriptive Flexfield ) . The "elastic domain" in the purchase requisition PR shown in Figure 15 and Figure 16 above is a typical example of the "descriptive elastic domain".
Almost all the important forms in the system (especially business process forms) have descriptive flexfields of this "custom" function, and the total number of descriptive flexfields in the system is as many as two to three thousand. Call it "Descriptive" ( Descriptive ), whichever means supplementary description of the standard form fields. The field information entered by the user in the descriptive elastic field can usually only be used for statistical analysis and report generation, and does not participate in the construction of system business processes, and the system (application) does not track or trace it between forms. As shown in Figure 17 below, the system definition interface of the purchase requisition PR header "Descriptive Flexfield":
The so-called "key elastic fields" of the system are much more complicated and stricter than the "descriptive elastic fields", because they participate in the construction of business processes, and the application programs of the system need to track and trace them. Of course, their role is very " Key" ( Key ), so the number is relatively small, and the total number in the entire EBS system is only about 35 . Among them, the most used ones are "material category flexfield", "accounting subject flexfield" and so on. Unlike the "descriptive flexfield" which belongs to the user's "supplementary field" of the form, the "key flexfield" itself belongs to the system standard field of the form. What the user enters in this form standard field is not a simple piece of information, but has certain A set of information that can be "custom-structured" at the system level.
As shown in Figure 18 below, in the "Material Category" field in the purchase requisition PR form interface, when the user enters, the "Material Category Key Flexfield" interface defined by the system will pop up for the user to (select) input specific information :
As shown in Figure 19 below , it is the interface for defining the "Key Flexfield" at the system level. All 35 key elastic domains are mainly defined in core business modules such as inventory, general ledger, assets, and human resources, and other modules are only called during application. Due to its system status and importance, key flexfields are more complex in definition and content than descriptive flexfields.
For each "key flexfield", the system allows to define several field combinations with different structures, so as to be used in different occasions in the system (such as different organizations or sets of books, etc.). As shown in Figure 20 below, it expresses that the "Accounting Item Flexfield" can have several different structures (codes). The 5- segment structure of " Vision China " in the figure can be completely different from that of other countries or regions.
Oracle 's elastic domain application technology is one of the most important basic elements of the system. After years of development, its application is far from being as simple as the "form field information" mentioned above. In fact, it has developed into an important methodology. Based on some important technical characteristics of the (key) elastic field, the system has gradually developed many flexible and powerful application implementation methods. (Related discussions must be carried out in conjunction with specific system applications, so I won't repeat them here).
An Overview of the Application Basis of ORACLE EBS System
7. Value Set and Lookup Code ( Value Set and Lookup Code )
Eight, the configuration file ( Profile )
Nine, document number ( Document Sequence )
10. Workflow ( Workflow )
11. Alert _
12. Application Open Interface ( Open Interface and API )
Thirteen. Conclusion
(Note: There is a problem with the batch of pictures sent by the website, and the display is not clear after uploading. After clicking the picture to open, the quality is acceptable)
7. Value Set and Lookup Code ( Value Set and Lookup Code )
In daily work, there are two ways for users to input data in form fields (including flexfield fields): one is direct manual input, such as the quantity (value) or text description (character) in the order, etc.; The other is the so-called "LOV" (List of Value), the user can only select and input from a pre-defined "source document" (if the user enters manually, the system may automatically check the source document to determine whether the input value is allow).
The "LOV" input of the form field actually accounts for most of the system input operations. The important reason for this is the need for "standardization" of business practice and system implementation. For example, the official name of "Human Resources Management Department" may be simplified as "Human Resources Department, Personnel Department, HR" and so on in people's daily work and communication. Everyone knows that they are the same thing, and generally do not misunderstood. But it is completely different for the system. The subtle differences are two different objects in the system, so LOV is actually the basis for the system to realize "data sharing and integration".
The source document value type of the form field LOV, some may be more complicated, such as "material, supplier, customer" and so on. When the values of these fields are brought from the source document, the system may also bring some other relevant important information Go to other related fields of the form. And some may be relatively simple, such as "Unit UOM, Currency, and Date" that belong to the category of general basic data. Others are relatively simple, but usually require users to define in advance, such as the "department name list" of the enterprise, etc. These LOVs are usually called "Value Sets" in the system.
Defining a complete "value set" in the system requires two independent and interrelated stages. The first is to define the "value set name". The system can define several value set names for different purposes. For each value set ( In the definition interface, relevant attributes (such as "validation type: none, independent, subordinate, table", etc.) can be specified to make it meet the needs of actual work. As shown in Figure 21, the interface for defining (or searching) the "Value Set Name" of "Department Name":
Secondly, it is to assign a specific value to the defined "value set name" (except for the verification type "none") to form the LOV available to the system. As shown in Figure 22 below, some values can also be defined to form a certain "hierarchical structure" according to needs, and the "parent-child value" has a "summarized and summarized" relationship.
The definition of the value set whose validation type is "dependent" or "table" is special, and the former needs to define the subordinate "independent" value set first. The latter is to use the "application table" in a certain system as its own LOV source (such as the supplier name table maintained by the "Define Supplier" form). When defining the value set, it is necessary to specify which tables to use and define the WHERE sub clause to restrict the values to be used for the value set.
The values of the form fields using the value set LOV almost all have a common feature that they generally do not directly participate in the construction of business processes, or do not directly affect the operation of business processes. However, some fields of the system form need to undertake the work of "process construction". Some of these form fields need to be entered manually, and some may be automatically assigned when the system process is running or automatically rewritten at different process stages (for example, the form status "not completed , Saved, Approved, Rejected, etc.), some values are normally "visible" in the form, and some may only be visible in special cases.
The LOV of the special fields (fields) of the above forms is generally defined by the system in the so-called "Lookup Code" function. ORACLE defines all Lookup Codes by module and by reference field in a unified interface (Form) at the system level. As shown in Figure 23, the "requirement type" definition of the material used in the inventory-related form:
The definition of the Lookup Code system is divided into three situations (access levels), one is "system level", which is predefined by ORACLE and does not allow users to add it. In this case, the "code value" (Code) basically belongs to the application program of the system that needs to be referenced, which affects or determines the operation of the system's business process; the second is "user level", which is not predefined by the system Added by the user, the code value in this case is generally not referenced by the application, and its function is roughly the same as the LOV value of the aforementioned value set; the three are "extensible levels", which are predefined by ORACLE but allow users to add them. In this case, the function of the system predefined value is basically the same as that of the "system level", and the function of the part added by the user is basically the same as that of the "user level".
Eight, the configuration file ( Profile )
The so-called "configuration file" of ORACLE is essentially the so-called system "parameter" that people are already familiar with (I don't understand why the original Chinese translation was so strange). The configuration file or parameters in ORACLE involve two processes: one is the definition of the configuration file itself (Definition); the other is the application setting (Setup) of the configuration file.
Although there are seven or eight thousand predefined configuration files in the ORACLE system, these configuration files are transparent and visible to users and are not mysterious. The system provides a "configuration file" definition interface for users to adjust or modify certain attributes (even applications) of the configuration file, and users can also customize new configuration files according to their own needs. The definition of the configuration file is shown in Figure 24 below:
It is worth pointing out that the "configuration file name" predefined by the system has certain naming rules (applicable to most configuration files, with a few exceptions), such as "MRP: Ignore Alternative BOM/Processing Route", the preceding MRP is the module code, representing It belongs to which application module, and the latter part represents the specific use. This "naming rule" makes it easy for us to find the relevant parameters for different modules. Although the number of system predefined configuration files or parameters is so large and daunting, in summary, it can be roughly divided into three categories by purpose:
One type is the part that really controls the operation of the business process or the way of transaction processing. These parameters are like the so-called "process switch" that people usually talk about ; the second type does not actually directly control the operation of the process or transaction processing, but only serves A function to default certain values on the form (these default past values, some participate in process construction, and some are only for reference. Users can still modify them on the form); the third type is to play some special control functions, such as Changing some working methods of the system, controlling the color and font of the UI interface, etc., usually has little to do with the specific business. Among all parameters, the first two categories account for the vast majority of the quantity (the first category occupies the main part), and the third category is very small. The difficulty and focus of the system application is the "first category", which belongs to the "process switch" part of the parameters.
The "Setup" of the configuration file of the ORACLE system is very convenient and flexible, and the combined application functions are very powerful. The configuration file setting of the system has a "structural hierarchy". For a specific configuration file, the system allows up to 6 levels to be set and function: location layer (system installation), application product (module), responsibility (autonomous Defined responsibility), server, organization (including OU/INV, etc.), user (custom user). Which of the above six levels can be "visible and settable" depends on the relevant attributes of the original definition of these configuration files. And when the actual application program is accessed, it will play a role in the order of "priority" from "location" to "user" from low to high. The settings of the configuration file are shown in Figure 25 below:
If the "user layer" with the highest priority is left blank and no value is assigned, the system will default the value of the upper layer (responsibility layer) as its own value. Move forward step by step until the lowest priority "site level", usually the system has an initialized default value at the "site level" after installation. Although it seems that there are seven or eight thousand configuration files, and the setting workload is huge, in the actual system implementation, for most enterprises, fortunately, the default initial values at the time of system installation can basically meet the requirements, so it is not very Difficulty is terrible. When an enterprise encounters a problem in the actual work process, such as hoping that the system can achieve a certain function or that the system process can run in a certain way, etc., it should usually first seek a suitable solution based on different settings of the system configuration file .
In addition, the system provides two "security" (authority) control functions of "system" and "user" for configuration files. Setting modification, such as "UI interface color, font" and so on.
Nine, document number ( Document Sequence )
Like making documents in the manual business mode, all business process forms and most data source forms in the system also need number management due to the huge amount of business data. ORACLE provides document numbering control functions for this purpose: automatic numbering, manual numbering or no gap (manual numbering must be continuous). Document numbering specifically includes three steps that are both independent and interrelated: one is to define the "document sequence" (generator); the other is to define the specific "document category", and the third is to assign the "document sequence" to the "document category".
As shown in Figure 26, define the "document sequence" (generator)
As shown in Figure 27, it is to define a specific "document category"
As shown in Figure 28, the document sequence generator is assigned to the document category, so that the two are associated
It is worth pointing out that, in fact, for some business process forms in the system (such as sales orders), the system allows it to customize a certain number of "document categories" (such as "order type" or "transaction processing type" in sales orders) , these self-defined "document categories" can have (assigned) different document serial number generators (equivalent to the system numbering them independently when used), or they can share the same document serial number generator (equivalent to The system mixes them with a common number when used), which provides great flexibility and convenience for the actual use and management of document numbers. In addition, it should be noted that some documents in the system, such as purchase requisitions, purchase orders, and suppliers, may also have their own special number management mechanism, which cannot be generalized.
In the actual management work of an enterprise, after an employee fills out an "Expense Reimbursement Form", it may need to go through multiple links such as the approval of the direct supervisor, superior supervisor, and financial supervisor before reaching the accountant (account entry) and cashier. (payment) in hand to complete the entire work process. Putting this work process "electronically" into the system forms a so-called "workflow" process. Usually, the system needs to pre-set the links that the "workflow" of the reimbursement form needs to go through, and the approval links that may be required to go through different expense categories are also different. As a participant in the process, such as "submitter, approver", etc., you can query and monitor the workflow processing process of the document, and the system can also send reminders to the processors of the next link during the process of moving the process link (such as email wait).
The "approval flow" of documents is actually a very simple and intuitive "workflow" application. By extension, it can be extended to the transaction processing process of other business process forms in the system. The so-called "workflow" technology application of the system is: according to different types of business documents, different business processing links that need to be passed through are defined in advance, and the documents are doing transactions. When processing, move between related links in a prescribed order. Users can monitor, that is, ordinary users can view the processing status of the workflow; the system can be managed, that is, the system workflow administrator can intervene in the workflow process of documents when necessary, such as skipping certain links, changing participants, etc. wait.
The processing of sales orders in the core business module OM of the ORACLE system is a typical example of using "workflow" technology. The system first defines different sales order "line types" according to the needs of actual business processing. For example, "Ship only" means that the goods sent to the customer are free and do not need to be invoiced (for example, due to the quality of the goods and other reasons); "Service" means that this is an intangible service provided to the customer without delivery, but The customer needs to be billed against the PO line, etc. Then assign an appropriate system-defined "line workflow" to these order "line types". As shown in Figure 29, the allocation definition of OM sales order "line type-line flow":
The above-mentioned system is used for the row workflow assigned to the "row type", and ORACLE provides a variety of predefined categories for users to choose when setting up the system. Furthermore, ORACLE also provides the "Workflow Builder" software package tool (this software can be downloaded and used freely from the official website of ORACLE), so that users can copy and modify all the predefined processes of the system, or customize special processes that meet the requirements of use.
For each specific sales order, the same order may contain order lines of different line types, and these order lines will follow their own "line workflow" for transaction processing. The system provides the function of "workflow status query" in the toolbar of the form interface, and the user can monitor and query the system processing process of each order line in the order at any time.
The user interface of the workflow monitoring function of the sales order line is shown in Figure 30 below:
Click the "Workflow Status" function in the figure above, and the system will open the workflow WEB query page belonging to order line 1.1. The system provides two main query methods, "Activity History Record" and "Status Chart", as shown in Figure 31 and Figure 32 below respectively. Figure 31 shows the activity history of the order line. The system starts from the user entering the order, and records almost every subsequent transaction processing operation.
Figure 32 shows the order line process status displayed in an intuitive graphical manner.
It should be pointed out that not all business process forms need to adopt the "workflow" processing method similar to the sales order, such as the processing of "purchase order". Whether to use the system application module and how to use the "workflow" technology has a lot to do with the specific business practice and the advantages and disadvantages of adopting it, which cannot be generalized. From the perspective of system development and design, although "workflow" is not difficult to grasp at the technical level, it is not easy to achieve a good combination with business practice. At present, domestic mainstream products basically claim to have "workflow" technology, but it is rarely used in the core business process of the system, and most of them are only in "document approval" or non-core transaction processing business such as "expenses". Reimbursement" and other fields have been applied.
In addition, the workflow application of "document approval" in EBS is only one of the system implementation methods of "document approval". In order to meet the needs of complex business environments of enterprises, combined with workflow technology, the system also provides a more powerful and relatively independent engine module "Approval Management" (AME) as a "peripheral product" for enterprises to choose and use.
An Overview of the Application Basis of ORACLE EBS System
11. Alert _
12. Application Open Interface ( Open Interface and API )
Thirteen. Conclusion
(Note: There is a problem with the batch of pictures sent by the website, and the display is not clear after uploading. After clicking the picture to open, the quality is acceptable)
Today, in many places such as corporate offices or hotel rooms, we can see "smoke alarms" and "automatic sprinklers" installed on the ceiling. The country has clear laws and regulations on the fire safety of buildings, so These "warn or suppress" devices have become almost standard in buildings. Similarly, the early warning platform is almost a standard equipment for today's ERP system. It is not very complicated and easy to master, whether it is from the perspective of system implementation or business application.
ORACLE's system early warning is divided into two ways, one is "event early warning" and the other is "period early warning". The basic working methods of both are to use the SQL Select statement to make a conditional judgment based on the relevant value in the database to decide whether to perform a certain activity (send information, execute concurrent programs, execute operating system programs, and execute SQL statements). Furthermore, for the "message sending" type of early warning, after the system receives a "reply" that conforms to the prescribed format for this information, it can also automatically execute related activities and complete related transaction processing accordingly.
The so-called "event warning", that is, when the user "inserts" or "updates" certain values in the relevant data table, the system automatically starts the check of the defined "SQL Select statement", and determines whether it is necessary to issue an early warning message or execute a certain Such an activity, as shown in Figure 33 below, is an event early warning definition: In the procurement management system module, when a huge number of requisition lines is entered, the system needs to send an early warning notification to the relevant responsible person (to remind such as making a good resource preparation, etc.).
The so-called "periodic early warning" means that the system automatically starts the defined "SQL Select statement" according to the pre-defined periodic interval or frequency to check certain values in the tables in the database, and has determined whether it is necessary to issue early warning information or execute certain Activities, as shown in Figure 34 below, a periodic early warning definition: In the procurement management system module, the system checks the expiration of all "Blank Purchase Agreement BPA" at intervals of every two working days, and will The results of the inspection (for example, some BPA will expire in a week) are notified to the relevant responsible persons.
12. Application Open Interface ( Open Interface and API )
Any ERP system cannot meet the various requirements of the actual use of the enterprise under any circumstances. Sometimes the enterprise may need to input data into the system in batches from other sources, such as importing from the Excel spreadsheet of materials to the INV system of EBS Item information, etc., or need to establish a business data exchange mechanism with other third-party application systems, such as importing transaction processing data from a dedicated "expense reimbursement or invoice application" management system to the EBS AP system and feeding back transaction execution results Back to the source system and so on.
Theoretically, using related database tools can directly write data in batches to the data table of the database, but in doing so, the correctness and compliance of the written data cannot be verified, and the quality of the written data cannot be guaranteed. Manage effectively. To this end, ORACLE provides the interface table Interface Table as an "intermediate table" transition, and on this basis, provides a business view Business View according to certain business needs, so that the imported data can be modified, corrected, re-imported, etc. managed. "Open Interface Diagram" as shown in Figure 35 below:
Furthermore, ORACLE encapsulates some data import and export functions and becomes an interface (API) that applications can call to realize data and process integration between modules and between internal modules and external systems. "Open Application Programmatic Interface (API) Diagram" as shown in Figure 36 below:
The basic working mode of the release interface (API) is divided into two stages: one is to load the source data into the (Load) interface table first. If it is between two application systems, this is usually done by a dedicated loader. For example, if an EBS internal purchase requisition is to be converted into an internal sales order, it is necessary to run the "Create Internal Sales Order Process" to send the internal purchase requisition And insert it into the interface table of the order management system. If it is imported from some spreadsheets such as EXCEL, you need to use a special SQL*Load tool to convert the data format and then directly insert it into the relevant interface table. Insert the source data into the Item data interface table through SQL*Load tools such as DataLoad. Whether to verify the data during the process of inserting the data into the interface table (or to verify when the interface table data is imported into the actual table) depends on the different designs of the application modules of the system;
The second is that the system imports the data existing in the interface table into the official business data table, such as "Order Import" in the EBS order management module, "Import Item" in the inventory management module, and so on. For the error or failure information caused by data verification during the process of importing the "official table" from the interface table or loading data into the "interface table", if the system provides a special business management view, you can view, correct, and reset the information in it. Submit, such as EBS's "Order Import Correction" window, etc. If administrative views are not provided, the results can be viewed in the concurrent program request's Output file. The "Flowchart of Importing Invoices of Expense Report Type of Accounts Payable Management Module" shown in Figure 37 below is a typical example of the application process:
We often see some domestic products in the publicity, always like to ridicule foreign products such as SAP is already an "old antique", deliberately emphasize how advanced their own technology is, how innovative the platform is, etc. These are actually far from enterprise application practice. Flashy things, but in the process of product development, the basic elements and application-based research that are more important to the practice of enterprise informationization are ignored. This is like the developer who sells the house always shows how good the steel bar is, how high the cement grade is, and the machinery and equipment used in the construction are all imported. What is the relationship between the required "house type structure, space application and community facilities"?
The advancement of technology will undoubtedly have a major impact on many aspects such as organizational form and business model in corporate management practice. In the past 100 years since management was born as a "science", corporate management practice has evolved from the early "functional management" From the introverted focus on "production efficiency" in the early days to the outward focus on "customer needs" in the modern era, the advancement of technology, especially the rapid development of information technology in the past two decades, has played an important role in promoting it. However, management science belongs to the category of "metaphysics" after all. Compared with the "metaphysical" level of artifacts, the role and influence of technological progress are always inherited rather than subversive.
Looking back at the development history and evolution of SAP R3 or ORACLE EBS over the past ten years, we can find that system developers and designers have integrated into the software at an early stage the core management ideas and business models that are crucial to the core business operations of enterprises. The content is not outdated, they are still the core and foundation to support the efficient operation of enterprises today, and they are also advancing with the times, constantly being enriched and perfected with the development of the times.
Management software has evolved from the mainframe era 30 years ago, to the client/server era of C/S architecture 20 years ago, and then to the Internet era of B/S architecture opened ten years ago. The impact of the overall progress of information technology on enterprise management practices is generally partial and inconclusive. Today, no one will believe the exaggerated statement that "the evolution of management software from C/S architecture to B/S architecture is a revolution in enterprise management practice", let alone the more inferior ones such as .NET platform, Java platform, private The ABAP platform and other development tools in the purely technical field have much impact on the management ideas and business process models contained in the management software.
People who like to watch American dramas may often see two magnificent landmark buildings built in New York in the early 1930s in the film: the Chrysler Building (77 floors) and the Empire State Building (102 floors). Eighty years ago, the technical conditions and tools are simply incomparable with today, but can we say that they are outdated today and are not "modern" buildings? Who knows that the Chrysler Building is still the tallest " brick " building in the world!
Human cognition always gradually extends from the known to the unknown. If we put aside the specific business process, functional application and operation details of the system for the time being, and only focus on the 11 basic components of the aforementioned ORACLE EBS system, from the perspective of practical sources and system implementation, this is not a detailed but intuitive summary Through discussion, we may be able to obtain such an overall understanding that no matter how large and complex a software application product system is, it is still composed of some basic components that are relatively simple to use and not esoteric to understand. These basic components come from business practice or are closely related to daily work. We are not unfamiliar with them. They are the crystallization of a high degree of integration of "from business to technology, and then from technology to business". They are also mysterious and elusive codes. Space is a bridge to the complex and colorful real world.
In most cases, for ordinary EBS system users, combined with their own business, they have mastered the first few of the above-mentioned more than ten basic elements, such as forms, queries, transaction processing, folders, and concurrent requests for reports. It is enough to cope with general daily work; for system implementation and maintenance personnel, relatively speaking, the latter few basic elements with a strong technical flavor, such as concurrent processing, elastic domains, configuration files, workflow, etc., may be working Key points and difficult points.
But it should be pointed out that the introduction of the basic components of the system in this article is only to help beginners break the mystery and guide the way. To further master the system, it is necessary to combine the specific test environment of ORACLE EBS, compared with monotonous abstraction and boring A large number of boring application help documents and a large number of hard, patient and meticulous study and research are by no means achieved overnight.
Regarding the specific test environment of the EBS system, installation and use are basically not a problem for today's computers with common configurations. There are a large number of detailed and detailed installation help documents with pictures and texts on the Internet for reference. The official application help documents of the ORACLE system mainly include three types for each module: Implementation Guide (implementation guide), User Guide (user guide) and online help (online help). These three types of documents are basically reference books frequently used by consultants and implementers.
At the end of the code word, I suddenly remembered the ancient inspirational quotes that a senior ORACLE consultant likes to quote on the cover of his article. Here, I will move here to share and encourage everyone:
The road is long and long, and I will search up and down .