Explore topic-wise InterviewSolutions in .

In Store Inventory Management (SIM): 

Some transactions can happen during a Unit & Amount (U&A) stock count while other transactions should be prevented from HAPPENING during a count. Sales and inventory adjustments can update the snapshot; sales because SIM cannot control that information unlike all the receiving and SHIPPING transactions, and inventory adjustments because these sometimes are REQUIRED in case something breaks during the count. 

In RETAIL Price Management (RPM): 

The behavior should be consistent across the transaction types. Customers using SIM will want to avoid updating the snapshot, as SIM does not do this.

In Store Inventory Management (SIM): 

Some transactions can happen during a Unit & Amount (U&A) stock count while other transactions should be prevented from happening during a count. Sales and inventory adjustments can update the snapshot; sales because SIM cannot control that information unlike all the receiving and shipping transactions, and inventory adjustments because these sometimes are required in case something breaks during the count. 

In Retail Price Management (RPM): 

The behavior should be consistent across the transaction types. Customers using SIM will want to avoid updating the snapshot, as SIM does not do this.

RMS has an Inventory Adjustment REASON Code Maintenance Window [rsninvad]. This window ALLOWS you to maintain a list of reasons for inventory adjustments. Reasons are used to INDICATE why the total stock on hand should be increased or decreased. For example, you may need to decrease the stock on hand due to shrinkage. 

To navigate to this window:

From the main menu, select Control => Setup => Inventory Adjustment Reason => Edit (or View). The Inventory Adjustment Reason Code Maintenance window opens, allowing you to Add/Maintain or View inventory adjustment reason codes.

RMS has an Inventory Adjustment Reason Code Maintenance Window [rsninvad]. This window allows you to maintain a list of reasons for inventory adjustments. Reasons are used to indicate why the total stock on hand should be increased or decreased. For example, you may need to decrease the stock on hand due to shrinkage. 

To navigate to this window:

From the main menu, select Control => Setup => Inventory Adjustment Reason => Edit (or View). The Inventory Adjustment Reason Code Maintenance window opens, allowing you to Add/Maintain or View inventory adjustment reason codes.

For U&A all items that have been extracted and are not COUNTED will default to zero and be CONSIDERED counted.

For U&A all items that have been extracted and are not counted will default to zero and be considered counted.

At a high level, the IMPACT will be in the sense that inventory will not be accurate until the authorization is processed. In addition, RMS cannot start the amount part of the stock count.

• The main impact is with regard to late-posting TRANSACTIONS. Ideally this should just mean sales, as other transactions flow from SIM to RMS in real time. Late-posting sales would update the snapshot if they are entered PRIOR to AUTHORIZING the count. 
• Inventory/stock ledger overlay will not occur until after authorization. 
• Between the count and the date of authorization, the average cost of the item may change, which may impact the cost of inventory. 

At a high level, the impact will be in the sense that inventory will not be accurate until the authorization is processed. In addition, RMS cannot start the amount part of the stock count.

PERFORM these steps:

1. Save the color palette in your local machine.
2. In Forms Builder, open the FORM requiring the color change.
3. Select [Edit] -> [Preferences].
4. ENABLE the 'Select Color Mode' on General Tab and click OK.
5. Open the main campus.
6. Select [Edit] -> [Import] -> [Color Palette].
7. Select the color palette which was saved in Step 1 and click OK.
8. Save the campus and compile the respective form.

Perform these steps:

YES, it is SPECIFIC to APPLICATION USER.

Yes, it is specific to application user.

BI Publisher is REQUIRED in version 13.0.1 or later. With the RMS 13.0.1 release, reports have been REWRITTEN USING BI Publisher and RDF reports have been discontinued.

BI Publisher is required in version 13.0.1 or later. With the RMS 13.0.1 release, reports have been rewritten using BI Publisher and RDF reports have been discontinued.

Report Repository NEEDS to be set up as "FILE SYSTEM" type and its value is set to the FOLDER where ADMIN, Demo Files, Reports, Tools and Users folders are created. This can be viewed by clicking on the Admin tab and then Report Repository under System Maintenance for BI Publisher.

Report Repository needs to be set up as "File System" type and its value is set to the folder where Admin, Demo Files, Reports, Tools and Users folders are created. This can be viewed by clicking on the Admin tab and then Report Repository under System Maintenance for BI Publisher.

