| 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.
|
|
This field is empty on AUTHORIZATION notifications and on some newer
notifications it appears to then simply not be included.
|
|
|
|
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.
|
|
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.
|
|
We dont want to lose things, but we dont mind loose things..
|
|
|
|
|
|
|
|
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.
|
|
|
|
Instead of never doing anything about them other than sending an email,
add a setting for ADYEN_IS_TEST_SYSTEM. If this setting is True
(default!) and the notification comes in from the adyen test
environment, process it as normal. If it's False and the notification
comes in frmo the live environment, process as normal. Only if there is
a mismatch is the email generated.
In passing, change the term "test system" to "test environment", to make
it more clear.
|
|
It's a lot cleaner API than urllib2, and will be easier once we port
version.
Hopefully this doesn't break something. Probably it does break encoding
somewhere, because py2.
|
|
Sibling imports should be prefixed with a period. Good idea in py2, will
eventually become required in py3, so another small step.
|
|
Python 2.6 introduced the better syntax, Python 3 removes the old one,
so one small step towards py3.
|
|
|
|
In passing remove some comments that were pointless
|
|
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!
|
|
We already had the payment references in a parameter, but for some
reason not the refunds.
In passing, add ORG_SHORT_NAME to the settings and org_short_name to the
context on all pages, to make it easier to do this in the future.
|
|
Importing from django.core.urlresolvers is deprecated in favor of django.urls.
|
|
The invoice API actually allows us to get the reason for why the
processing failed, so use that instead of just throwing an exception.
In particular this lets us track the case of invalid size payment in
relation to invoice amount (never happened so far), and also payments
that happen after the invoice has been deleted (theoretically possible
with creditcard payments, but very much realistic with iban payments --
it's more surprising it hasn't happened before).
In these cases create an empty accounting record that can be processed,
instead of leaving things in incomplete state.
|
|
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.
|
|
The correct spelling is credit card and not creditcard as we had
in various places. Correct all userfacing occurrences except the
already published financial reports.
|
|
This reverts the workarounds in 6b382af and c3ae5ec as they are no
longer necessary. Seems like the actual fix was a lot easier than the
workarounds..
|
|
|
|
|
|
Since we round such payments down to 0, the accounting system throws an
exception because the record becomes invalid.
Instead, special-case this and flag it as FIXME in the accounting system
for manual processing.
|
|
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).
|
|
It's a "lossy tracking", since we allow invoices that are not paid with
an explicit payment method, to maintain some of the decoupling that existed.
With this, we can now also show for each invoice how much the payment fees
were, which will make it easier to deal with refunds.
|
|
|
|
|
|
|
|
This will be visa/mc/amex, but also (and the reason for this addition) separates
out banktransferIban for the new payment method.
|
|
There is no real currency on report notifications, but Adyen pass along a
hardcoded value of EUR. This rejected the notification when the system was
configured for a non-EUR currency.
With this change, we accept all notifications that are for report availability,
even if they're not in the primary currency, but still reject any other kind
of notifications.
|
|
|
|
Put the EUR abbreviation and the € symbol as settings in settings.py
instead, with the default obviously being Euro. We still only support
one currency per installation configured globally, to keep things simple.
The paypal integration requries a separate setting for currency, as
some of that code is not in django (yet).
This is intended in particular to be able to run the confreg system
for non-euro conferences, but the settnigs are made global for the site.
|
|
Instead of just including the payment reference, we also include whatever
text was entered into the POS terminal. That makes it a bit more reasonable
to understand what's going on.
Suggested by Guillaume
|
|
It's not fully automated. When a refund is sent, an open entry is
created, where the treasurer will have to match it to the original
transaction(s), and make sure the money is taken out of the appropriate
account and object. It's automatically booked against a short-term debt
account.
When the settlement batch completes, we now process the refunded entries
automatically against the rest of that batch.
|
|
It never hurts to have a linkback to Adyen and Paypal as well as
the link directly to the invoice - since we have the info.
|
|
|
|
This makes it possible to link to for example scanned invoices stored
elsewhere.
Automatically generate attachment URLs for invoices generated in our
system, as well as for manual Adyen payments.
|
|
This reverts commit 693f93df9490f9a3121b51b0bb8ad1ea8ff38f6e.
This means we are now auto-generating accounting entries, as intended.
|
|
To make sure we don't stop payments from working while working
on setting up the base information.
|
|
This will automatically create as much as possible of accounting records
when payments arrive that we already know about. This menas either
automated payments through Paypal or Adyen, or manually flagged invoices.
Transactions that are fully specified (typically those caused by an invoice
being paid) will automatically be closed and no manual work is needed.
Transactions that are not fully specified will be left with an open
accounting entry for manual completion.
For manually flagged invoices, there will be a single accounting entry,
with the full cost. If any fees show up later, they will need to be
processed later.
For Paypal paid invoices, there will be a single accounting entry,
containing both the payment entry and the cost (going to different
accounts of course). Paypal has it's own balance account, from which
we make manual transfers in and out - and those manual transfers have
to be manually accounted as well.
For Adyen paid invoices, multiple accounting entries will be made. When
the payment is authorized, one entry turning it into a short-term
receivable under "Adyen authorized payments" for the full amount. Once
the settlement completes, the fee will be known and posted to the
cost account, and the remaining amount is moved to the "Adyen
payable balance". Once the payout happens, it will need to be manually
moved from the payable balance account to the main bank account (this
step could possibly be automated in the future).
Refunds are currently not tracked automatically, they have to be
fully manually processed.
With this change we now track accounting accounts and objects on the
invoices. These fields can be left empty for manual processing, and
there's intentionally not a foreign key in the database between these
systems to keep them loosely connected. Conferences in the registration
system now also carry a field to keep track of which accounting object
transactions should be posted to - but the actual account numbers are
per system (e.g. confreg vs membership).
|
|
|
|
We don't really do anything with them, other than collect the information and
link it to the original payment. In particular, we do NOT attmpt to cancel
any existing registrations or invoices, or anything like that.
|
|
|
