Oracle Inventory Key Flexfields

Oracle Inventory provides the following flexfields:

1. System Items
2. Item Catalogs
3. Item Categories
4. Stock Locators
5. Account Aliases
6. Sales Orders
7. Service Items

Depending on your system's setup, Inventory may also use some or all of the following
flexfields provided by other Oracle products:

• Accounting (Oracle General Ledger)
• Sales Tax Location (Oracle Receivables)
• Territory (Oracle Receivables)

1. System Items
You can use the System Items Flexfield (also called the Item Flexfield) for recording and reporting your item information. You must design and configure your Item Flexfield before you can start defining items.

Owner	Oracle Inventory
Flexfield Code	MSTK
Table Name	MTL_SYSTEM_ITEMS
Number of Columns	20
Width of Columns	40
Dynamic Inserts Possible	No
Unique ID Column	INVENTORY_ITEM_ID
Structure Column	ORGANIZATION_ID

All Oracle Applications products that reference items share the Item Flexfield and support multiple-segment implementations. However, this flexfield supports only one structure.
You must set up your OE: Item Flexfield profile option to specify the Item Flexfield structure that you will use for your Oracle applications.
Users can also set up the OE: Item Flexfield Entry Method profile option to specify your preferred method of entry for this flexfield.
You can optionally use the item flexfield to default item information for invoice, debit memo, and credit memo lines or you can enter your own line information.
2. Item Catalogs
This key flexfield supports only one structure.

Owner	Oracle Inventory
Flexfield Code	MICG
Table Name	MTL_ITEM_CATALOG_GROUPS
Number of Columns	15
Width of Columns	40
Dynamic Inserts Possible	No
Unique ID Column	ITEM_CATALOG_GROUP_ID
Structure Column	None

 3. Item Categories
You must design and configure your Item Categories Flexfield before you can start defining items since all items must be assigned to categories. You can define multiple structures for your Item Categories Flexfield, each structure corresponding to a different category grouping scheme. You can then associate these structures with the categories and category sets you define.

Owner	Oracle Inventory
Flexfield Code	MCAT
Table Name	MTL_CATEGORIES
Number of Columns	20
Width of Columns	40
Dynamic Inserts Possible	No
Unique ID Column	CATEGORY_ID
Structure Column	STRUCTURE_ID

4. Stock Locators
You can use the Stock Locators Flexfield to capture more information about stock locators in inventory. If you do not have Oracle Inventory installed, or none of your items have locator control, it is not necessary to set up this flexfield.

 

Owner	Oracle Inventory
Flexfield Code	MTLL
Table Name	MTL_ITEM_LOCATIONS
Number of Columns	20
Width of Columns	40
Dynamic Inserts Possible	Yes
Unique ID Column	INVENTORY_LOCATION_ID
Structure Column	ORGANIZATION_ID

If you keep track of specific locators such as aisle, row, bin indicators for your items, you need to configure your Stock Locators Flexfield and implement locator control in your organization.
This key flexfield supports only one structure.

 

5. Account Aliases
This key flexfield supports only one structure.

 

Owner	Oracle Inventory
Flexfield Code	MDSP
Table Name	MTL_GENERIC_DISPOSITIONS
Number of Columns	20
Width of Columns	40
Dynamic Inserts Possible	No
Unique ID Column	DISPOSITION_ID
Structure Column	ORGANIZATION_ID

 

6. Sales Order
The Sales Order Flexfield is a key flexfield used by Oracle Inventory to uniquely identify sales order transactions Oracle Order Management interfaces to Oracle Inventory.

Owner	Oracle Inventory
Flexfield Code	MKTS
Table Name	MTL_SALES_ORDERS
Number of Columns	20
Width of Columns	40
Dynamic Inserts Possible	Yes
Unique ID Column	SALES_ORDER_ID
Structure Column	None

Your Sales Order Flexfield should be defined as Order Number, Order Type, and Order Source. This combination guarantees each transaction to Inventory is unique. You must define this flexfield before placing demand or making reservations in Oracle Order Management.

