Subject: Inventory Setup for Intercompany Invoicing Doc ID: Note:11243 7.

1 Last Revision Date: 14-MAR2005

PURPOSE This document is intended to help users successfully setup organizations for the purpose of Intercompany Invoicing through the Oracle Inventory Application. SCOPE & APPLICATION This document is intended to supplement the documentation provided with the application. Intercompany Invoicing Inventory Setup Information

Type: BULLETI N Status: PUBLISH ED

Steps to Implement the Multiple Organization Support 1. Develop the Organization Structure 2. Define Sets of Books 3. Define Organizations 4. Define Organization Relationships 5. Define Responsibilities 6. Set the Operating Unit Profile Option for Each Responsibility 7. Convert to Multiple Organization Architecture 8. Define Inventory Organization Security (optional) 9. Change Order Entry Profile Options (optional) 10. Update Profile Options Specific to Operating Units 11. Implement the Applications Products 12. Secure Balancing Segment Values by Legal Entity (optional) 13. Run the Setup Validation Report (recommended)

Prerequisites to Using the Intercompany Invoicing Process 1. Define 2. Define 3. Define 4. Define Receivables. 5. Set up your your your your intercompany relations. Oracle Receivables system options. Oracle Payables system options. tax structures in Oracle Payables and Oracle

the Account Generator for the Cost of Goods Sold

accounts.

Inventory Setup Confirmation Steps 1. Verify Set of Books, Legal Entity, & Operating Unit: A) Navigation: Inventory-> Setup-> Organizations B) Select the particular organization in question (Both organizations, i.e. Japan, US). C) Select the Inventory Organization under "Organization Classifications" and click on the "Others" button. D) Select "Accounting Information". E) Open up the "Additional Organization Information". F) "Accounting Information" flexfield will open with Set of Books, Legal Entity, and Operating Unit. G) Confirm that the information in these fields is accurate and relevant to the particular organizations involved in the Intercompany process. 2. Intercompany Relations Defined: A) Navigation: Inventory-> Setup-> Organizations-> Intercompany Relations B) Confirm the Operating Units: Shipping: Selling: C) AR Invoicing for Shipping: Customer: Number: Location: Transaction Type: D) AP Invoicing for Selling: Supplier: Site: Freight Account: E) Revalue Average:

3. Verify Set of Books: A) B) C) D) E) Navigation: Inventory-> Setup-> Financials-> Books Select the particular Set of Books Chart of Accounts defined Functional Currency defined Accounting Calendar defined

4. Verify Currency Codes: A) Navigation: Inventory-> Setup-> Financials> Currencies-> Currency Codes B) Ensure that the currency codes used are active and have not

been disabled (Scroll to the right)

Profiles Options: 1. Consistent Profile Option Values: All responsibilities in one operating unit must share the same profile option values and the same sequence numbering option. The Validation Report indicates an error if this is not the case, and notes when profile options should be set at the responsibility level. 2. HR:Business Group This section applies to you only if you have multiple business groups, or if you do not choose to use the default business group provided by Oracle Applications. If you have multiple business groups, you must associate each responsibility with one and only one business group. You associate a responsibility with a business group via the HR:Business Group system profile option. If you are upgrading to Multi-Org, you must also associate each existing responsibility with a business group. After you have associated business groups with responsibilities, you can enter business group setup information such as additional organization information and business group classifications. If you have multiple business groups, verify the HR:Business Group profile option before you define organizations in each business group. 3. MO:Operating Unit You must set the MO:Operating Unit profile option for each responsibility. Set this profile option to the appropriate operating unit id (ORG_ID) for each responsibility. The operating unit context for each responsibility is set via this profile option. This profile option must be set for Oracle Training Administration (OTA) responsibilities when OTA is used in a Multi-Org environment. This

