Release 28

Iris X Release Notes

Following are the enhancements/fixes in Iris X with the latest deployment

New Version details

User Interface - 5.6.0

Application - 4.17

Algorithm - 11.31

Summary

• No More ado about the data at Increff: Summary reports of the transactional data are now available on the IRIS Interface.

• The same style can now be tagged to multiple seasons in the style masters which will help carry over their intelligence.

• Distribution for Selective Stock on Floor: Be as selective as needed while replenishing the styles on the floor.

• The brilliance of Reordering as a report now: The Period wise forecast of Reorder Target sales and ROS is available as a Download.

• The Core/NooS styles will never be out of your stores: The reorders will ensure maximum availability.

• Additional control over Discounting: Dynamic Markdown Increment factor can be applied at Performance Level.

Get familiar with the new changes/ enhancements

Summary reports on the transactional data page

• The transactional data reports section from BI is added to the transactional data and master data page.

Open

• Transactional data report has a month-wise summary of sales and inventory with a channel filter.

• It also has Sales anomaly and inventory anomaly dashboards that are used to identify missing, duplicate or incorrect sales and inventory with channel and store-level filters.

• The report has channel-wise and season-wise summaries

• These will help to keep a check on the transactional data shared with increff

Open

Multiple seasons for a style

• Now users can tag a style with different seasons. Seasons will be ‘#’ separated(latest followed by the older ones) and will be uploaded from style master.

• In the stock selection, this style will be part of the analysis even when any of the tagged seasons is selected. This is applied to all modules.

• This will help during analysis in ensuring that the styles that got repeated and updated with the latest season are not missed.

Stock selection in Style Merchandise tagging

• The Stock Selection constraint that lets the system select the pool of styles to consider for distribution is split into two, Read Merchandise stock selection and Replenish Merchandise Stock selection.

• The Read tagged styles will be considered for the calculation of the initial quantity at the store(Stock on hand) to consider against the planogram and the Replenish tagged styles will be the ones that are dispatched from the warehouse.

• The quantity will be suggested for both the Read and Replenish styles(for healthy styles) and the dispatch quantity is overridden as 0 when it is given as Read-only.

• In the output, a remark for these entries 'Read-only style' is introduced for these store style combinations.

Maintaining minimum reorder Quantity at a store level

• To ensure the reorder quantity suffices at least the minimum depth to be maintained the size set will be the reordered quantity at the store level in case the reorder quantity suggested based on ROS is less than the size set.

Period-wise ROS output at store group style level in reordering

• A new report: Period Wise ROS Report is added to the reorder module which is used to get period-wise ROS(Rate of Sale) and period wise target sales.

• This will help to understand the period wise generation of reordering suggestion that is calculated basis the performance in the corresponding Analysis period letting the user know the jumps in ROS across the periods.

Dynamic Markdown Increment factor at Performance Level

• Previously, the increment factor is provided in the Discounting Guardrails input which is at the channel - brand - category - season level. 

• This increment can be capped with an extra column in discounting engine logic which has % of increment factor.

• With the help of this input, the user can cap the increments at the performance level. ex-The discounting for a High ROS style can be capped to 5% if the increment factor given for its brand category and season type is 10% and % of increment factor is 50%.

Value Additions

More accurate Alerts:

• The Alerting system can now differentiate between stopped runs and failed runs.

• As a result, users now will not be receiving any calls if module runs are stopped by a user.

NOOS Optimisation

• The most time-taking step within the NOOS module has been optimized and it’s 60% faster than earlier.

Have any Questions?

Please feel free to contact your account manager if you have any queries.