You must set up the OM: Source Code profile option to determine the source code you will use in for the third segment of this flexfield to guarantee that each transaction is unique. (Oracle Inventory defaults the value of the OM: Source Code profile option to 'ORDER MANAGEMENT'.)
For your value sets, you must use Dynamic Inserts. The Validation Type should be None. Value Required should be Yes to improve performance of concurrent programs. The value set must be alphanumeric. The value set maximum size must be 40.
You should set the Required field to Yes in the Validation Information region when enabling the flexfield segments. Setting this field to Yes, improves performance when updating existing demand or reservations by guaranteeing that Oracle Order Management always supplies a value.
Set Right-justify Zero-fill Numbers to No so sales order numbers are not padded with zeros.
Oracle Inventory defines a unique ID for each order in MTL_SALES_ORDERS based on this flexfield. The Inventory unique ID, as opposed to the Order Management unique ID, is used throughout Oracle Manufacturing applications.

7. Service Items

The following table lists details for this key flexfield.

Owner	Oracle Service
Flexfield Code	SERV
Table Name	MTL_SYSTEM_ITEMS
Number of Columns	20
Width of Columns	40
Dynamic Inserts Possible	No
Unique ID Column	INVENTORY_ITEM_ID
Structure Column	ORGANIZATION_ID

The Service Item flexfield uses the same table as the System Item Flexfield. However, you can set up your segments differently with the Service Item Flexfield.

Troubleshooting Remit To Address in Oracle Receivables

Troubleshooting Details

1.  Setup and Usage of Remit-To Address in Oracle Receivables

Define remit-to addresses to let your customers know where to send payment for their invoices. Receivables uses the addresses that you define in the Remit To Addresses window to provide default remit-to information when you enter transactions.  Remit-To Addresses are also printed on invoices and optionally printed on Statements and Dunning Letters (Based upon the selections in the System Options window for AR). 

If you use AutoInvoice but have not defined a remit-to address that can be derived for a specific bill-to address,  AutoInvoice will reject all invoices for which it could not determine a remit-to address with the following message in the AutoInvoice Import Execution report:

Errors: 1) Cannot get remit to address

If you do not wish to set up a remit-to address for each location, you can set up one remit-to address with a default assignment. Receivables will then use this address for all locations or for any locations for which you do not have specific location assignments. This ensures that AutoInvoice will not reject invoices because it could not determine a remit-to address.

For more on setting up Remit-To Addresses in Oracle Receivables including step-by-step instructions and screenshots, refer to Note 1101666.1, How to Setup a Remit-To Address in Release 12 Oracle Receivables.
2. Troubleshooting Remit-To Address Issues and Errors on Transactions

    a. Error: Cannot Get Remit To Address

This is the most common error reported for Remit-To Addresses.  The steps below outline how you can determine what value should be used and also how to fix this problem.

Alternate Error Presentations:

WARNING: No default remit-to address found
WARNING: No default remit-to address (country) found 

        i. Identify The Customer Bill-To Address

The Remit-to Address is derived based upon the customer Bill-To Address.  You should therefore begin troubleshooting by identifying the Bill To Address (State, Postal Code and Country)

        ii. Identify the Operating Unit on the Transaction

For a Manual Invoice, this can be found by looking at the list of values on the Transaction Source as shown below:

For AutoInvoice this can be found
Responsibility:  Receivables Manager
Navigation:  Control > AutoInvoice > Interface Lines

As shown above the Operating Unit field will be displayed.  If AutoInvoice failed with an error, query this form for any rows where the "Errors Exist" checkbox is checked.  This will return a listing of all rejected records.  Find the row that is showing a rejection reason of 'Cannot Get Remit To Address' and take note of the operating unit displayed for that row.

        iii. Check your Remit-To Address Setup

Note 1101666.1 explains in detail how to set up a Remit-To Address. 

