Upgrading Configurator Data

[DBohner-(db)]

Howdy,

Cross-posting to the Functional side - to see if I am missing something in my logic.

The Configurator Data Upgrade takes too long (You knew that, right???). Oracle's own documents state hours to days... I have been trying to identify a means to make this process cruise... or, at least - be able to run over current year and prior year data...

In reviewing Oracle Doc: "E1: 32: Configurator Processing (Doc ID 642459.1)" - it appears there is a way to re-sync the CFGSID across all the configurator tables.

So, Conceptually:
- Prior to Go-Live, run the R893201S over a Subset of Prior Years data (say Document Numbers less than XXXXXX)
- Increment the CFGID, via SQL, of the Prior Years data set (all Configurator Tables and F41021) and copy that dataset for later use (to be merged after Go-Live).
- At Go-Live, run R893201S over a Subset of Current Year data (say Document Numbers Greater than or equal to XXXXXX)
* We would, temporarily, remove the prior year data
- Merge the Two Data Sets

Then, if I understand the document correctly:
- R893283F - will clean up the F3283 (CTKID)
- R893215F - will clean up F3215, F3211 & F41021 (CFGSID)

I don't see that CFGSID is used in any other tables other than the F32* and the F41021 - so, incrementing that value across one data set or the other - shouldn't have any impact (as long as all are in-sync).

Does that sound like it will work? Any Gotchas that anyone sees?

(db)

 

[clmates]

Hi

I had go live now in end of 2013

beware that R893201H at least don't use nn for the CFGSID counter, it is hard coded in the .c code, so if you run it, it will delete all F3201, F3211, F3212 F3215 data and start to calculate new configurations using CFGSID 1 as start

also if you don't want to delete F32* tables, you must adapt the code

We had also problems with this upgrade as we had data since 2003 to convert

Look that in relation with our go live, Oracle have patched R893201H (we used H as we have sales data in F42119) in order to skip Q rules conversion to F3215, these rules will be converted by another new TC, but we dont have used it, as we detected errors if you have rules that references Segment values forming part of the derived calculation of routes, the way to be able to skip the use of this report is to have all WO processed with R31410 on XE before the stop of XE services

Also We have found that the logic to calculate and populate new CFGSID on F41021 was very bad as it was iterating for all ITM and MCU but not for ITM + MCU + CFGSID so it was running all over again over the same items and lots, and checking with a string compare if the CFGSID was the proper one to be updated.

Now they have patched this by adding a new index to F42021 with the CFGSID included, and now the conversion will run much faster as only the affected CFGSID records will be selected each time


We have found also that you can run R893201H as many times as you like , as he always set the new CFGID to 1(don't use nn), and regenerates all new configurator transaction tables F3215, F3201, F3211.

F3212 is deleted but not regenerated, as now it is regenerated by the new conversion report, anyway you only need this table generated in order to run R31410, and if you have run thin on XE previous to the upgrade you will have no problems

Hope this helps

 

[DBohner-(db)]

Thanks for the input, CLMates

....

Another Question:


Maybe to clarify the question a bit more:
- When R893215F is run, how does the process determine if the CFGSID is incorrect?
- What keys are used to regenerate the CFGSID value, when it is determined that the CFGSID is incorrect

(db)

 

[clmates]

Hi DBohner

The F41021 conversion placed the old CSID into the new CFGSID column of the table

The old CSID is a number, that was calculated for each item as a independent counter , so it is strange to have high values there, maximum 4 or 5 digits

then new CFGSID is a hash , so it is a alphanumeric string of 32 characters long. So when the TC gets a new line in F3296 to convert, it haves the old CSID and calculates a new CFGSID based on the required segments hash , now it goes to F41021 and find all records for the SAME ITM and MCU (and now CFGSID as old CSID) and updates to new CFGSID



a good query to make after the conversion is one that looks in F41021 for CFGSID <>0 and CFGSID = numerical value (or < 99999) then you detect configurations that the TC was not able to convert. This could be due to changed in configurator specifications in the middle of a manufacturing or sales, we had about 1000 records affected for this, but only about 100 with stock on hand

also is mandatory that you change the stocking type back to C for all configurated items, if you had changed any of these to stocking type O (like we did when we obsoleted old cfg items), the TC routines wont convert configurations if the tocking type is not C

Regards

 

[DBohner-(db)]

CLMATES,

Do you know what the values are used to derive the new hash values?

(db)

 

[clmates]

Hi

Yes, it uses the values of the segments (marked as save segments on F3291), as are on F3211 for this configuration ID, but I don't know exact logic or sequence taken for the calculation

the objetive of the CFGSID hash is to have an "easy" way to detect if there is stock available that could satisfy a new created sales order for an specific configuration,

Regards