Comment 12 for bug 1777675

Basically, have a single inventory date stored but in such a way that it
does not preclude later development to retain all inventory dates?

J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 150
Atlanta, GA 30045

404.235.7128 Office
404.548.4241 Cell
404.235.7201 FAX

On Fri, Jul 13, 2018 at 4:07 PM, Mike Rylander <email address hidden> wrote:

> Thanks, Elaine!
>
> WRT inventory history, one problem with looking at the historical scan
> date alone, including just the "last" inventory time, is that without
> some sort of session and physical locality concepts to provide grouping,
> it can quickly become very difficult to identify (and even to analyze,
> short of some time-series visualization where a human looks at the peaks
> on a graph) when scans are nominally "concurrent" for an inventory
> process.
>
> It's certainly useful to see that a copy has not been inventory-scanned
> within the last year and its status is Available, but things become
> murky when you want to see the state of the collection in real-time. If
> the scanning process, for a particularly large or particularly
> understaffed library, or even just particularly unlucky library, takes a
> while to complete -- perhaps done over the course of a few months --
> then during that time you can't really use "last scan time" alone
> reliably to indicate presence or lack thereof.
>
> The fact that those situations can't be reasonably covered by the
> simpler proposed feature does not mean I'm against the simpler feature
> existing, it's that I don't want the simpler feature to make the fuller
> feature significantly harder to engineer down the road by having to take
> the existence of fields (for reporting, etc) into account in a future
> implementation. If we make a reasonable guess about how just the data
> we need now would fit into a more full implementation, we can make our
> future selves happier.
>
> (I can reiterate my database-level concerns more if that's unclear, but
> they require some preexisting understanding of how PG works internally.
> This bug probably isn't the forum for a PG-internals workshop -- I've
> provided tangents enough thus far. ;) )
>
> [As a side note, with historical scans you can, at least to an
> approximation, investigate the collection by each run's bounding dates
> to see changes over time, such as identifying sub-collections with more
> "stock lossage" as a percentage of the part or the whole. That may not
> be important for annual reporting, but it seems it could be important
> for placement and security.
>
> Of course, with the appropriate run and collection grouping mechanisms
> of the full proposal (granted, the cost is non-trivial) those sorts of
> reports and analyses are both natural and well-defined.]
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: <email address hidden>
> https://bugs.launchpad.net/bugs/1777675
>
> Title:
> Support for inventory date
>
> Status in Evergreen:
> New
>
> Bug description:
> Evergreen should have support for inventory date and workstation
> fields in the asset.copy table. Dedicated inventory fields would
> facilitate the process of performing inventory on a library's
> collection and can also be leveraged for potential future development
> of a full inventory module.
>
> We propose adding the current date and workstation to these fields in
> the following places:
> - From the check in screen using a check in modifier.
> - From the item status screen
>
> Full requirements for this enhancement are available at
> http://masslnc.org/node/3379.
>
> The MassLNC Evergreen Development Initiative is working with Catalyte
> on this project.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1777675/+subscriptions
>