products are not always being sold at the same price

[delia]

Site has had problems in the past but upgrading to 1.5.6 cured the only remaining issue we knew of but all of these orders occurred since the upgrade to 1.5.6. PHP 7.3.22 (upgraded on new folders, completely default files). Database had had alterations in the past but looks to be dang close to where it's supposed to be.

This is one bizarre thing where a product sells at a different price at different times. Set price for this one product is 137 with attributes, some of which cost extra. This has happened at least 5 times over the last 4 months. If an attribute that costs 40 is added, the final price is 47.81 instead of the 182. If no attributes added that have additional cost, the final price is 50.81. One order had an attribute of 200 but final price was 230 when base price was a little lower at 126 where the final price should be 326.

But orders exist for the full, correct amount too, with or without extra cost attributes.

The products sold table says price 137.95 and final price 47.81, etc.

This was the product the owner noticed - that does not mean there aren't others.

Customers have no discounts, there are no group discounts. No sales info, special pricing. No mods that affect pricing or core file changes. Template is standard one I always use and only has a few alterations in checkout for display only.

Customers from different countries using different payment methods.

I just don't see any trend here. Anyone got a guess?

[twitchtoo]

I have dealt with these oddities in the past - product/attribute price prefix empty, incorrect, product or attribute names with special characters, order total modules in the wrong order, improperly installed/uninstalled pricing module, cart reload behaviour related to client javascript interfering/blocking, recalculations between carious checkout pages corrupt the data or miss a calculation, customer add to cart/change/update behaviour causing values to be dropped.

Testing starts from the page that displays the original problem first and works backwards. Clearly I have been able to trace data flow in both directions and missed the problem... hours of testing later it turns out a customer was adding and removing things from the cart and checking shipping prices and the data could get lost between pageloads.

[mc12345678]

The various country related purchases... any relationship? What are the exchange rates for the currency supported? After reviewing them, how do they vary once they are updated?

[delia]

The various country related purchases... any relationship? What are the exchange rates for the currency supported? After reviewing them, how do they vary once they are updated?

One from Australia, the others from the US.

I even back through the database and don't see any evidence this has happened on any other product.

I tried to do a query to pull up all final prices that are lower than the product price but the product price is "raw" and the final rounded, that was no help. Can I do that and restrict it to just the numbers before the decimal point? That's not a full check here but I think might turn up this happening somewhere else.

twichtoo - I wonder if the numbers and types of attributes could have anything to do with that possible issue? This product has 2 text boxes and 4 dropdowns. Only one dropdown has option pricing. One thing I just noticed was that the owner doesn't seemed to have aggregated the attribute names betweeen products - setting up separate dropdowns for each? Dunno, but my heavens it's messy.

[mc12345678]

One from Australia, the others from the US.

I even back through the database and don't see any evidence this has happened on any other product.

I tried to do a query to pull up all final prices that are lower than the product price but the product price is "raw" and the final rounded, that was no help. Can I do that and restrict it to just the numbers before the decimal point? That's not a full check here but I think might turn up this happening somewhere else.

Somewhat useful, but doesn't get to the question asked. I asked about the currency settings, not about the origin of the order. One could be anywhere in the world and pick a currency that is supported by the site. If that currency has a grossly incorrect currency conversion, then it could be purchased at a significantly "altered" value...

Please go to Localization->currencies and provide all of the current info.

Then at the bottom of that page, click update exchange data and report the new results as well.

[delia]

There is only one sale for Australia and all the rest I see for the US - so currencies, though they haven't been updated in years, should not be any issue here. I mentioned that to show that it seems to affect a variety of buyers no matter the origin. Sure now that the currencies are updated, they are different with the Australian rate being now 1.49... as compared to 1.38....

[twitchtoo]

I would have to see the code but my guess is the secret to finding this is in the calculation.

What would make the code recalculate the value with or without the correct amount and is there a pattern to the amount missing from the calculation.

Testing should reproduce the problem as you can see the products and orders 'as they were recorded' when the order was placed. It may be necessary to log in as the customer but as mentioned time zone, currency and customer attribute adding behaviour may interfere. One that used to plague some sites was the stock Zen Cart 'add to cart' script. It would corrupt the data passing it directly to the cart without reloading the page/loading the shopping cart.

Any updates?

[delia]

Any updates?

Thanks for asking! No, so far we haven't found any other products that act the same. It seems confined to one product only which makes even less sense and I cannot see how the calculations could affect this. There's definitely nothing obvious. They are watching closer to see if it repeats.