packing slip

Inventory Control Software- 10 Second Rule - Part 3

In version 7 of NeXT, scheduled for release in the 4th Quarter of 2010, we will be shuttling transactional processing off to a background service so that your current task can be released from pushing a thermometer bar across your screen.

Retail Inventory Control Operations - The 10 Second Rule - Part 1

Retail Inventory control operations have been DataWorks'  focus for the past 24 years. We design systems to assist buyers in creating purchase orders; receivers to process packing slips, auditors to review costs, and controllers to generate accounts payable invoices and credit memos.

One of our design tenets is that user input time on heavily-used-forms is very expensive - so we try to spend our CPU coin wisely.  If we can shave a half a second off a process, that half second gets multiplied by all our end-users doing the same process every single day.  A billion here, a billion there, pretty soon it adds up to whole lot of time for running reports, re-ordering fast movers, or dialing in a pizza.

Notice that our tenet has a condition - "Heavily-Used-Forms". If a form is used to launch a one time process or it is a rarely used configuration option, we don't spend our R&D budget on making the form into a high performance, code-injected hot rod.

Speed to save and process a transaction is of extreme importance. If a transaction takes over 10 seconds to save then the end-user's cranium shifts into idle and the neurons start filling their synaptic gaps with sudoku puzzles and we fail in our efforts to get more data for the price of one transaction.

The receiving transaction is the core of our inventory control operations -  It has a lots of moving parts and it generates a lot of transactional heat. When the receiver clicks on the process button, he or she is kicking off a big assembly line of linear processes:

  1. Accommodate Units of Measure, Currency Rates, Terms Discounts, Freight Charges, Cost Changes and Vendor Allowances
  2. Consider the employee's access rights and privileges
  3. Update Inventory Quantity On Hand, Quantity Received, and Status
  4. Flag an Item for the need to update the Stock Ledger *
  5. Update a Purchase Orders' Quantity On Order and Back Order Status
  6. Calculate Base Cost, Net Cost, and Landed Cost
  7. Update a log for any shifts in cost or retail
  8. If merchandise price tags are needed, generate a Ticket Batch
  9. If a Packing Slip, generate a General Ledger journal entry to book the Asset and PO-Clearing accounts
  10. If an Invoice, generate an Accounts payable Invoice with the appropriate distributions.
  11. If  allocating to more than one outlet, generate one or more Transfer-Outs.
  12. If Transfers are set to process in one step versus two, process one or more Transfer-Ins.

The bad news is this  gymnastic routine takes much longer than 10 seconds to stick. With large receipts of over a 100 SKUs just the calculation of new costs take longer than 10 seconds to execute.

By the way, the one thing that does not occur here is a posting to our Daily Inventory Summary system. Notice the special * above. We set a flag but we don't do any actual work. The summary table is a daily stock ledger that is used to track various pieces of information such as beginning on hand, net sales, discounts, receipts, returns, markdowns and shrink. We decided it would take too long to update the core of our analytical system. And since the stock ledger is not a requirement for daily operations we reasoned that it could wait and run at a later time.

This is actually a clue to our design thinking. Operational events are linear and need to occur in the users'  time frame;  analysis and data crunching are not time sensitive.  Analysis can run a minute, a hour,  a day or even be regenerated a year from now.

So how can we speed up operations but deal will the need for real time information?

That will be the subject of our next post.