fugglesby

I have been going through things further and have confirmed the refund totals issue stems from refunding it by moving the status over to refunded. This just dumps a -100% of total revenue at the bottom of the order and analytics then deducts this entire amount from net sales. Incorrect behaviour.

If instead I go into the totals at the bottom and enter a refund of the full shipping amount in the shipping tab and then the Net Payment amount in the “amount to refund” tab then analytics displays the correct behaviour of showing a net sales deduction that is 100% of net sales rather than 100% of net revenue. It needs the shipping box filled in order to make the correct calculation here. I have verified this behaviour for both cases.

Fixes:
-analytics logic side: You could place some logic into the calculator to ensure that the total amount deducted from net sales for a specific order never exceeds 100% of the net sales taken in for that order. It seems that net revenue is already calculated separately so maybe no issues there? Perhaps some users would prefer to have this reporting take into account lost shipping costs when assessing net sales but I don’t think “net sales’ is the right place for that to go. As you have said this is an operational cost.

-woocommerce side: You could change it so that the default behaviour when moving an order status from processing to refunded is to fill out the shipping refund tab automatically. This would ensure analytics behaves correctly and seems a more robust approach anyway. You could keep the current behaviour of not filling the shipping refund form when moving status from shipped to refunded as this money would presumably be spent at this point and it would maintain the current behaviour for those that find it useful. I think the usefulness is questionable though and the capability for confusion is high.

• This reply was modified 2 months ago by fugglesby.

As I work my way deeper and deeper into cross referencing these reports I keep stumbling across new bugs in analytics.
I am cross referencing our actual received payments from bank accounts both with the analytics export you get from the orders tab and an actual export from woocommerce orders itself.

The net revenue for all 3 is correct in all 3 of these sheets.

The net sales/ line item costs shown in the actual order export unsurprisingly matches up with the information shown in the order page itself.
However analytics order export does not! There are seemingly random rounding events all throughout the sheet . The net revenue though is correct which means that an inverse rounding error is happening somewhere else- likely in shipping. Not all values are being rounded. Some are being left with the 0.5. Some are being changed from a dollar exactly to 1.50. Super strange.

Here are 4 screenshots showing the same order with various totals in these different locations:
Woocommerce orders backend
Woocommerce orders export
Woocommerce analytics orders export (in error)
Woocommerce analytics orders page (in error) This shows 15176 as an example of a value that SHOULD have $61 as the correct value but is being given 50 cents- presumably from shipping.

At this stage I cannot trust analytics at all and will be manually exporting orders monthly and resubmitting finance documents for the entire financial year. The potential implications of these analytics bugs are serious in terms of tax compliance and employee pay calculations and these bugs should be taken as seriously as possible.

Hey there- thanks very much for the reply 🙂
Glad to hear you have got eyes on this bug already.

The second issue is regarding the way that analytics immediately assumes that refunded shipping costs are a loss and deducts the net revenue from the net sales. it isn’t related to order status change.

Yes- the orders were in status “processing” which is a paid status.
Every now and again we receive a phantom payment error in a plugin that we use for our payment gateway. We are a Nepali company working so have very limited legal options for ecommerce aside from a few janky plugins. These phantom payment errors themselves are not caused by woocommerce, but woocommerce rigidly defining a payment date and then not allowing that to be edited is a woocommerce issue.

I’m aware of this analytics settings and have it set as date paid- this is the most applicable for finances.

The product gallery is still duplicated. It is stacked vertically. I can’t tell you whether they are both functioning or not as the images are not loading in- just that grey pulsing loading background.
The php changes you told me to make are not active during this behaviour. It is there for pages with CSS disabled and for normal pages where my css fix is temporarily removed

Unfortunately not sorry- the product galleries are now:
-stacked vertically rather than horizontally
-the same size
-both functional where previously one was unclickable, wouldn’t update images etc

Sure. here is a test product page displaying the issue. The css I am using to remove the duplicate gallery on every other product page is deactivated for this test page.

Hey there David- thanks very much for the reply.
The product gallery block within the FSE template is only added once.
If I delete the product gallery block from the template this non functional duplicate product gallery still shows up. I have made a duplicate product page which is not targeted by these css fixes that the customers see for your reference.
https://kailashblades.com/product/bhura2/
This is with the product gallery added to the template. With the product gallery deleted from template the layout for product options moves left but the massive broken gallery remains in place.

Thanks for the pointer on the SVI global tab- I’ll have a dig around and see if I can fix it in there 🙂