Well. I think it should be an option - as you can register yourself as a return point - which might be applicable for bigger breweries or breweries that do a lot of on site sales (we have to pay/charge deposits on the cans we sell in our pub, takeaway and webshop as well).
I have another info session today actually - will share the info once I have an english version
I just realised today that when working with this make sure the deposits are customisable on client level.
As in you can select for which products the customer is liable for deposits.
Thanks Gijs. Previously, I had noted down the following for the rules to determine if the deposit should be applied could be:
Would this cover what you need (would you be able to fit your customers into customer groups to help ensure only the correct deposits are applied)? Or would this truly be needed at the customer level as this sounds like a lot of work for you to choose on a per-customer basis?
It is more that you can uncheck some boxes on client level.
This occured to me as I will have at least one bar I have the agreement with not to charge for the deposits of kegs, but will have to charge the can deposits to in the future (as that is not voluntary)
I would rather not separate it out on type level as that muddles other reporting.
Hi Luke,
The english version of the second session is now available in the drive.
Hi
Iâm actually at the 2 day Deposit Return Scheme conference in Glasgow at the moment. Hazel has done a good job and flagging some of the issues and needs of brewers. I would raise a couple of things that I have picked up:
The VAT issue is not resolved yet and so I would suggest that in building anything you ensure that VAT can be set for the deposits separately to the main system as this may not be resolved very quickly
Producing data on your own customers is one thing and what has been suggested above is very sensible and we must display and show the deposits as a seperate line item. However the issue facing us is managing our trade customers that then sell to Scotland. They may well not know (especially if they are online sellers) how much they are going to sell in Scotland so we will need to get data back from them each month how much they have sold to Scotland. We will then have to bill them for the deposits for what they have sold. So this means I think we will need a flag in the system that says this is a customer that has said they sell to Scotland. We then need to be able to add the data we receive from them to generate the deposits invoice. This data then needs to be added to the report which picks up our own customers so that we can send a combined report to Circularity Scotland.
I hope that the above makes sense and happy to be involved going forward. It would also be worth talking to SIBA who have a wealth of knowledge between Barry Watts and Jamie at Fyne Ales in Scotland
Iâm also at the conference in Glasgow and have picked up a lot more insight into the requirements for go live which I can summarise later.
Hi sorry for delay in answering your questions. I think there is a bit potential to over complicate this but equally there are lots of factors to consider particularly because none of the systems are identical. It is inevitable that the Scottish and rUK systems will not be aligned (size of deposit, articles included etc). And the Netherlands is different still! I would recommend a small working group to be represented by the various schemes to see if we can get something simple enough that would be customisable as required by each geography? I have much more insight following the conference in Glasgow this week and would be happy to contribute.
Hi Luke,
What is the status of this project?
It is gathering momentum here. There is a hard start april 1st.
Some things I thought about:
We should be able to generate reports that includes the EAN codes (as this is the reference used for the registering of the DSR
I am currently already experiencing some logistical issues with deposits being handled as a credit note (some customers are annoyed they have a separate step in their admin, others forget they have them at all) - so a way to include these on an invoice would be a great feature.
I am also very keen in developing this with you for the dutch market (I sent quite an influential brewery your way - I am hesitant to broadcast Breww currently due to this issue).
That being said happy holidays 
Thanks for the reply, Gijs, I hope you had a good break and thanks for the recommendation - itâs very much appreciated.
This is certainly a key project for us to get to soon, but itâs not been started yet. We donât have a specific start date for it at the moment, but donât worry, itâs very much on the radar and will be started soon!
Weâre also looking at how to grab the data we need to handle monthly reporting to DRS.
So far, weâve tagged our customers who are in Scotland, so we can run a report as to what type of units were sold to them. What weâre missing is a Containers Sold report - something that shows all the individual containers and their taxable volumes sold within a filterable period. Or, additional fields in the Products Sold (order lines) report, that can add Product->Container Type->Taxable Volume, and Product->Packaged Beer->Quantity.
For things like mixed-packs and multipacks there isnât an easy way for us, even in excel, to grab or report this information - especially if a multi-pack contains different sized cans and/or bottles - without a massive lookup table. Or, allowing us to create a duplicate multi-pack with a different product code / EAN with the deposit value applied to it. That way we can disassemble and assemble the Scotland only products as required.
The data appears to be available, various reports have bits of it, but what we need is something unified that we can schedule to be sent to our reporting person weekly or monthly.
Thanks every for your input on this, itâs been invaluable. Weâre expecting to start this project very soon and will let you know when we know more, or if we have any further questions 
D-day (meaning deposit day in this context) is approaching quite rapidly now - we will start implementing it from the 27th of march. Any updates on the Breww front?
Yes, weâre making good progress on a tool for managing this 
This is a very busy month for us as we will be at BeerX on 15-16th and thereâs quite a bit of prep involved as weâre a main sponsor. Weâre expecting to have the first version of this tool in place before your D-day, which will allow you to automatically add bottle deposits to orders, track how many you have charged and allow you to generate the reports that you need.
We donât expect to have âreturnableâ deposits completed before the end of the month, so you wonât be able to use this for your own internal keg deposits this month, but hopefully that part wonât be far behind and will build on the work weâve done for the first part of this project.
Goods news, everyone, this is now deployed and ready to use 
Weâll keep this feature request open until weâve completed the final bits for managing internal keg deposit schemes, but we should be good for the Netherlands and Scottish schemes.
This is so superbly awesome! You wonât believe how much work this is going to save us.
Initial stuff:
Thanks, Gijs, we really appreciate the positive feedback - thank you!
We can see what youâre looking for here with these extras and will see what we can do for you Weâll get back to you shortly with an update.
Itâs your lucky day, Gijs Weâve managed to push this through for you as we know weâre going to be extra busy next week.
You can now filter on price books when setting up the rules of who should be included in the scheme. If a customer is filtered out using these rules, this will mean that they are excluded from the scheme completely (and so not included in reporting). This should work for keeping some customers out of your internal keg deposit scheme, for example. We can add other filtering options here too, if youâd find them useful?
In addition, weâve added the ability to choose specific customers that should be included in the scheme for reporting purposes but not be charged anything on their invoices. Youâll still see a âgreyed outâ line where the deposit would be on the order page in Breww, so you know that theyâve been accounted for in the scheme, but the value will be ÂŁ/âŹ0.00.