2014-08-01 meeting minutes

[jonkeim]

Present:

• Andy (WFC), Alvin (Willy Street), John Leary (George Street), David & Kelly & Don (Harvest), Eric "flathat" Lee, Jeff Haug (HoZt) Medford, Joel Brock, John Purdy (Wedge Co-op), Jon (YFC) (taking minutes)

BADSCANs

• John Leary: Can we do data entry to fix badscans at the lane?
• Not diretcly
• issues w/ implementation:
  • technical: no mechanism for pushing item updates from the lanes back up to the back-end
  • joelbrock: cashiers don't know how to price items / lots of needed fields: price, description, tax, cost, subdept, FS, scalable, etc. / scanning the entire store is a NECESARRY step / keep a list at the register for cashiers to record products that don't scan. review that list once/week
• workarounds
  • have a back-end computer nearby w/ a USB UPC scanner (useful for all sorts of other fixes too)
  • have a Fannie tab open on lane (would still need a USB UPC scanner if you want to avoid hand-keying UPCs)
  • look at department open ring that (usually) immediately follows a badscan for hints on what it is
  • cashiers can use the "Note" key to add hints as well
  • future: enhance the "Item Not Recognized" error dialog to accept price, department, and description for a "quasi-open-ring"

[jonkeim]

Sorry I was late. Anyone else have notes from earlier? Eh-heh.

(My wife and I juuuust finished buying a house. We are running a little behind on other things.)

[gohanman]

I'm thinking it may make sense to just have a replaceable API module at the "item not found" point. CORE could provide a couple different out of the box and plugins could provide even more options. There's probably room for reasonable disagreement on exactly how much information cashiers should enter at that point and balancing getting details vs speed of transaction.

Also discussed:

• Havest idea: deriving lane number for IP Address * Main idea is to have an array of all known IP => lane number combinations in ini.php so that file can be copied from lane to lane without edits * I still think most of the configuration should live in the parameters table, but this seems like a sound idea. The lane needs a unique identifier and manually applying one does wind up being an extra step \ Main challenges: how to consistently find non-loopback IP address
• Donation functionality * CORE currently supports a round up (RU) function. This adds an amount to bring the total to the next even dollar. It also supports arbitrary amounts (e.g., 500RU) * Willy Street uses a percentage option (e.g., donate 1% of total). \ No real strong preference for one way or the other

[gohanman]

Lane IP detection implementation: e31e675f687150c7d7991a3dc3645b8b9a1fc8e3

[scannerdarkly]

I very much like the idea of a replaceable module for "item not found".

Regarding Harvest's idea: If the IP can’t be determined, could you hash the MAC address to get a lane number? Or hash the hostname? I wasn’t on for that part of the conversation, so I don’t know if that would be helpful.

[gohanman]

One's not really more easily determined than the other. If you can't determine the IP you almost certainly can't determine the MAC address. The hostname may be usable although hashing it doesn't make much sense. It just makes reading and writing the configuration harder (from a human standpoint).

On Thu, Aug 7, 2014 at 5:54 PM, John Leary notifications@github.com wrote:

I very much like the idea of a replaceable module for "item not found".

Regarding Harvest's idea: If the IP can’t be determined, could you hash the MAC address to get a lane number? Or hash the hostname? I wasn’t on for that part of the conversation, so I don’t know if that would be helpful.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/382#issuecomment-51543434.

[gohanman]

API class so item not found behavior can be customized: b4625da103948173626c1c444eedac9801ad8f62