| Age | Commit message (Collapse) | Author |
|---|
|
The qrencode library we've been using is basically dead (and has been
for a while), so add support for the newer pure-python qrcode library.
We keep support for the qrencode one around, so we don't break things
on existing installs, but consider it deprecated and should eventually
be removed.
Fixes #123
|
|
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 adds the support for registering more than dejavu fonts to the
system, and tries to do so in a backwards compatible fashion. That means
the old FONTROOT setting remains but now instead means the root for the
DejaVu fonts only. Further fonts can be added in local_settings.py
specifying botht he name of the font and the full path to the ttf file.
|
|
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.
|
|
|
|
|
|
Switch the system to properly use django and postgres timezone support,
by allowing each conference to render all date related information in a
conference specific timezone (using the one that has already been
specified on the conference, per a previous commit).
All non-conference parts of the system keep using the default timezone
as specified in settings.TIME_ZONE.
This includes a migration that updates the existing sessions, session
slots and volunteer slots based on what timezone has been configured
for the conference (since previously everything was stored in the
wrong timezone if the conference was in anything but the default
one).
In order to make this work for non-django-orm queries, a context
manager that swaps the timezone to the conference and back out is
introduced, and related to that a way to get a cursor that turns off
django's protection against doing exactly this.
This finally removes the very ugly "timediff" column on the conference
which was a quick hack back in the days to support ical feeds using utc.
In passing, this also:
* Fixes ical feeds to include all required fields (uid and dtstamp
were missing on schedule entries)
* Fixes xml feed to use conference local time (fixes #8)
* Clarify what "valid until" and "active until" means in the help text
on discount codes and registration tpes.
* Don't duplicate dates in schedule xml feeds (seems others don't, and
there is no clear spec anywhere that I can find)
|
|
In particular, cairosvg is only used for the PNG format twitter cards,
so most functionality exists without it.
Make sure we import those modules conditionally only when needed and
handle the import exception. Also add an explicit attempt to load them
during system startup and write to the log if it fails, so it doesn't do
so silently.
|
|
If an invoice without a header was generated, the color of much other
text would end up being white on white.
|
|
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.
|
|
|
|
|
|
py3 changes the / operator from current integer division (floor
division) to instead be true division (float division). The // operator
exists in both py3 and py2 and always performs floor division.
Most of our important calculations already use Decimal with explicit
number of decimal points which is safe against this. But for some cases
like calculating pixels in pdfs and reports make sure that we explicitly
use the // so we don't risk a change in behaviour when we eventually
switch to py3.
|
|
|
|
Basically reverse the flow - instead of having the invoice system
refund an invoice and trigger an action in the attached systems (such
as confreg or membership) to remove something, have the actual end
systems like confreg handle the cancelation and just tell the invoice
system what the refund is.
This makes the system a lot more flexible and makes it possible to
handle things like multi-attendee invoices that get partially refunded
more than once.
Other than the order-reversal:
1. Each invoice can now have multiple refund notes. In doing this, the
view of "refunded invoices" has also been retired, as it makes less
sense now.
2. Refund notices now include a "previously refunded" section if they
are anything except the first refund note, to track across multiple
refunds. This creates a breaking change in the API for PDF
generation, but recent other updates to the skinning broke them all
anyway.
3. For confreg, implement "refund patterns". This is a set of rules
with "refund x% minus fees of y" rules that can be applied when
canceling a registration. They are applied to the individual costs
being refunded. They can also be given a start/end date during
which they should be used, which is used as a hint in the UI.
|
|
Don't overwrite the value of preview with a hard-coded False.
|
|
It no longer has any pgeu specifics in it.
|
|
Split apart the settings for Invoice PDF and Refund PDF builders, as
they can theoretically be loaded from different places.
Remove all PGEU specific contents from the invoices. This will now
instead go in a class that lives in the skin, if there is one. If there
is no skin, an "anonymous" invoice with basically no info will be
generated. Enough for testing, but invoices should really always be
skinned.
Rename invoices to BaseInvoice and BaseRefund to make this clear.
Make the invoice properly handle both VAT and non-VAT cases, so that it
can be used in skinned versions of both.
BREAKING change - this changes the way the invoices are configured and
called, so all skinned installations must update to cover this.
|
|
To make it easier to read, invent functions for cm() and mm() conversion
instead of doing in-place multiplication.
Clean up all other expressions in these two files to match proper
styling.
|
|
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
|
|
Many of these were masked with the using of tabs, but were basically
incorrect all the time. It's all in places where whitespace doesn't
actually matter, but let's try to match up to PEP8.
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
It needs to go on the invoice per the rules, but by definiton the
invoice has already paid when we issue a receipt, so no need to include
it there.
|
|
Per the new instructions from the tax authorities, we should do 100%
opposite of their previous instructions, and instead actually issue
reverse VAT invoices for sponsorship.
To do this, we implement a new flag on each invoice that indicates if it
should have reverse VAT. If this is used, the actual VAT must be zero,
and instead it will trigger text about it on the invoice.
Sponsors inside the EU and with a valid VAT number, but *not* inside
France, will get reverse VAT. Any sponsor without a VAT number *or* a
sponsor in France with a VAT number will get regular VAT. No invoices
are issued without VAT.
Based on this we no longer keep track of VAT number separately from "in
vat area" as our previous instructions required, so drop this field from
the database.
Finally, uses screen scraping to validate VAT numbers on the EU websites
since their SOAP service is basically broken. This can easily be turned
off in the config file (and is turned off by default) in case the
service stops working.
|
|
This helps with cases when just the PDF invoice is passed along.
Unfortunately it's still a very long link, so it's not convenient for
typing in if delivered on paper. For this case there is also a QR code
included with it. For online viewing the link directly in the PDF is
clickable and goes to the link that does not require a login.
|
|
This is an incompatible change to the API, but by doing it this way it
can be the last one. Any arguments added by a caller after this point
will be ignored if the implementation does not know about them, so new
arguments can be added without breaking things.
|
|
Previous way worked fine on the version of reportlab deployed in
production, but fails on newer versions.
|
|
If we round it off at the total, the total won't match the callers
specified total, and the safeguard fires. Could show up when multiple sets
of invoice rows all with calculated VAT on them turn into roundoff
errors.
|
|
|
|
The actual VAT calculation will have to be done manually when
a partial refund is done, since we can mix VAT amounts. This
is unlikely to happen though, and refunds in general are quite
uncommon, so we'll live with it.
In passing, implement a nicer looking refund notice since we
need to have VAT on it, including adding to the refund
notice that the payment was returned to the original form of
payment, as well as a hint to what that method was (including
the type of credit card when available).
NOTE! This makes an incompatible change to the PDF refund API,
the same way that 5c2989d did for invoices. If VAT is not used,
nothing other than just accepting the parameters and ignoring
them is required.
|
|
This implements support for handling VAT on invoices, including
automatically calculating the VAT amount as necessary.
Support is also added to the confreg and confsponsor modules to
auto-generate invoiecs with the correct VAT. The membership module is
explicitly excluded from VAT handling, as we know we don't need to
process VAT on that.
Different VAT levels are supported by registering them in the table
VATRate in the Invoices module. This rate can then be specified
individually for each row on an invoice, and for the
confreg/confsponsor modules different rates can be specified for
registrations and sponsorship on a per-conference baseis.
This leads to a number of other changs:
* Invoice amounts now deal in two-decimal fractional values, instead
of just integers as before.
* This also extends to Adyen and Paypal payments that now handle
two-decimal fractional values at all integration levels, not just
at the core API.
* The invoice layout for PGEU has a lot of changes to support showing
VAT on the different entries as well as in the summary
* Invoice titles are changed in the confreg/confsponsor modules to
be more consistent
* Sponsor signups now explicitly ask for VAT number
In general, just adding the VAT rates will make the system active, and
not adding it will leave it turned off. To enable the VAT information
colleciton for sponsorships, set the parameter EU_VAT to True in the
local settings.
NOTE! This makes incompatible changes to the PDF invoice API. An
updated implementation for PGEU is included, but downstream
implementations like pgopen need to update the PDF invoice
specification calling parameters (see change to PDFInvoice class)!
|
|
This switches invoices to use DejaVu Serif font instead of Times,
because the Times font does not have all characters we need. In
particular this has become obvious with Turkish characters.
We use DjeaVu Serif because that's what we already use for conference
badges and PDF schedules so we know it exists on our servers and that it
works for those. The DejaVu font is slightly bigger than Times, so
decrease the size by one point to make it look roughly the same as
before.
|
|
This means a few things:
1. We track refunds properly. Each invoice can be refunded once, but we now
also support partial refunds (which is important, as almost every refund we
make on a conference registration ends up being a partial one - if nothing
else it is deducted transaction fees).
2. We support API initiated refunds. That means that as long as the payment is
done using a supported provider (today that means Adyen and Paypal), the
complete invoice processing is done in the webapp, which means there is no
risk of getting the wrong numbers into the accounting (which has happened more
than once).
3. We now generate proper refund notices in PDF format for all refunds (both
automated and manual). The user receives this one as well as status updates
throughout the refund process.
Actual API refunds are handled by a new cronjob, to ensure that we don't end up
blocking the user if the API is slow. Initiating the refund puts it on the queue,
the cronjob sends it to the provider, and the notification from the provider
flags it as completed (and generates the refund notice).
|
|
Apparently in the newer versions. So instead, loop over and use textLine(),
which works fine.
|
|
Since we already have a single file with the code that builds the complete
invoice, just rename it to a different name (pgeu specific), and make it
possible to specify a completely different one in the config file.
We still only support one invoice generator per installation.
|
|
|
|
This happens if there are more than 15 items on a page, something that
was quite unlikely before, but can easily happen with bulk payments. We'd
better be prepeared for when it does...
|
|
|
|
Even though that's implied by not listing a VAT number, we keep getting
a lot of questions about this, so state it clearly. Suggested by
ads, wording by Dave.
|
|
We want new invoices to go into the new account, so update both the
donate page and the details that go on the invoices.
|
|
Previously this was excluded from receipts but not from invoices. Turn
this into a specific flag, and make sure that autogenerated invoices
(for conference registrations and memberships) don't include is, so that
people won't pay to the bank even though we don't want it.
|
|
Just not the bank transfer information
|
|
|
|
|
|
|
|
Doesn't do any conversion, just allows the creator to flag
which currency the invoice is in, and then use the appropriate
currency symbol on the invoice rows.
|
|
|
|
|
