summaryrefslogtreecommitdiff
path: root/postgresqleu/invoices/backendviews.py
AgeCommit message (Collapse)Author
2023-07-25BREAKING CHANGE: Allow the currency format to be configurable.Dave Page
This change allows the currency format to be configured in the instance. This allows us to use alternate symbols (e.g. £), and to format amounts using the format required in different jurisdictions. The currency format is set to Euro by default. Note that this change requires an update to any Jinja templates that use the currency_format tag. This must be changed to format_currency.
2022-09-01Add match information on invoice idMagnus Hagander
Just matching up the invoice id is not enough to auto-approve a payment (it's too short, and people should use the payment reference), but it should still be given as a hint tot he user for manual matching.
2021-12-19Make django ORM use joins for pending xacts and matchersMagnus Hagander
Without this a silly number of queries is generated if there is a lot of pending records.
2021-04-09Don't crash when matching payment to multiple invoices with zero invoicesMagnus Hagander
Unintentionally "reported" by Lætitia Avrot
2020-04-06Fix incorrect query for refund exposureMagnus Hagander
It accidentally multiplied the cost of a bulk payment with the number of people on it, which is clearly not correct.
2020-04-06Add simple report showing refund exposure per payment providerMagnus Hagander
This shows the exposure to refunds for current and recently-past conferences, in case they have to be canceled and everything refunded.
2020-04-05Properly decode base64 output in bank file uploadMagnus Hagander
The actual file was correctly decoded, but the temporary storage during the validation step was not.
2020-04-04Store id instead of internalname of payment method for bank transfersMagnus Hagander
Internal names can change, and since this field is only ever used internally or in debugging anyway, it's better to store the id.
2020-03-30Show payment provider on refunds listMagnus Hagander
2020-03-29Remove date parameter to create_accounting_entryMagnus Hagander
This should always be set to todays date, so set it in the function instaed. This changes the behaviour of the paypal plugin to actually use todays date rather than a date parsed out from the notification. In theory this could change the accounting entry date in case the notification is so delayed it ends up on a different day, but either one could be argued to be equally correct in this case, and using the date of creation of the transaction makes tracking things a lot easier. While at it, clean up some imports that have been missed earlier.
2020-03-27Add an administrative view of refundsMagnus Hagander
While refunds could be viewed on the individual invoice that was refunded, it's useful to also have a global view of refunds on the admin page (which links to the invoices as necessary). Button on the frontpage will be highlighted if there are any refunds that are in pendning state (either waiting for us to issue them or waiting for completion).
2020-02-22Add Generic Managed Bank AccountsMagnus Hagander
This is a subset of the managed bank accounts to handle the case where no API or scrapers exist, but there is a "reasonable format" available for downloadable transactions. For these, the file format definition can go in a JSON file instead of requiring specific code for each banks format. This centralizes a bit of the code written specificaly for the pgeu bank and kept in a separate repository, and makes it more configurable to suit the regular case. In doing so, also create the concept of a BankStatementRow that contains the actual output from the bank files. This was previously handled independently by each django app for different payment providers, making it hard to provide a good generic view. And finally, also create generic views to see this set of bank statement rows coming out of the files, so it's possible to follow things up. For now this can be filtered by file (which file did these transactions come from) or just by payment method ("all transactions for this bank account"). This can be extende din the future to cover more advanced filters and searching. Include generic parsers for Credit Mutuel (the one previously living in code form in the pgeu repository) in France, SEB and Swedbank (both in Sweden).
2020-02-09Verify that integer parameters are integers at an early stageMagnus Hagander
Previously we'd in many places pass down the value directly from get or post requests to a lower layer, only to have that layer throw an exception because it wasn't an integer, or we'd ust wrap it in int() which also causes a hard exception when it's not an integer. Instead create a small wrapper for get_int_or_error() which can be called with a parameter that's supposed to be integer, and will then just return a 404 if the parameter doesn't exist or is not an integer. These are all "should never happen" scenarios, so not generating hard crashes and stackdumps are an improvement. None of these were places where the actual bad data would get anywyhere, they would all just cause an ugly exception, but should get fixed regardless. One or two instances spotted by Daniel Gustafsson, and then a lot of grep to try to find most of the rest.
2020-01-30Delegate decoding of uploaded bank files to implementationMagnus Hagander
In particular, this removes the global hardcoding of files being utf-8, instead allowing each implementation to figure that out from the contents (or just from knowing it).
2020-01-04Add support for uploaded bank filesMagnus Hagander
This adds generic support to all managed bank accounts for handling uploaded files. The idea is that for banks that don't have a working API to download transaction list, one can be downloaded manually from the bank and then uploaded into the system, and thereby using the same type of matching etc. Each account also gets to set a time limit after which it shows up as "you should be uploading a file!" in the interface, and a scheduled job will email a reminder to the treasurer email daily (can be set to 0 to turn off).
2019-06-24Support spaces in payment referencesMagnus Hagander
Some people input payment references with spaces in them and since that's always irrelevant to us, remove them in automatic matching. Also update the matching of invoices to be able to show more than one match, such as both the invoice number and the amount. Normally this wouldn't happen, since it would've already been auto-matched, but as a way to search things after the fact it can still be useful.
2019-05-31Add support for "return to sender" on bank transfersMagnus Hagander
This allows the return of a bank transfer that does not belong to an invoice. A regular refund is attached to an invoice and thus cannot be used. Implement this for TransferWise only at this point, since it's the only bank transfer provider that actually supports sending money. We do this by adding a generic payout framework to it, that we can also use for other things in the future, and then use this one to track return-payments.
2019-05-29Add support for bank payments matching multiple invoicesMagnus Hagander
Sometimes, payers will "merge" multiple payments into a single bank transfer, making it no longer available for automatic matching, since the amounts no longer matter. This update makes it possible to match more than one invoice to the same payment. This will only work if the amount *exactly* matches the multiple invoices, so there is no support for handling fees (as it would be unclear where the fees would be deducted).
2019-04-23Allow manual matching of pending bank transfersMagnus Hagander
In the case where the bank transfer gets recorded with the wrong text, allow for manually matching it up between a pending transaction and a pending matcher.
2019-02-22Implement cache for VAT number validationMagnus Hagander
If a VAT number has been validated, allow it to be used without further validation for 3 months. This will also make it possibly to bypass a broken VAT validation service, which there are clearly plenty of.
2019-02-09Add support for generic managed bank accountsMagnus Hagander
This adds a generic support for a new type of payment method that is a managed bank account. This is an account where we can download (or otherwise get notified about) new transactions, and want them in our systems. Support for actual providers are not included yet, and will be done separately. Incoming transactions can be matched against pending invoices using the new payment references. If these match, it will be handled like any other payment in the system. They can also be matched against "bank matchers" which is a pattern that other parts of the system can register for integration, for example a creditcard provider can register a payout as going into a managed account. This turns the payout into a two step operation, where the first one is creating an accounting record and awaiting the payment, and when the pattern is matched the record is automatically closed an filed. Finally, all transactions that don't match either of the above can be processed manually. This include both fuzzy matching of invoices (e.g. payment reference is wrong) and creating manual accounting records for manual transactions. As part of this, the idea of "include bank information on the invoice" is removed as a parameter on invoices. Instead, when the PDF is generated the list of available invoice methods will be enumerated and the first one with a bank information will have that included. If no method includes bank information, it will be omitted from the invoice (as will the payment reference). A new scheduled job is added that sends a notification if there are pending bank transactions in the system that have not been handled after 24 hours or more. NOTE! As the bank information migrates into the database, it has to be manually added to existing unmanaged bank trasfer providers, otherwise no invoices at all will get bank information.
2019-01-19Re-factor payment methods and move configuration to the databaseMagnus Hagander
This is a major refactoring of how the payment method integrates, with the intetion of making it more flexible and more easy to use. 1. Configuration now lives in the database instead of local_settings.py. 2. This configuration is edited through the /admin/ interface, which makes it a lot easier to add constraints (and instructions), thus preventing misconfiguration. 3. Invoice payment methods are now separate from invoice payment implementations. That means there can be multiple instances of the same payment method, such as multiple different paypal accounts, being managed. 4. All payment method implementations are now available in all installations, including Braintree and Trustly. This retires the x_ENABLED settings in local_settings.py. The code won't actually run unless there are any payment methods defined with them. 5. On migration, all payment methods that are marked as inactive and have never been used are removed. Any payment method that has been used is left around, since there are old invoices connected to it. Likewise, any payment method that is selected as available for any sponsorship level (past or future) is left in the system. XXXXXX manual action needed on production systems XXXXXX 1. Settings for payment methods should be migrated automatically, but should of course be verified! 2. The template for Manual Bank Transfer is *not* migrated, since it wasn't in settings.py, but in a template and overriden downstream. Migrate the contents of the template invoices/banktransfer.html to the database using the /admin/ interface. When this is done, the template can be removed. 3. Notification URLs in Adyen must be updated in the Adyen backoffice to include the payment method id in the url (adding a /n/ to the end of the URL, with n being the id of the payment method). 4. Notification URLs in Paypal must be updated the same way.
2018-12-17Add invoics to backend adminMagnus Hagander
This only adds a link to the existing invoice admin system along with an editor for VAT rates, for now.