Posts Tagged ‘receiving’

• Inventory Control Operations and Transactions

  While writing the prior posts about the 10 Second Rule in inventory control, I started thinking about our end-users and the forms they use to operate our software. Imagine that we could gather every inventory control system ever written by DataWorks (and while we are at it let’s toss in every AR, AP, GL, Payroll or ERP application ever programed by any software company) into a huge vat of creamy digital goodness.

  Then using a yet-to-be-invented silicon-spatula, we would pry the user interfaces from these systems into a giant pile of one-dimensional pelts.

  Next we would rake these skinned bits into the intake scoop of a yet-to-be-invented silicon-shaking machine. After clicking the OK button, we would adjust the lumbar support of  our Herman Miller Aeron chair (mine’s black),  and watch as the mythical machine shakes and sifts the leafy bits though various mesh screens. Eventually all the input will be sorted into five unequal mounds of output. In order of their height and weight the piles would be grouped like this (you may not like the names of the piles, but this is my made-up machine, so these are my made-up names) :

  1. Confirm & Comfort – Little crumbs of programing chaff  that ask yes-no questions,  tell the user that something is happening (Hour Glass or Thermometer Bar), or will happen – once they click the  “OK” button.  These forms generate comfort to the end user – they let you know the software is working away on something, they ask a question to make sure you really want to change all the prices of the beanie babies to 19 cents. They add some flavor to the system, but they don’t really do much. They are the cranberry laced croutons of a much bigger salad.
  2. Configure & Forget- rarely used after initial setup. Super simple to program. If you have seen one you have seen them all. (i.e. System Defaults, Colors, Sizes, Units of Measure, Classes, Departments, Margin Plans, Ticket Type, Currencies, Languages, Addresses).
  3. Daily Maintenance – highly specialized forms that handle the heavy daily lifting of inventory. Lots of code.  Speed and flexibility are important.  (i.e Product Input, SKU definition, Cost Updates,  Price Changes.)
  4. Show & Tell – retrieves and organizes data for your viewing pleasure. This group includes screens used to select date ranges for running reports  and forms used for looking up a particular data set (i.e.  Product look up, Sales Audit review, Comparative Sales Reports,  Best – Worst Analysis,  In-Transit report,  Inventory shrink, General Ledger Batch)
  5. Transactional – an elite group or  highly trained, highly specialized forms,  used to record an inventory control action. These forms are the work horses within any inventory control system.  (i.e. Purchase Order, Receipt, Transfer, Markdown, Inventory Adjustment, Return to Vendor).  Lots of Code.  Lots of business logic.

  Read the rest of this entry »

  2010.01.14 / no responses / Category: Uncategorized

• 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.

  2009.11.30 / no responses / Category: Uncategorized