github-actions[bot]
commented
3 months ago SudoSOS Coverage Report
Commit: dc2c600 Base: develop@a8bc690
| Type | Base | This PR |
|---|---|---|
| Total Statements Coverage |  87.55% |
86.27% (-1.28%) |
| Total Branches Coverage | 85.49% |
84.75% (-0.74%) |
| Total Functions Coverage | 88.98% |
87.78% (-1.2%) |
| Total Lines Coverage | 87.53% |
86.32% (-1.21%) |
Details (changed files)
| File | Statements | Branches | Functions | Lines |
|---|
50%
33.33%
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