Open the Remit-To Address form as shown below

Responsibility: Receivables Manager
Navigation:  Setup > Pring > Remit To Address

Find the row or rows associated to your Operating Unit and check to see if the bill to address is covered by the "Receitps From" definition.

The most common cause of an error in deriving a Remit-To address is in this "Receipts From" mapping.  A best practice to avoid problems is to set a default remit-to address for all countries where you transact.  This allows you to avoid errors during AutoInvoice and transaction entry.  In the example above we have defined this California address as the default for all Canadian bill-to addresses. 

Note: You can derive an alternate remit-to address with a more narrow definition.  For example, if you have a default for the United States with a New York address but then have a California address that is mapped to a specific Postal Code range, the system will use the California address ahead of the default address for any address in the from/to postal code range

In this example the Invoice had a Florida address but tthe Receipts From shows no combination that includes this Florida Address.   Assuming the Row above with the New York address also does not cover this Florida addess we can fix this defaulting issue by modifying the "Receipts From" to include the Bill  To address from the Invoice.

    b. Can I Use Additional Factors to Default the Remit-To Address?

At this time the only factors available to derive remit-to address are Geography and Operating Unit.

• Enhancement Request 6006313 was logged to request the ability to derive remit-to using transaction type

• Enhancement Request 4676489 was logged to request that factors other than geography be made available to derive Remit-To

    c. Remit-To Address is not Defaulting

Refer to section 2a and verify that the address is properly mapped in the 'Receipt From' setup.

    d.  Unable to Delete Obsolete Remit-To Address

Receivables does not allow for a remit-to address to be deleted.  It is suggested that instead of deleting an address, the Receipt From values under the address simply be deleted.

    e. Remit-To Address Does Not Include All Address Segments

ARXSURMT.fmb , Remit to Address Form has Record group State based on the following query:

select state_code, description
from ar_remit_to_state
where country = :loc.country

Ar_remit_to_state is a view based on hz_locations table.  Data is populated in this table as customer addresses are created thus if you have not yet defined customers the LOV will not show the segments as available for selection. 

For more on configuring geographies in R12 refer to Note 554492.1 Setting Up Geography Hierarchy And Address Validation in Release 12

    f. Remit-To Bugs and Other Common Errors

