Organization
(1) Business Group (BG )
(2) Legal entity (LE )
(3) Business entity (OU )
(4) Inventory organization (INV )
(5) Company cost center (Cost Center )
(6) HR organization
(7) Multi-organization access control
Organization
In the process of enterprise management practice, the term "Organization" is a concept that is often used. It is generally closely related to the two elements of "personnel" and "function", reflecting some kind of administrative relationship, such as "financial organization". Department, Sales Department, Purchasing Department, Production Department, Warehousing Department” and so on. The division of the internal administrative organization (department) of the enterprise is the basis for the operation of the enterprise based on the "function-driven" business management model. At present, most low-end management software suitable for small enterprises in China does not consider the "organization" setting in the system. The division of the system application modules, such as purchasing module, warehouse management module, sales module, etc., is actually It has basically reflected the division of "organizational functions" in the operation of enterprises.
However, for complex and large-scale enterprises (such as so-called "group enterprises"), the issue of "organizational setup" of the system for the use and implementation of management software will be a primary and important issue. A common and wrong way to implement the system is to directly map the "administrative organization settings" of the enterprise to the system, and replace the "business organization" with "administrative organization". Although this system implementation method has the advantage of being easier to understand and master, it completely violates the basic management principle that the operation of large enterprises must be based on the "process-driven" business model. There are so-called high-end management software in China. In the process of system implementation, there are often dozens of financial and purchasing organizations, hundreds of sales organizations, and even thousands of inventory organizations. This makes the system almost unusable. Herein lies the crux.
Unlike the "administrative organization" setting of an enterprise that is closely related to the size of the personnel and is complex and changeable, the "organizational setting" of the software system must focus on business process operations, requiring it to be as simple as possible and relatively stable. The process has continuity and inheritance. As the originator of ERP, SAP simply divides the system organization into categories such as "Group (Client), Company Code (Company Code), Purchase Organization (Purchase Org), Sales Organization (Sale Org), Plant (Plant)". ORACLE's organizational settings are basically similar in nature, but as a latecomer, it has been further abstracted and simplified. The system organization is divided into "Business Group (Business Group), Legal Entity (Legal Entity), Business Entity (Operating Unit), Inventory Organization (Inventory Org)", etc.
If SAP’s organizational model literally has a little trace of “administrative organization” (this may be the reason why some domestic products that claim to learn from SAP go astray), the organizational model of the ORACLE system is almost invisible. What is the relationship with "administrative organization"? "Inventory Org" is translated into "inventory organization" in Chinese today, which is easy to be confused with the "warehouse management department (Warehouse)" of the enterprise, but the original meaning of Inventory should actually be " Inventory", it may be better to call it "inventory organization". The multi-organization model of the core business of the ORACLE system is shown in Figure 22 below:
"Finance, Sales, Purchasing" in the above figure is not the "Organizational Entity" of the system, it only represents the relevant business processing functions of the business entity (OU). "Sub-library" is a special system organization entity, which has no context to enter, and mainly represents a certain business function under the inventory organization.
(1) Business Group (BG )
The concept of "business group" can be referred to the concept of "group" of an enterprise, but the difference is that an enterprise can set up multiple "business groups (groups)" in the system. Usually, for an enterprise, it is enough to have one "business group" in the system, which means that the enterprise is a "group company". For some very large companies with "diversified" businesses (such as multinational companies), it may be necessary to set up multiple "business groups" in the system, indicating that the enterprise is composed of multiple "group companies".
Business group setting is the first step of system organization setting, and it is the highest level of organization form, but it is mainly related to the separation of human resources information, that is, the setting of "personnel information" is shared by all business modules within the scope of a BG (If needed). Once the user name (User) set by the system is associated with "Employee", no matter what "responsibility" is used to enter the system, it will be located in a certain BG, and any responsibility can only be associated with one BG at any time. After EBS is installed, an "initial business group" named "Setup Business Group" has been preset in the system. As shown in Figure 23, the system preset "Setup Business Group":
After entering with the system preset super user SYSADMIN, first set a "responsibility" name with the function of creating an organization under HRM or INV, and then set the value of the "HR: User Type" configuration file of this responsibility to "HR User ", then this responsibility has the ability to create a new BG. Usually, it is necessary to establish all the BGs required by the enterprise at one time. Generally, it is enough to create a new BG that is consistent with the name of the enterprise, such as "XX Group", or you can (not recommended) directly use the system preset "Setup Business Group ” without creating a new BG.
Every time the system creates a new BG, it will automatically add an optional value with the same name as the newly created BG in the LOV of the configuration file "HR: Security Configuration File" (there is only one value "Setup Business Group" initially). For any responsibility created under a certain BG (initially Setup Business Group), the system defaults the value of the configuration file "HR: Security Configuration File" of the responsibility to the current BG. To be able to switch to a new BG when entering the system, the "HR:Security Profile" setting for that responsibility must first be modified.
If the value of the configuration file "HR: Cross Business Group" is set to "Yes", the newly created organization names should (although can) be different under different BGs, otherwise it may cause confusion when viewing. All newly created organizations under the same BG must not have the same name.
(2) Legal entity (LE )
A legal entity (LE, Legal Entity) corresponds to a "corporate company" registered in accordance with national laws and regulations in the real world. In R11, when LE is defined in the organization FORM, each LE must be associated with an "Account Set SOB" for its "Legal Entity Accounting Item". Each LE corresponds to an SOB, which is consistent with real-world regulatory requirements. As shown in Figure 24 below:
It should be noted that the LE defined in R11 is not associated with the "Company Segment" value of the "Accounting Account Flexfield Structure", and the user must know which value in the company segment value it corresponds to. In R12, although the organization definition of LE is still retained in FORM, the FORM setting of LE's "Legal Entity Accounting Subject" is discarded (so it is useless to define it in FORM), and it is changed to when defining "ledger". Define and assign the legal entity LE in the "Account Setting Manager" WEB. Multiple LEs can be added to one ledger setup (primary and secondary ledgers), but each LE can only have one ledger setup. As shown in Figure 25 below:
In R12, legal entities must also be assigned the Company segment of the Accounting Flexfield structure, the Balance segment value. Each LE can be assigned multiple "balanced segment" values. Once each segment value in the company segment value set is assigned to a certain LE, other LEs cannot be assigned. After creating an LE in R11 or R12, you should add the corresponding company segment value LOV (one or more) to the account elastic field structure in time, and recompile the elastic field, otherwise the system may pop up an error alarm message . In R12, one LE corresponds to multiple company balance segment values, which means that there are multiple branches, and LE is their merger. The primary and secondary ledgers can have the same or different company segment value sets, indicating that companies are divided from different dimensions (such as by region, by product, etc.) to facilitate assessment. Add the balance segment value for LE as shown in Figure 26:
Whether it is R11 or R12, the setting of the legal entity LE has little impact on specific business processing. It is not related to system users or responsibilities, and does not directly affect the switching of system contexts. Therefore, some people even think that the LE setting of EBS has little effect. This is indeed similar to the internal operation of the system, but for documents with legal significance (such as purchase orders, financial statements, etc.) that need to be generated through the system for external use, it is still necessary to strictly distinguish the legal entity LE. R12 obviously takes this legal requirement for external use into consideration (the so-called "regulatory compliance" or "compliance"), and it is reflected in the relevant business application modules.
(3) Business entity (OU )
The business entity (OU, Operating Unit) is one of the key points and one of the difficulties in the organizational setting of the EBS system. It has no necessary relationship with the legal entity LE itself, nor has it a direct relationship with the "company segment" in the flexible domain structure of the accounting subject. From the perspective of the actual business management needs of the enterprise, the business entity OU can be regarded as dividing the business processing and data of multiple companies (including LE) into relatively independent "management units" according to the similarity of business in the system ". Within each administrative unit, the business operations of each company share relevant data and execute unified business policies.
For example, there is an enterprise with diversified businesses that produces both X-ray machines used in hospitals and ordinary TV sets, and its subsidiaries have many branches and subsidiaries that produce X-ray machines or TV sets across the country. Since the materials, suppliers, and target customer groups used by these two products are very different, for the convenience of management, the enterprise can divide the "business operation" into two relatively independent "business management groups", corresponding to the EBS system There are two business entities OU.
From the perspective of daily business operation management, for the simple TV business, it is most convenient to set up a company nationwide to be responsible for planning, production, procurement, sales and other operational management. Considering factors such as local policies, etc., sometimes it is necessary to register a number of so-called "companies" all over the country and even around the world in order to pay taxes to the local government and accept its financial and accounting supervision.
EBS is under a business entity OU, such as "TV management group", which includes the daily business operations of all branches and subsidiaries (LEs) responsible for the production or sales of TVs across the country, which is ignored at the organizational level of business operations. Company information as a legal entity, but at the financial stage (GL) reflecting the final results of business operations, it is still convenient to provide financial data and results in accordance with local regulations. For system users who are responsible for specific businesses, they hardly need to care about or consider the setting of "company" in their daily work.
The number of LEs in EBS can be increased arbitrarily as needed, but the number of OUs should be as simple as possible based on the convenience of management. In the early implementation of EBS products, there was a practice that one company (LE) corresponds to one OU or that one OU can only belong to one LE, which is not appropriate. The design of some domestic products fails to effectively distinguish the special relationship between "legal entity (company)" and "business entity (operation)" in the system, which is both connected and essentially different. The "stupid method" of business entities can be dealt with by small enterprises. Once the scale becomes larger and the number of registered companies increases, the so-called "system multi-organizational structure" becomes unusable at all.
This system characteristic of ORACLE EBS business entity OU greatly facilitates the daily management of enterprise operations, and has a high degree of flexibility and scalability. Figure 27 below is the OU definition interface of R11:
In the "Business Entity Information" in the figure, only one "Account Set" must be set for it, that is, one OU can only belong to one account set (conversely, one account set can be assigned to multiple OUs). It should be noted that the legal entity setting in the above business entity information does not mean that the OU can only belong to one LE, it just means that the default value is provided when the legal entity information is required for business operations in the "business entity" (in R12 It is clear that it is the "default value"). The definition of business entity in R12 is basically the same as that in R11, except that the account set is changed to "main ledger".
In EBS, one OU can be assigned to multiple LEs at the same time. The above example of "TV management group" has illustrated this point; one LE can also have multiple OUs, which is equivalent to a registered legal entity company. There are multiple "divisions" (such as X-ray machines and televisions) that need to be run independently. OU and LE have a "many-to-many" relationship, but there is a restrictive prerequisite, that is, OU and LE must belong to the same SOB or Ledger. Since the settings of LE and OU can be performed independently in the system, if the SOB or Ledger of the two parties are different, the connection relationship cannot be established.
If it is said that the person entity LE has a little relationship with the real-world enterprise administrative management organization structure, the business entity OU has almost nothing to do with administrative management, and changes in the administrative organization within the enterprise have no direct impact on the setting of the OU. In EBS, the functions of business modules such as purchase management, sales order fulfillment, and receivable and payable management are all based on OU. When users perform the business processing of the above-mentioned related modules, they must always enter a certain OU (context environment) to proceed. The so-called "multi-organization" function (MOAC) of EBS is also aimed at multiple OUs, which is different from the real world "Multicompany" (LE) is not directly related.
In fact, SAP's "purchasing organization, sales organization" setting is also irrelevant to the real-world administrative organization "purchasing department, sales department". ORACLE abandoned the concept of "purchasing organization, sales organization", and OU actually played a similar role. tissue separation. In some related documents of ORACLE, if the so-called "purchasing organization, sales organization" and other concepts are mentioned due to description needs, sometimes they actually refer to the business entity OU (or the inventory INV organization under the OU).
(4) Inventory organization (INV )
The inventory organization (INV) of ORACLE EBS is the most basic and one of the most important tasks in the system organization setting. The connotation of inventory organization is far from being as simple as the "warehouse department" in the real world. In addition to being the basis of business functions such as "material receipt and delivery", more importantly, it is also a plan related to the EBS system (MPS/MRP) , Work in Process Management (WIP), Bill of Materials (BOM) and other module business functions operation and management platform. As shown in Figure 28 below:
The role and function of the inventory organization INV in EBS can be referred to the plant Plant in SAP. An inventory organization INV can only belong to a certain account set SOB, a certain legal entity LE, and a certain business entity OU, and has a unique relationship (note: the setting interface of R11 does not consider the association restrictions of SOB/LE/OU , prone to errors; R12 has made improvements, after the Ledger is selected, the available LE/OU is limited). Conversely, a combination of "Account Set/Legal Entity/Business Entity" can have multiple inventory organizations INV. In addition, multiple INVs under one OU can correspond to different LEs belonging to the OU. This is equivalent to extracting four factories that produce two products belonging to two legal person companies according to the pairwise combination of the same product. different OUs for daily business management.
In EBS, there are two organizational concepts "MRP organization and WIP organization". They are actually organizational concepts that must be built on the inventory organization, indicating that the inventory organization can also perform MRP or WIP functions. The reason why the system handles this is mainly to control that certain INVs cannot be used for MRP or WIP, because the number of INVs set based on material receiving or sending needs may be relatively large.
For most business functions based on inventory organization INV (except for a few), system users must first select and switch INV when doing business operations, so as to enter a certain INV context. The role of the inventory organization is so basic that when EBS related documents refer to the concept of organization (Org), if there is no special explanation, it refers to the INV organization by default.
(5) Company cost center (Cost Center )
The so-called "cost center organization" of EBS does not have the function of business processing. Its setting is mainly to consider the corresponding relationship between the "company segment value" and "cost center segment value" in the "accounting flexible domain structure". As shown in Figure 29 below:
After the "Company Cost Center Organization" is created in the system, you can run a "Concurrent Checking Program" to verify whether the segment value in the "Account Flexfield Structure" is consistent with the settings of all "Company Cost Center" organizations.
After adding the LOV value in the "Cost Center Segment" value set in the "Accounting Account Flexfield Structure" and recompiling, you can run the "Automatic Organization" concurrent program function of the system, and the system will automatically create the "Company Cost Center" organization.
It should be noted that a company cost center organization and its cost center segment value cannot belong to different legal entity LE and its company segment value, which is consistent with the management requirements in the real world. Inventory organization INV has a "one-to-one or many-to-one" relationship with the "cost center" segment (department) in the accounting flexfield, that is, one "cost center" segment value can have multiple inventory organization INVs, but one An inventory organization INV can only belong to a certain cost center.
(6) HR organization
The HR organization setting of the system is related to the relevant business processing functions of the HRM module, and has little to do with the core business/financial processing functions. The main thing is to pay attention to whether it is associated with the "Cost Center", and you can enter the "Cost Center" code if necessary. Its LOV is the value set of the cost center segment in the "Accounting Account Flexfield" structure. As shown in Figure 30 below:
(7) Multi-organization access control
In the EBS organization setting interface in Figure 30, the so-called organization "type" (Type) division is only a "dimension" defined based on the organization's own statistical analysis work needs, such as "company headquarters, product line" and so on, and It does not affect the business processing function of the system. What really works is the "Classification" in the setting interface. In addition to the above-mentioned "business group, legal entity, business entity, inventory organization" and so on, the system's preset organization classification LOV also includes "asset organization, Operating company, employer" and other options. The business processing functions of each application module in the EBS system usually need to be built on a certain "organization classification". It depends on the application module functions that the enterprise needs to use.
For example, the setting of the so-called "asset organization" is only involved when the enterprise needs to use the asset management module FA. "Asset organization" is actually a synonym for the so-called "asset book". It just represents a data dimension of relevant asset information. Its main function is to separate the data range. When users enter the system for business processing, they do not need to switch the context business environment . For such so-called "organizations" that do not involve "context" environment switching, the design of the ORACLR system is mainly to use the "hierarchy" concept of "organizations" to achieve the control of "multi-organization access" permissions Function.
It should be pointed out that the organizational "hierarchy" here is not directly related to the administrative management organization hierarchy of real-world enterprises (although there may be references to it), it is just the enterprise's management and control according to certain needs (such as authority management control, data statistics reporting, etc.) ) and an artificially set "hierarchy", such as any number of "business entities" or "inventory organizations" that have been set up in the system. Pyramid-shaped multi-layer structure. As shown in Figure 31 below:
When starting to define in the figure above, once the (most) top organization Name is selected, only the subordinate organization Name can be assigned to it. If you want to assign a lower-level organization to the subordinate organization, you need to click the "Down" button. Promote the current subordinate organization to the "Top Organization" position. Click the "Up" button to drop the current "top organization" to the position of the subordinate organization. Enterprises can set several "organizational hierarchy" Names with different internal structures according to actual needs, which can be called when defining the so-called "security configuration files" of the system. As shown in Figure 32 below:
The "Security Profile" defined in the above figure is the basis for the system to control various security controls including "organizational security". It specifies the scope and implementation of system security controls. All defined The "Security Profile" Name constitutes the LOV of the system multi-organization access control parameter "MO: Security Profile". As shown in Figure 33 below:
EBS implements the so-called "multi-organization access" control function MOAC through the joint action of three system configuration files: "MO: business entity", "MO: security configuration file", and "MO: default business entity". However, the functions of the above three configuration files in R11 and R12 are quite different.
For "MO: business entity", it must be set in R11, and it plays a decisive control role. Its LOV is automatically created by the system based on the created OU name, and the system automatically locates the specified OU when the user logs in. In R12, once the "MO: security configuration file" is set, the configuration file becomes invalid and does not work.
As for "MO: security configuration file", although it exists in R11, it does not actually play a role in controlling OU access, and only works for some applications such as data statistics of modules such as FA. Therefore, it is generally believed that R11 does not have a complete multi-organization access control function. In R12, if this parameter is not set, the "MO: business entity" parameter must be set; once this parameter is set, it will play a decisive role, and the system mainly relies on it to implement MOAC.
For "MO: default business entity", although it exists in R11, it does not actually work. In R12, it will work with the "MO: Security Profile" and its LOV is all defined OUs, but if the set value is not in the range of "Organization Hierarchy" selected by "MO: Security Profile" However, it still does not work (that is, in the FORM interface related to OU such as PO, OM, etc., the default value of the OU field is still empty). This seems to be a problem in the design of the ORACLE system, that is, the LOV value set of "MO: Default Business Entity" cannot be consistent with the OU value range in "Organization Hierarchy" in "MO: Security Profile".
ORACLE emphasizes that its "multi-organization access to MOAC" function is mainly for the business entity OU. Another meaning is that all application functions built on the inventory organization INV are actually irrelevant to the above configuration files. The accessibility of inventory organization is to specifically set the association between "inventory organization" and "responsibility" in the "organization access" control function, as shown in Figure 34 below:
According to ORACLE, if the system does not define the "organizational access" control of the inventory organization at the beginning, all "responsibility" can access all INVs. Once one of them is restricted or assigned, the rest must be assigned one by one to establish " The link relationship between Inventory Organization" and "Responsibility".
In short, the EBS system combines multiple dimensions and aspects such as "elastic domain segment value security", "account set/ledger security", "multi-organization access security (MOAC)", and "inventory organization access control". System settings provide flexible and convenient user rights management functions, and clarifying and mastering their complex relationships is an important basic work for system implementation.