On-hand inventory with CORE tools

[flathat]

I'm getting ready for an on-hand inventory (distinguished from "perpetual inventory") this coming Thursday and want to do as much as possible with Fannie tools, beginning with those in the Shelf Audit plugin. I thought I'd describe here what I'm doing as I go along.

I like SaReportPage.php because it reports the results of input from SaScanningPage basically in real time. Our previous inventory method required a couple other load and merge steps before a report like this was available. We'll see how much the "real time" aspect matters in the heat of capturing the data, but I can't see it not being nice to have it all there right away once the capture is done.

I will be changing the SaReportPage a bit to total cost instead of price, and may, if I have time, write something to display it per-department or per-section.

There are two capture interfaces that display compact screens suitable for portable devices.

The earlier interface is SaScanningPage, looks like: and makes a separate record in shelfaudit.sa_inventory for each scan/entry.

(The first issue, see #676 that came up had to do with changing SaScanningPage.php to support the configuration of the handheld scanner we usually use.)

The later interface is SaHandheldPage which looks like: about which its author (of both) @gohanman has commented:

the only real gotcha is it's additive (scan an item and enter 2, scan the same item and enter 5, your total is now 7). For us this is the easiest way to deal with stuff that's stocked in more than one place but making corrections after bad entries requires entering negative numbers.

These both write to the same table. I've learned that it is necessary to use one or the other because SaHandheldPage does not handle multiple records for an item well. My preference, based only on some short trials, is for the older SaScanningPage because the real-time report also supports deletion of mistakes. We'll see what I think after a real world experience.

One of the issues we have to deal with is items on the shelf that don't have barcodes. We make paper lists of these, with barcodes, scan the barcode and enter the count. I adapted Fannie's batch and shelf-tag apparatus to make these pages. I:

• Made a ShelfTagQueues record for each superdept that has items that need this treatment.
• Used Item Maintenance > Product List and Tool to populate it with whole departments of items.
• Wrote a shelftag format that looks like:

Our process will probably be to hand-enter the count from the shelf, verify it, and then scan the barcode and enter the number in SaScanningPage, and tick "Entered".

[gohanman]

It's a good point that the two entry tools treat the underlying table differently and probably should not be used at the same time. I personally don't find the report's deletion option all that useful because it's really difficult to work with on a handheld device's screen (or at least our iPod sized screens). Negating previous entries is definitely less intuitive but it fits on screen.

The CSV export will give you totals by both price & cost. I didn't bother changing the web version since the spreadsheet is ultimately what gets saved.

I did not write SaScanningPage.php. That, the report, and the table structure were a Wedge contribution.

[gohanman]

Related: I recently added a storeID column to the sa_inventory table to support concurrent counting in both buildings. I think this (fa37b59e642c6efbc348bcf5fbb98582fa2a5bf5) will set the storeID to zero for entries from either scanner and always report on storeID zero in single store mode.

The catch is unlike many schema upgrade the column isn't optional. This is basically the same as issue #655. Letting models inspect the table structure and format INSERTs/UPDATEs to match is great for compatibility but takes extra time. And this is an application where speed is directly related to usefulness.