Prices of items in a Co-op Deals BOGO group

[flathat]

• Version of CORE? Current

• Issue with Office, Lane, or both? Office

• Is this [mostly] a bug report, feature request, or question? Question

I'm relatively new to Co-op Deals uploads generally and am just getting familiar with the new BOGO items. In the recent commits to support these it seems to be assumed that all the items within a given BOGO code have the same price. My understanding so far is that you can't assume that. In the sample upload file NCG supplied most but not all items in a given BOGO, e.g. BOGO2, have the same cost, and the FAQ says the store's regular price should be used. I don't see, but perhaps am missing, a price regularization or some other way around this.

[gohanman]

It's a good question. I believe since each item is priced at 2 for {it's own price}, it'll work out that every 2nd item in a set will ring up for free. But I do need to test this out still.

In some sense it's not really optimized for the store (cheaper is the free one), or the customer (more expensive is the free one), but as long as they're only doing this with similar cost items it should average out OK.

Also FYI since it's a work in progress: I'm guessing the CoopDealsBogos table may need some additions to manage cleaning out old entries and/or differentiate current and future. I'll have a better handle on that once I see another couple months of deals.

[gohanman]

After testing, it does work as suggested in the previous post. Every 2nd item in a set will ring up as free.

---

I took a crack at "cheaper is free" here a03b49e5b929388408a136ec736b31b618213a2b. It's a bit of a mixed bag. Say there's a pair of items for $1.79 and $1.99. If rung in that order, the first rings up for $1.79 and the second for $0.20 - in effect, only the second item is being paid for. That's explicable, but maybe not ideal that neither line is free in a more obvious way. It's also still not fully independent of ring order since it's only comparing the prices of the current pair of items. I'm not sure it's worthwhile trying to shoehorn something that re-evaluates the entire transactions for all pairs into the existing price method. I suspect it'd quickly get hard to explain what's happening.

I'm not sure which approach is better, but the relevant bit to turn it on/off: https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/lib/Scanning/PriceMethods/QttyEnforcedGroupPM.php#L168-L186

[gohanman]

Another option: 9bfddc215d5dc19caa4eaa1bc0e401b32d59192d

This is very much single-purpose functionality and isn't going to interact with complexities like member-only pricing, but should be logically sound for always giving the same total regardless of the order the items were entered. It does this by repricing every applicable item on each applicable ring. This is definitely not standard practice, but I think the use case is narrow enough to be confident the results are accurate.

[flathat]

My first idea on this, before I found your approach, was to use a House Coupon of Discount Type "BOGO (Qty Limited)" for each of the BOGO groups. I haven't done a test implementation but it seems like it would handle mixed prices. Outside the Co-op Deals framework though, which may be more of a problem than I'm aware of yet.

[gohanman]

That might work, but it would require new processes on the accounting side since the redemption value of these coupons would need to be treated differently from other coupons. I'd be really leery of making that the standard way to do a sale price since the accounting implications aren't obvious and could easily be missed.

Handling mixed prices per se isn't an issue; all three approaches above do that. NCG's FAQ doesn't provide any guidance at all how mixed prices should be handled so presumably there's some leeway for stores to decide.

[flathat]

NCG does provide a set of screenshots of how to do it in SMS, as a sale price with their implementation of mixmatch which includes giving the lowest-price one for free.

[gohanman]

Sure, but the FAQ doesn't say you have to do it that way. In any event, I think we'll go with the BogoPM approach initially. Borrowing some logic from the old AB groups and creating separate discounting record(s) seems reasonably clean.

Basic ordering doesn't matter (high, low, low high)

And it can adjust if an earlier discount ends up too large (high, high, low, low)

I'm going to leave the batch creation side alone for now. Using a price method created yesterday that will result in items not ringing at all if the lane doesn't support it does not seem like a sensible default. But eventually there should be a setting for preferred BOGO price method (which would have to be a PriceMethod class to be able to be triggered via a sales batch).

[gohanman]

Forgot to mention, the above isn't strictly confined to BogoPM. It also require an additional TransRecord method 058fcd264583b1b18c7403277f9d6d5a64d31fbc