ENH REQ For Programmatically and Repeatable Way of Adding the SIOCS Configurations (Doc ID 2971037.1)

Last updated on AUGUST 07, 2024

Applies to:

Goal

Describe how the current product functionality is insufficient.
For the different configurations that we have to add to SIOCS (e.g.: system options, store options, roles, code info, buddy store, auto receive stores, package size, carrier service, inventory adjustment reasons, shipment reasons, sub-buckets, CFAs) we cannot add them programmatically (template import, CSV, web-service for example), for those configurations the UI is time-consuming and error-prone, and we need to repeat the process for each environment.
Some configurations are by store and we have more than 1300 and also with process of adding through UI can lead user error when setting up +200 system options for example, so for those configurations the UI is time-consuming and error-prone", we can change various configs at the same time for a group of stores but that's not as reliable as using a CSV or a webservice for configurations (any way of doing it programmatically) so we have always the same result, imagine having 10 system options that affect 50% of stores, you need to perform 750 check on the select store options, and if that 10 stores affect different stores you now have to multiple that for 750 * 10.

For examples in the cutover phase we should have all stores to auto receive from other stores (so SIOCS stores can receive automatically from non SIOCS stores), we need to define the auto receive stores with all stores having auto receiving from all stores, and as the rollout begins we start changing those values, the expectation is that we go through all 1300 stores one by one defining the auto receiving stores?

For roles, if we define 4 roles we have to do does roles one by one, we have more than 300 options to go through for each one (you may say that each role will only have a small set of option, but either way you have to go through them).

And for the examples that were given we need to multiple them by the number of environments that we have, so for example if we have DEV, UAT, TTT, PRD, that's a lot of work and time and probably errors only because you have to do it manually using the UI.

Provide a detailed description of the Enhancement Request (desired functionality).
A programmatically and repeatable way of adding the configurations into SIOCS is required, this can be achieved by the use of (templates import like the ones used for users-roles, CSV or web-service that can be called with the options), this will ensure that the same values are used between the different environments, faster, and will be less error prone, as the user does not have to add it one by one, it will also allow to have the same option (for example packaging options) to all stores with all the values and in a fraction of the time, for example a client that has the same package definition to 1000 stores.

Describe how this Enhancement will benefit your business.
It will improve the quality as it is less susceptible to human error, it will allow to prepare the different environments a lot quicker, it will not require that the client to define options that we know will not change (in the near future) and can be added to all stores, the cutover options (like auto receive in non SIOCS stores) can be implemented easier.

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.