In previous payout implementations, we disabled payouts when the order had promotions, adjustments, taxes, etc. This PR is intended to support them.
To support all types of adjustments, we need to understand who is running those adjustments to calculate the correct commission and exact money that merchant expect for each of their products. We want to automate the process as much as possible.
Example:
When the promotion is run by the merchant:
If the item is 50$ with 10% promotion run by the merchant, user will pay 45$. We can safely send that 45$ to the merchant since 45$ is what merchant expect.
In another case when the promotion is run by the store (us):
If the item is 50$ with 10% promotion run by the store, user will also pay 45$, but the merchant expected 50$. In this case, we can only send 45$ to the merchant and record the remaining $5 as an outstanding balance, which we (the store) will cover. After recorded, we can clear this amount later.
II. Table Design
This is the database designed to support the above use cases & records all financial data.
I. Why?
In previous payout implementations, we disabled payouts when the order had promotions, adjustments, taxes, etc. This PR is intended to support them.
To support all types of adjustments, we need to understand who is running those adjustments to calculate the correct commission and exact money that merchant expect for each of their products. We want to automate the process as much as possible.
Example:
II. Table Design
III. Test with use cases
1.
Use case #12.
Use case #23.
Use case #34.
Use case #45.
Use case #56.
Use case #6Related PR (UI for this changes):