A lot of questions pop up when it comes to taxes and how the TTB is calculated in the database.
Below is a diagram that shows transactions in/out of the brewery/distillery, tap room or offsite warehouse. A few definitions are important to go over first:
1. The most important things to pay close attention to aren't the names of the buildings listed below, but rather the "Location" and "Tax Determined" status.
2. Both "Location" and "Tax Determined" status is set on the warehouse level (under View > User Defined Fields).
3. The "L" numbers next to the arrows below refer to the lines on the TTB that are affected. For example, if you transfer product from brewery 1 to Tap Room 1 (same location) then Line 15 is affected. If the same product is returned to brewery 1, Line 7 is affected. Same is true whether this product is inventory transferred or if the product is sold/goods receipted back in (line 15/line 7 respectively). If it's transferred from brewery 1 to brewery 2 (different location) then line 19 is affected; returning it back to brewery 1 posts to line 5.
4. "Location" is a data table set up in SAP and is used for TTB purposes, not what you'd otherwise assume a "location" would be. For example, you might say to a prospective customer "our tap room is in the same location as our brewery." From Orchestra's perspective, though, a tap room physically in the same property of a brewery could still both be "Location 1" or the same taproom could be considered "Location 2" depending on how you want it to hit the TTB. Contract warehouses could be seen as the same or different locations for the same reason. The most important thing is understanding which lines the TTB should be affected and set up the items/warehouses accordingly.
5. "Tax Determined" status is either "Yes" or "No". As the diagram shows, product sold/transferred from a "No" warehouse to a "Yes" warehouse has different effects than transfers between "No" warehouses or "Yes" warehouses. In the last example, transferring from a "Yes" to a "Yes" warehouse has no effect on the TTB since this product was already previously reported on the TTB. Bottom line: transferring from "No" to "No" with the same location has no effect (product is transferred "internally" and not sold yet), "No" to "Yes" for the same location hits line 15, "Yes" to "No" for the same location posts the credit back through Line 7, and "Yes" to "Yes" means no effect since taxes were paid when the product was initially transferred from "No" to "Yes".
One way to think of “Yes” vs “No” is whether tax has been paid (“Yes”) or tax has yet to be paid (“No”).
6. It's important to remember that the TTB is a very dynamic report. If the offsite warehouse above had been listed as "No" for Tax Determined status and we changed it to "Yes" and re-ran the report, all prior transactions would post as if it was Tax Determined from the beginning. Same is true for locations.
The real key to making the TTB report in Orchestrated work for you will be to run the report, verify the numbers displayed (i.e. 26 production orders show in the calculation of 2585.90 BBLs which matches what is expected for the period) and then diligently auditing the data over time to ensure that the report continues to run as expected. Although the TTB report should be much easier to run than in the past, it will by no means be a "click one button and assume all is correct" type scenario. I'm sure I don't have to tell you that we're talking about the payment of taxes here and you're relying on multiple people to do their job correctly in order for these numbers to populate as expected. :) As much as we want to trust everyone is doing their job and new items/warehouses are created correctly, we must "trust, but verify" until we're very comfortable with how the system is running.
The first few times the TTB is run it can be a bit time consuming learning how it's set up and how to resolve issues that we come across, but over time this should get easier (meaning if it doesn't, contact your Orchestra Software Consultant or Support because our goal is always to make your lives as easy as we possibly can. If it's not getting easier, we need to determine why and do what we can to correct that). There will always be a need to audit the database periodically, though, to ensure that the data is flowing as expected. The addition of new items or BOMs to the database, new employees hired/trained, etc. leads to more need to ensure all the i's are dotted and t's are crossed.
Sample TTB Report:
When the TTB report is run in Orchestrated, remember that the individual fields with populated data (e.g. G24 in image above) can be drilled in to by double clicking in the cell. This will open a new tab in Excel which will show us the transactions that led to that figure:
Here you can confirm that the volume in column Q does, in fact, add up to 2585.90 (as posted in G24 of the report). You can also double-click the Document Number or PdO Number to drill directly in to those documents in OBeer. Unfortunately, those of us from OBeer can't tell just from looking at it if these numbers look right (since we don't work there, we don't know if it should be 2585 or 25850 or any other figure). But by looking at these numbers you should be able to determine if these numbers look right or not due to past reporting, forecasted production and actual numbers generated for the period. If something is there that shouldn't be, or vice versa, we will need to take the appropriate steps to resolve it. As I mentioned, the TTB report is dynamic, though, so if it's determined that a PdO is missing we can create a backdated PdO that was missed and it will populate on this page when the report is re-run.
Excise Tax Reporting
Once the TTB looks good we can then run the Excise Tax Report itself under Report Generation > Create Excise Tax Form.