is to ensure that the OTA customer and supplier functions work correctly in a Multi-Org environment. You must also define the default operating unit by setting the MO:Operating Unit profile at the site level. If this is a fresh installation, the default operating unit can be any operating unit you have defined. If this is an existing installation, you should assign as the default operating unit the operating unit to which all existing data should belong. 4. The following profile options affect the operation of the Create Intercompany AR Invoices process: a) INV: Intercompany Currency Conversion Determines the conversion type for foreign currency invoices. b) Tax: Allow Override of Tax Code Determines whether tax code information should be passed to AR for freight. c) Tax: Invoice Freight as Revenue Indicates whether freight lines should be invoiced as revenue lines. d) Tax: Inventory Item for Freight Use this inventory item when freight lines are invoiced as revenue lines. e) OE: Item Validation Organization Inventory organization in which the freight item specified in the profile Tax: Inventory Item for Freight is defined. 5. OE:Item Validation Organization The OE:Item Validation Organization profile option determines the inventory organization that Order Entry uses to validate items. Some inventory item attributes for Receivables and Order Entry, including Tax Code and Sales Account, are specific to an operating unit or an accounting flexfield structure. Therefore, you should use the OE:Item Validation Organization profile option to define an item validation organization for each operating unit. 6. Update Profile Options Specific to Operating Units Use the Update System Profile Options window to set profile options that are specific to each operating unit. You must set these profile option

values for all relevant responsibilities that connect to each operating unit. Some profile options, including AR:Receipt Batch Source and AR:Transaction Batch Source, reference data that is secured by operating unit. You must set these profile options at the responsibility level. For profile options that need to differ at the operating unit level, including OE:Item Validation Organization, OE:Set of Books, and GL Set of Books, you must set the values at the responsibility level. Oracle General Ledger windows use the GL Set of Books profile option to determine your current set of books. If you have different sets of books for your operating units, you should set the GL Set of Books profile option for each responsibility that includes Oracle General Ledger windows. For profile options that need to differ at the set of books level, including Sequential Numbering, set the values at the responsibility level. Profile options specify default values that affect system processes, system controls, and data entry. In a multiple organization environment you may want to confine the effect to a specific operating unit. Therefore, you may want to change your profile options to be visible and updatable at the responsibility level.

Problem statement: ON POXBWVRP BUYER CAN SEE ALL REQUISITIONS, DESPITE SECURITY LEVEL=HIERARCHY

*** 09/03/04 01:36 am *** ======================================================================= ====== PROBLEM DESCRIPTION ======================================================================= ====== ** DETAILED DESCRIPTION OF PROBLEM, INCLUDING ALL ERRORS: Customer is using a Document Security Level of Hierarchy in order to restrict the document access on Purchase Requisitions: Users should not see everyone else's Requisitions.

. 1) Setup/Purchasing/Document Types For Purchase Requisition document type the Security Level is HIERARCHY. ' Hierarchy : Only the document owner, subsequent approvers, and individuals included in the security hierarchy can access the document' 2) Setup/Personnel/ Position Hierarchy One position hierarchy including all positions that require access to the document types to be controlled with a Security Level of Hierarchy has been defined . 3) Setup/organizations/Purchasing Options form POXSTDPO In the Control tabbed region in the Purchasing Options window, the Security Hierarchy is indicated so it governs access security for the document. . 4)Some users and positions are defined: - A, B have positions defined in the same hierarchy - A, B are defined as buyers - B's position reports to A's position / A is one level above B . 5) On the Requisitions Summary form , POXRQVRQ , the document access security is well in place. On the Autocreation form, POXBWVRP, find form doesn't check 'Document Security Level' set to 'Hierarchy' on documents and so buyer can view or autocreate all requisitions: . B creates a requisition, A will be able to view the same from Requisition Summary form A creates a requisition, B will not be able to view the same from Requisition Summary form . However from Autocreate form B can view and autocreate the requisition created by A . According documentation , with a Document Level Access set to 'Hierarchy', Only the document owner, subsequent approvers, and individuals included in the security hierarchy should access the document. This should be true for the autocreate form, POXBWVRP, as it is true for other forms (POXRQVRQ, POXPOVPO...). There is a security hole

