| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This was already done once in 8289e05cd but had not been properly
maintained.
|
|
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.
|
|
2to3 doesn't do this automatically, probably because weird things can
happen if you had both. We know we didn't, so just do a straight
replacement.
|
|
|
|
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
This will be required in future Django versions, and currently throws
deprecation warnings.
|
|
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..
|
|
nulls are meaningless for many2many and missing/conflicting default values.
|
|
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.
|
|
|
|
Makes it easier to find the correct raw notification - instead of having
to manually compare the exact date of processing.
|
|
|
|
|
|
Include both when the report is downloaded as well as the full contents
of the downloaded report in the database.
|
|
Previously this required looking up in the notification, but it makes sense
to materialize this in the transaction status, to make it easier to work
with.
We also now track the settled amount separately, so we can summarize the fees
easily.
|
|
|
|
Also, track settlement timestamp as a separate field. We don't set it
yet since we don't have the report processing done.
|
|
|
|
|
|
This squeezes a large number of commits over time, and should at this
point contain a more or less complete Adyen processor. There are some
things around reports that still need to be merged, once we have some
real reports to look at. Notifications are at this point not fully tested,
since we have no place to send them in the testing environment yet.
Cron jobs are not yet merged, that will send summary reports and such
things. Instead, I will verify it manually each day in the beginning,
and then write the scripts :)
|
