| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
Without this a silly number of queries is generated if there is a lot of
pending records.
|
|
Unintentionally "reported" by Lætitia Avrot
|
|
It accidentally multiplied the cost of a bulk payment with the number of
people on it, which is clearly not correct.
|
|
This shows the exposure to refunds for current and recently-past
conferences, in case they have to be canceled and everything refunded.
|
|
The actual file was correctly decoded, but the temporary storage during
the validation step was not.
|
|
Internal names can change, and since this field is only ever used
internally or in debugging anyway, it's better to store the id.
|
|
|
|
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.
|
|
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).
|
|
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).
|
|
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.
|
|
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).
|
|
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).
|
|
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.
|
|
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.
|
|
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).
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
This only adds a link to the existing invoice admin system along with an
editor for VAT rates, for now.
|
