Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

RabbitZzZ

Members
  • Content Count

    68
  • Joined

  • Last visited

Community Reputation

4 Neutral

Recent Profile Visitors

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

  1. Could anybody find the cause of the rounded discounts? Really sorry to bother, but we have the problem on a live shop and the wrong refunds get more and more.
  2. So the problem with the products seems to be resolved, but the part about the discounts still persists.
  3. Is this the solution for it: https://github.com/thirtybees/thirtybees/commit/0177e604e103f49ac8c2670923b264ebbae989f7 ? Edit: Tried it and no. Github says there is a known workaround, but I can't find it. Could you give me a direction? Thanks!
  4. I'm sorry, I didn't actually see that solution. But I tried it and it worked. Thanks! What's the strange behaviour of AEUC? This shop is in production already. Would it be wise to downgrade? On the other hand the update also fixed some stuff that was wrong before...
  5. German most parts show up, but for instance translation page and order editing page are in English (haven't checked evrything) running on PHP 7.1.3 (also tested on 7.0 -> same), minimum requirements are met
  6. In 1.1.0 when I want to manually add a product to the order, the tax exclusive price is rounded to the next full Euro. If I save it directly like this, the then tax included price is different from the original article price because it now calculates from the rounded one. Only when I delete both prices from the fields an replace the tax included price it get's calculated correctly. Also after saving the article the loading sign in the upper right corner doesn't stop spinning. Edit: Also when I add a discount it gets rounded down to full Euros.
  7. This didn't change anything for me. The admin.php has the same size before and after.
  8. That's very odd. Input is 100% right. Also: Before the update there weren't any shipping costs on the pdf automatically. Now after the update, the shipping costs are refunded automatically, even if I don't type them in the field. The difference then ist, that they don't appear as an extra line on the PDF but only in the sum. If I put them in the field before refunding, everything ist correct.
  9. Ok, what would you have done differently then? In my case it doesn't work in 2 shops. Both are recently updated to 1.1.0 without errors. What I have done: - create order with one product - set order to payment received - partial refund for the product - partial refund for the shipping cost -> ERROR
  10. Was it also the one and only product in that same order? When I try and no products in the order are left for refunding I can't refund just the shipping costs on their own. And: order slip = credit note (the template in TB is called order-slip), this isn't correct if the shipping costs aren't on there but are in fact refunded
  11. It's not a problem of the stats but merely of having correct accounting. The invoices and order slips have to conform to bank account activity. This is important because of correct tax calculation and everything. I suppose the error is somewhere in the condition in line 813 of AdminOrdersController.php
×
×
  • Create New...