Subje 11i PO ct: POXBWVRP Buyer is able to autocreate requisitions created by

other user Doc ID: Note:241647. 1 Last Revision 15-SEP-2004 Date: Type: Status: PROBLEM PUBLISHED

fact: Oracle Purchasing 11.5.8 fact: POXBWVRP - AutoCreate Documents symptom: Buyer is able to autocreate requisitions created by other user symptom: Security Level for the hierarchy is set as "Hierarchy" symptom: Buyer will not able to view these requisitions from requisition summary form change: Note Role : - A, B , C are in the same hierarchy - A, B , C are defined as buyers - B and C reports to A - B and C are in the same level in the hierarchy - B and C occupies different positions at the same level - A is one level above B and C - B creates a requisition , C will not able to view the same from Requisition Summary form - However from Autocreate form C can view and autocreate the requisition created by B cause: Intended Functionality Document security rule will be applicable to only the corresponding document windows i.e Requisition window or Purchase Order window not for autocreate window.

fix: Intended Functionality Autocreate window is accessible for all buyers in the organization.

Hence, if a person is setup as buyer, then all these documents will be visible for him to autocreate to a PO

PROBLEM DESCRIPTION =============================================================== ============== ** DETAILED DESCRIPTION OF PROBLEM, INCLUDING ALL ERRORS: Customer is using a Document Security Level of Hierarchy in order to restrict the document access on Purchase Requisitions: Users should not see everyone else's Requisitions. . 1) Setup/Purchasing/Document Types For Purchase Requisition document type the Security Level is HIERARCHY. ' Hierarchy : Only the document owner, subsequent approvers, and individuals included in the security hierarchy can access the document' 2) Setup/Personnel/ Position Hierarchy One position hierarchy including all positions that require access to the document types to be controlled with a Security Level of Hierarchy has been defined . 3) Setup/organizations/Purchasing Options form POXSTDPO In the Control tabbed region in the Purchasing Options window, the Security Hierarchy is indicated so it governs access security for the document. . 4)Some users and positions are defined: - A, B have positions defined in the same hierarchy

- A, B are defined as buyers - B's position reports to A's position / A is one level above B . 5) On the Requisitions Summary form , POXRQVRQ , the document access security is well in place. On the Autocreation form, POXBWVRP, find form doesn't check 'Document Security Level' set to 'Hierarchy' on documents and so buyer can view or autocreate all requisitions: . B creates a requisition, A will be able to view the same from Requisition Summary form A creates a requisition, B will not be able to view the same from Requisition Summary form . However from Autocreate form B can view and autocreate the requisition created by A . According documentation , with a Document Level Access set to 'Hierarchy', Only the document owner, subsequent approvers, and individuals included in the security hierarchy should access the document. This should be true for the autocreate form, POXBWVRP, as it is true for other forms (POXRQVRQ, POXPOVPO...). There is a security hole.

The information in this article applies to:

Oracle Purchasing - Version: 11.5.9 to 11.5.9 This problem can occur on any platform. POXBWP1B.pls-115.165.1159.3 porelgeb.pls-115.48.1159.2

Symptoms
During Autocreation and Create Release processes the Promise Date is not automatically populated from Need-By-Date on Requisition.

Cause
Before POXBWP1B.pls-115.165.1159.3 and porelgeb.pls-115.48.1159.2 this was standard functionality, because the information in these two fields is coming from different sources. Need-By-Date is entered by the customer, while the input for the Promise Date is coming from the Supplier. Therefore the information is not copied over automatically. However, since this functionality was requested, a new profile option was introduced to have the possibility to copy over the information from the Need-By-Date from the requisition onto the PO Promised Date

Fix
A new 11i: How to setup profile Secure User in 'PO: Release 11.5 Default PO Promised Date from Need By Date' is introduce d. Based on this profile, the promise date is autopopul ated from Need-ByDate in Autocreat e and Create releases programs. This

