#ostatni5_docs
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1217477604672540723
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hello, so the scenario is that you have a product agnostic coupon and are trying to understand how that $10 is distributed on, say, and invoice with two $8 items?
Yes i mean i have such scenario and from my calculations tax should be applied for 214.88
And so far I think I wrongly distributed fixed discount
Gotcha, I am unsure what our logic is here. I will look in to this and get back to you
Can you tell me about what you would ideally like this discount to be?
Also can you send me the ID of the invoice that that screenshot is from? (in_123)
Id for invoice: in_1Otr03F9R6Nkg8poLK2VebJ7
This was my attempt to calcualte it in excel
without rounding in between discounts and with
I am having trouble finding info on this and have reached out to my colleagues. We will get back to you with what we can find
Hi there ๐ taking a look
Hi
Could you confirm what order the line items for that Invoice are listed in when you retrieve it from the API? I believe that is relevant here. I think I see a pattern to the rounding, but am also trying to confirm that's correct.
From API: First is that costs 100$ and second is 10$
Gotcha, thank you for that. I've confirmed how we round, and it does appear to align with the calculations on that Invoice. Though it is a bit complex.
We can't just calculate the percentage of a payment a line item makes up, and use that to gain a percentange of the discount to apply. Think about a scenario where a $10 discount is split across three $10 line items. If we just calculate 10/30*10, we end up with a $3.33 discount for each line, totaling a $9.99 discount which is short of the total discount.
Instead we use a nested cumulative remainder approach.
With that approach, we step through each line item one at a time.
For the first line we do:
10/30 * 10 = $3.33333 discount
The $3.33 is applied to that line, and the remainder of .333 cents is rolled to the next line item.
So for line item 2 we would have:
10/30 * 10+$0.00333 = $3.33666
we still don't round up here, the remainder keeps getting carried over
The last line would then come out to $3.33999, but we know we need it to be $3.34 for the overall total to sum to $10 for the discount, so that one is rounded up.
Looking at your specific example, line items are $300 and $10, with a discount of $19.98
300/310*19.98 = $19.33548
$19.33 gets applied to the this line, and the remaineder gets rolled to the next line
Since there are two lines, the final line must be large enough to sum to the total discount:
$19.98 - $19.33 = $0.65
Ok I understand now, thanks for your hard research work โฅ๏ธ
It would be great if docs would be updated with such example for future developers.
Oh I very much agree, and have added an item to my todo list to raise that to the right team ๐