How many warehouses can we create in SAPB1

[leon_laikan]

Hi,

Our company is engaged in the shipchandling, i.e we supply goods to ships.

The particularity of this business is that ships can order practically anything from us. Most of the time, they order food and beverage items, but any unexpected item can crop up: a pet rabbit, a Buddha statue, a book, an anti bullet jacket - well anything you can or cannot imagine!

To use the Inventory Module of SAP B1 ver 8.81, we've got to code all stock items we sell, even if we sell once in a blue moon, which means theoretically an 'infinite' list.

I thought a lot about the problem. Really, don't know.

Our SAP consultant proposed an attractive idea:

Treat each incoming ship as a WAREHOUSE. All goods purchased for the ship would be put into this warehouse.

All deliveries would be deducted from this warehouse.

This would streamline and facilitate the work of all staff.

In addition, the accounts dept can easily ensure that all ships which have departed have their stocks zeroised.

My concern is:

If thousands of ships buying from us over the years, we must create thousands of WAREHOUSES, one for each ship!

It's not a problem for us, but ...

Is there any upper limit to the number of WAREHOUSES we can create in SAPB1?

Thanks a lot

Leon Lai

[Former Member]

Hi Leon Lai,

Glad you post question here. The consultant's solution is a big NO, NO. You can not do that. No matter if there are limits or not, it is not a solution but put your system in danger.

The warehouse must not be created like that. The best solution is to try Item Groups. That is the most efficient way to deal with it.

Thanks,

Gordon

[leon_laikan]

Hi Gordon,

Thanks for your reply.

I really don't know how to cope with my problem. So many constraints to meet!

I and our consultant have struggled with the problem for nearly 1 year.

And I have only 1 month left to implement inventory module.

You see..

(a) All our stocks are temporary stocks. Once a ship orders goods, we go shopping to obtain the goods for it.

(b) We stock the goods in our store. Once we get all the goods, we can deliver them to the ship.

(c) Our customers can order practically anything.

(d) A very long list of item codes can be confusing to work with both for the storekeeper and the invoicing clerk.

(e) Storekeeper has more risk of forgetting that a code already exists, and create a duplicate code.

(e) I need to zeroise the stock when the ship leaves. Because this is what we expect.

Once we have delivered all goods ordered, stock should be zero.

That's not a problem; I can always create a query to inform me which ships to zeroise.

(f) You proposed item groups, but will this solve the problems associated with the long list of item codes?

(g) We work like this:

We give a serial number to each ship which comes: 1500, 1501, 1502, etc. All transactions then refer to this code.

(h) Our consultant thinks he got an idea. He creates a warehouse with same names: 1500, 1501, 1502, etc

I just summarize the situation. If you have an idea, let me know. I'll post another thread!

I only want to ask you a question

If I create one warehouse for each ship, in what way can this put my system in danger?

Sorry for insisting. Your answer sent a nasty chill down my spine, and sent my heart racing.

This is the first time I am really terrified by your answer.

I was hoping the consultant's solution would be THE answer. All my hopes are shattered!

Best Regards

Leon Lai

Edited by: LEONLAI on Nov 23, 2011 7:49 PM

Edited by: LEONLAI on Nov 23, 2011 7:49 PM

[Former Member]

The fact is: System table for OITW is depending on WHS# X Item#. Suppose you have 1,000 whs and 10,000 items, you will have a 10,000,000 records in the table. It is a huge table. You may have more than the example number.

In you specific situation, I would suggest batch management plus reuse itemcode if possible.

[leon_laikan]

Hi Gordon,

Thanks a lot for your concern.

I am meditating on your answer, and studying the implications.

I may post another thread later.

Best Regards, and closing

Leon Lai