2 ms·

Well, the problem with the first scenario is that if the discount is percentage based (say, 10% off), then it's going to require code to calculate. It's no long

Well, the problem with the first scenario is that if the discount is percentage based (say, 10% off), then it's going to require code to calculate. It's no longer just an SKU - it's an SKU which does a calculation, which is presumably not part of the platform already. And so we have a new "discount" SKU - but which line items should the SKU apply to? How do we know when to stop using that SKU when the discount runs out? And anyway, why should an SKU have a discount % field on it? Why do we get different behaviours based on some magic SKU field? It's a breakdown in cohesion... and so the spaghetti begins... You can also argue that we can just "get someone" to apply discounts manually, but isn't that the job of the billing system? Manual labour doesn't scale too well, and a lot of mistakes get made - asking a customer to return an accidentally applied discount is a very, very difficult conversation, and I've worked with companies who simply had to absorb years of incorrect discounts because doing so was the only way to keep the customer.

donavanm 4y ago
Dont forget co-selling discounts. First 100 messages free with a monthly resource. And is that per monthly resource, or each monthly resource?
AnhTho_FR 4y ago
Also, here is an example of 'looks simple' but 'raises many question' 1/ Should it be a discount on future invoices, or a refund (an angry customer will ask for a real refund: aka $$ on their bank account)? 2/ Do you want to keep track of how much has been discounted/refunded to which customer (so that you can identify deeper trends: if a segment is being discounted many times: maybe you can adjust things, or maybe it's fraud?)? In that case, just erasing a line doesn't help 3/ If you refund, how do you deal with taxes that have been paid already? Btw, we've written a quick primer on Refunds, Coupons, and Credit Notes: to lay out the pros/cons https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Coupons-&-Credit-Notes https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Co...
- doctor_eval 4y ago
  #3 is an absolutely classic example of unanticipated complexity. Tax might differ depending on individual line items on an invoice, so if you’re refunding $50 on a $100 invoice, how do you compute the tax payable for the invoice? If memory serves, we ended up solving this by pro-rating the tax against the refund amount, on a per-item basis. And, I think, some smart accounting. Oh and then you have the problem of when tax is becomes payable. Is it when the invoice is raised (accrual based)? or when it is paid (cash based)? And if memory serves, it depends on the size of your company. :head asplode:

donavanm 4y ago

Dont forget co-selling discounts. First 100 messages free with a monthly resource. And is that per monthly resource, or each monthly resource?

AnhTho_FR 4y ago

Also, here is an example of 'looks simple' but 'raises many question' 1/ Should it be a discount on future invoices, or a refund (an angry customer will ask for a real refund: aka $$ on their bank account)? 2/ Do you want to keep track of how much has been discounted/refunded to which customer (so that you can identify deeper trends: if a segment is being discounted many times: maybe you can adjust things, or maybe it's fraud?)? In that case, just erasing a line doesn't help 3/ If you refund, how do you deal with taxes that have been paid already? Btw, we've written a quick primer on Refunds, Coupons, and Credit Notes: to lay out the pros/cons https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Coupons-&-Credit-Notes https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Co...

doctor_eval 4y ago
#3 is an absolutely classic example of unanticipated complexity. Tax might differ depending on individual line items on an invoice, so if you’re refunding $50 on a $100 invoice, how do you compute the tax payable for the invoice? If memory serves, we ended up solving this by pro-rating the tax against the refund amount, on a per-item basis. And, I think, some smart accounting. Oh and then you have the problem of when tax is becomes payable. Is it when the invoice is raised (accrual based)? or when it is paid (cash based)? And if memory serves, it depends on the size of your company. :head asplode: