Validity Date Data Modelling Quesiton

[Former Member]

We want to design a Product Repository.

The main table will store product information based on VALIDITY DATES.

We have say 30 fields in the main table.

Any of the 30 fields could change based on the validity date.

We have the practise of working with SKU in the future.

Ex:

<u>ProductID Description SalesUnit Start Validity Date End Validity Date</u>

Printer01 HP Inkjet EA 02/06/2006 06/06/2006

Printer01 HP Special Jet EA 06/07/2006 04/04/2007

How can you represent the same SKU based on validity dates?

Note: Any of the 30 fields in the main table could change based on validity date.

In the Example above, Printer01 is called HP Inkjet based on a validity date.

The same Product Printer01 is called HP Special Jet based on a future validity date.

Qn: How can we model this scenario.

Any leads is appreciated.

I promise to reward the answers which are helpful.

Thanks,

[Former Member]

Hi,

Based on initial look at the sample records you mentioned I could think of the following scenario.

You can have a qualified table maintained for the validity periods.

You said based on the start validity date and end validity dates the any of the 30 field values might change.

So in your Main table, keep the primary key like SKU number, in the qualified table define "Start Validity date" and "End Validity date" as Non Qualifiers. The other 30 fields as Qualifiers.

This way u can maintain different validity periods for each SKU.

Sample record

SKU Validity Range

-

---

P0910 02/06/2006 06/06/2006 Prntr1 HP InkJet

06/07/2006 04/04/2007 Prntr1 HP Special Jet

etc..

Hope this helps.

Thanks and Regards

Subbu

[Former Member]

Thanks Subbu for your insight.

We thought of Qualified Tables for storing the 30 fields.

The Qn I am pondering is..

Does it make sense to have only the SKU number in the main table.

How will it affect the Publishing piece, Taxonomy and Family Hierarchy if we have all the 30 fields in the Qualified Table.

[Former Member]

Hi,

Can you be more specific with regards to the Publishing, Taxonomy and Family hierarchy. Put some example, so that I can think of it

Thanks and Regards

Subbu

[Former Member]

Hi Adhappan,

If all the 30 fields as combination makes a unique record, then it makes sense to keep all of them except dates in the Main table. Then you can think of dates as Non-qualifiers in a Qualified table as Subbu pointed out.

Please let us know more details of these 30 fields and the "Unique key" in your case.

Regards,

Rajani Kumar

[Former Member]

The Unique Key in the Main table is SKU_ID.

In total we have 31 fields including the Unique Key.

The 30 fields are

Item Width

Item Height

Item Depth

Product Class code

Price Authority Code

Price Assortment Code

Vendor Number etc...

Any of the above 30 fields can change based on the Validity date.

The validity dates should not cut across each other.

The reason is " We plan for the future - something like Planned Changes in Material Master in R/3"

Ex: The Vendor is currenly packing the printer in a 50 inches length box.

The vendor may say that starting August 2006, the printer will be packed in a 80 inches box.

We want to store such information today with Validity Start date as Aug 1, 2006 and Validity end date as sometime in the future.

Currently in the legacy system, we have

SKU id, Validity Start and Validity End as the Primary Keys.

How can we model this scenario in MDM?

[Former Member]

Thiagarajan,

The more and more I go through the scenario, I feel that the Solution explained by Subbu sounds more appropriate. To summarize, if for a specific unique SKU, there are multiple fields that change based on Validity period, then the Validity period is a Non-Qualifier field and all others are Qualifier fields.

"The validity dates should not cut across each other" can be implemented via Validation rules. (Please note that currently there are certain limitations on implementing Validations on Qualifier fields which will be fixed in SP4. But in your scenario, if the dates become the Non-Qualifier fields, then there should not be any problem.)

Regards,

Rajani Kumar