| Age | Commit message (Collapse) | Author |
|---|
|
If a payment method that had bank info on it was added to an invoice, we
would include the bank data on the PDF even if the method was not marked
as active. It would still not show on the webpage of available methods,
but if someone forwarded the PDF alone for payment, they would get the
bank info for an inactive method. So fix that.
|
|
|
|
Allow fractional tax rates, up to 6 decimal places.
Author: Steve Singer, with some fixes from me
Fixes #164
|
|
This way we get to see the qr code on the preview as well, even
though it can of course not be used. But it helps adjusting layouts.
|
|
This is not a normal situation and has to be dealt with manually
regardless, but we shouldn't crash on it prior to telling the user they
have to do that...
|
|
If an automated system added an accounting account to an invoice that
did not have the checkbox for "available in invoicing", we would first
not show the account on the invoice, and if it was saved (to change the
payment providers for example), we would crash. This is normally a
misconfiguration, but we sohuldn't crash hard on it...
Crashed and diagnosed by Steve Singer
|
|
When viewing a PDF either in the user or admin interface, set the
filename using content-disposition so if the user decides to save the
file it will get a reasonable filename, and not just `document.pdf` or
similar depending on the browser.
|
|
Instead of requiring registration transfer invoicing to be full manual,
create a new object that represents a pending transfer. So instead of
transfering, the admin will create a pending transfer and have it
auto-generate an invoice. That's left as pending until the invoice is
paid, at which point the transfer is automatically completed.
|
|
Commit c594130d missed that the fee amount can be returned as a string
(e.g. "not settled yet"), and thus cannot be passed to format_currency.
A cleaner fix might be to return it as an object, but for now just make
the invoice payment wrapper figure it out and apply format_currency only
when it's not already a string.
|
|
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.
|
|
This is a free text field added to each invoice (optional). If
specified, the text in question will be included on the invoice payment
page and in the email sent to the invoice recipient (if an email is
sent).
Also add a field to the SponsorshipLevel model in confsponsor, that
allows you to specify this individually for each sponsorship level. It
will then be passed through to the invoice and included everywhere
(sponsorship invoices are always automatically emailed). This is
intended to for example inform sponsors about optional other payment
methods or oher such information.
|
|
Message only appears when debugging, but debugging becomes a lot
easier..
|
|
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.
|
|
When the invoie is overpaid we have to put the overpayment *somewhere*
in the accounting, otherwise the accounting entry doesn't balance and an
exception in thrown.
So put this overpayment in as a "negative cost" on whatever account gets
the payment fees, set the description to indicate what it was, and then
leave the accounting entry open for the treasurer to handle.
|
|
Pass the current conference (if any) to this base class, and make it
available to subclasses. Doing this as a proper baseclass makes further
additions later easier.
|
|
This is complained about more loudly in newer versions of pycodestyle,
and it's a bad idea in general. So rename them all to something more
readable.
|
|
Seems in django 3.2, it no longer recognises that 0 can be a decimal and
considers it an integer, ccomplaining about type mismatch. So explictly
make it a Decimal(0) to get around it.
|
|
This code was copy/pasted between several different places, so
centralize it into the InvoiceManager class to reduce the risk of
furhter off-by-one mistakes when editing.
|
|
Django 3.2 has deprecated the JSON field that's in contrib.postgres and
instead have one in core, so switch to using that one.
|
|
Without this a silly number of queries is generated if there is a lot of
pending records.
|
|
Unintentionally "reported" by Lætitia Avrot
|
|
|
|
For managed bank accounts that don't have support for automated refunds,
we can still generate pending bank matcher for a reasonable string,
since the transaction will eventually show up. If it doesn't, or amounts
don't match etc, the operator can always drop the pending bank matcher
as well. This also means it can complete the accounting entry for
automatic closing.
In this also update the email that's sent to treasurer to suggest the
proper string.
Fixes #47
|
|
We have a very cheap check to see if there is antyhing at all to do, so
we can definitely run it a bit more often to decrease waiting times. We
still want to batch things out a bit like this due to how some of the
upstream APIs work, but once an hour is definitely still within reason.
|
|
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.
|
|
This hasn't changed since 2016, but the new version of django complains
(with the opposite complaint that 1.11 had back in 2016).
|
|
|
|
The version we have doesn't work in django 2.2. And while there might be
newer ones available, we only use it in the admin interface and the
newer django has it's own functionality for delivering the same thing
there.
|
|
While this works in the current django version, the syntax is not
correct and will be removeed in the future, so let's get it fixed.
|
|
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 check is normally done higher up in the stack to make sure we can
give a proper error message. But if the upper end of the stack failed to
do it's checking, add a hard exception in case an attempt is made to
refund more of an invoice than is actually available.
|
|
|
|
Per warnings in newer django versions
|
|
When issuing a partial refund of a manual invoice, the full amount was
put in the pending accounting record, instead of the partial amount.
(For automatic refunding it was correct, which is why this went
unnoticed for so long)
|
|
This was already done once in 8289e05cd but had not been properly
maintained.
|
|
This will work differently for conferences and non-conferences once we
add proper timezone support, so abstract it out into a separate couple
of functions. For now they both return the same thing, but this will
change in a later commit.
In passing, fix missing datetime.now() -> timezone.now() conversions.
|
|
When manual refunds are generated in the system, there is a manual step
that needs to be handled by the person managing the account. So send an
email explicitly saying that this has to be done, instead of just
creating and open accounting entry and leaving it at that.
|
|
|
|
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).
|
|
Now that we don't crash on the individual refund in order to proceed
with others, it became a bit too easy to miss the fact that something
went wrong at all. So instead, collect the error state until the end and
raise an exception if anything went wrong earlier, thereby triggering an
error flag in the job scheduler.
|
|
Needed to store actual real world error messages.
|
|
Instead of crashing the cronjob, catch the exception and log it. This
allows the script to proceed with further refunds if one fails.
|
|
As a step on the way to better timezone support, use the django function
timezone.now() instead of datetime.now(). As long as we haven't enabled
timezones globally this becomes a no-op and does exactly what it did
before, but once timezones are enabled it will generate datetimes that
are aware of this.
No functionality change but gets a lot of boiler-plate out of the way
making the verification of the rest of the timezone work easier.
|
|
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.
|
|
There were a few places that directly accessed request.GET/POST without
verifying that the parameter actually existed first. This would cause a
hard 500 internal server error -- so to make that nicer, instead look
for them and exit with a 404 if the data is incomplete.
|
|
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).
|
