1 Feature Summary
This chapter describes the feature enhancements in this release.
Noteworthy Enhancements
This guide outlines the information you need to know about new or improved functionality in the Oracle Retail Merchandising Cloud Services update and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.
Column Definitions
-
Feature: Provides a description of the feature being delivered.
-
Module Impacted: Identifies the module associated with the feature, if any.
-
Scale: Identifies the size of the feature. Options are:
-
Small: These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
-
Medium: These UI or process-based features are typically comprised of field, validation, or program changes. Therefore the potential impact on users is moderate.
-
Large: These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
-
-
Delivered: Is the new feature available for use immediately after upgrade or must the feature be enabled or configured? If no, the feature is non-disruptive to end users and action is required (detailed steps below) to make the feature ready to use.
- Customer Action Required: You must take action before these features can be used. These features are delivered disabled and you choose if and when to enable them.
| Feature | Module Impacted | Scale | Delivered Enabled | Customer Action Required? |
|---|---|---|---|---|
|
Allocation |
Small |
Yes |
No |
|
|
Ability to Hold Credit Note Posting until Matched or Manually Released |
Invoice Matching |
Small |
Yes |
No |
|
Invoice Matching |
Small |
Yes |
No |
|
|
Invoice Matching |
Small |
Yes |
No |
|
|
Merchandising |
Small |
Yes |
No |
|
|
Merchandising |
Small |
Yes |
No |
|
|
Off Invoice and Allowance Deals Enhancements – Retroactive Deals |
Merchandising |
Small |
Yes |
No |
|
Merchandising |
Small |
Yes |
No |
|
|
Ability to Create Up-Charges To/From Non-Stockholding Stores |
Merchandising |
Small |
Yes |
No |
|
Merchandising |
Small |
Yes |
No |
|
|
Merchandising |
Small |
Yes |
No |
|
|
Merchandising |
Small |
Yes |
No |
|
|
Merchandising |
Medium |
No |
Yes |
|
|
Enhanced Archive and Truncate Process for Purge History Tables |
Merchandising |
Medium |
No |
Yes |
| Enhanced Availability of Inventory Transaction Related APIs |
Merchandising |
Medium |
Yes |
No |
|
Enhanced Processing of Inventory Transactions During Nightly Batch Window |
Merchandising |
Medium |
Yes |
No |
| Improved Inventory (ITEM_LOC_SOH table) Update Process |
Merchandising |
Medium |
Yes |
No |
|
Merchandising |
Small |
No |
Yes |
|
|
RFMCS – Enhanced Transfer Workflow to Account for Transfer Returns |
RFMCS |
Small |
Yes |
No |
|
RFMCS – Enhanced GL Cross Reference Mapping to Add Locations |
RFMCS |
Small |
Yes |
No |
ReST Service for Allocation Upload
This cloud service update introduces a ReST service to upload allocations within Allocation CS. This service closely mirrors the Allocation screens for field definitions and validations. It is expected to be used in business setup, where an external system is responsible for creating the initial version of an allocation, which is expected to be further enriched by the end user through online screens once it passes the basic validations associated with the workflow and gets successfully loaded into the database. This service, however, will not allow the creation of ‘What if’ or ‘Scheduled’ allocations.
Ability to Hold Credit Note Posting until Matched or Manually Released
This cloud service update introduces an enhanced supplier option ‘Document Hold’ which allows greater flexibility in managing credit note postings. With this enhancement, users can select from three options — ‘Do Not Hold’, ‘Hold Invoices until Credit Note is Received’, and the new ‘Hold Credit Notes’ in the Supplier Options screen. The new ‘Hold Credit Notes’ option allows credit notes to be matched before posting without requiring the associated invoice to be held, thereby improving process efficiency and offering more control over the document flow to the end user. This change streamlines reconciliation processes for retailers and better aligns the system behavior with various operational preferences while maintaining secure and auditable handling of credit notes and related documents.
ReST Service for GL Cross Reference Maintenance
This cloud service update introduces a ReST service designed for importing General Ledger (GL) cross-reference mappings in bulk into Invoice Matching Cloud Service. This service closely mirrors the existing screen-driven cross-reference creation process, offering support for all relevant fields and validations including account type, account code, set of books, tax codes and up to twenty segment values as defined for each set of books. Designed to streamline and automate the management and integration of GL mappings, this new service allows users to efficiently handle large-scale updates, ensures compliance with existing validation rules, and supports enterprise integration needs without impacting current data or manual processes.
External Account Validation
This cloud service update introduces a dedicated system option for external account validation within Invoice Matching Cloud Service, allowing organizations to configure whether account combinations should be validated locally or through integration with an external financial system similar to Oracle Fusion General Ledger. This enhancement provides the flexibility to validate accounts either against an internal repository or by calling external endpoints (with support for both RFI and direct CFIN integration), based on a system level configuration. With streamlined credential management and compatibility with enterprise security practices, the new design improves controls over account validation during GL cross-reference setup, reduces errors and enhances overall compliance with financial governance policies.
AI-Assisted Capability to Refine Comments
This cloud service update introduces the ability to refine user-entered comments with the help of generative AI. Merchandising online screens for Purchase Orders, Transfers, Items and Deals now provide an option where users can choose to expand, fix grammar, rephrase or summarize their comments with AI assistance. They can provide their own instructions for refinement as well.
Carton Level Stock Order Reconciliation through Induction
This cloud service update extends the current spreadsheet-based management of stock order reconciliations to support carton-level reconciliations such as the Merchandising online screen. It supports all the fields and validations that are available on screen and has been added as a new worksheet in the existing Stock Order Reconciliation spreadsheet template.
Off Invoice and Allowance Deals Enhancements – Retroactive Deals
This cloud service update provides the ability to edit Off Invoice and Allowance deals at extended points in their life cycle (worksheet, approved, active). The update capability allows for changing dates (including backdating) as well as changes to components, item-locations, and discount details. The editing capability is not available for PO-specific deals, where there is a dependency on keeping the purchase order and deal in sync.
The updated deal definition is re-applied on all applicable orders and the net cost variance for each item on the POs impacted by the deal update is recorded via transaction data posting. The impacted orders and shipments reflect the new cost based on the updated deal definition, and the inventory associated with these shipments is revalued to account for the deal cost adjustment. In the case of shipments that are already matched, an additional collection document is generated to account for the cost variance arising from the deal updates, given that these documents are not likely to be matched again.
For deals, the option to revalue inventory is always selected by default. If Inventory Layers are being tracked, it will be leveraged to identify where the inventory associated with the deal-impacted POs reside, and the average cost will be revalued based on the number of units of “deal-eligible” inventory available at each location. If Inventory Layers are not used, the cost correction is recorded at the deal location.
Deals Usability and Processing Enhancements
This cloud service update delivers the following usability and processing-related enhancements for Deals.
-
Deal Definition at a Supplier Site Level – This enhancement allows deals to be created at a Supplier Site level to supplement the current capability of creating deals at a supplier level. The deal processing and billing calculations are augmented to support this flexibility. Deals defined at the supplier level are applicable to all sites for that supplier.
-
Deal Qualification Comparison Date – This enhancement provides flexibility to select which date on a purchase order (Original Approval date, Not Before Date, Not After Date, Earliest Ship Date, Latest Ship Date) should be used as the qualifying date for deal applicability for off invoice deals. In previous versions of Merchandising, the eligibility of orders for off invoice deal application was determined based on whether the Not Before Date of the order falls within the deal window (that is, between the deal active date and close date). If the date specified on the deal for this comparison does not exist on the order, the order is not considered for deal application.
-
Discount Apportionment – The discount apportionment logic for the ‘Buy Get’ type of deals has been enhanced to use Discount Apportionment Percentage (if defined) for deals with a Get type of ‘Percent off – Get Units at % Off Cost‘ or ‘Amount – Get Units at Amount Off Cost’. If the Discount Apportionment Percentage is not defined, the apportionment is based on the relative values of the buy/get items. Definition of the Discount Apportionment Percentage is not allowed for deals with a Get type of ‘Fixed Amount – Get Units for Fixed Price’.
-
Deal Comments – Users can now update Comments at the Deal Component level irrespective of the Deal Status.
Codes
| Code Type | Code Type Description | Code | Code Description | New or Updated? | Delivered |
|---|---|---|---|---|---|
| DQCD | Deal Qualification Comparison Date | ESD | Earliest Ship Date | New | Enabled |
| DQCD | Deal Qualification Comparison Date | LSD | Latest Ship Date | New | Enabled |
| DQCD | Deal Qualification Comparison Date | NAD | Not After Date | New | Enabled |
| DQCD | Deal Qualification Comparison Date | NBD | Not Before Date | New | Enabled |
| DQCD | Deal Qualification Comparison Date | OAD | Original Approval Date | New | Enabled |
| SUH2 | Deal Partner Types | SS | Supplier Site | New | Enabled |
| SUHL | Supplier Hierarchy Levels | SS | Supplier Site | New | Enabled |
DAS/RDS Updates
| Application Table | DAS/RDS Table or View | Change Type | Change Description |
|---|---|---|---|
| DEAL_HEAD | DAS_WV_DEAL_HEAD | Update | Added COMPARISON_DATE column. Modified the comments on columns SUPPLIER and PARTNER_TYPE |
| DEAL_HEAD | RDS_WV_DEAL_HEAD | Update | Added COMPARISON_DATE column. Modified the comments on columns SUPPLIER and PARTNER_TYPE |
| FIXED_DEAL | DAS_WV_FIXED_DEAL | Update | Modified the comments on columns SUPPLIER and PARTNER_TYPE |
| FIXED_DEAL | RDS_WV_FIXED_DEAL | Update | Modified the comments on columns SUPPLIER and PARTNER_TYPE |
| DEAL_DETAIL | DAS_WV_DEAL_DETAIL | Update | Modified the comments on columns GET_FREE_DISCOUNT |
| DEAL_DETAIL | RDS_WV_DEAL_DETAIL | Update | Modified the comments on columns GET_FREE_DISCOUNT |
Ability to Create Up-Charges To/From Non-Stockholding Stores
This cloud service update introduces the ability to include non-stockholding stores as 'to' and 'from' locations in the up-charge definition at the department or item level. These up-charges are also considered for book transfers and recalculate the weighted average cost (WAC) at the receiving location to reflect these costs along with relevant transaction data postings.
Spreadsheet Based Upload for Inventory Adjustments
This cloud service update introduces the capability to create inventory adjustments by items and locations using a spreadsheet-based upload process in Merchandising. This process closely mirrors the existing screen-based inventory adjustment creation process, offering support for all relevant fields and validations. Additionally, a new field to capture user comments has also been added to the spreadsheet template, online screen and inventory adjustment ReST service.
Privileges
| Priv Name | Change Type | Priv Description | Parent Duty |
|---|---|---|---|
| MAINTAIN_INVENTORY_ADJUSTMENTS_VIA_SPREADSHEET_PRIV | New | A privilege for performing inventory adjustments via spreadsheet upload. | RMS_INVENTORY_ADJSUTMENT_VIA_SPREADSHEET_MGMT_DUTY |
Codes
| Code Type | Code Type Description | Code | Code Description | New or Updated? | Delivered |
|---|---|---|---|---|---|
| BT | Induction Download Blank Template | RMSIAD | Inventory Adjustment | New | Enabled |
| RMST | RMS Admin API Templates | RMSIAD | Inventory Adjustment | New | Enabled |
Privileges
| Priv Name | Change Type | Priv Description | Parent Duty |
|---|---|---|---|
| MAINTAIN_INVENTORY_ADJUSTMENTS_VIA_SPREADSHEET_PRIV | New | A privilege for performing inventory adjustments via spreadsheet upload. | RMS_INVENTORY_ADJSUTMENT_VIA_SPREADSHEET_MGMT_DUTY |
Ability to Define Shrinkage at Class and Subclass Level
This cloud service update introduces the capability of a more granular definition of shrinkage percentage at a class or subclass level. Previously, it could be defined only at the department level and modifications have been made to the Half Data Budget spreadsheet template and ReST service to allow for the optional definition at the class or subclass level. The period ending inventory calculation logic has also been enhanced to handle these definitions.
The existing system level option ‘Use Budgeted Shrinkage for Ending Inventory’ is being replaced with a new one ‘Budgeted Shrinkage Usage Level’, which allows for the setting of the level (Department, Class, Subclass, or None) at which the shrinkage percentage is desired to be maintained. For existing customers, it is set to ‘Department’ if the previous option to use budgeted shrinkage percentage was opted for. If previously not opted for, it is set to ‘None’ (blank) to maintain backward compatibility. The setting of this system parameter is an implementation time activity, and any subsequent modification is not recommended due to data implications. However, if needed in exceptional circumstances, it should be a planned exercise and must be handled through a service request to Oracle Support.
System Options
| Attribute Name | New or Update? | Attribute Description | Default Value |
|---|---|---|---|
| BUD_SHRINK_IND | Update | This column determines whether budgeted shrinkage will be used in the calculation of period ending inventory value in the stock ledger. If this option is set to Department (D), then shrinkage will be calculated as a percentage of sales using the budgeted shrinkage percent defined at the department level. If this option is set to Class (C), then shrinkage will be calculated as a percentage of sales using the budgeted shrinkage percent defined at the class level. If this option is set to Subclass (S),then shrinkage will be calculated as a percentage of sales using the budgeted shrinkage percent defined at the subclass level. If this value is set to No Budgeted Shrinkage (N), then actual shrinkage is calculated. | N |
Integration
| API Name | Change Type | Integration Type | Field Name | Change Description |
|---|---|---|---|---|
| Half Data Budget ReSTful Web Service | Update | REST Service | CLASS , SUBCLASS. | Added new fields CLASS and SUBCLASS. |
Codes
| Code Type | Code Type Description | Code | Code Description | New or Updated? | Delivered |
|---|---|---|---|---|---|
| BSUL | Budget Shrinkage Usage Levels | C | Class | New | Enabled |
| BSUL | Budget Shrinkage Usage Levels | D | Department | New | Enabled |
| BSUL | Budget Shrinkage Usage Levels | N | No | New | Enabled |
| BSUL | Budget Shrinkage Usage Levels | S | Subclass | New | Enabled |
DAS/RDS Updates
| Application Table | DAS/RDS Table or View | Change Type | Change Description |
|---|---|---|---|
| SYSTEM_OPTIONS | DAS_WV_SYSTEM_OPTNS | Update | Modified the comments for the column BUD_SHRINK_IND. |
| FINANCIAL_UNIT_OPTIONS | DAS_WV_FINANCIAL_UNIT_OPTNS | Update | Modified the comments for the column BUD_SHRINK_IND. |
| HALF_DATA_BUDGET | DAS_WV_HALF_DATA_BUDGET | Update | Added new columns - CLASS and SUBCLASS. |
| HALF_DATA_BUDGET | RDS_WV_HALF_DATA_BUDGET | Update | Added new columns - CLASS and SUBCLASS. |
| SYSTEM_OPTIONS | RDS_WV_SYSTEM_OPTIONS | Update | Modified the comments for the column BUD_SHRINK_IND. |
| FINANCIAL_UNIT_OPTIONS | RDS_WV_FINANCIAL_UNIT_OPTIONS | Update | Modified the comments for the column BUD_SHRINK_IND. |
Enhanced UDA Cascade Workflow from Parent to Child Items
This cloud service update introduces enhancements to the UDA management workflow to cascade only UDAs from the parent to child items that are added or modified by the user in the same session, once the user chooses the option to cascade them in the Item UDA screen. This allows unchanged UDAs to remain unaffected and prevent any unwanted updates in the workflow.
Inventory Ownership Change for Transfers
This cloud service update introduces an option to control ownership of in-transit inventory. Previously, the in-transit inventory always belonged to the destination location starting from the moment of the transfer shipment. If the new option is opted for, the ownership of in-transit inventory belongs to the source location until the transfer is received. The “shipped” inventory is part of a new bucket in the item-location Stock on Hand table. Relevant transaction data postings, total stock on hand, and stock ledger calculations are modified to account for this new inventory bucket, and the ownership change that happens at the time of transfer receipt at the destination location.
System Options
| Attribute Name | New or Update? | Attribute Description | Default Value |
|---|---|---|---|
| REC_WAC_UPDATE_IND | New | This system option will change the moment when the average cost is updated for the destination location in transfers. If enabled, the average cost will be updated at the time of transfer receiving. | N |
Integration
| API Name | Change Type | Integration Type | Field Name | Change Description |
|---|---|---|---|---|
| stockCountDetail | Update | REST Service | snapshotShippedQty | Added field snapshotShippedQty. |
| itemlocInvDetail | Update | REST Service | shipped_qty and pack_comp_shipped_qty | Added shipped_qty and pack_comp_shipped_qty fields |
DAS/RDS Updates
| Application Table | DAS/RDS Table or View | Change Type | Change Description |
|---|---|---|---|
| SHIPSKU | DAS_WV_SHIPSKU | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| SHIPSKU | RDS_WV_SHIPSKU | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| ITEM_LOC_SOH | RDS_WV_ITEM_LOC_SOH | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| ITEM_LOC_SOH_EOD | DAS_WV_ITEM_LOC_SOH_EOD | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| ITEM_LOC_SOH_EOD | RDS_WV_ITEM_LOC_SOH_EOD | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| SHIPSKU_PRG_HIST | DAS_WV_SHIPSKU_PRG_HIST | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| SHIPSKU_PRG_HIST | RDS_WV_SHIPSKU_PRG_HIST | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| INV_MOVE_UNIT_OPTIONS | DAS_WV_INV_MOVE_UNIT_OPTNS | Update | Added new column REC_WAC_UPDATE_IND |
| INV_MOVE_UNIT_OPTIONS | RDS_WV_INV_MOVE_UNIT_OPTIONS | Update | Added new column REC_WAC_UPDATE_IND |
| ITEM_LOC_SOH | DAS_WV_ITEM_LOC_SOH | Update | Added new column SOURCE_LOC_AV_COST and RECEIPT_UNIT_COST |
| SYSTEM_OPTIONS | DAS_WV_SYSTEM_OPTNS | Update | Added new column REC_WAC_UPDATE_IND |
| SYSTEM_OPTIONS | DAS_WV_SYSTEM_OPTIONS | Update | Added new column REC_WAC_UPDATE_IND |
Enhanced Archive and Truncate Process for Purge History Tables
This cloud service update introduces multiple enhancements to Merchandising batch process for archiving and truncating Purge History tables. The following is the list of modifications:
-
The Archive and Truncate Purge History Tables batch has been moved out of the nightly schedule and is now available as a standalone job BATCH_ARCHIVE_PURGE_HIST_ADHOC_JOB under the process BATCH_ARCHIVE_PURGE_HIST_ADHOC_PROCESS.
-
Retention days for purge history are configurable and can be set through system parameters ‘Purge History Retention Months’ and ‘Purge History Rollup Retention Months’ with a maximum retention period of 18 months. Earlier the entire purge history was truncated every 180 days.
-
There is now an option to delay the deletion of data from the purge history table after exporting into files. The number of days of delay can be set through a system parameter ‘Purge History Deal Days’ with a maximum of 7 days and a minimum of 0 days.
-
The purge history tables are now interval partitioned by month. This change enables the retention and deletion logic to operate at the partition level. Table partitions meeting the purge criteria are exported as a single dump file (*.dmp) per table. The filename format for the dump files is: EXPDAT<table name>YYMMDDHH24MISS.dmp
-
The exported dump files continue to be available in object storage under the outgoing prefix for retrieval. The exported dump files are also copied to the archive folder in persistent volume.
-
The status and details of a job run can be tracked through a new table, ARCHIVE_PURGE_TRACKER. The status fields indicate where a particular table partition is in the archive and purge process.
-
New (N) - New row for processing. Table partitions satisfy purge retention criteria. This is the first stage.
-
Exported (E) - Table partitions have been exported to a dump file in the database file system. This is the second stage.
-
Outgoing (O) - Export dump files from database file system have been moved to the outgoing prefix in object storage. This is the third stage.
-
Archived (A) - Export dump files have been copied to the archive folder in persistent volume. This is the fourth stage.
-
Purged (P) - Table partition has been dropped. This is the final stage.
-
-
If Purge History Delay Days is set for more than 0 days, it is expected that a run completes with the to-be purged table partitions in "A" (archived) status. This means the data has been exported but needs to be purged from the purge history tables. Once the configured delay has passed, the data is purged, and status set as P" (purged). A delay of 0 days results in a final status of ‘P’ (purged) after execution.
Note:
Important Pre-installation NotePrior to installing the release, it is recommended that the current BATCH_ARCHIVE_PURGE_HIST_JOB should be triggered to archive and truncate existing data on the purge history tables. By default, the process runs if 180 days or more has lapsed since LAST_PURGE_HIST_ARCHIVE_DATE on the RMS_ARCHIVE_DATES table. This date can be updated to fulfill the purge condition and trigger the process even when 180 day limit is not yet reached. If there is no intention to retain existing purge history, a request can be made to truncate the data in the purge history tables.
If no action is taken prior to the patch installation, all existing data in the purge history tables is retained and falls into a single partition having an upper bound of + 1 day. For example, if there is currently 100 days’ worth of purge history, and the patch is installed on the 1st November, all 100 days are moved to a month partition with an upper bound date of 2nd November. Please note that if the "no action" route is taken, the first run of the updated batch with actual data to be purged can run long. The run time is directly proportional to the volume of existing data that was retained. As such, it is recommended to do a data cleanup prior to installation.
This enhancement aims to address following business needs:
-
Frequent export and archiving to meet customer audit requirements.
-
Historical data retention to assist in resolving data anomalies and discrepancies.
-
Configurable data retention that can be tailored to the needs of the customer.
-
Configurable delay between exporting and purging. This allows users to validate the exported files before the data is deleted from the tables.
-
Lesser volume in base tables to improve overall application performance while having the purged historical data readily accessible.
System Options
| Attribute Name | New or Update? | Attribute Description | Default Value |
|---|---|---|---|
| PURGE_HIST_DELAY_DAYS | New | This field contains the number of days before an archived partition is dropped by the Archive and Truncate Purge History Tables batch. Maximum delay is 7 days. | 7 |
| PURGE_HIST_RETENTION_MONTHS | New | This field contains the number of months retained in the purge history tables. Records past the retention period are removed by the Archive and Truncate Purge History Tables batch. Maximum retention is 18 months. | 6 |
| PURGE_HIST_ROLLUP_RETENTION_MONTHS | New | This field contains the number of months retained in the purge history tables specific to tables contained rolled-up data. Records past the retention period are removed by the Archive and Truncate Purge History Tables table. Maximum retention is 18 months. | 12 |
Batch Schedule
| Process Name | Process Type | New or Updated? | Delivered |
|---|---|---|---|
| BATCH_ARCHIVE_PURGE_HIST_PROCESS | Nightly | Removed | Enabled |
| BATCH_ARCHIVE_PURGE_HIST_ADHOC_PROCESS | Ad Hoc | New | Disabled |
DAS/RDS Updates
| Application Table | DAS/RDS Table or View | Change Type | Change Description |
|---|---|---|---|
| PURGE_CONFIG_OPTIONS | DAS_WV_PURGE_CFG_OPTNS | Update | Added PURGE_HIST_RETENTION_MONTHS, PURGE_HIST_ROLLUP_RETENTION_MONTHS, and PURGE_HIST_DELAY_DAYS columns. |
| PURGE_CONFIG_OPTIONS | RDS_WV_PURGE_CONFIG_OPTIONS | Update | Added PURGE_HIST_RETENTION_MONTHS, PURGE_HIST_ROLLUP_RETENTION_MONTHS, and PURGE_HIST_DELAY_DAYS columns. |
| SYSTEM_OPTIONS | DAS_WV_SYSTEM_OPTNS | Update | Added PURGE_HIST_RETENTION_MONTHS, PURGE_HIST_ROLLUP_RETENTION_MONTHS, and PURGE_HIST_DELAY_DAYS columns. |
| SYSTEM_OPTIONS | RDS_WV_SYSTEM_OPTIONS | Update | Added PURGE_HIST_RETENTION_MONTHS, PURGE_HIST_ROLLUP_RETENTION_MONTHS, and PURGE_HIST_DELAY_DAYS columns. |
Enhanced Availability of Inventory Transaction Related APIs
Along with the enhancement to allow processing of inventory transactions during the nightly batch run, several ReST APIs that were previously not available during the Inventory phase of the nightly batch can now be called during all phases. This ensures 24x7 inventory processing through ReST services and thereby consistency across inventory-related operations.
Another set of APIs that were not available during both Inventory and Costing phase are now unavailable only during costing batch runs.
This enhancement has following operation impacts:
- When RIB is used, RIB Inventory Adaptors will remain ‘started’ throughout Merchandising nightly batch.
- RMS_BATCH_STATUS.INVENTORY_BATCH_RUNNING_IND will remain ‘N’.
- ReST APIs related to inventory transactions and transactions from SIOCS to MFCS through direct database integration will be processed immediately throughout Merchandising nightly batch.
Enhanced Processing of Inventory Transactions During Nightly Batch Window
This Merchandising update introduces an enhancement to allow processing of inventory transactions during all phases of the nightly batch run. This enhancement, coupled with the availability of inventory-transactions-related ReST APIs during the nightly batch run and improved inventory update process, ensures 24x7 inventory processing in Merchandising. This includes the following modifications:
-
Database Related Modifications
- TRAN_DATA_A and TRAN_DATA_B tables are now dropped for optimization
- TRAN_DATA table is changed from a view to a physical table
- TRAN_DATA table is added to the SHRINK_TABLE_SEGMENT process in delete_tab_stats.ksh
-
Batch Job Related Modifications
- MAINTAIN_IFTD_HIST_JOB: Updated to include the new Tran Data ID column.
- salapnd.pc: Updated to include the new Tran Data ID column.
- wasteadj.pc: Updated to perform updates (not overwrites) to ITEM_LOC_SOH.STOCK_ON_HAND and STAKE_SKU_LOC.SNAPSHOT_ON_HAND_QTY, supporting parallel API operations.
- prepost.pc stkxpld_pre (new): Updated to read stake_lockout_days from system_options. If stake_lockout_days = 0, set RMS_BATCH_STATUS.SNAPSHOT_TAKEN_IND to ‘I’ (In‑progress). When stake_lockout_days = 0, stkxpld.pc updates STAKE_SKU_LOC.snapshot_*; Inventory APIs running concurrently may also need to update STAKE_SKU_LOC.snapshot_*.
- prepost.pc stkupd_pre (mod): If stake_lockout_days > 0, set RMS_BATCH_STATUS.SNAPSHOT_TAKEN_IND to ‘I’ (In‑progress).
- stkxpld.pc/stkupd.pc: Chunk up rows on STAKE_SKU_LOC that need to be updated for snapshot; lock the corresponding rows on ITEM_LOC_SOH to get the snapshot values; commit for each chunk.
-
Flashback Query Related Modifications
- refeodinventory.ksh - Updated to use the SCN recorded by STOCKLEDGER_SWITCHTIME_JOB in the FLASHBACK_SNAPSHOT_INFO table (for process_name = 'SCCEXT_SALSTAGE_REFEODINVENTORY' and business_date = vdate) to flashback query ITEM_LOC_SOH when populating ITEM_LOC_SOH_EOD.
- salstage.pc - Enhanced to use the SCN captured by STOCKLEDGER_SWITCHTIME_JOB immediately before execution to flashback query TRAN_DATA for populating IF_TRAN_DATA and IF_FUTURE_TRAN_DATA.
- The same SCN will be used by refeodinventory.ksh to ensure consistency when querying ITEM_LOC_SOH.
- This update ensures that both ITEM_LOC_SOH_EOD and IF_TRAN_DATA/IF_FUTURE_TRAN_DATA
include the same set of transactions, meeting RAP requirements.
Note:
The timestamp represents the End of Day for Inventory and Stock Ledger, not the End of Day for Business Date, as VDATE switching occurs later in the nightly batch.
-
Job Dependency Updates
- Jobs and Processes related to starting/stopping RIB inventory adapters are now dummy jobs. When RICS is used, RIB inventory adapters will remain up during the nightly batch.
- Dependency Removals
- SALSTAGE_JOB on OWNCHG_PROCESS_JOB.
- REFEODINVENTORY_JOB on OWNCHG_PROCESS_JOB.
- Dependency Additions
- SALSTAGE_JOB and REFEODINVENTORY_JOB post-dependent on STOCKLEDGER_SWITCHTIME.
- STOCKLEDGER_SWITCHTIME post-dependent on:
- STKVAR_PROCESS/STKVAR_POST_JOB
- SALESPROCESS_PROCESS/SALESUPLOADARCH_JOB
- END_COSTING_BATCH_PROCESS/END_COSTING_BATCH_JOB
Batch Schedule
| Process Name | Process Type | New or Updated? | Delivered |
|---|---|---|---|
| STOP_RIB_ADAPTOR_INV_PROCESS | Nightly | Update | Enabled |
| START_RIB_ADAPTOR_INV_PROCESS | Nightly | Update | Enabled |
| STOP_RIB_ADAPTOR_INV_24x7_PROCESS | Nightly | Update | Enabled |
| START_RIB_ADAPTOR_INV_24x7_PROCESS | Nightly | Update | Enabled |
| RDE_STOP_RIB_ADAPTOR_INV_24x7_PROCESS | Nightly | Update | Enabled |
| RDE_START_RIB_ADAPTOR_INV_24x7_PROCESS | Nightly | Update | Enabled |
DAS/RDS Updates
| Application Table | DAS/RDS Table or View | Change Type | Change Description |
|---|---|---|---|
| TRAN_DATA | RDS_WV_TRAN_DATA | Update | Added CREATE_ID,CREATE_DATETIME,LAST_UPDATE_ID,LAST_UPDATE_DATETIME,TARGET_COMMIT_DATETIME,CSN_NBR,LAST_DML_TYPE and ID fields |
| TRAN_DATA | DAS_WV_TRAN_DATA | Update | Added CREATE_ID,CREATE_DATETIME,LAST_UPDATE_ID,LAST_UPDATE_DATETIME and ID fields |
| IF_TRAN_DATA | DAS_WV_IF_TRAN_DATA | Update | Added ID field |
| IF_FUTURE_TRAN_DATA_HIST | DAS_WV_IF_FUTURE_TRAN_DATA_HIST | Update | Added ID field |
| IF_FUTURE_TRAN_DATA | RDS_WV_IF_FUTURE_TRAN_DATA | Update | Added ID field |
| TRAN_DATA_HISTORY | DAS_WV_TRAN_DATA_HISTORY | Update | Added ID field |
| TRAN_DATA_HISTORY | RDS_WV_TRAN_DATA_HISTORY | Update | Added ID field |
| TRAN_DATA_A | DAS_WV_TRAN_DATA_A | Update | it's dummy view now as underlying TRAN_DATA_A is drooped from RMS base |
| TRAN_DATA_B | RDS_WV_TRAN_DATA_B | Update | it's dummy view now as underlying TRAN_DATA_B is drooped from RMS base |
| IF_TRAN_DATA | RDS_WV_IF_TRAN_DATA | Update | Added ID field |
| IF_TRAN_DATA_HIST | RDS_WV_IF_TRAN_DATA_HIST | Update | Added ID field |
| IF_TRAN_DATA_HIST | DAS_WV_IF_TRAN_DATA_HIST | Update | Added ID field |
| IF_FUTURE_TRAN_DATA_HIST | RDS_WV_IF_FUTURE_TRAN_DATA_HIST | Update | Added ID field |
| IF_FUTURE_TRAN_DATA | DAS_WV_IF_FUTURE_TRAN_DATA | Update | Added ID field |
| TRAN_DATA_A | RDS_WV_TRAN_DATA_A | Update | it's dummy view now as underlying TRAN_DATA_A is drooped from RMS base |
| TRAN_DATA_B | DAS_WV_TRAN_DATA_B | Update | it's dummy view now as underlying TRAN_DATA_B is drooped from RMS base |
Improved Inventory (ITEM_LOC_SOH table) Update Process
As part of this Merchandising update, along with the enhancement to allow processing of inventory transactions and availability of inventory-transactions-related ReST APIs during the nightly batch run, the inventory update process has also been improved to achieve 24x7 inventory processing. This includes the following modifications:
-
A new ‘wait and retry’ mechanism on the ITEM_LOC_SOH table to reduce locking errors within the APIs updating this table. Instead of failing immediately upon contention, the process will wait for up to 10 seconds and attempt to acquire the lock a configurable number of times before failing.
-
The configuration is defined on the MERCH_BATCH_PARAM table with batch_name ‘DEFAULT_LOCK_RETRY’, param_key ‘RETRY_LOCK_ATTEMPTS’, and a param_value of 3. The param_value can be modified as needed.
-
Existing processes that already define their own locking parameters (for example, those in RMS_PLSQL_BATCH_CONFIG and MERCH_BATCH_PARAMS for BATCH_NAME = 'SALES_AUDIT_STORE_DAY_LOCK') will continue to use the existing configurations.
Ability to Cancel Order Line with Open Shipments
With this cloud service update, there is now an option to allow line level cancellation even when there are open shipments on an order which was previously not allowed. This enhanced feature is controlled by a system level parameter, ‘Skip Open Shipment for Order Line Item Cancellations’, which will allow users to cancel both shipped and unshipped but unreceived units for an item on the order. This helps resolve scenarios where shipments are not expected to be received by the retailer.
System Options
| Attribute Name | New or Update? | Attribute Description | Default Value |
|---|---|---|---|
| SKIP_OPEN_PO_SHIPMENT_LINE | New | Indicates whether or not the system will allow Order Line level Cancellations of open shipped quantity. Valid values are Yes (Y) or No (N), with a default value of No (N). When set to Yes (Y), user is allowed Order Line level Cancellations keeping shipment Open. This will cancel the unreceived quantity - both shipped and unshipped. When this value is No (N), system cancels only the unshipped quantity. | No |
RFMCS – Enhanced Transfer Workflow to Account for Transfer Returns
This cloud service update introduces updates in transfer shipment and transfer receiving workflows within RFMCS to account for the transfer return scenario. With this change, the fiscal ledger in the location receiving the transfer reverts the outbound records instead of creating new inbound ones, and the fiscal ledger balance is updated, allowing the location to return the goods to the vendor and keep the fiscal ledger properly updated.