I am messing around with ditching sql-ledger finally and am testing the 3.0.0.1 release’s A/R functions.One hiccup I am encountering is that we sell products in-house and via mail order. In sql-ledger, as long as the patient’s contact info had a state defined, it would know to add local sales tax to in-state (California in our case) patients and not to out-of-state ones. As far as I can tell, the integrated A/R does not do this. It seems to add tax to every checkout process if an item has a tax rate associated. If it has 2 tax rates, both appear in the checkout pop-up.
Am I wrong or am I missing something?
If I am right, then being able to calculate tax per patient based on their state would be pretty useful. The problem I see in the current configuration is that the Tax Rate and State lists aren’t related in any way and, because of their free-form nature, one can’t depend a sql query that matches on the ID columns of each. This could further complicated by internationalization should we get into localized address formats.
So, two ways I see to deal with this:
1. Add tax rate check boxes to the patient demographics
Pros: Slightly easier solution to code for in checkout
Cons: Repeated and additional manual entry per patient
2. Add a tax rate select list column to the State list.
Pros: One time entry
Cons: Forces international users to reply on the State definition
There are a number of open user defined fields and lists in the as-distributed. It would be a simple task to make a formal label in the Admin - Layout - Demographics for Tax and put in the tax factor, then refer to that field in a query within the checkout function to multiply the sales total by that. A null would return zero in the calculator function.
Remember that STATE tax may not be sufficient. In New York you can have three different sales taxes added cumulatively. Smarter is to use a sales tax table to determine same-state taxes by Patient zip code, and out-of-state only by their state, but do so manually. Your front-office staff should be instructed to do this if you are so affected.
Then, the only thing you need to add is a percentage value for the individual, and a label describing that, into the selected field at demographics input. Please also note that some of the services may not be taxable, so be sure to factor the service code in your calculation function.
Idea Man can provide that kind of service for compensation, but it is fairly simply done by yourself.
There is already a list for tax rates. Each rate is given an ID, name and percentage. Currently these entries can be linked to products or services, not to locations.
I don’t think you can just tax by state or zip without also considering what the product or service is. Even if that works for you it won’t work for others. And if you have, say, 50 states and 500 products then that gives you 25,000 possible tax rates to maintain just for products.
Might be better to put a tax rate override into the Fee Sheet or checkout form. This would take some careful work to do it right, as affected code is in a few different places.
Another thought: Add a state column to the list of tax rates, with an empty value indicating a default rate. Computing the rate for a given product would involve matching with the patient’s state. Again, careful work required. Also the list_options table would need another column which would affect a few other areas (that’s not all bad, as other lists may also eventually find uses for the extra column).
Actually, after writing this, I realized that I don’t really need to manage in vs out of state tax in openemr. We’d recently moved all sales (besides walk in which are in state by default) to a web store that handles the tax rates. Pardon my absent-mindedness.
Others might however so, this might be something to mull on low priority.