First of all, it needs to be explained that this series of documents assumes that readers already have basic system-related knowledge and skills (for example, they can basically understand the content in "ORACLE EBS System Application Basics Overview"), so the content discussed is limited to the author's opinion. Issues that are important or doubtful from the perspective of system use and actual business cannot be exhaustive, and are designed to help readers grasp the core and grasp the main points (for detailed content, please refer to the relevant official documents of ORACLE). For the purpose of discussion, the accompanying drawings and texts are all taken from the ORACLE EBS test environment (Vision Demo). The version is mainly R12.1.1, supplemented by version R11.5.10. The interface language is mainly Chinese (supplemented by English when necessary) . There may be some differences between the two EBS versions in terms of interfaces and functional applications, and related explanations will be made when necessary, but generally they will not affect the discussion of basic issues.
Technology is the abstraction and tool of business, and business is the source and purpose of technology. Throughout this series of documents, we will adhere to the methodology of "examining technology from the perspective of business and returning to business from the perspective of technology" (the so-called "technology" here means "system implementation") to discuss the relationship between system implementation and business practice. Convergence issues, in order to gradually achieve the integration of technology and business. Limited to the author's cognitive level, there are errors or inaccuracies, welcome to criticize and correct.
From the perspective of system use, an important daily work of system management is the management of "users" and their "permissions", which is called "Security" (Security) management in ORACLE. "Security" is a conceptual term with a richer and broader meaning than "authority". Although it is relatively abstract, as the name suggests, it covers well the relevant enterprise data and information in actual business and system use. Certain management content that needs to be protected and controlled.
Regarding the management of user rights, there are three basic elements in the ORACLE system: menu ( Menu ), responsibility ( Responsibility ), and user ( User ) . The organic combination of the three forms the basis of system authority or security management, supplemented by the use of parameters or "security configuration files", etc., and further "entity (organization, account set or ledger) access" of users Permissions are subdivided. In addition, in each application module of the system, it is possible to adopt unique system implementation methods based on different business characteristics, and further divide the user's access management or function authority (the specific method depends on the personal preference of the system designer). Certain relationship, cannot be generalized).
"Menu" (Menu) has become a very common term in the daily life of today's information age. The concept of "menu" in ORACLE is nothing special, it also represents the user's system application function entrance. The most basic "menu" is composed of several "form functions" preset by the system. EBS currently has about 20,000 such form functions; Some non-form "sub-functions" called by the logic contained in it need to be developed for background settings). Users can customize the user menu including several basic menus as "submenus", and the customized "user menu" can also be used as "submenus", thus forming a menu structure (tree diagram). As shown in Figure 1, the menu definition and optional system preset form function LIST:
After the EBS system is installed, the so-called "Super User Menu" including all functions (or permissions) has been pre-defined for each application module. The enterprise (system administrator) can define the user's "responsibility" Use the "method of elimination" to meet actual business management needs. In addition, the system also provides a predefined menu with the function of "inquiry only", which is used by some users who need to limit their business operations.
Compared with the familiar "menu", EBS's so-called "Responsibility" (Responsibility) concept is much more blunt and abstract, and it can usually be referred to with the relatively familiar "Role" (Role) concept. In enterprise management, personnel are usually divided according to "job roles", such as "planners, purchasers, warehouse managers", etc., which usually correspond to certain job responsibilities (responsibility), and have real business management implications. Be more specific. The system pre-defined role, after assigned to the user (User), the user has all the application functions of the role; but EBS does not use the role concept like other products (such as SAP), but uses the "responsibility" concept, which is more inclined Abstractly represents the combination of some functions (entry menu), which may not have real management meaning. For example, under the responsibility of the so-called "sales manager", it can have the same menu items and functions as the "purchaser". , and this point is obviously inappropriate if it corresponds to the actual "job role". Role is more clear and direct, but not flexible enough to use; Responsibility can be used flexibly, but it is easy to cause ambiguity and misunderstanding in understanding, so pay attention to the distinction when using it. The "responsibility" definition interface shown in Figure 2 below:
Each responsibility must be associated with a certain menu, but you can use the "exclude" function to make it have different menu structure combinations. The "exclude" function here does not affect the original structure settings of the menu, which is convenient and simplifies the system administrator. Management of "responsibility" and "menu". The "responsibility name" always belongs to a certain "application product" (module), and different modules can define the same "responsibility name" (including the menu), but these two identical responsibility names are in the "configuration file" When set as a hierarchy, it can have different values, which further provides the flexibility of the system. Once the responsibility is defined, it cannot be deleted and can only be invalidated by setting the validity period. Setting a "request group" for it limits the range of "requests" (concurrent programs) it can use. As for its "Adoptable" application product range setting (Web, self-service, etc.), it seems that it only plays the role of system management for statistical analysis, and does not actually affect specific functional applications.
After the system is installed, it will have an initial user named "SYSADMIN" (password sysadmin) with "system administrator" responsibility (this user is sometimes called "super administrator"). Use this initial user to set up Menus, Responsibilities and Users. The definition interface of "User" is shown in Figure 3 below:
Each defined system "user" can be associated with several different responsibilities, and each responsibility can also set a valid date range for the user to use. When users with multiple responsibilities log in to use the system, they need to switch between different responsibilities, which cannot be used at the same time. The password set during the initial setup of the system will be prompted by the system to modify it when the user logs in for the first time. Passwords can be limited by "days of use" or "number of visits", and the system's early warning platform can set early warnings of password failures to urge users to modify them in a timely manner. Once a "user" is set, it cannot be deleted, and it can only be invalidated by setting the validity period. "User" does not necessarily have to be associated with the "personnel" set by the HRM module, but for the application functions of some modules, it is necessary to associate the "personnel" that has been properly set by HRM. Associating "customer" or "supplier" mainly plays the role of system management for statistical analysis, and does not affect specific functional applications. The "email" address associated with the user is mainly used by the system early warning platform to send information.
Regarding the use of relevant "configuration files" in the EBS system, such as "MO: business entity, MO: security configuration file, HR: security configuration file, GL: data access permission set, GL account set name or GL ledger name", etc., further The issue of subdividing the responsibility or user's "entity access" rights (compared with R11, R12 has a large change), will be discussed in the "organizational structure" setting below.
As for the further division of responsibilities or user rights in specific application modules, such as "organization access" (Access) in the inventory module and "authority management" (Grant) in the shipping module, we will discuss it later in the relevant module documents.
To define a user , you can give him multiple responsibilities ; a responsibility corresponds to a menu , but some functions and submenus in the menu can be disabled according to actual needs; a menu includes multiple submenus . (Generally, there will be a menu after the system is installed , and users can define the menu later according to their own needs )
two,Accounting Flexfield Structure
Before discussing the setting of the "organizational structure" of EBS, it is necessary to discuss the setting of the Accounting Flexfield and its set of books (SOB) or ledger (Ledger). "Account set" is a term in R11 and previous systems, and "ledger" is a term used in R12 to replace the account set and to make a difference. For the convenience of expression, unless otherwise specified, the customary term "book set" will be equivalent to the term "ledger". In EBS' concept of "organizational entity", the account set is actually a form of "organizational entity". The reason for this has something to do with the development history of ORACLE products.
Accounting subjects are the basis for enterprises to carry out financial data accounting work, and the accounting laws and regulations formulated by various countries based on the needs of enterprise supervision and taxation work have corresponding provisions. The new accounting standards promulgated by our country in 2006 divide the accounting subjects into six categories: assets, liabilities, joint, owner's equity, cost, and profit and loss, with a total of 156 (level 1) subjects. Simple financial accounting software or when the scale of a single company is small, the implementation of the "computerized" system similar to manual bookkeeping is not a big problem, but when the accounting business management needs are complex and the enterprise develops from a single company to a multi-company group, It is necessary to consider the problem of how to conveniently manage the accounting data of multiple companies in a centralized and unified manner at the system level.
ORACLE's ERP product was originally developed from financial software, and the general ledger GL is its first application module. In fact, before the advent of computers or management software, the needs and practices of the so-called "group management and control" of enterprises already existed. ORACLE's financial software includes "multi-company information" unique accounting subject flexible domain structure design, which makes the group management and control of financial work more technically feasible and convenient. One of the most basic and simplest accounting title flexfield structures is the combination of "company code + accounting title code", and there is not much esoteric source of its original business requirements.
In ORACLE's flexible domain structure of accounting subjects, the "accounting subjects" that reflect the requirements of national laws and regulations has become an indispensable component segment, that is, the "natural account" segment. The value set used by natural accounts is commonly referred to as "Chart of Accounts". The system adds multiple pieces of information such as "company, department" to the natural account, which greatly facilitates the statistical analysis of accounting data within the company and between companies. As shown in Figure 4, it is a typical 5-segment account elastic field structure:
The "company segment" in the figure is a "balance segment" (Flexfield Qualifiers, which is an "identification mark" with a specific attribute), which means that at the "company segment" level, journals (Journals, "accounting entries" ), the "debit equals credit" always balances. Its value set is the code LOV that contains all companies, including legal entities and operating entities set based on company management needs; as shown in Figure 5, the definition of the "company segment" value set of the account elastic field structure:
The legal entity LE defined in the EBS system must correspond to (at least) one value (row) in the company segment value set, but the difference between R11 and R12 is that when R11 defines LE, it does not explicitly tell the system which corresponding (binding) Segment value, as long as the user is clear and not confused. When defining LE in R12, it needs to be clearly associated with a certain company segment value in the account elastic domain structure. The resulting confusion.
The flexible domain qualifier of "Department Segment" is "Cost Center Segment". The cost center LOV value may be a specific administrative organization in the enterprise, or it may represent a combination of multiple administrative organizations sharing a cost center, or it may represent the The combination of multiple cost centers set for statistical management needs; as shown in Figure 6 below:
The flexible domain qualifier of "account segment" is "natural account segment", and its LOV value is the statutory chart of accounts and the summary account set for statistical needs; as shown in Figure 7:
Note that the content of the "segment qualifier" in Figure 7 is different from that in Figures 5 and 6. It specifically stipulates the category of accounting subjects represented by the segment value of the natural account (assets, liabilities, etc.), and the "elastic domain qualifier " and "segment qualifier" are two different concepts, and the value of the segment qualifier is controlled by the value of the flexfield qualifier.
The "sub-account segment" of the account flexible field structure means "secondary account or detailed account", which has a summary and summary relationship with the first-level account of the account segment; "product segment" means that it is set based on specific statistical analysis needs The product LOV.
The system allows setting up to 30 segments, but must contain at least two segments (balance segment, natural account segment). Since the account elastic domain structure is set and used, it is difficult to modify later, so one or more reserved segments are usually set, for example, a temporary unused segment can be added in addition to the above typical 5-segment structure (Reserved segment) and become a 6-segment structure. The setting of the account flexible field structure is one of the important tasks of the system basic setting. For detailed setting methods and steps, please refer to the relevant system setting documents.
In addition, the EBS system provides the "Security" setting function for the access rights of the "segment value" of all elastic domains to control the actual range of segment values that can be used by "responsibility", as shown in Figure 8 below:
three,Set of accounts (ledger)
The combination of account flexible field structure (COA), currency (Currency), and calendar (Clander) constitutes the so-called "set of accounts" (SOB) of EBS R11 and previous systems. In R12, another dimension "accounting method or accounting practice" is added, which becomes the so-called "ledger". The so-called "accounting method or practice", for example, for different countries or regions and different companies, accounting regulations may stipulate whether the unit price of an item of 5,000 yuan is treated as a "fixed asset" or a "period expense". ten thousand yuan. With different standards, the accounting subjects for bookkeeping are also different, and the operating results reported by enterprises will also be different. For example, a company registered in Hong Kong, on the one hand, needs to submit financial reports that comply with local regulations to Hong Kong government agencies, and on the other hand, may also need to provide financial reports that comply with domestic regulations to the head office in China (to facilitate assessment and management), which is The so-called "multi-account book" (corresponding to the primary and secondary ledger in R12) has a system function problem. Figure 9 below is the definition interface of "Account Set" in EBS R11:
As shown in Figure 10 below, it is the definition interface of using "Account Manager AMB" to set "Primary Ledger" and "Second Ledger" in EBS R12:
A "Primary Ledger" defined in R12 can be defined with multiple "Secondary Ledgers" associated with it, as shown in Figure 11 below:
The "primary ledger" and the "secondary ledger" can have different chart of accounts structures (COA). Since other application modules of the system (referred to as "sub-ledger application products" in R12), such as PO/AP/AR, etc., their transaction processing is based on the chart of accounts (COA) of the "main ledger" by default, so , if the chart of accounts of the primary and secondary ledgers is different, a "Mapping" relationship (1-to-1 or many-to-1 relationship) must be established between the two. As shown in Figure 12 below, the mapping definition interface of the primary and secondary ledgers, if the two charts of accounts are the same (different currencies), the definition interface will be different, there is no mapping content of the "chart of accounts", only the latter part (currency) conversions and journal conversions, etc.):
Figure 13 below shows the definition interface of the system chart of accounts mapping when the chart of accounts of the primary and secondary ledgers is different. It can be seen in the account rule definition that the source account can be a range, while the target account can only be one:
The "ledger Ledger" defined by the four dimensions (4C) in ORACLE EBS R12 constitutes the processing basis for the "multi-book" function of the ORACLE system. In fact, the "set of accounts SOB" defined by the three-dimensional (3C) in R11 also has the concept of "multi-reporting currency account books", but that is limited to the automatic conversion of financial statements between different currencies, not a system in the true sense "Multi-account book" function (that is, a company automatically generates multiple sets of accounts that meet the requirements of accounting regulations).
The core and key of ORACLE EBS R12's "Multi-ledger" function is how each related application module (sub-ledger application product) automatically generates a separate account for the "main ledger and auxiliary ledger" in the general ledger when transferring journals to the general ledger module. journal entry for . This involves setting the "sub-ledger accounting option" in Figure 10 for the main and auxiliary ledgers respectively. It actually includes two steps. One is to define which application modules for the system can use the sub-ledger accounting method (ORACLE has Predefined); as shown in Figure 14 below, the system has predefined 21 application products including PO/AP/AR/CST/FA, etc. that need to use the sub-ledger accounting method:
The second is to set the "sub-ledger accounting method" for the main and auxiliary ledgers for the application modules that have defined sub-ledgers, as shown in Figure 15 below:
The "Event Classification Options" and its related settings are the most basic, complex and abstract processes of the system, including complex user-defined tasks, such as the combination of accounting event classification (Event Class) and accounting event type (Event Type) Definitions, Journal Line Definitions, Journal Line Type Definitions, and so on. The system transaction processing of each sub-ledger application product is based on the "code combination" of the main ledger and its account generator rules by default. When the sub-ledger application product system starts the "transfer journal to GL" process, for each accounting event For the "classification-type" combination of classification, the process will generate the corresponding "account code" (CCID) and journal line according to the "condition" and "account derivation rule" of the journal line type contained in the "sub-ledger accounting method". Different ledgers, such as primary and secondary ledgers, may generate different CCIDs, which is what the "multi-book" function requires. For the detailed process of setting the "Subledger Accounting Method", please refer to the relevant ORACLE documents. As shown in Figure 16 below, it is only one of the definition interfaces:
For EBS R12, even if the auxiliary ledger is not used, the "sub-ledger accounting method" must be added to the "main ledger". It can make ORACLE preset the default one, or it can be customized by the user after modification. In fact, for EBS R11, the installation is equivalent to ORACLE directly preset sub-ledger accounting methods for all SOBs. The system shields the definition of complex sub-ledger accounting methods from users, and users cannot modify and adjust them.
The complicated definition of "subledger accounting method" is the price that EBS R12 has to pay for the "multi-book" function. Fortunately, it only has a certain impact on the use of the GL module, and has no direct impact on the use of related application modules. From R11 to R12, the "multi-book" function is only equivalent to calling one more "service". The EBS system The upgrade and use have maintained a good inheritance.
In the general ledger GL module of EBS, since the object of work is mainly the data information of the journal (accounting entry) based on the "account code", the "organizational attributes" of the accounting data of different companies from each business module are actually passed through the account The different company segment values in the code are already reflected, independent of the relevant "(Business) Organization Attribute" settings in the respective source business modules (subledger application products). Therefore, comparing the general ledger module with other business modules, the general ledger module does not need to be divided into so-called "organizations", which can be said to be "unorganized".
General Ledger users can generally handle all company accounting data (unless security is set for flexfield segment values). If it is necessary to say that the general ledger GL also has similar business organization attributes, then this "organization entity" is a set of books or a ledger, and the system will use the "organization access" configuration file similar to the business module (such as "MO: business entity") "Account set access" configuration file (such as "GL account set name" in R11 or "GL: data access permission set", "GL ledger name" in R12, etc.) to separate the user's work authority.
There are the following precautions regarding the use of the "Account set access" configuration file. For the configuration file "GL account name", the LOV of this parameter in R11 is automatically created by the system based on the created SOB name. Once it is assigned a value, the system automatically locates the specified SOB when the user logs in. Since the GL module has nothing to do with the OU, after entering the GL, the division of data is mainly based on this parameter, but this parameter does not limit the access to data that requires cross-SOB functions such as FSG. As shown in Figure 17 below:
For the configuration file "GL ledger name", this parameter is only available in R12, similar to the "GL account name" in R11, but its function is quite different from that of R11. Its LOV is a collection of ledger names (automatically added when creating ), it only means that the "ledger" entered by the current user also needs to use sub-ledger products such as AP/AR and so on. As shown in Figure 18 below (the ledger that the current user can enter is controlled by "GL: Data Access Permission Set"):
For the configuration file "GL: Data Access Permission Set", this parameter is only available in R12 and must be set (with a value), otherwise the system will report an error. However, the system provides a special control mechanism, that is, whenever the setting "GL Ledger Name" is modified, the system will automatically modify the value of "GL: Data Access Permission Set" at the same time, so that it is consistent with the value of "GL Ledger Name" unanimous. If the "GL Ledger Name" is set first, and then the default value of "GL: Data Access Permission Set" is modified, when the system enters the FORM of the journal, if the latter value does not include the former value, the former setting is invalidated, but the system cannot use the associated subledger product. If the latter value contains the former value, the former value represents that the ledger also needs to use the related subledger product. As shown in Figure 19 below:
The value LOV of the configuration file "GL: Data Access Permission Set" needs to be set in the system separately. Each value contains several defined ledgers/ledger sets and their read and write permissions. Select switch in the interface, as shown in Figure 20 below:
Special attention should be paid to any modification (including clearing) of the "GL Ledger Name" of R12, which will automatically affect the value of "GL: Data Access Permission Set". The reason why the system is designed in this way is to ensure that the business control function of the original R11 remains unchanged, and to control the "range of accessible data" in R12 by adding parameters. Therefore, the correct approach should be: first set the value of "GL Ledger Name" to realize basic business functions (associated with sub-ledger products), and then modify the default value of "GL: Data Access Permission Set" to control data access. Access scope, but must ensure that its value contains the value of the former.
During the test, it was found that if the "GL Ledger Name" configuration file value is left blank, and the "GL: Data Access Permission Set" is modified, the default ledger of "GL: Data Access Permission Set" does not appear in the FORM window In the interface, this appears to be an oversight on the part of the designers.
ORACLE GL will automatically create the "data access permission set" LOV value when "creating ledgers and defining ledger sets", and its type is "all ledgers", providing full read and write permissions. When it is desired to further restrict read and write access to specific balancing segment values or management segment values of a ledger, ledger set, or ledger/ledger set, users need to create their own data access permission sets.
In R12, it is also possible to additionally define an "access permission set" for the financial system (different from the parameter "GL: data access permission set"), and assign it to a responsibility to limit the functions that the responsibility has (of course this is in the current under the ledger). The system presets a "Super User Defined Access Permission Set" (unmodifiable). It is speculated that the restriction method of "authority" may be "peeling" (when it is empty, the authority is the largest, and every time an item is added, there will be one less corresponding authority), as shown in Figure 21 below:
Finally, it should be noted that the so-called "multiple account books" function of the EBS system and the "multiple account sets (ledger) access" function are two different concepts. The "Multi-account book" function means "the system automatically generates multiple books for the same business processing of a user", which reflects the system business processing function, which is available in R12 but not fully in R11 (R11 can only provide multi-currency reports). "Multiple account sets (ledger) access" function means "how a user accesses multiple account sets (ledgers)" rights management method ("context" environment switching method), which is also available in R11, but for the same user, It must be realized by switching between different responsibilities with the same business function, which is not very convenient to use. However, the same user of R12 does not need to switch "responsibility", it can be realized only by directly selecting the switch on the form, which is more convenient to use. Although the context switching methods of R12 and R11 are different, the system service processing functions after switching are basically the same.