Tax Exemption
The tax exemption flow within Smart Tools Hub replaces Three Bears Alaska's paper-based process for recording tax-exempt purchases, capturing the customer's details and signature at the register and rolling them into daily and monthly reports for accounting.
Overview
Certain customers in certain regions of Alaska are tax exempt and carry a tax exemption card. See Tax Exempt in the glossary for the categories and the background.
Three Bears Alaska records these purchases so that if the state ever asks why tax was not collected, they have a record to point at. The signatures are not treated as strictly legally binding - the value is in being able to show a good-faith effort to track exemptions. Both Three Bears Alaska and the state understand that no store captures every single signature; some cashiers will skip it. The record exists to demonstrate the effort, not to be perfect.
How It Works
At the register, the customer hands over their tax exemption card and the details are entered into the app:
- Customer details - name, tax ID, and exemption type are entered through the on-screen options, with autofill handling much of it. The cashier's main job is confirming that what's on screen matches the card.
- Purchase details - the cashier enters the purchase amount and the purchase ID
- Signature - a signature pad appears, the customer signs, and the record is submitted
The record is written to the database, and the signature image itself is stored in an Azure blob storage container.
Reporting
Reports are produced by an Azure Function, which pulls the stored records and signatures and builds them into an Excel file. The function is deliberately general: it takes a date, a store number, and a flag for whether the report is monthly, and returns the matching report.
It is built from the tba-daily-excel repo, where it sits alongside the purchase order file function used by SmartPO. That repo has a wiki documenting how to call the functions - rare enough across our projects to be worth knowing about, and the place to start before digging into the code.
Daily Reports
A daily report is built and emailed to the accounting team. These still send reliably.
In practice the daily reports aren't heavily used by Three Bears Alaska. We receive them too, which serves as a daily check that the job actually ran - if it ever fails, we find out quickly.
Monthly Reports
The monthly report is the one that matters. It carries the month's totals along with every signature and record for that month, so an audit request can be answered by pulling a single month.
Only two stores, 119 and 120, use tax exemption, but the volume of exemptions per month is enough that these reports have grown too large for email to accept as an attachment. The reports are built and stored in SharePoint, and the send is still attempted but fails every time.
Rather than fix the delivery or build a dashboard, Three Bears Alaska simply retrieves the reports from SharePoint directly, which they were shown how to do. The failing email is a known, accepted annoyance.
Mike made the call never to delete the reports from SharePoint, so the number stored there grows indefinitely.
Data & Tables
- Database - the exemption records themselves
- Azure blob storage - the signature images, in a storage container
- SharePoint - the generated monthly reports, retained indefinitely
[Placeholder: specific tables - link out to the data dictionary once it exists]
Access & Permissions
Used by cashiers on the iPads at the front of the store, which are bookmarked directly to this flow. See Access & Permissions on the application page for how store accounts work.
Known Issues & Limitations
- Monthly report email always fails - the attachment is too large to send, so the report is collected from SharePoint instead. The send is still attempted and still fails.
- SharePoint storage grows without bound - by decision, monthly reports are never deleted
- Capture is incomplete by design - not every exempt purchase gets a signature, which is understood and accepted on both sides