For our retail customers, we would like to enforce that they can only get any purchases from the Tap Room location so our TTB reporting is correct. At the moment, this can only be done on the individual customer basis. We’d like to be able to enforce this in the customer group screen, so once we add the retail customers to that group that business logic is enforced along with all of the other items that are already allowed.
1 Like
Thanks for the suggestion, David.
Can I clarify: when you say Customer Group, do you mean Customer Group or did you instead mean Customer Type? “Retail customers” would typically be a Customer Type rather than a Customer Group.
Thank you.
Hi Luke,
I was referring to Customer Group. You have different levels of business logic attached to types and groups. I think it would probably work for either, but at the moment we set the customer type correctly and put them in the right customer group.
Although, as I look at the options for both group and type, it looks like we could probably do everything we want with just type now. I think I had them in a group back when we were initially setting up sync and was trying to get the QB information mirrored correctly, but I suspect that is no longer needed.
David.
Thanks, David. I’ve renamed this request to Customer Type now.
The two work differently in Breww and have different intended use cases, so I’d recommend using them for their intended use case only to ensure future updates don’t cause unexpected behaviour. Cheers.
Hi Luke,
Thank you for that clarification.
Let me give a little clarity as to why we set it up that way (I agree, it’s a little weird). Currently, we run our retail CC/cash processing through our POS systems for our taproom. That means that kegs are usually paid for that way as well. On the accounting side, that comes through as a single ACH deposit each night, which is inclusive of our taproom sales + our keg sales.
That means for Breww, that customer keg invoice which is cut flows through into QB as a child customer of our Retail group, and the single payment can then be applied to the Retail Taproom customer (that’s an invoice we cut manually from our POS reporting), as well as all of the Breww retail customers which roll up to the same group.
It’s a little bit of a kludge, admittedly, but much easier and less error-prone than journaling around payments between accounts in QB. It seems to generally work out fine.
I think since Breww doesn’t actually sync the customer group up into QB (unlike Ekos, which is why we set this up), I think as long as we continue to do that grouping in QB and not Breww, we can probably stop using the Retail Group in Breww and put all of the necessary business logic in the Type. I need to double-check that the product accounting will still work correctly when we override it in Type vs. Group, as we book customer kegs to a different P&L account.
Cheers,
David.
1 Like
One other future-looking note. At the moment, we don’t have multiple taprooms, but I could envision a future where a retail customer might pull the keg from a different location depending on where it’s sold. Group might not be the best place to put that but we do need to make sure the sale shows up correctly for TTB reporting so you’d want to be able to tag the type to trigger that and then figure out the inventory part separately.
1 Like