This article is an excerpt from the book Inventory Accuracy: People, Processes, & Technology

?/P>

"That's impossible!"

"How can we have negative inventory?"

"How can you have less than nothing?"

"Is it like a black hole, sucking inventory into it before the inventory even exists?"

"Is negative inventory like anti-matter? If it comes in contact with positive inventory, will it create a fracture in the time-space continuum?"?

Yes trekkies, I've heard them all.

People can get rather excited over negative inventory because the concept seems so ridiculous. Surprisingly, negative inventory is a very common occurrence and may even be a "normal" part of some processes. Though negative inventory balances certainly reflect some type of problem, it should not be assumed that you must manually adjust inventory up to "fix it." In many cases, negative inventory is simply a timing issue. For example, if materials are coming right out of manufacturing and into an outbound shipment, the shipment transaction may be completed before the production-reporting transaction if the production run is still in process. This will result in a temporary negative balance until the production quantity is reported. While it would be nice to have had the production quantity reported prior to the materials being moved to shipping, there is no real harm being done here. When the production is finally reported (hopefully later that same day) the quantities will all be fine.

Transaction timing is certainly not the only cause for negative inventory balances. Any transaction that affects on-hand balances can create a negative inventory balance if the transaction is incorrectly executed. It's important to be able to make a distinction between negative balances caused by timing issues and those caused by transaction errors. It's also important to make a distinction between location-level negative balances and item-level negative balances.

?/P>

Location-level negative balances.

A location-level negative balance occurs when an incorrect location is used in a transaction or when an incorrect quantity is transferred in a location transfer transaction. For example, if I had 100 pieces of an item stored in location "X" and picked 50 pieces for a shipping order but mistakenly issued the material from location "Y"; the end result would be 100 still showing in location "X" and -50 showing in location "Y." Though I now have a negative balance in location "Y," my item-level inventory balance of 50 pieces (the sum of location level inventories) is actually correct. A similar situation occurs when you transfer inventory from one location to another and enter an incorrect "from location" or enter a quantity greater than was actually moved. For example, if I had 100 pieces of an item stored in location "X" and moved the entire 100 pieces to location "Z," but mistakenly entered a quantity of 1,000, the end result would be 1,000 showing in location "Z" and -900 showing in location "X." Once again, my item level inventory balance of 100 is still correct. Though these location-level balances will create problems in the warehouse, they should not be causing problems with planning systems.

Item-level negative balances

Item-level negative balances, on the other hand, may be affecting planning system. These can occur from a variety of transactional mistakes. Over-reporting scrap quantities, cycle count adjustment errors, over-reporting production when using backflushing, overissuing materials to production, duplicate transactions, and overissuing inventory to shipping orders are just some examples of errors that can create item-level negative balances.

Correcting negative balances

The reason it's so important to make the distinction as to the type of negative balance (timing, location-level, or item-level) is to ensure that your subsequent actions to "correct" the negative balance don't result in more serious inventory problems. If you were to adjust up a negative balance caused by a timing issue, you would create an inventory problem since, once the other transaction goes through, you will now be overstating your inventory by the amount of the adjustment. The same is true if you were to adjust up a negative location-level balance. Where your item-level balance was previously accurate, your adjustment would now result in overstatement of your item-level inventory.

Item-level negative balances not related to timing issues should also be carefully investigated before taking any actions. Usually you will want to identify the transaction that caused the negative balance and use the same transaction program to enter an offsetting transaction. This is especially true in manufacturing environments since the incorrectly executed transaction may have also created errors with other items (such as with backflushing transactions).

Despite the seemingly complex aspects of negative inventory balances, they are actually very easy to manage. They are easy to identify since all you need is a report that shows any items with a quantity on hand less than zero. In addition, it is usually very easy to track down the source of the error since the errant transaction is usually the transaction that brought the inventory balance below zero (if not, it very likely occurred within a very short timeframe prior to the negative balance being created).

Negative inventory effects on planning systems.

In addition to understanding the sources of negative inventory balances, it's also very important to understand their effects on planning and execution systems. In most planning systems, a negative item-level balance is treated the same as positive demand. Basically your system will tell you to make or buy more to offset the negative balance. Obviously this is a problem when a large negative balance occurs but can also create serious problems with small negative balances under certain conditions. For example, if you have an item that is set up as an "order as needed" item, meaning that you do not want to order or stock any unless you have actual demand (orders), an errant adjustment that drives the balance to   -5 will result in a recommended buy of 5 pieces. Since "order as needed" is often associated with very slow moving or obsolete items, you may have just added to an obsolescence problem. In a manufacturing environment using MRP, a negative balance of a single end-item, will result in demand cascading throughout the bill of material structure, potentially resulting in unnecessary orders for hundreds of lower-level items. This is what occurs if your system handles negative balances as would normally be expected. Some programs, either purposely or due to poor programming practices, may not execute properly if they encounter a negative balance. They may ignore the records with negative balances or simply "blow up" because they weren't designed to incorporate negative balances into their calculations.

Though there are valid reasons for not wanting a program to execute if it encounters a negative balance, there are also potential problems with this logic. You may actually need to take action, but because the calculations were suspended due to a negative balance, you did not get the information needed to initiate an action. Due to the complexities of demand-planning systems, especially MRP/DRP systems, there is no "best" way to handle negative balances within the programming. Execution systems such as warehouse management systems and manufacturing execution systems can also have problems with negative balances. While you may not be willing to modify your systems to handle negative balances in a specific way, you should at least understand what your systems are doing when they encounter negative balances.

Ultimately, avoidance of negative balances in the first place is the best solution. However, since perfection is pretty tough to achieve, you should have a backup plan. Since most planning systems still operate in batch mode (run nightly or on weekends) you can eliminate conflicts by resolving all negative balances prior to running these programs. With execution systems that are more likely to run real-time, you don't have this same luxury. Fortunately, the impact on execution systems is generally less dramatic than on planning systems.

I'd once more like to emphasize the importance of thinking through your actions when trying to "fix" negative balances. A "run the report and adjust them all up" mentality will most certainly cause problems. Remember, you should not make adjustments to timing-related negative balances, you should only correct location-level problems with a location transfer program, and you should try to correct other negative balances by entering an offsetting transaction in the same program that created the problem.