This is excellent - our use of an internal deposit scheme is already live and I see nothing obstructing the can deposit scheme going live
Something to think about when implementing return deposits for internal schemes is that not all containers are returned by the party we delivered it to. We get wholesalers returning kegs from accounts that we or another wholesaler has delivered to - the return charge needs to go to the returning party - despite it being in the system as being returned by another party
When you remove products from an order it does not automatically remove the deposit! Got a complaint about an invoice having no containers but deposit calculated.
It would also be really useful to exempt certain products - we have been confronted here with some hidden costs which makes it no longer interesting to relabel some old stock in the new system. As such I would like to be able to sell this stock without deposit (despite the risk involved)
Also for errors it would be usefull if we can credit a deposit - we needed to swap a case at a client and not sure how I can correct this as a credit note system does not handle deposits at the moment
Weâre hoping to get the final parts of this project done soon, and this will include crediting a deposit. This isnât possible right now, so Iâm afraid until this last part is done, youâll need to keep track of these manually. Once done, this will work well with your own internal keg deposit scheme too
Sorry for the slow response on this. Until weâve built out this last part of this feature, youâll need to keep track of this outside of Breww. In a future update, youâll be able to track crediting deposits in Breww, but this isnât possible just yet, Iâm afraid.
Following a support ticket with Gijs, I thought it may be helpful to clarify a few points in the container deposit scheme report here for others to see too:
Deposits taken shows how many deposits have been taken (even if there was no charge passed onto the customer), e.g. 24 x 71 = 1704
Deposit charge value shows how much you have charged your customers for deposits. This will usually be equal to Deposits taken x Charge to your customers per container, unless you have some sales in Customers to exclude from charge but include in reporting. Customers chosen here will be included in Deposits taken but donât increase the Deposit charge value number (as they were not charged).
Deposit cost value is similar to Deposit charge value but with Cost to you per container used instead of Charge to your customers per container.
I think this rounds out this project (at last), but please let me know if you have any questions or think anything has been missed. Thank you everyone for your patience.
great you got a return part of the deposit implemented, it is much anticipated - however there are a couple of issues that make the feature quite imperfect. In all fairness I have not fully being able to test it yet, but I already see a couple of major issues:
The choice is now between two imperfect things:
Make a credit note which creates additional work on the admin level
Attach it to a future order which creates a delay in the handling which means on both client and customer level have to keep track of/ remember them (an order can be anything from 1 week to a month)
It is common practice here with other systems to return kegs on the invoice of the order delivered - it settles everything in one go. There are a couple of ways to go around this:
At delivery level the return kegs are scanned and added to the order delivered in an automated fashion before completion (i.e. beers is delivered, kegs are scanned in and added to the order, order is signed off. done).
An alternative might be to dislodge the signature from the completed order (but keep it as proof of delivery). In that way we can manually add the returns to the order and complete/invoice it after.
Another issue, is that you canât return deposits to customers that are not delivered to that customer. This happens quite a lot especially with wholesalers as they pick up kegs we have delivered. they are returned by wholesaler A but Breww sees it as a return from Client B. As such the system should be able to manually be adjusted. Related to this is that it also doesnât work with keg pool kegs that we are allowed to take in but have not necessarily delivered. A way to select who to credit it to might work best as well as a feature to ad deposits to the order manually.
The deposit returns report should be made clickable, or there should be a date based page that gives an overview of containers that can easily be added to orders
Other questions:
we currently have kegs in the market of two different deposit values - can we tweak the amount returned?
Also a question - is the âdiscountâ booked onto the same account as the deposits taken?
Thanks for the comments, Gijs. Apologies for the delay getting back to you, I was on our stand at BrauBeviale all of last week, so Iâm just catching up now.
Only kegs delivered after the deposit scheme was converted to be âReturnableâ will be returnable, so if you do not see these on the customer account, I suspect this might be why? If you delivered a keg before updating the scheme, returning that keg will be handled as though the deposit is not returnable. If you think there is a problem, can you open a support ticket with details of the order/delivery/customer so we can take a look for you?
The intention is that the credit note is only used if the customer isnât ordering again, or doesnât want to wait for their next order to get the deposit back. There needs to be a legal document to account for returning the deposit and offset its original value on the invoice.
For returning the deposit on the next order, you shouldnât need to keep track of this, or remember it manually. Breww will be tracking this for you and will only show the blue Return container deposits button (above the orderâs product list) if there are available deposits to credit against this order.
Regarding returning the deposit on the same order, I do not quite understand how this should work, to be honest. Would you want to invoice an order with a deposit on it, then a few weeks later take back the keg and edit the value of the original invoice? It doesnât seem right to me to be editing the value of an invoice potentially weeks after it was raised. Or have I misunderstood something?
Yes, this isnât possible. This would need to be added as a new feature.
Iâm not sure if this will be needed once youâve got the issue of the deposits not showing on the customer account, but I might be wrong. Letâs get that part sorted for you and then we can re-visit this.
Not currently, unless you use different container types. Can you use two different container types with separate schemes?
I think there are some misunderstandings here better to explained with a call as I feel there lacks a bit of insight on how the deposits actually work over here (not limited to NL):
As far as âreturing the deposti on the same orderâ: I meant that I would like to put the returned deposits on Day X on the same invoice as the delivery we did at day X. Not push the deposits towards a delivery on day Y. So you do not have to rely on credit notes or next orders for the deposits to be returned.
Fundamentally: We need to be able to take in all our own and keg pool kegs returned to us, no matter where they came from. For example I just got 11 kegs returned today by one wholesaler - when I scanned them in they were associated to 4 different accounts, 3 kegs were not our own but part of the pool, so not in our system. Only 2 were associated with the wholesaler in breww. All of them need to credited to the wholesaler though as he credited the other accounts - in this situation in breww the other accounts have âreturned kegsâ against them - which is incorrect and very confusing. This is common practice. Hence we need a lot of flexibility for it to work properlyâŚ
The fact it only starts from now on creates a problem as I have a lot of kegs in the market that need will trickle back in everything between a week and year. So there is no solid start point, meaning I also canât rely on this info brews gives me.
As far as value it is not possible to use different container types as we switched the amount of the same container type. The higher deposit value are kegs delivered before 08/23 - and these still trickle back in so need to be returned. Also this is not ideal as it creates too many products.
So unfortunately I need to conlcude I canât work with this system at the moment and I donât see it working for my fellow DRS colleagues.
I really appreciate all the work - but I think with some more feedback from us, these issues would be flagged earlier on
This is ideal for deposits on your own tracked kegs/casks.