refactor(invoices): Invoices are now considered as a balance top-up #259
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Yoronex
reviewed
Aug 14, 2024
JustSamuel
force-pushed
the
refactor/invoice-as-topups
branch
from
a66db2d
to
12edb0d
Compare
JustSamuel
force-pushed
the
refactor/invoice-as-topups
branch
from
48e2b0d
to
74d79ac
Compare
JustSamuel
force-pushed
the
refactor/invoice-as-topups
branch
from
73be1aa
to
d1acb8c
Compare
Yoronex
approved these changes
Aug 24, 2024
JustSamuel
force-pushed
the
refactor/invoice-as-topups
branch
from
8df279a
to
dc2c600
Compare
|
🎉 This PR is included in version 0.6.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR is the second part of what is (hopefully) the last significant refactor of how invoices work in SudoSOS.
Currently, invoices are treated as an agreement that a debtor will pay the seller via bank transfer. As a result, when an invoice is created, the invoiced amount is subtracted from the seller's balance and added to the buyers balance.
Initially, this approach worked fine. However, as SudoSOS matured, more and more conflicts arose from this behavior. Coupled with the (ab)use of credit invoices and the ambition to create automated invoices, it was decided to treat invoices as a top-up. That is, the balance of the invoiced user increases by the invoiced amount, while the seller's balance remains unaffected.
This change means that, once this PR is migrated, invoiced transactions will appear in the sales overview, as they are simply sales. The seller should not need to concern themselves with whether a transaction is invoiced since the invoice is just a way for the buyer to top up their account. Consequently, we can start considering invoices as top-ups, both in SudoSOS and in the bookkeeping.
Adding the invoice to the bookkeeping is straightforward. The invoiced transactions are now included in the monthly sales overviews, meaning that VAT will be handled just like the rest of the transactions. The BACPM will not include the invoice in the bookkeeping; instead, a "TopupRequest"-PDF will be created and inserted into the bookkeeping. This top-up request is what the buyer will pay to the BACPM and is how the invoice gets paid off.
The reason for the "TopupRequest" instead of the invoice PDF is that the VAT of the invoice is already included in the monthly sales. Creating another PDF with even more VAT would be confusing. This also simplifies custom entries, as these will be included in the "TopupRequest" on a row by row basis and WILL be VAT-liable, whilst the invoiced amount will be represented as "SudoSOS balance, 0% vat". This makes it extremely clear what part of the invoice is just a "top-up" and what part is actually paying for goods and services outside of SudoSOS.
Credit invoices will be refactored to represent what they actually are: Payout requests by sellers linked to specific transactions. To this end, we will create another PR that will split the payout into a UserPayout and SellerPayout. The SellerPayout will specify what timeframe created this amount, allowing the BACPM to quickly generate a sales overview.
In conclusion, this PR decreases the complexity of invoices and makes the process more sustainable in the long run.
TODO
Related issues/external references
Types of changes