This is explained in chapter 12 on "Setting up Oracle Business Intelligence Publisher" in "RMS 13.0.1 Back-end Configuration and Operations Guide - Volume 3". 

RMS.env file should have environmental VARIABLES set up as in the example below:

ORACLE_RMS_REPORTS_HOST=http://mspps003.us.oracle.com:7777/ 

ORACLE_RMS_REPORTS_SERVER=xmlpserver 

ORACLE_RMS_RWSERVER=xmlpserver/Guest/rms13/

All the FILES and directories from STAGING_DIR/rms/application/rms13/reports/* need to be COPIED to Reports/Guest/rms13 folder on BI Publisher. Port 7777 in the example is the HTTP listen port as defined in /Apache/Apache/conf/httpd.conf file for BI Publisher.

Note:- While opening BI publisher reports from RMS application, if it fails with error "FRM-92020:invalid URL" please confirm above settings in .env file.

This is explained in chapter 12 on "Setting up Oracle Business Intelligence Publisher" in "RMS 13.0.1 Back-end Configuration and Operations Guide - Volume 3". 

RMS.env file should have environmental variables set up as in the example below:

ORACLE_RMS_REPORTS_HOST=http://mspps003.us.oracle.com:7777/ 

ORACLE_RMS_REPORTS_SERVER=xmlpserver 

ORACLE_RMS_RWSERVER=xmlpserver/Guest/rms13/

All the files and directories from STAGING_DIR/rms/application/rms13/reports/* need to be copied to Reports/Guest/rms13 folder on BI Publisher. Port 7777 in the example is the HTTP listen port as defined in /Apache/Apache/conf/httpd.conf file for BI Publisher.

Note:- While opening BI publisher reports from RMS application, if it fails with error "FRM-92020:invalid URL" please confirm above settings in .env file.

In all reports, there is a .xdo. Those xdo files have a default data SOURCE set to "RMS13" out of the BOX. Therefore it is required to set up the JDBC connection with a data source name of "RMS13" when USING reports out of the box. The data source name in .xdo file NEEDS to match with the data source name defined for the JDBC connection.

In all reports, there is a .xdo. Those xdo files have a default data source set to "RMS13" out of the box. Therefore it is required to set up the JDBC connection with a data source name of "RMS13" when using reports out of the box. The data source name in .xdo file needs to match with the data source name defined for the JDBC connection.

BI Publisher 10.1.3.3 Enterprise Edition BUNDLED with ORACLE Business INTELLIGENCE Suite Enterprise Edition (OBIEE) 10.1.3.3 is REQUIRED.

BI Publisher 10.1.3.3 Enterprise Edition bundled with Oracle Business Intelligence Suite Enterprise Edition (OBIEE) 10.1.3.3 is required.

For RMS VERSION 13.1 or RMS version 13.1.1, Oracle BI Publisher version 10.1.3.4.0 is REQUIRED.

For RMS version 13.1 or RMS version 13.1.1, Oracle BI Publisher version 10.1.3.4.0 is required.

1. When determining the individual ROW of stores, it does not matter which replenishment METHOD the stores themselves are using, as long as they have forecasts. 
2. The attributes of the WH are USED to determine the ROW for each store. 
3. This will ALLOW the WH to use one replenishment method to stock the WH (during the supplier cycle) and the stores to use a different replenishment method for WH to store ordering (during the store cycle).

The inventory is CHECKED at the SOURCE WAREHOUSE, which is a stock-holding location. So in a multi-channel ENVIRONMENT it would be a virtual warehouse.

The inventory is checked at the source warehouse, which is a stock-holding location. So in a multi-channel environment it would be a virtual warehouse.

The RPLAPPRV batch will look through all orders created, but will only approve automatic replenishment related orders. It also will purge orders if Inventory Management Supplier has a minimum order constraint and order purge below minimum is set.

The RPLAPPRV batch differentiates between automatic and semi-automatic replenishment-created orders using the ORD_INV_MGMT.ORD_APPROVE_IND flag. If ORD_APPROVE_IND = 'Y', then the order was created in the replenishment process with the intention of being approved during the order APPROVAL validation process (Automatic); OTHERWISE it will not (Semi-Automatic).

EXACTLY what RMS data tables/data fields are needed as INPUTS for the DC Replenishment Min/Max Calculation? Specifically looking at how on-order (PO) and on-hand (stock) totals per item per location.

The replenishment batch Rplext.pc looks into the REPL_ITEM_LOC and ITEM_LOC_SOH tables to determine the Recommended Order Quantity (ROQ) in the ORDTEMP table. Batch Rplbld.pc further generates orders. Inventory availability at warehouses (for DC replenishment) is calculated by the Rplext.pc batch based on details in ITEM_LOC_SOH table.

The RPLAPPRV batch will look through all orders created, but will only approve automatic replenishment related orders. It also will purge orders if Inventory Management Supplier has a minimum order constraint and order purge below minimum is set.

The RPLAPPRV batch differentiates between automatic and semi-automatic replenishment-created orders using the ORD_INV_MGMT.ORD_APPROVE_IND flag. If ORD_APPROVE_IND = 'Y', then the order was created in the replenishment process with the intention of being approved during the order approval validation process (Automatic); otherwise it will not (Semi-Automatic).

Exactly what RMS data tables/data fields are needed as inputs for the DC Replenishment Min/Max Calculation? Specifically looking at how on-order (PO) and on-hand (stock) totals per item per location.

The replenishment batch Rplext.pc looks into the REPL_ITEM_LOC and ITEM_LOC_SOH tables to determine the Recommended Order Quantity (ROQ) in the ORDTEMP table. Batch Rplbld.pc further generates orders. Inventory availability at warehouses (for DC replenishment) is calculated by the Rplext.pc batch based on details in ITEM_LOC_SOH table.

AUTOMATIC replenishment causes automatic CREATIONS of orders and automatic approvals of those orders. Approvals are HANDLED through the RPLAPPRV batch. SEMI- automatic replenishment causes automatic creations of orders, but orders NEED to be manually approved.

Automatic replenishment causes automatic creations of orders and automatic approvals of those orders. Approvals are handled through the RPLAPPRV batch. Semi- automatic replenishment causes automatic creations of orders, but orders need to be manually approved.

There is no TWO LEVEL APPROVAL

There is no two level approval

By doing the below steps, you will assign an amount to the BUYER which he can not approve an ORDER that exceeds this amount.

LOGIN to RMS 

Navigate: CONTROL > Setup > User Role Privileges

Set the required amount in the 'User Role Privileges' screen.

By doing the below steps, you will assign an amount to the buyer which he can not approve an order that exceeds this amount.

Login to RMS 

Navigate: Control > Setup > User Role Privileges

Set the required amount in the 'User Role Privileges' screen.

Oracle Purchasing will not allow unit price update on INVENTORY line items

when the line is received or billed because accounting transactions have already taken PLACE. The difference between the PO price and INVOICE price will be recorded in the Invoice Price Variance Account which will show up on the Invoice Price Variance report. If you have MISTAKENLY entered the incorrect price on the PO, then you can workaround this by cancelling or backing out the invoice and processing a return on the receipt which will allow unit price update.

Oracle Purchasing will not allow unit price update on Inventory line items

when the line is received or billed because accounting transactions have already taken place. The difference between the PO price and invoice price will be recorded in the Invoice Price Variance Account which will show up on the Invoice Price Variance report. If you have mistakenly entered the incorrect price on the PO, then you can workaround this by cancelling or backing out the invoice and processing a return on the receipt which will allow unit price update.

The FIELD 'Firm' in the 'Terms and CONDITIONS' indicates that the Purchase order is firm. Firm your purchase order when you want to indicate to Master Scheduling/MRP or your MANUFACTURING application that it should not reschedule this purchase order. The Field 'Firm' in the alternate REGION 'more' in the PO shipments indicates that the Purchase order shipment is firm. Firm your purchase order shipment when you want to indicate to Master Scheduling/MRP or your manufacturing application that it should not reschedule this purchase order shipment .

The field 'Firm' in the 'Terms and Conditions' indicates that the Purchase order is firm. Firm your purchase order when you want to indicate to Master Scheduling/MRP or your manufacturing application that it should not reschedule this purchase order. The Field 'Firm' in the alternate region 'more' in the PO shipments indicates that the Purchase order shipment is firm. Firm your purchase order shipment when you want to indicate to Master Scheduling/MRP or your manufacturing application that it should not reschedule this purchase order shipment .

You can place a Purchase order 'On hold' only at the header level. This approves the purchase order while preventing PRINTING, receiving, INVOICING, and future APPROVAL until you remove the hold. You can 'Freeze' only at the header and release level. You freeze a Purchase order when you want to prevent any future modifications to the Purchase order. When you freeze a Purchase order, you can still receive and pay for goods you already ordered. If you use a Requisition template or AutoSource to source requisition lines from a Purchase order line, Purchasing does not automatically update the corresponding sourcing INFORMATION when you freeze a purchase order with which you source requisition lines. If you freeze a purchase order, you have to update the corresponding information in the Requisition Templates or the AutoSource Rules window.

You can place a Purchase order 'On hold' only at the header level. This approves the purchase order while preventing printing, receiving, invoicing, and future approval until you remove the hold. You can 'Freeze' only at the header and release level. You freeze a Purchase order when you want to prevent any future modifications to the Purchase order. When you freeze a Purchase order, you can still receive and pay for goods you already ordered. If you use a Requisition template or AutoSource to source requisition lines from a Purchase order line, Purchasing does not automatically update the corresponding sourcing information when you freeze a purchase order with which you source requisition lines. If you freeze a purchase order, you have to update the corresponding information in the Requisition Templates or the AutoSource Rules window.

When all LINES for a GIVEN header are closed, PURCHASING AUTOMATICALLY CLOSES the document.

When all lines for a given header are closed, Purchasing automatically closes the document.

Purchasing automatically closes shipments for RECEIVING and invoicing based on Tolerances that you SPECIFY in the Purchasing Options window. Once all shipments for a GIVEN LINE are received and invoiced WITHIN these tolerances, purchasing automatically closes the line 

Purchasing automatically closes shipments for receiving and invoicing based on Tolerances that you specify in the Purchasing Options window. Once all shipments for a given line are received and invoiced within these tolerances, purchasing automatically closes the line 

The default values for Default Ship to and Bill on the PO header are DEFINED in the SUPPLIER Purchasing region of the Financial options FORM.

Setup/organizations/Financial options-> Supplier-Purchasing alternate region

Define the Ship to and Bill to fields

The default values for Default Ship to and Bill on the PO header are defined in the Supplier Purchasing region of the Financial options form.

Setup/organizations/Financial options-> Supplier-Purchasing alternate region

Define the Ship to and Bill to fields

The Purchase Orders form always defaults a PO TYPE of 'Standard Purchase ORDER'. Although the DEFAULT value cannot be changed, the user can change the type once the form OPENS.

The Purchase Orders form always defaults a PO type of 'Standard Purchase Order'. Although the default value cannot be changed, the user can change the type once the form opens.

The system does not allow Supplier update on a saved or APPROVED PO. You will need to CANCEL the PO and create a NEW PO with the correct Supplier.

The system does not allow Supplier update on a saved or approved PO. You will need to cancel the PO and create a new PO with the correct Supplier.

When an item is deleted from itemmaster screen, the item_master.STATUS for that item will still be what it was PREVIOUSLY. If Active, item_master.status will still be 'A'. However, it will have a record in DAILY_PURGE. Whatever items those are in DAILY_PURGE will have status in the itemmaster screen as 'DELETE Pending'. We do not have a form/process/functionality within RMS to remove the item from *Delete Pending*. Item will be deleted from the tables during dlyprg.pc batch run. But it will have to GO through some validations before it can be deleted. Those that failed VALIDATION will not be purged and an entry will be inserted into DAILY_PURGE_ERROR_LOG. If you do not want to delete the item, you can remove the corresponding record from DAILY_PURGE and DAILY_PURGE_ERROR_LOG tables.

When an item is deleted from itemmaster screen, the item_master.status for that item will still be what it was previously. If Active, item_master.status will still be 'A'. However, it will have a record in DAILY_PURGE. Whatever items those are in DAILY_PURGE will have status in the itemmaster screen as 'Delete Pending'. We do not have a form/process/functionality within RMS to remove the item from *Delete Pending*. Item will be deleted from the tables during dlyprg.pc batch run. But it will have to go through some validations before it can be deleted. Those that failed validation will not be purged and an entry will be inserted into DAILY_PURGE_ERROR_LOG. If you do not want to delete the item, you can remove the corresponding record from DAILY_PURGE and DAILY_PURGE_ERROR_LOG tables.

To generate a Unit & Amount Stockcount you have to implement the follow conditions:

1. 3rd PARTY Stock Count - Unit and Amount Option should be Set to "NO" under store admin.
2. Only sellable items can be counted.
3. Items with status of A, C, D, Q, I will be on the Stock Count for any SOH.
4. Items with status I & D will only be on the Stock Count if there is NEGATIVE or positive SOH, not 0 SOH.
5. Nonranged items should not appear on the stock count.
6. Nonsellable packs will not appear on the stock count.
7. Is mandatory to have have ITEM location RECORDS.

To generate a Unit & Amount Stockcount you have to implement the follow conditions:

The Retail Merchandising SYSTEM (RMS) Purchase ORDER dialog prompts the user with a "Yes/No" message asking if manual costs should be overwritten when applying deals on ORDHEAD form. However, same user interaction is not provided for DSD orders CREATED through the Application Programming Interface (API). The assumption with DSD orders is that the receiving location (store) has a better idea what the supplier's cost is at the time of receiving than does the corporate system so RMS don't override any cost that were manually entered because the end result may be a higher cost. Any changes to this process will have to be built on a custom basis because they will not be applicable to the business processes of all clients.

The Retail Merchandising System (RMS) Purchase Order dialog prompts the user with a "Yes/No" message asking if manual costs should be overwritten when applying deals on ORDHEAD form. However, same user interaction is not provided for DSD orders created through the Application Programming Interface (API). The assumption with DSD orders is that the receiving location (store) has a better idea what the supplier's cost is at the time of receiving than does the corporate system so RMS don't override any cost that were manually entered because the end result may be a higher cost. Any changes to this process will have to be built on a custom basis because they will not be applicable to the business processes of all clients.

Internal finishers are part of the warehouse where some tasks are PERFORMED on the merchandise. These are not used to store merchandise. Internal finishers have much of the same functionality of a normal virtual warehouse in RETAIL Merchandising System (RMS) EXCEPT for the following:

1. It cannot be attached to Stores as the Default Warehouse
2. It cannot be the From Location nor the To Location of a Transfer. It can only be selected as a middle point on a 2 legged transfer
3. Can be part of Allocation
4. Cannot ORDER to an Internal Finisher
5. Cannot Replenish To/From an Internal Finisher

External finishers on the other hand are created as Partners. External finishers are finishing location not part of the organizational hierarchy. External finishers are included as a location within the Item/Location Inventory (ITEM_LOC_SOH) table PROVIDING full range of inventory buckets to review.

Internal finishers are part of the warehouse where some tasks are performed on the merchandise. These are not used to store merchandise. Internal finishers have much of the same functionality of a normal virtual warehouse in Retail Merchandising System (RMS) except for the following:

External finishers on the other hand are created as Partners. External finishers are finishing location not part of the organizational hierarchy. External finishers are included as a location within the Item/Location Inventory (ITEM_LOC_SOH) table providing full range of inventory buckets to review.

As this value depends on the country, you should to CONSULT your BUSINESS team to determine the PROPER FORMAT. 

As this value depends on the country, you should to consult your business team to determine the proper format. 

No, prior to RMS RELEASE 13.1.x, HTS was configured for one country. From RMS Release 13.1.x onwards, HTS has been GENERALIZED for USE by any country.

No, prior to RMS Release 13.1.x, HTS was configured for one country. From RMS Release 13.1.x onwards, HTS has been generalized for use by any country.

The SETUP MUST be done MANUALLY, as it VARIES from country to country. 

The basic steps are as follows:

1. Make an entry into HTS_IMPORT_COUNTRY_SETUP table for the country. (Back-end entry)
2. Create a Harmonized Tariff Schedule (HTS) chapter from the HTS Heading Maintenance WINDOW [htshead].
3. Create Quota Category.
4. Create required HTS from the Harmonized Tariff Schedule Window [hts].

A typical entry in the HTS_IMPORT_COUNTRY_SETUP would be:

INSERT INTO HTS_IMPORT_COUNTRY_SETUP VALUES ('IN', 'FMXXXX"."XXXX"."XX', 4);

Where columns are Import Country ID, HTS Format Mask, HTS Heading Length.

The setup must be done manually, as it varies from country to country. 

The basic steps are as follows:

A typical entry in the HTS_IMPORT_COUNTRY_SETUP would be:

INSERT INTO HTS_IMPORT_COUNTRY_SETUP VALUES ('IN', 'FMXXXX"."XXXX"."XX', 4);

Where columns are Import Country ID, HTS Format Mask, HTS Heading Length.

Running the post PROCESSING for EDIDLPRD PATCH will DELETE data from the EDI_DAILY_SALES table.

Running the post processing for EDIDLPRD patch will delete data from the EDI_DAILY_SALES table.

Setting the EDI_SALES_RPT_FREQ in SUPS table to 'W', Sales and STOCK information will be downloaded weekly, so EDI_DAILY_SALES will not be updated.

Setting the EDI_SALES_RPT_FREQ in SUPS table to 'W', Sales and stock information will be downloaded weekly, so EDI_DAILY_SALES will not be updated.

EDI_DAILY_SALES HOLDS daily sales information for SKUs of suppliers transmitting daily EDI activity reports. It will hold sales quantities of SKUs at the LOCATION and the transaction date LEVEL. 

The table will only hold information regarding REGULAR sales. It will be populated during the processing of POSUPLD. 

Records will be PURGED according to the EDI_DAILY_RPT_LAG indicator on SYSTEM_OPTIONS.

EDI_DAILY_SALES holds daily sales information for SKUs of suppliers transmitting daily EDI activity reports. It will hold sales quantities of SKUs at the location and the transaction date level. 

The table will only hold information regarding regular sales. It will be populated during the processing of POSUPLD. 

Records will be purged according to the EDI_DAILY_RPT_LAG indicator on SYSTEM_OPTIONS.

You must indicate which EDI TRANSACTIONS are supported by the supplier. If the supplier requests product activity, you can indicate whether the data should be transmitted on a daily or weekly basis. 

ALSO you should indicate the VARIANCE allowed for cost changes by monetary AMOUNT and by percentage. Cost changes received from the supplier that are within the tolerated range are automatically APPROVED by the system after you accept changes.

You must indicate which EDI transactions are supported by the supplier. If the supplier requests product activity, you can indicate whether the data should be transmitted on a daily or weekly basis. 

Also you should indicate the variance allowed for cost changes by monetary amount and by percentage. Cost changes received from the supplier that are within the tolerated range are automatically approved by the system after you accept changes.

TEXPZ (Total Expense Zone) – This component will be used to STORE the total of the expenses for each ITEM/Supplier/Zone/Discharge Port COMBINATION. It will total all expenses that have an Expense Type of ‘Zone’ within the Item Expenses dialog. This total will be ADDED together with the Total Expense Country, the Total Duty, and the item’s UNIT Cost to come up with the Total Estimated Landed Cost of the Item/Supplier/Country combination

TEXPZ (Total Expense Zone) – This component will be used to store the total of the expenses for each Item/Supplier/Zone/Discharge Port combination. It will total all expenses that have an Expense Type of ‘Zone’ within the Item Expenses dialog. This total will be added together with the Total Expense Country, the Total Duty, and the item’s Unit Cost to come up with the Total Estimated Landed Cost of the Item/Supplier/Country combination

The base cost for the ORDER is ITEM_SUPP_COUNTRY_LOC.UNIT_COST. The landed cost for a purchase order will be (ITEM_SUPP_COUNTRY_LOC.UNIT_COST) X ORDER QUANTITY + Expenses.

The base cost for the order is ITEM_SUPP_COUNTRY_LOC.UNIT_COST. The landed cost for a purchase order will be (ITEM_SUPP_COUNTRY_LOC.UNIT_COST) X ORDER Quantity + Expenses.

Whenever cost changes are extracted for an item, accordingly all the cost components dependent on supplier cost get UPDATED (ITEM_EXP_DETAIL). If RECALC_ORDER_IND is 'Y' for the cost change, then all the orders for the item which are approved and not yet RECEIVED get updated with the new UNIT cost and corresponding EXPENSES. THUS, Estimated Landed Cost (ELC) also gets updated. If RECALC_ORDER_IND is 'N' for the cost change, then order cost does not get updated.

Whenever cost changes are extracted for an item, accordingly all the cost components dependent on supplier cost get updated (ITEM_EXP_DETAIL). If RECALC_ORDER_IND is 'Y' for the cost change, then all the orders for the item which are approved and not yet received get updated with the new unit cost and corresponding expenses. Thus, Estimated Landed Cost (ELC) also gets updated. If RECALC_ORDER_IND is 'N' for the cost change, then order cost does not get updated.

Yes. This is based on the fact that the ELC costs are pretty much DETERMINED at ITEM setup, but those costs are only UPDATED when RECEIVING happens

Yes. This is based on the fact that the ELC costs are pretty much determined at item setup, but those costs are only updated when receiving happens

There is no table that STORES TOTAL ELC value by SUMMING up all components.

Total EXPENSE is displayed on ORDHEAD by summing up individual component expense VALUES.

There is no table that stores Total ELC value by summing up all components.

Total expense is displayed on ORDHEAD by summing up individual component expense values.

ELC calculation LOGIC is based on the values of ELC_COMP.CALC_BASIS and ELC_COMP.COST_BASIS.

ELC_COMP.CALC_BASIS decides whether the expense component is calculated on per-unit basis or value basis. ELC_COMP.COST_BASIS decides whether expense is calculated on SUPPLIER cost or Order cost. 

If COST_BASIS is 'S', ITEM_SUPPLIER_COUNTRY.UNIT_COST is USED to calculate expense. If COST_BASIS is 'O', ORDLOC.UNIT_COST is used. 

Table ELC_COMP STORES details of expense components along with rates, currency, cost_basis, calc_basis, etc. Table ORDLOC_EXP stores expense value at order, item, LOCATION and expense component level.

ELC calculation logic is based on the values of ELC_COMP.CALC_BASIS and ELC_COMP.COST_BASIS.

ELC_COMP.CALC_BASIS decides whether the expense component is calculated on per-unit basis or value basis. ELC_COMP.COST_BASIS decides whether expense is calculated on Supplier cost or Order cost. 

If COST_BASIS is 'S', ITEM_SUPPLIER_COUNTRY.UNIT_COST is used to calculate expense. If COST_BASIS is 'O', ORDLOC.UNIT_COST is used. 

Table ELC_COMP stores details of expense components along with rates, currency, cost_basis, calc_basis, etc. Table ORDLOC_EXP stores expense value at order, item, location and expense component level.

• The "ROUTING LOCATION" field om the Purchase Order screen is editable. This field is editable for all order types.
• EVEN if defaulted, the user has the option to remove the routing location.
• The value in this field is not mandatory.
• There is no VALIDATION on the location type.
• Users will be able to add a routing location even if it is not associated at supplier/supplier site level.

If a supplier/supplier SITE is ASSOCIATED to a routing location, the same will be defaulted at the order header as soon as the supplier/supplier site is ADDED. Validation to check if the order is an import order has been removed (i.e., there is no NEED to validate whether or not the order is an import order).

If a supplier/supplier site is associated to a routing location, the same will be defaulted at the order header as soon as the supplier/supplier site is added. Validation to check if the order is an import order has been removed (i.e., there is no need to validate whether or not the order is an import order).

Previous VERSIONS of RMS (versions PRIOR to RMS 13.1.1.3) were designed to default the routing LOCATION only if the following criteria were satisfied:

• Order should be an import order.
• Order should have all Stores and no Warehouse (WH).
• Order should have items attached to it.

Previous versions of RMS (versions prior to RMS 13.1.1.3) were designed to default the routing location only if the following criteria were satisfied:

The Order Header MAINTENANCE has been AMENDED with a NEW field called "Routing LOCATION" from RMS 13.1.x onwards. This will serve as the "Ship To" location for consolidation purposes.

The Order Header Maintenance has been amended with a new field called "Routing Location" from RMS 13.1.x onwards. This will serve as the "Ship To" location for consolidation purposes.

Some retailers require a Routing LOCATION for consolidation of Import Orders. These are distribution centers which are not cross dock LOCATIONS and also not stock holding locations. Items are not received at these routing locations; the locations are only used for consolidation purposes. From an inventory perspective, a Routing Location is OUTSIDE the RMS DEFINITION of a regular store or WAREHOUSE location. Therefore, it will be created as part of the Outside Location functionality.

Some retailers require a Routing Location for consolidation of Import Orders. These are distribution centers which are not cross dock locations and also not stock holding locations. Items are not received at these routing locations; the locations are only used for consolidation purposes. From an inventory perspective, a Routing Location is outside the RMS definition of a regular store or warehouse location. Therefore, it will be created as part of the Outside Location functionality.

Individual items can be associated to TICKETS through the Request TICKET WINDOW in RMS. Multiple items are associated through the help of an item LIST or a Purchase order through the same window.

Individual items can be associated to tickets through the Request Ticket window in RMS. Multiple items are associated through the help of an item list or a Purchase order through the same window.

A TICKET TYPE broadly defining the CHARACTERISTICS of a ticket according to the NATURE of information it contains, and the nature of the item it is MEANT to get affixed on.

A ticket type broadly defining the characteristics of a ticket according to the nature of information it contains, and the nature of the item it is meant to get affixed on.