Linnworks had helped me with a calculation to get this sorted in our export MySQL:
CAST(ROUND (o.fTotalCharge,2,1) AS NUMERIC(18,2)) AS 'Order Value'
which seemingly worked until we processed weekend orders and a number of them are out by a penny with the new calculation. The problem is the way o.fTotalCharge is stored. If I do an ad hoc export of open orders, all other channels e.g. Amazon/Ebay are to two decimal places whereas Woocommerce is to 14 decimal places! So looking down the o.fTotalChargecolumn you get:
20.99 32.48 25.99 3.7 25.48 40.99 12.68 25.99 33.98999969 20.09 32.89 18.18 34.97000008 83.96999763 39.96999931 18.98000001 28.32999985 270.6100025 46.63000107 25.58 21.65999985
..guess which ones are the Woocommerce values....not great when exporting and hoping can come up with a solution.
Could you please provide an order ID example from today/yesterday?
I've noticed that on a couple of orders that have come in via the Woocommerce integration, the order xml shows one value (which is correct and matches the money taken by Woocommrece) and the 'total value on the other Linnworks screen shows a value that is incorrect by a penny.
I find this strange as, although it could be to do with rounding/VAT etc, the stored value it is pulling from i.e. Woocommerce is to two decimal places and the XML is exactly the same value....yet the 'Total' is wrong. Even when exporting, the values are the 'wrong' value. Whilst a penny is not much, the invoice looks odd when it doesn't actually match what was paid.