Hello! @laura.asplin 

Slightly off-topic, but you triggered me

When we started using MEWS in January this year, the hard coded Vienna City Tax was broken, or at least not working correctly (it didn’t subtract breakfast elements from the gross rate, thus calculating the city tax also based on breakfast, instead of internally splitting included breakfast from the gross rate to calculate city tax only based on net rate without breakfast). Thus we had to make manual stay products and posting rules to correctly account for that, adjust rate for breakfast, calculate city tax and add breakfast back to the bill… However, when splitting the invoice or moving stay items partially to company bills and so on, city tax get’s mixed up a little bit.

For you question: we wouldn’t mind having city tax cancellations or rebates  posted to the same accounting category, as long as we get the correct value at the end of each month to know what we have to pay to the city. For tax audits by authorities it would be very usefull to get a report of city tax base amount, like “what was the net revenue, with breakfast internally splitted, for a certain period?”
With our “custom” solution with manual products and product rules, we get that information in the accounting report, but I don’t know how that would work for the hard coded Vienna City Tax.

BTW: I would rather have a correctly hard coded city tax for Vienna with correspondig reporting and internal breafast splitting - any insight into whether there is any work on that? And how would a transition from “manual” to “hard coded” work out, in case … ?

Regards,

JP.

@laura.asplin in the perfect world (that you are building) i believe you will have a seperate accounting category that is connected to the original.

eg ‘food - vat low’ and ‘food - vat low corrections’

both would always be counted as a whole, however when you want to, you would be able to easily split the amounts posted on these two seperate accounts to verify what amount of value was actually reducted from the original. 

but as a default starting point i would always suggest correcting on the posting categorie, and not (accidently) sowhere else

Hi @laura.asplin! 

I like the idea of @mauritsbots, separate accounting categories which are connected.

While we are on the topic of city tax: we consider city tax as “non revenue” products, since it is not actual revenue. It would be great if there would be a feature to have a “non revenue” grouping/tickbox within the accounting categories to make sure those accounting categories are not calculated as revenue within several reports. 

Hi @j.spiess thank you for your reply! Sorry to hear that the current hard coded city tax isn’t meeting your needs. I have passed this onto the relevant product manager to understand if this is something they are aware of or have plans to change.

In relation to the manual city tax product you set up as a workaround can I just clarify my understanding:

You have created a city tax product with accounting code a.

You have set rebates and cancellations of this product to also post to accounting code a.

You use the accounting report to identify the total amount of city tax you owe to the city.

 Thanks once again for your insights.

@mauritsbots thanks for your reply! So it sounds like you would want them all to be posted to the same accounting codes, but ideally you would want a way of seeing the breakdown of how this was calculated if required? I.e. how much was cancelled and how much was posted? Can I ask the reasons for wanting to see this level of breakdown and in what scenario you might use this level of analysis?

Thank you so much for your support and insights :) 

@Sanne Thank you so much for your comments and feedback. Can I ask why you would want to them as separate or connected codes? In what scenario would you look at them separately?

Thank you for your additional feedback on the non-revenue items, I can see we have this as an idea in our Product feedback portal (Uservoice), if you like you can add your vote to this idea and it can help us to prioritise. Uservoice

Hi @laura.asplin !

That’s correct.

Regards,

JP.

hi Laura,

we would be looking at something like attached. it would consolidate the amounts based on the accounting category, but also (easily expended with + or chevron) to show what amount was rebated/corrected. Reason why is to verify that the correction is not always done in the same consumption month as the charge; and now it does not show that clear that the corrections done are not part of the same consumption period

@mauritsbots thanks for this valuable feedback. Just to give you an update we are thinking about the rebate logic more broadly than just City tax. Essentially we would like to simplify the current rebate logic which seems overly complicated at the moment, to ensure that all rebated items are always posted to the original accounting category. Before we implement this we need to do some further data analysis to understand how this may affect all customers going forward and this is what we are currently focusing on.