I have a question on what the best way to calculate and store sales tax in the US should be. I am creating an invoice program that can have multiple line items. Here is an example of the issue I'm am running into.
One of my invoice line items looks like this.
quantity 2
amount 1133.67
tax rate 7.5% (.075)
If I add 1133.67 to 1133.67 and multiply by .075, the tax is 170.05.
However, if I take each quantity 1133.67 and apply tax to it individually first, the amount of tax totals up to 170.06.
Obviously, when I'm dealing with taxing each individual quantity, each quantity is being rounded up. But when I total each quantity and then tax the total, there is no rounding up.
I can probably solve this problem by simply editting my table field to allow for 3 decimal places instead of 2.
This may be a question only I can answer, but does it make sense to store tax amounts for each line item or no? I was thinking the data could be useful in reports later down the road.
Wondering what others are doing.
Thanks in advance.
Having worked at a successful sales tax startup, I can tell you "it depends". Local laws vary on whether you calculate sales tax at the line item or invoice level. For some discussion on the topic see:
https://money.stackexchange.com/questions/15051/sales-tax-rounded-then-totaled-or-totaled-then-rounded
I can also tell you that US sales tax is extremely complicated. There are over 10,000 jurisdictions that can levy a tax (state, county, city, and special districts such as stadium districts, metropolitan transport districts, water districts, etc.). The boundaries of those districts are not well defined an a readily available public source, and certainly do not conform to ZIP code boundaries.
If you want to get it right, your best bet is to use a sales tax calculation service. There are several SAAS solutions that are well-suited for web apps.
Related
The site has 5 currencies. The sales price of goods and delivery is set in euros. But the customer can choose the preferred currency to display prices.
A better solution would be to keep prices in all currencies in the table "prices" or convert dynamically?
Structure of table "prices":
id
currency
variant_id
value
original_value
Dynamically. It would be a simple JOIN plus a calculation.
However, ... It would be tempting to ROUND(..,2) when displaying. This works for many Western currencies but does not work well for some of the Gulf states, which need 3 decimal places, or Korea, which does not really use Jeons any more.
If you need to round to a different number of places, use a Stored Function. And/or perhaps the JOIN also gives the number of decimal places.
The answer depend on the business rule. If a price can be calculated by a simple conversion then store only price in some reference currency and convert it dynamically. However, you need a date to store rate history. When a price cannot be calculated dynamically you should store it. The combined approach may be used, too.
just a logic question.
I'm building a shop based on Laravel and other stuff but that's not the point.
The point is, how to handle stock addition / deduction.
Right now, I have a package (my item) with the qty of (let's say) 20 in the shop. Every time a user try to add this item (and the qty) to the cart or updates the qty of the item in the cart, I check if:
- Count of QTY of the PAID orders is < QTY OF ITEM - I do not count the qty of other orders which are not paid.
Is this correct? Or do I have to include orders with "pending payment" or other ?
Quite difficult to find the right way. What is the best way to manage stock ?
I'd say it all depends on how the logic and implementation you want to add is.
Think of it this way on a case-by-case scenario (me being the customer):
If i am allowed to create an order and never pay for it (changed my mind, out of money, forgot about it)
Will you reserve the stock for me forever?
If i create an order, i come back to pay a week later but you are out-of-stock
Will you make sure i get the item somehow?
Will you prompt me that the stocks have changed for some of my items and i need to review my order?
Will you just cancel my order as stock in not available?
If i make an order and while i am trying to find my credit card to pay someone else buys the last items before me, what will you do then?
Conclusion:
In case 1 the store is at a disadvantage and probably will face problems for keeping stock for items that are never going to be actually purchased.
In case 2 it was my fault for not making sure i paid for the orders promised in a reasonable amount of time so i would accept the scenario of "losing" the item
In case 3 it was probably the system's fault for not keeping the items for me as promised when making my order as it could be a matter of minutes or even seconds.
From this i would suggest you used a time based reservation of items, prompting the users to settle their payments in a reasonable amount of time (1 day, 1 week, 1 month... it depends on you) for which their orders are considered active.
By counting the active pending orders and just cancelling them after some time, you would keep customers happy since you are delivering as promised and them feeling obligated to pay their order or risk losing up on the items in their order.
i am working on a plugin for prestashop, i am done with it, but i have stumbled on to an issue.
The program flow is as follows:
A person places an order at the eCommerce website, the order is accepted, the order details such as items, prices, taxes, discounts etc is send to an external invoice API service.
An example of an order could be:
(These prices include taxes)
1x T-shirt 20.64
1x Shipping 125
1x Discount -18.58
(In this particular test case, the discount is 90% off the product, the math is simple 20.64 * 0.90 = 18.58)
Order total after tax is applied: 127.06
This is all fine, but, when i send the details off to the API, the order is saved as the following:
(These prices are saved without tax applied, the tax rate being 25%)
1x T-shirt 16.51
1x Shipping 100
1x Discount -14
Order total after tax is applied: 128.14
As you see, the order totals do not mach, the difference is 1.08, i am thinking this a discount & tax issue.
Its worth noting that the external site does its own math on the values sent, e.g products, tax etc. I cannot influence the way the external invoicing site does its calculations. I think the issue occurs in the order of which the operations are performed on the different platforms.
Its also worth mentioning that the code works perfectly fine when there is no discount present.
What can i do prior to sending the values, so that i get the prestashop price at the external service?
Let the value of the items be v_1 (t-shirt), v_2 (shipping) untaxed values, respectively.
Case 1.
1.25*v_1+1.25*v_2-0.9*1.25*v_1 = 127.06
Case 2 (tax at end)
(v_1+v_2-0.9*v_1)*1.25 = Same as Case 1 after expanding the brackets.
The figure which is amiss is, as you suggest, the -14 discount, which is more like -0.9*16.51=-14.86.
1.08 difference
There is a difference of 86 cents/pence, whatever, between the untaxed discount values. After taxes this difference grows to, 0.86*1.25=1.08, which explains the discrepancy.
To fix the code, the discount calculation needs to be fixed, unless there are other tax considerations that apply to discounts, etc. In other words why is -14 being used, rather than -14.86?
To you second point about the order of events, this should not impact anything - unless discounts are taxed differently.
Fix
Either
The discount calculation is wrong (i.e. 14 should be 14.86), or
The discount value of 14 is correct, in which case a different (tax/discount) methodology than what is being assumed and this needs to be ascertained before you can make a fix for it.
I'm trying to figure out how to build a specific algorithm (ultimately implemented in PHP, but that's less important), but I'm having a hard time wrapping my head around the best way to do the math. Instead of defining a complex industry-specific process, I'll use a crazy metaphor here (the math is what's important). Imagine you're trying to identify the percent chance a specific make of car is parked in a store's parking lot based on the items sold within the store. To begin you take a physical survey of 100,000 store parking lots, recording each unique car make spotted outside, each unique item sold within the store, and a fixed percent relevance that item has to the store (ex: lumber has an 89% relevance to Home Depot, but pencils only have a 23% relevance to Walmart).
There are two parts to what I’m trying to solve. First, I’m trying to figure out the best way to roll-up this data to a specific item, while respecting each relevance percent and the number of confirmed observations (so one spotting doesn’t equal 100% chance, similar to http://www.evanmiller.org/how-not-to-sort-by-average-rating.html ). In other words, if a brand new, never-before-seen store is selling Waterford glasses and cashmere sweaters, from those items we can predict there’s an 89% chance a Mercedes is in the parking lot.
So to recap:
Each item has been seen a specific number of times in a store. For each of those times, there is a different product/store relevance percentage and a list of all car makes in the parking lot. How do I best mathematically calculate the percent chance a specific make is in the parking lot of a brand new store, only based on the items within?
Now the second part of this is getting a bit more complicated by adding another layer of abstraction. If a single person visits 50 stores, and we aggregate all the items in all those stores, we can predict what type of car they drive (ex: lots of camping and hiking stores, so they have a 67% chance of driving a Jeep). Then if they visit a new store and are exposed to a brand new item, for which we have no data, I need to apply that 67% Jeep onto the new item (still respecting the relevance of that item to the store). Then use that item’s less-than-certain Jeep statistic to influence our predictions of parking lots that contain that new item (which was never directly measured). Perhaps this requires us to add a confidence interval of some kind? Or how can we represent that uncertainty, without every one of the millions of items we analyze eventually averaging out to 50%?
I REALLY appreciate your help on this!
I think, you need to build cross-correlation matrix,
where lines are goods, and columns are car types.
Each cell contains normalized coefficient, how to some
good (i.e. diamond ring) is related to car type (Geo or Mercedes).
Details see here:
http://en.wikipedia.org/wiki/Cross-correlation
EDIT: Im sorry guys my explantion of the problem wasn't clear! This should be better:
User sends ID numbers of articles and the max. number of bundles(packages)
API searches for all prices available for the articles and calculates best result for min. number of bundles (limit to max. number provided by customer)
ONE Bundle is one package of items delivered to ONE platform(buyer)
Thanks!
This is a fun little problem. I spent a few hours on it this morning, and while I don't have a complete solution, I think I have enough for you to get started (which I believe was what you asked for).
First of all, I'm assuming these things, based on your description of the problem:
All buyers quote a price for all the items
There's no assumption about the items, they may all be different
The user can only interact with a limited number of buyers
The user wants to sell every item, each to one buyer
The user may sell multiple items to a single buyer
Exact solution -- brute force approach
For this, the first thing to realize is that, for a given set of buyers, it is straight forward to calculate the maximum total revenue, because you can just choose the highest price offered in that set of buyers for each item. Add up all those highest prices, and you have the max total revenue for that set of buyers.
Now all you have to do is make that calculation for every possible combination of buyers. That's a basic combinations problem: "n choose k" where n is the total number of buyers and k is the number of buyers you're limited to. There are functions out there that will generate lists of these combinations (I wrote my own... there's also this PEAR package for php).
Once you have a max total revenue for every combination of chosen buyers, just pick the biggest one, and you've solved the problem.
More elegant algorithm?
However, as I intimated by calling this "brute force", the above is not fast, and scales horribly. My machine runs out of memory with 20 buyers and 20 items. I'm sure a better algorithm exists, and I've got a good one, but it isn't perfect.
It's based on opportunity costs. I calculate the difference between the highest price and the second highest price for each item. That difference is an opportunity cost for not picking the buyer with that highest price.
Then I pick buyers offering high prices for items where the opportunity cost is the highest (thus avoiding the worst opportunity costs), until I have k - 1 buyers (where k is the max I can pick). The final choice is tricky, and instead of writing a much more complicated algorithm, I just run all the possibilities for the final buyer and pick the best revenue.
This strategy picks the best combination most of the time, and if it misses, it doesn't miss much. Its also scales relatively well. It's 10x faster than brute force on small scales, and if I quadruple all the parameters (buyers, buyer limit, and items), calculation time goes up by a factor of 20. Considering how many combinations are involved, that's pretty good.
I've got some code drafted, but it's too long for this post. Let me know if you're interested, and I'll figure out a way to send it to you.
This is a graph problem. It can be solved with the Edmond's Blossom V algorithm. It's a matching algorithm to find the best pairwise matching for example in dating programs. Maybe you want to look for the 1d bin-packing algorithm. In 1d bin-packing you have a limit items to assign to unlimited boxes or shelves the better the boxes get filled.
If I understand the problem correctly, it is NP-complete via reduction from Minimum Set Cover. We can translate an instance of Set Cover into an instance of the OP's problem as follows:
Let an instance of Set Cover be given by a set X of size n and a collection of subsets S_1, S_2, ..., S_m of X. Construct an instance of the OP's problem where the seller has n items to sell to m buyers, where buyer i offers a price of 1 for item j if *S_i* contains item j and 0 otherwise. A solution to the OP's problem where the number of buyers is limited by k and the total price paid is n corresponds to a solution to the original Set Cover problem with k sets. So, if you had a polynomial-time solution to the OP's problem, you could solve Minimum Set Cover by successively solving it for the case of 1, 2, 3, etc... buyers until you found a solution with total price equal to n.