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.
Related
Pretty much I want to increase the shipping cost depending on the number of items in order... e.g. by default shipping cost is 10$ but when number items goes beyond 20 it will add 3$ to shipping cost so it would be 13$
I tried changing codes but it's complicated somehow
I had to find all places that include shipping tax like in 1-blockcart module, 2-one page checkout, 3-payment, 4-inserting to database... And then change some codes. And it's a lot of work and hard
Prestashop includes a shipping range functionality. You can define shipping cost depending of the total weight of your products.
If you want a simple implementation, you can define all your products weight to 1Kg and add shipping cost ranges like those:
0kg => 20kg : 10$
20kg => 40kg : 13$
40kg => 99999kg : 15$
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.
when using paypal subscriptions in magneto - by default, magento uses the awkward method of
separating the subscription items from grand totals
grand total is zero if only sub is in cart while it calculates physical good separately
subscription items cost is placed below grand totals so it looks like:
as shown, subscription items are not even totaled
subtotal
0.00
grand total
0.00
subscription items
sub1 $1.00
sub2 $1.00
In my view, it would be better like this:
this would be what i consider normal....
Subscription Items:
sub1 $1.00
sub2 $1.00
Subtotal $2.00
Other Cart Items:
T-Shirt 1.00
Subtotal $1.00
grand total
$3.00
or...
Subscription Items:
sub1 $1.00
sub2 $1.00
Other Cart Items:
T-Shirt 1.00
Subtotal $3.00
grand total $3.00
or simply...
Your Cart Items:
sub1 $1.00
sub2 $1.00
T-Shirt 1.00
Subtotal $3.00
grand total $3.00
has anyone faced this and found a way to fix paypal/magnetos bad coding so that everything in cart adds up like a normal shopping cart?
It is a standard practice to keep subscription items separate from current order items. The way you're outlining this would cause confusion with your customers, I can pretty much guarantee.
If you show a break down like you've explained...
sub1: 1.00
sub2: 1.00
tshirt: 1.00
subtotal: 3.00
grand total: 3.00
Your customers are going to wonder if they're being charged 3.00 on a recurring bases or only the 2.00.
The actual shopping cart items that are "normal" as you put it, would be setup and included in the one-time purchase. Subscription items, which would be billed on a recurring basis, would be shown separately to differentiate and make it very clear.
Now, a subscription profile may have an "initial amount" charged, and that could be included and shown as a cart item, but again, the recurring amount would typically be shown separately.
Here's an example of a site of mine that is completely custom. I toyed around with lots of ways to display this so it was clear to people, and this is the sort of thing I came up with.
As you can see there I'm showing the one-time amount as the subtotal and then the recurring amount under that as an additional charge that will happen based on the subscription included with the order. If I were to simply show 71.85 as the total that would be confusing to people (and I experienced that first hand before I moved to this format.)
So then here's another screenshot of what it looks like with shipping included, so the subtotal and grand total are updated accordingly, but the subscription amount is still separate.
I have other orders where the one-time is $0 and there's nothing but a subscription, but it still gets broken down as $0 + 1.95/mo or whatever the case may be.
So, personally, I think what Magento is doing makes sense and is going to be better for you once you have live customers shopping on your site. It breaks down exactly what will be charged now, one-time, vs. what will be charged on a recurring basis.
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.
I was wondering, has anyone ever created a discount system with PHP for ecommerce? i.e: Before discount the price is $100, after the discount the price becomes $85, and the $100 was stroked.
For changing text to be crossed out, use the <STRIKE> tag (Like this). The rest just involves multiplying current price by 1.00 - discount/100.0, or subtracting current_price * discount/100.0.
You can also use css (text-decoration:line-through;). Css is probably a better choice, really.
For example, a 15% discount means taking the price and multiplying by (1-15/100), which means price * 0.85.
It's quite a short description, but I think you can create a table in your DB with associated to the item ID the discount percentage you want to apply...
Than on the aplication side you can fetch from the DB the original price, print it and after this the new price calculated easily by the original price and the discount percentage.
It's very easy :)