Call Agenda 30May14

[gohanman]

Primary discussion topic is multistore item management. We plan to use screenshare to look at how some existing systems work.

Summary of some methodologies discussed:

1. One record per-product per-store. This approach is in use at Harvest.
2. One master record per product, plus an additional per-store record. This is an approximation of what SMS does. Its approach sounds more denormalized than CORE but that's outside the scope of representing per-store customizations to products.
3. One master table of all products with one record per product, and one supplementary table at each store representing products sold in that store. This is the approach used by Counter Point.
4. One master record per product, plus an additional per-store record only if customizations are needed. This was my own initial suggestion and it can probably be dismissed. There's deduplication, but disk space is cheap and it's not that much data to justify the extra complexity. The other three approaches have all been used successfully in real operations, too.

---

I find (3) appealing aesthetically, although it adds some minor backend complexity. A server would need to know whether or not it's the master to determine where to save its edits. Using per product, per store records each store could simply be assigned an ID and always edit the appropriate record.

[chaploeb]

My apologies for missing the call today-- I had planned to show Counterpoint's item schema along with some external tools used by Weavers Way to handle certain per-store issues. An offsite meeting I was in with our management team ran much longer than expected and I'm just getting back to my desk now-- my apologies for not being able to present today. If possible I'd love to hear a brief summary of where we went with this today, and I can promise to be available for the next call if people still want to see our stuff.

[gohanman]

Not a problem. I brought #352 to everyone's attention. It has become less pressing for me as some internal projects changed shape, but I think it's still worth getting opinions on what an ideal membership structure should look like. @DavidHermann suggested that decoupling discount from member type with a table of valid discounts and foreign keys to each in the membership record.

We talked extensively about a company Harvest is dealing with called Instacart that is a personal shopping service. Members [of Harvest] tell Instacart what they want, freelancers loosely associated with Instacart pick it up and deliver it. Notable wrinkles:

• Instacart does allow users to submit membership information so the actual shoppers can identify themselves as the member at checkout
• Harvest reports retail prices to Instacart. Users are billed based on this price, not the actual price at purchase with any membership benefits applied
• Harvest wants to mark these transaction with the correct member number for patronage purposes, but also wants to be able to identify them as Instacart. I'm not clear on the exact fee structure, but reconciling what Instacart says they purchased with POS is important.

The solution we ultimately settled on was adding a comment to the transaction as an Instacart tag but otherwise ringing it up under the member's account. I don't think it's ideal but the situation is tricky.

[chaploeb]

Thanks for the recap, especially of the Instacart conversation (we've been talking about working with them, so hearing what Harvest is running into is really helpful).

[roberski]

Wow, I totally spaced this one. Thanks for the write up.