Row	Release	Error String or Presentation	Cause	Recommended Fix*
1	12.0	When using Multiple Org's in AR, if a transaction type is entered for operating unit "A" and then subsequently changed to a transaction type associated with operating unit "B", the Remit-To address is not being updated to reflect this change.	Bug 8642210 Remit To Address not properly refreshed	Recommended Patch:  12.0 Patch 9451008 12.1 Patch 9343518 Fixed File: ARXTWMAI.pld 12.0: 120.163.12000000.72 12.1: 120.180.12010000.46
2	12.0	Re-display the remit-to address details, the following error message is displayed: No HZ_CUST_ACCT_SITES was found for ID XXXX	Bug 8522000	Recommended Patch: 12.0: patch 8331653 Fixed File: HzPuiAccountSiteAMImpl.java 120.22.12000000.3 12.1Patch 8522000 Fixed File: HzPuiAccountSiteAMImpl.java 120.25.12010000.2 Fix is included in 12.0.6 and 12.1.2 forward
3	12.0	iSetup is creating duplicate Remit-To addresses instead of updating existing records	Bug 6729003	Patch 6729003 See also Note 550257.1
4	12.0	AR_DEPOSIT_API is not Defaulting the correct remit-to address via the Bill To Location	Bug 9451008	Recommended Patch:  Patch 9451008 Fixed File: ARXDEPLB.pls 12.0.6 120.11.12000000.4 12.1 120.12.12010000.3
5	12.0	REP-0069: Internal error REP-57054: In-process job terminated:Terminated with error: REP-1419: MSG-00100: DEBUG: BeforeReport_Trigger +	Remit-To Address was not defined and invoice print was attempted	Define remit to address and/or default remit-to
6	12.0	Query a transaction returns: ORA-01422: exact fetch returns more than requested number of rows ORA-06512: at "APPS.ARP_TRX_DEFAULTS_3", line 1463 Debug log showed: selecting the default remit to address. EXCEPTION: arp_trx_defaults_3.get_default_remit_to() EXCEPTION: arp_trx_defaults_3.get_remit_to_address() ---------- Parameters for arp_trx_defaults_3.get_remit_to_address() ---------- p_match_state : NJ p_match_country : US p_match_postal_code : 07095 p_match_address_id : p_match_site_use_id : EXCEPTION: arp_trx_defaults_3.get_remit_to_default()	Remit-To address not properly defined	Review/correct setup.
7	11.5 - 12.1	When printing a specific credit memo, it errors with the following: MSG-43749: There is no remit to address defined for country US and state XX. REP-1419: 'remit_to_control_idformula': PL/SQL program aborted.	The zip code for this credit memo was not included in any of the existing remit-to ranges.	Make sure a valid range is defined for the zip code on the transaction. 1. Setup\Print\Remit-To Address --> Add a range for zip code 09136 (this problem zip code in this example) which is the zip for the credit memo. 2. A new line can be added, or you can alter the existing range for the that state to include the new zip code Alternately you can set a default to be used to avoid this issue.
8	11.5 - 12.1	APP-FND-00676 The flexfield routine FDFGDC cannot read the default reference field specified for this descriptive flexfield	Incorrect setup of descriptive flexfield for Customer Form	Customer form and Remit-To address form share a common foundation.  Enhancement 3100593 was logged to split these apart.  Until this is fixed it is suggested that the DFF not be used on the Reference Field for the Address InformationDFF
9	11.5	Remit-to Address Does Not Exist In The List of Values. State/Country combination already exists. APP-AR-96282 Error: Invalid value for party_site_id	Data Corruption of unknown origin (rare occurrence)	Perform the following steps to resolve this issue: Verify Issue 1.) select address_ id from ra_remit_tos_all where country = 'DEFAULT' and state = 'DEFAULT'; 2.) Select address1, address2, address3, city, state from ra_addresses_all where address_id = '&address_id_step1'; If query 2 returns no rows then corruption exists.  Contact Support for assistance
10	11.5	Entering new Remit-To address returns: APP-AR-96282: Error: The following SQL error occurred: ORA-29861: domain index is marked LAODING/FAILED/UNUSABLE	Corrupt domain index	1. Rebuild the domain indexes associated to the form as described  in Note 165115.1 HZ_CUST_ACCT_SITES_ALL_T1 HZ_LOCATIONS_N15 HZ_STAGE_PARTY_SITES_T1
11	11.5	Opening Remit-To Form from OM returns: ORA-06550: line 1, column 7: PLS-00905: object APPS.ARP_STAX_165 is invalid ORA-06550: line 1, column 7: PL/SQL: Statement ignored ORA-06512: at "APPS.ARP_STAX", line 371	Item Validation Organization is not set.	1. Order Management Responsibility, N: Setup > System Parameters > Values 2. Select the 'Generic Parameters' Category. 3. Pick your org into 'Item Validation Organization' 4. Save your work.
12	11.5	ORA-06550: line 1, column 7: PLS-00905: object APPS.ARP_STAX_5749 is invalid ORA-06550: line 1, column 7: PL/SQL: Statement ignored ORA-06512: at "APPS.ARP_STAX", line 371 FRM-40735: WHEN-NEW-FORM-INSTANCE trigger raised unhandled exception ORA-06550. Tried to compile ARP_STAX_5749 package and got the following error message: PLS-00920: parameter plsql_native_library_dir is not set.	ARP_STAX package for this ORG_ID was in status invalid.	set parameter plsql_native_library_dir and bounce the DB to take effect
13	11.5	APP-AR-96282 Error:Value for Party_site_number must be unique.	The profile HZ: Generate Party Site Number is 'No' The remit-to-address does not have the field to enter the site number in that case must be generated	This is ER: 3297103: 'GENERATE PARTY SITE NUMBER' IS 'NO',SITE NUMBER IS COUNTED BY AUTO. Workaround ---------- 1. Go into the responsibility: System Administrator 2. Create a new responsibility to have the privileges to create the remit-to-address setup 3. Assign thjavascript:void(0)at responsibility to the user in charged to do that or 1. Go into the responsibility: system Administrator 2. Navigate to Profile \ System 3. Put the profiles HZ: Generate Contact Number HZ: Generate Party Number HZ: Generate Party Site Number in Yes, for the User designated to create the remit-to-address or a Dummy user that will do that
14	11.5	Rep-1401: 'C_Remit_To_Concatenateformula' Ora-01403: No Data Found	Remit-To Address and/or Default not defined	Setup Remit-To Address as per Note 1101666.1
15	12	Remit to address does not show in Dunning	Bug 9437627	Patch 10198415 Fixed File ardlgm.lpc 115.47.15104.38 (or higher).

