How to manage unique item variants with many possible combinations ?

[former_member631464]

Greeting,

I'm working with SAP business one 9.3 patch level 5. Our company mainly resells industrial products. Those are highly configurable and their part numbers are build around their configurations.

I'll take a car as an example. It has two configurations : the color (2 options) and the engine (2 options).

• The colors are : B : Blue or R : Red
• The engines are L : 150 bhp and H : 220 bhp

The item codes for that cat would be:

• CAR-B-L
• CAR-B-H
• CAR-R-L
• CAR-R-H

Now here is our problem, our products can have up to 10 variants, each with up to 8 options. That's over a billion item codes for one product. Moreover, different options have different prices which all have to be maintained. Our suppliers use custom built ERPs that don't store an item table like OITM so they couldn't help much.

We are currently handling this issue by having a few generic part numbers like CAR-Premium and CAR-Economy in our sales orders, then renaming the item description in the purchase order to the right code. Apart from being tedious to do, we are not able to stock any of those items as their differences are unknown to SAP.

So far, we have been only able to set the serial numbers in the sales order when receiving the items from our suppliers to tell them apart.


We've been searching a solution for this issue for a while now (included or add-ons) and even considered developing a software threw DIAPI to generate and manage the massive amount of item codes (prices / translations / etc...). Although possible, this last solution seems to be tackling the problem the wrong way, we are not even shure if our database will be able to handle billions of items. We've also heard that an item reservation feature was being developed by SAP and should be released in PL12 or 13 though we've seen no official announcements for it. It could potentially help in stocking those items.

Thank you for your help.

[agustin_marcoscividanes · Accepted solution]

Hi

I would try to use a formatted search to build the itemcode. When you select an attribute you add a value to the code.

This answer is quite simple, you have to add info to solve.

Kind regards

Agustín

[agustin_marcoscividanes]

Hi

I think as johan.hakkesteegt, the first question is how many different completely configured products you need to manage.

I think you should manage your products as you need to add sales orders, I think this is the best way to avoid an largest database size.

Kind regards

Agustín

[former_member631464]

Hi,

Theoretically, we would need a total of 10 billion item codes, but we sell about 500 items per year, so we could probably add new ones when we need to sell them. The only problem would be keeping those items up to date. For instance if the price for a specific option increases, we would have to go through every item code that has that option and update it.

This is the reason I wanted to write an application that would create and maintain those item codes. The initial idea was to have it generate all of them at once, but I guess that I could haveitgenerate part numbers on demand. Is that what you are suggesting?


Sincerely,
Matthias

[Johan_H]

Hi,

If using the DI API is an option for you, then one solution that comes to mind is using the production module. However it all depends on a few key questions:

1. how many different base products do you have?
2. are variants common between base products?
3. are options common between variants?
4. how many different completely configured products do you need to keep in stock simultaneously (maximum)?

Regards,

Johan

[former_member631464]

Hi Johan,

Thanks for your answer.

• how many different base products do you have

We have about 15 configurable products that are currently spread across 80 item codes.

• are variants common between base products?

It depends on supplier of the product though I can point out a couple of variant that should apply to every base product.

• are options common between variants?

Not really, they are pretty specific to each variant.

• how many different completely configured products do you need to keep in stock simultaneously (maximum)?

Those items are generally not meant to be stocked. The ones we have are mainly the result of returns.

You mentioned the production module, as we only resell items, I'm not very familiar with it. How would you use it ? Create BOMs for every base item ?

Regards,

Matthias

[Johan_H]

Hi Matthias,

So if I understand your scenario correctly:

• You have some 15 base products.
• You have some 10 variants per product.
• Some variants are common between base products
• You have some 8 options per variant
• Your stock turnover is pretty much immediate.
• You may get some returns sometimes.

Production in B1 is reasonably straightforward. You create a Bill Of Materials (BOM), a recipe if you will, and then your create a production order with which you create stock of an item according to that recipe, that BOM. It is just a tool that allows you to combine items into another item. You do not need to actually build a factory 😉 We too are a reseller, and use it to create displays for example, allowing us to sell a display to a customer filled with products. Please create a test company database based on the most recent backup of your production company database, and just play around with the Production module. You'll see it is quite easy to use.

Basically what I would suggest to solve your problem is the following:

1. Create two items for each base product. One is the regular item, and you use the other to handle any return stock. That makes about 30 items. This assumes that you negate the returned stock before the base product is returned again with a different configuration (read on, and you will see what I mean). Otherwise you may need to create 3 or more items per base product.
2. Create as many items as there are unique variants. With common variants lets say that makes 120 items.
3. Create as many items as there are unique options. That should make about 960 items
4. That makes for a total of 1000 to 2000 items, which is no problem for B1 whatsoever (we are running with about 30.000 items, and no problems)
5. Build an interface that allows you to configure a product as needed, by combining a base product with one of its variants and the relevant options. You can make this interface so that you can always only select the correct variants and options, based on the base product.
6. Using the DI API you would then:
7. Create (or edit to be more precise) a BOM to match the configuration you just created, where the base product is the father item.
8. Create a production order
9. Consume the production order. You now have stock for the base item
10. Create a sales order, add the base item you just created stock for, and change the description as needed
11. Then:
12. Deliver the configured product

To make your work easier, you could even create a couple of user defined tables to store common BOMs in, so you can simply pick such a BOM, instead of configuring one from scratch each time. You could even save each new configuration to those tables, so you can simply pick the one you need. If these tables start to have too many records, you can just wipe them clean.

In case of returns, you book that stock to one of the "backup" items, and rename that item to describe the base product, variant and options in question (or describe all that in the comments field of the item).

Regards,

Johan