Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


yahalimu last won the day on November 10 2019

yahalimu had the most liked content!

Profile Information

  • Real Name
  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Discount NOT applied to shipping, only product excl. price.
  2. Hi, Yes discount is on order sub total. (exclusive of tax)
  3. Aha decimal places.. =2
  4. Hi, That would be great if you have the time. Normally its only 1 penny out but for some reason that one above was more.. Tax rate here is 20%. Tax is applied to shipping. No other mods applied that could affect it , its a version. No extra order_total modules added. Module Version 5.1.2. BS Display Discount True Show shipping fee discounted false Base discount tax on prices excl. true Sort Order 3 Delete auto created tables when uninstalling False Not sure what you mean by 'Tax Decimals'. (20% = 0.2) Iain
  5. Still getting many errors when using discount codes, mostly just 1pence out but this one many pence out. The totals plainly do NOT add up to the grand total. Total should be £362.96 according to the totals. I think the VAT is calculating incorrectly as £363.06 is actually correct. (£308 - 5%) + £9.95.... VAT should be £60.51 which wpould then all add up to £363.06
  6. Indeed, but because I had this issue with percentage discounts before, which was easily fixed but removing the last 2 d.p. I though it might work for this issue also. In truth, an Invoice should always add up to the total. If it doesn't I would suggest that is a bug.
  7. Hi. I changed the $discount to round up, so it rounded it up to £61.91. Alas £932.09 - £61.91 + £172.44 STILL comes to £1034.62 NOT £1034.63 so I still cannot import the order_total values as they do not add up. I thought removing the extra d.p. this might change the VAT and total calculations so they add up properly but obviously not.
  8. I think this is caused by the VAT being rounded up. I could just reduce the total by a penny (which WOULD make the invoice more accurate) but an easier fix is to limit any discount value to 2d.p because anyone seriously examining the total lines below will notice its a penny out. Just to re-iterate, this only occurs with discount values greater than 2d.p.
  9. Hello, For example a sub-total {excl. VAT) = £932.09 Activating a 7.5% discount, OsC gives a displayed discount of £69.91. (Actual $discount value is £69.9068) VAT is displayed in admin as £172.44 and TOTAL is displayed as £1034.63 Now, when I import the values, £932.09 - £69.9068 + £172.44= £1034.62 NOT £1034.63, a penny out, Thus Quickbooks complains they don't add up. Using the rounded discount of £69.91 also doesn't work as its still a penny out. IF I work it out accurately, using as many decimals as necessary, (£932.09 - 7.5%) * 1.2 = £1034.6199. This rounds to £1034.62 but QsC says total is £1034.63 IF the discount was rounded BEFORE sending to order_total and it then works out the VAT etc all is good and it all adds up. Now I noticed this issue also with percentage discounts in specials. If I limit all prices to 2 decimal places at all points all is good and it imports correctly, if not I have penny out errors. Rounding errors. hard to pinpoint. As I said, no rounding errors if all values set to 2 d.p.
  10. Hello, I thnk it would still create issues if placed there as it is after all the calculations are done using the 4 decimal point version. eg. $discount_formatted may now have a different value to the rounded version. The only time I have 4 decimals is in the percentage discount function. I was looking to apply it only at that point. ie. where it calculates a percentage discount. Maybe this is more complicated than I first thought.
  11. Hello, Thanks for a great addon, seems to work well. Can anyone help me on how to implement a small change? I use some Quickbooks import code which complains the totals do not add up properly when the discount is greater than 2 decimal places, due to rounding errors. Rather than change the Quickbooks import code, which would then import an invoice with slightly different totals to the website, an easier fix would be to round up or down the discount value so it doesn't go to 4 decimal places. i.e. just down to 2 decimal places. Where do I change the code to do this?
  12. yahalimu

    htaccess redirect query.

    OK Thanks I'll try that. Yes its at the top, right underneath RewriteBase / and before the SEO URL redirects. First few minutes in, still getting calls to non existent pr URL's, for products that have never had a review. The old mobile site has now been switched off so I can't check what settings it had.
  13. yahalimu

    htaccess redirect query.

    Apologies I was rushing too much. I added it to ht access but getting lots of 'Primary script unknown' server log error. (mostly from bots/crawlers) On investigation it is trying to redirect to a slightly different product URL (using SEU URL5) For example it is looking for www.XXX.co.uk/object-sileo-300-pr-1474.html when it should be www.XXX.co.uk/object-sileo-300-p-1474.html and www.XXX.co.uk/object-sileo-300-mp-1474.html when it should be www.XXX.co.uk/object-sileo-300-p-1474.html Can you suggest what I edit the htaccess to correct this? (I am assuming it is the mobile re-direct code causing his) also www.XXX.co.uk/object-sileo-300-mc-1474.html when it should be www.XXX.co.uk/object-sileo-300-c-1474.html
  14. yahalimu

    htaccess redirect query.

    Will this also work if using SEO URLS 5 on Phoenix?
  15. Sorry to bump this but STILL getting lost orders. Is it a Cookie Samesite attribute error maybe? https://www.neowin.net/news/chrome-80-arrives-today-with-potentially-site-breaking-cookie-changes/ It started about the same time and maybe explains why it is so random if it happens.