profile is available at Site, Responsi bility and User level. By default it is NULL meaning not to default Promise Date. If set 'Yes' then Promise Date will be copied over from the NeedBy-Date. Subject: Doc ID: Note:73910 .1 Last Revision Date: 14-NOV2006
"Checked for relevance on 14-Nov-2006" Purpose ------Oracle HRMS provides two different security models which enable you to set up security specifically for your enterprise: Standard HRMS security and Security Groups Enabled security (formerly called Cross Business Group Responsibility Security). This note provides an overview of both models and a simplistic setup for the Security Groups Enabled Model.

Type:

BULLETIN

Status: PUBLISH ED

Standard Security Model ----------------------Standard HRMS security restricts access to your enterprise's records and data. To set up Standard HRMS Security, you first create responsibilities and

then define the windows, menus items, workflows, data and records the user can access. The System Administrator then assigns users to as many of these responsibilities as is required to complete their business tasks. If you are using Standard HRMS Security, you must ensure that the Enable Multiple Security Groups profile option is set to the default value No. You must then create a security profile for each distinct security grouping of employees your enterprise requires. You then create a responsibility for each user type you require, for example HR Manager, Branch Manager and Salesperson, and link the security profile and responsibility to a business group. These three elements create a security grouping to which you assign employees. Security Groups Enabled Model ----------------------------The main difference between the two security models is that the Security Groups Enabled model enables your enterprise to share security profiles and responsibilities between users and business groups. This reduces the set up time, and also increases the flexibility of this security model. The key to re-usability is the relationship between the security elements and the users that you create during the set up process. Attention: Once you have set up Security Groups Enabled security, you cannot revert to Standard HRMS Security.

Related Documents ----------------Please refer to the on-line documentation 'Security Models' for a more detailed explanation of the process.

Security Groups Enabled Model Step-by-Step Setup Information -----------------------------1. Set Enable Security Groups profile option for the application Oracle Human Resources to YES. Navigation: System Administration -> Profile -> System. Application = Oracle Human Resources, Find %Enable%

2.

Define a user. Responsibility - System Administrator. Navigation: Security -> User -> Define

3.

Define a responsibility. Responsibility - System Administrator. Navigation: Security -> Responsibility -> Define

4.

Set HR User type profile option for the new responsibility to HR User or HR w/Payroll User. Navigation: System Administration -> Profile -> System. Responsibility = <new responsibility>, Find = HR%

5.

Run Enable Multiple Security Group process. Attention: Once you have set up Security Groups Enabled security, you CANNOT revert to Standard HRMS Security. Responsibility - HRMS Manager Navigation: Process & Reports -> Submit Processes and Reports Select Enable Multiple Security Group.

6.

Define a security profile with the restrictions required (organization or position hierarchies or payroll). Responsibility - HRMS Manager Navigation: Security -> Profiles

7.

Assign security profiles. Responsibility - HRMS Manager Navigation: Security -> Assign Security Profiles. Combine the Username, Business Group and responsibility as of the appropriate start date.

8.

Run Security List Maintenance (LISTGEN) Responsibility - HRMS Manager Navigation: Process & Reports -> Submit Processes and Reports Select Security List Maintenance

PROBLEM DESCRIPTION: ==================== How do you disable an Inventory organization when the organization contains items with on hand quantities? SOLUTION DESCRIPTION: ===================== Enter a date in the 'Date To' field, this will disable the Inventory organization from that date. This will remove the organization from the list of organizations available for assignments. The system will not allow an Inventory organization to be deleted for audit purposes. STEPS TO PERFORM: ================= 1. Transfer all stock on hand out of the Inventory organization. 2. Close the period for this Inventory organization. 3. Navigate to Inventory > Setup > Organizations. In the Define Organization form (PERWSDOR), query up the Inventory organization and enter in date in the 'Date To' field. Save your changes. .