*Note: that the patch recommendation is for the latest released version of the file and not necessarily the version that included the fix.  For example, if version 46 is the fixed file, the recommended patch may contain version 72 of the fixed file.  This fix will include the bug fix referenced here as well as any other bug fix released since the bug was resolved.

3. Troubleshooting Printing Related Remit-To Address Issues and Errors

    a. Remit-To Address is Not Printing, No Errors

By default the system should print the remit-to address from the invoice when printing statements, dunning and invoices.  If this does not print verify the following:

1) Check in Setup -> System -> System options, Alternate Region- Miscellaneous if the Print Remit to Address flag is checked
2) Verify that the invoice has a remit-to address defind

    b.  Remit-To address Errors with MSG-43749: There is no remit to address defined for country and state

This problem has been reported when the default value contains postal codes.  Removing the postal code has proven to remedy this symptom.

    c. Is it possible to highlight the Remit-To Address when printing?

In BPA, you can select "Bold" or "Regular" for the content item value.

Hence, you can duplicate the default template and make the remit to address as "Bold".  It is even possible to make BOLD only a part of the Remit-To address.
Instead of using BPA content item 'Remit To Address Formatted', use each individual content item such as 'Remit Address 1', 'Remit Address 2' etc.

4.  Descriptive Flexfields on Remit-To Addresses

The top zone of the Remit-To Address form displays the "Address Information" DFF. This is by design. This allows one to see additional address info for the current address displayed. The "Receipts From" zone is where the "Remit Address Information" DFF is available

Naming Conversion Table Name end with _ALL, _TL, _VL, _V, _F, _A, _B, _S, _AVN and its Meaning

• _ALL : Table holds all the information about different operating units. Multi-Org environment. You can also set the client_info to specific operating unit to see the data specific to that operating unit only.
• _TL : are tables corresponding to another table with the same name minus the _TL. These tables provide multiple language support. For each item in the table without _TL there can be many rows in the _TL table, but all with different values in the LANGUAGE column.
• _B : these are the BASE tables.
  They are very important and the data is stored in the table with all validations.
  It is supposed that these table will always contain the perfect format data.
  If anything happens to the BASE table data, then it is a data corruption issue.
• _F : these are date tracked tables, which occur in HR and Payroll. For these there are two date columns EFFECTIVE_START_DATE and EFFECTIVE_END_DATE which together with the PK identifies a row uniquely. The date intervals cannot overlap. Many think they are Secured data. Guess someone from Oracle confirms.
• _V : tables are the views created on base tables
• _VL : are views for multi language tables which combines the row of the base table with the corresponding row of the _TL table where the LANGUAGE = USERENV('LANG').
• _S : are sequences, used for finding new values for the primary key of a table.
• _A : are Audit Shadow Tables
• _AVN : and _ACN are Audit Shadow Views (when data was changed, and with what values