2014-08-15 Agenda and Minutes

[jdpurdyvi]

Documentation - At what intervals should we refresh the doxygen folders, etc

[scannerdarkly]

Membership configuration — how should George Street Co-op set up CORE’s membership modules?

[jonkeim]

[typist's notes in brackets]

Present

• alvin (willy street), Andy (WFC), Call-in User 7 ( / John Leary / George Street Co-op), David & Kelly & Don (Harvest), Eric "flathat" Lee (West End Food Co-op), Jeff Haug - HoZt (Medford), joelbrock, John Purdy (Wedge Co-op), Rowan (Franklin Community), Jon (YFC; taking minutes)

streamline check tender @ checkout

• Rowan: [Sorry, Jon missed the actual question]
• use membership subsystem to issue non-members "approved for check writing accounts" (Ypsi doesn't take checks from non-members, and will probably start doing this for our list of non-member check writers)
• use ESC/POS (Epson printer language) to access built-in MICR reader somehow, process checks through POS?
• FirstData, (and other merchant processors?) offer check-scanners with varying guarantees of how likely a check is to not bounce. Per Andy they sometimes reject checks they don't need to, and/or have pretty high fees.

sales tax holiday

• Rowan: how to implement?
• Joel: cron job to swap between tax rates
• Harvest UPDATEs product table manually, changes back when over (automation wasn't worth it)

grocery delivery tender type

• Harvest: has Grocery delivery via InstaCart
• InstaCart has their own tender type, which correctly prompts for manager approval
• need it to also record InstaCart's Order Number, ideally via a 2nd prompt
• potential data validation: typically an [x]-digit number
• [verify?] store gets notified of incoming orders via instacart iphone app; could read pending txn #s from InstaCart [somewhere], present a pick-list of only pending txns to cashier

Documentation

• John Purdy: schedule a doxygen run along w/ each release?
• also when adding in new modules, making other major code changes

Version string in core somewhere?

• Jon: something like a "Help --> About" menu, just to jog a sysadmin's addled mind as to what release they're running
• nothing fancy; update by hand
• Andy: simple text file with nothing but a version it it might be ideal

Further Versioning topics

• John Leary:
  • are fannie and lane versioned together, or can one upgrade them independently?
  • Developed and released together. May make sense in some cases to track master on lanes, fannieDevelop on server
  • Effort is made to work around database columns that may not've been added at a particular site yet. Most important part may be to keep server & lane data schema in sync [confirm?]
  • [Jon: the back end is fannie, but do we have an official name for the lane component? "CORE:POS" or somesuch?]
  • standards for version number incrementing?
  • Andy: software as a whole moving away from encoding significant information in version number; can be easy to miss, and major changes to functionality need to be obvious in release notes anyway.

Membership subsystem extravaganza

• John Leary: lots of member functionality; which ones should we use?
  • Contact Info & Member Types are 2 critical components, most other is optional
• Andy: two reasons for separate modules:
  • some of them are optional
  • to arrange input boxes on screen
• Eric / flathat: we use SugarCRM to manage membership renewals over the web, a cron job sync between the two
  • can do two-way sync
  • John Leary: We want to do that, but need to manage households as well
  • Andy (WFC): "[cron jobs are] all run via FannieTask - i.e., php FannieTask.php SomeTaskName"
  • Andy (WFC): "it makes generating the cron commands easier because they're consistent"
• John Leary: two ways of earning membership George Street
  • pay for it
  • sweat equity - currently could be tracked as a separate equity type, as hours "sales"; no volunteer hours-tracking / timesheet plugin yet
• John Leary: is it safe to turn on all of the membership modules, will they interfere with each other?
  • two kinds of membership modules:
  • anything on fannie/install/InstallMembershipPage.php is more or less an interface module, doesn't do anything major to the back-end database; should be safe enough to turn on all modules. Eric: just make sure you have one test member w/ data for every module you enable
  • anything membership-related on fannie/install/InstallPluginsPage.php has the potential to change around your database, and should be enabled w/ more care
• architecture
  • member data flows server --> lanes
  • equity flows lanes --> server (naturally, via dtransactions)
  • could write a plugin for setting up skeleton members @ lanes, but subject to data entry error, syncing problems, etc
• typical workflow
  • pre-issue batches of member numbers
  • pre-print member cards, signup forms, or stickers
  • leave these at lanes so cashiers know what numbers are available for new members
  • members are then properly associated with their own member number from day 1, tracking equity and patronage cleanly

[roberski]

My original question was about if anyone had done anything with MCIR readers around detecting bad checks. Harvest & WFC go though first data to authenticate with a stand alone device. We also discussed the legal and technical ramifications of a way to keep a list of bad checking account numbers and check against it from a reader.

[DavidHermann]

sales tax holiday

...

Harvest UPDATEs product table manually, changes back when over (automation wasn't worth it)

Sorry if I wasn't clear: Harvest updates tiny table taxrates manually, not table products. Items remain flagged as eligible for sales tax, but the sales tax percentage in column rate is 0 (zero) during the tax holiday.

David Hermann

Database Programmer

Harvest Co-op Markets

(617) 874-5134

dhermann@harvest.coop

From: Rowan Oberski [mailto:notifications@github.com] Sent: Friday, August 15, 2014 2:21 PM To: CORE-POS/IS4C Subject: Re: [IS4C] 2014-08-15 Agenda and Minutes (#394)

My original question was about if anyone had done anything with MCIR readers around detecting bad checks. Harvest & WFC go though first data to authenticate with a stand alone device. We also discussed the legal and technical ramifications of a way to keep a list of bad checking account numbers and check against it from a reader.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/394#issuecomment-52340449 . https://github.com/notifications/beacon/1864398__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyMzc0NjA2NCwiZGF0YSI6eyJpZCI6Mzk2MjM5MzV9fQ==--e689a04a539e51b543cf25d7471ad7d5db6751db.gif

[gohanman]

On the versioning & naming subject: I usually just call the lane part "lane" or "pos".

Regarding database columns, the front and back don't necessarily have to be in sync. Crashing because the schema isn't what's expected is wrong, period. If a column only exists on the server and not on the lanes, a feature relying on that column might not work but it should not-work gracefully not catastrophically.

[flathat]

WEFC_Toronto uses CiviCRM, not SugarCRM. The cron job members.sync.with.Civcrm.php is described in #401.

[gohanman]

Version file: e2518803c37773bc00813af8660c2c025b62acb4