Our "On Hand" warehouse inventory is not adding up correctly. This is a wide-spread problem in our system.
We are running on Baan IVc3, Informix, WinNT.

Our situation is as follows:
===================================================================================================

Item Master (tiitm0101m000 - Maintain Item Data - form 2)

Inventory on Hand (stoc) - 570.0000
Inventory on Hold (blck) - 0.0000
Inventory on Order (ordr) - 0.0000
Allocated Inventory (allo) - 173.0000
Quotation Allocations (quot) - 0.0000
Economic Stock - 397.0000
===================================================================================================

Warehouse Inventory (tdinv0510m000 - Display Warehouse Inventory by Item)

Wrh On Hand On Order Allocated Econ Stock On Hold Hard Alloc
cwar stoc ordr allo calculated blck hall
--- --------- -------- --------- ---------- ------- ----------
C3 408.0000 0.0000 85.0000 323.0000 0.0000 0.0000
001 0.0000 0.0000 -5.0000 5.0000 0.0000 0.0000
--------------------------------------------------------------------------------------------------
Totals 570.0000 0.0000 173.0000 397.0000 0.0000 0.0000

As a note in unsual programming approaches, Baan gets these totals from tiitm001 instead of being calculated totals from the values in tdinv001!!!
===================================================================================================

As you can see, the "On Hand" from the 2 warehouses, does not add up properly.
These values should match for all products. In many cases they don't.

My questions are as follows:

1) What causes this?
2) How to stop it from happening?
3) How do we fix our current data to reflect the correct numbers without messing up anything else?
4) Should we be looking at the possibility of running correction programs as follows:
a) tdinv0250m000 - Rebuild Planned Inventory Transactions
b) tdinv0251m000 - Rebuild 'Allocated for Picking List'
c) tdinv0252m000 - Check Inventory Data
5) What would be the ramifications of running these correction programs?
6) Is there a better way to resolve this?


Any assistance would be greatly appreciated.

Dear Ron,

BaanERP is usually quite stable on this issue. The only time I've seen such things as this happened was when a consultant customised someone else's BaanERP untidily. So, do you have any customisation made to your BaanERP distribution routines (things like customisation to accomodate barcode integration, etc.) ? If yes, then you might want to look deep into them and make sure that they are "tidy" customisation

Rgds,
Paul

Hi Paul,

Thank you for responding so quickly. This really is a great site!

Regarding our problem; unfortunately we are running Baan IVc3 "out of the box". When looking at customizations, the costs were prohibitive and the returns low so we didn't pursue that avenue. We have some minor screen changes (moved fields from one tab to another etc...), and some extra fields that are for reference only (no coding to "do" anything). We have created sessions that do some reporting (inquiry stuff only), but there is no data manipulation.

I am thinking it may have something to do with the way the data is stored and retrieved. Currently Baan is working on a problem for us (posted call in Jul 2002 - and still going....) that involves scientific notation generated from an exchange scheme. The import from that exchange scheme can't read what the export created (neat huh?). If the same technology for storing the data is used in other Baan functions, it could mean we have a much larger problem on our hands than we know. It could mean there are many other errors we are just not yet aware of! I hope not!

Are there any other possible causes? Our only other option seems to be to have a script written to "correct" these values. The problem with this approach is obvious in that there would be more than just one table to update (as is normal in Baan). We would have to make sure we identified ALL tables that need to be examined and updated. The script would have to run regularly (perhaps as a job) to maintain data integrity. This is not what we had in mind when we purchased Baan but we are starting to run out of alternatives.

are you upto date as far as the Baan solutions are concerned ??
Baanc3 out of the box comes with inventory errors (inventory not kept in synch across the system).

I had similar problems when on BaanIVb4, but not just IOH, also allocated/blocked qty's were not correct.

What I did was:
For a warehouse/location/lot that I knew the inv was off - I would use the history sessions to trace back when the inv "went bad" which would give me the transaction that caused the problem. In my case it was the DDC ineventory transactions and regular sessions.

If this root cause fails. Then do some testing with all sessions that modify the IOH - sales deliveries/purchase receipts/ etc....
Also you may be using DDC's etc so test them also.

I do use the tdinv0252m000 session to synch up the tables ( I am now on another system other than the b4).
This session takes the tdltc001 (if lots used) and updates the parents being the tdilc001/tdinv001/tiitm001

if lots are not used then the tdilc001 data will update the parents being the tdinv001/tiitm001

Hi,
we had similar problems when we were on b2 three years ago. Running tdinv0252m000 usually solved the problems, so we run it every weekend in a job.
Things improved dramatically since we are on c4: no error since running this release.

Best regards

Martin

O, sorry, Ron. As you can see in my profile I started up with BaanIV 4.0c4, where all the problems were solved as Martin said :o .

Rgds,
Paul

Hi guys,

Well I ran the correction programs to resolve the imbalances (tdinv0250m000, tdinv0252m000) which seems to have done the trick.

It seems to me that a major enterprise package such as Baan that touts it's package as capable of tracking inventory, should be able to do it correctly. Maybe it is just another Baanism (a pet-name we have given to these annoying program bugs that tend to rarely be repaired by the company). I hate it when they call it "standard functionality" and fluff it off from the support desk. They still do that WAY TOO MUCH. They haven't even fixed a Y2K bug I found that directly affects us! Oh well.... I'll stop ranting about Baan now....

Thanks again for all your help. It got us over the current hump. Does anyone know of a way to stop the numbers from going out other than running the correction programs as a regular job?

Hi Ron,

we felt quite similar as you do (about standard software and it's quality), when we detected inventory handling problems within the b2 release.
You mentioned that you're running Baan right out of the box. Did you ever take an upgrade to c4 into consideration? We know, that "quantity handling" and other related things have been redesigned in this release. A lot of european customers are running c4 due to the Euro. So it's a widespread and very well tested (by the customers ;) ) release.
For somebody who's running c3 without any customizations it shouldn't be a gerat deal to upgrade.

Best regards,

Martin

Dear all,

We suffered more than 3 years with this baan "problem". I mean gaps between tdinv001 and tdilc101.......

We did air freigth shipments $$$$ because of this !!!

Why..... Because shortage report became false to items involved with this #@%&*#@?;!? of BaaN...

The solution adpted was run tdinv0252m000 daily in JOB.
Things improved dramatically too as Martin Jung experience...

Best regards, Gustavo

what exactly does tdinv0251m000 - Rebuild 'Allocated for Picking List' do ??

I did a bic_info on this and it appears as only the tdinv001/tipcs021 tables get updated.....what about the allocated qty at the tiitm001/tdilc101/tdltc001 levels ?

The picking list (tdsls4402m000) checks the available stock on warehouse level. But there was no way it could determine which orders were already using the stock, so the field alpl was introduced. For each itemline for which a picking list was printed the alpl field was recalculated, so for the next itemline for the same item the program could take this "reservation" into account.

If you are using this functionality (like we do), you should make sure you have the latest solutions installed for tdsls4402m000 and for tdinv0251m000 (and maybe some other related sessions) since even the correction program tdinv0251m000 needed a solution because it did calcuate the wrong allocation.

Regards,
Klaas