diff options
| author | Magnus Hagander | 2013-12-08 15:08:45 +0000 |
|---|---|---|
| committer | Magnus Hagander | 2013-12-08 15:54:50 +0000 |
| commit | d1c5e87f6edf30df62d892f3c91fa3f8ef0e3280 (patch) | |
| tree | a2f0f5cecfb87d572ae94990721be8ee524c8018 /postgresqleu/paypal/views.py | |
| parent | 361e0d856b857e5b7d20a439bf8fc06be6359a76 (diff) | |
Automatically generate accounting records on payments
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).
Diffstat (limited to 'postgresqleu/paypal/views.py')
| -rw-r--r-- | postgresqleu/paypal/views.py | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/postgresqleu/paypal/views.py b/postgresqleu/paypal/views.py index dcca1819..1667899b 100644 --- a/postgresqleu/paypal/views.py +++ b/postgresqleu/paypal/views.py @@ -134,6 +134,9 @@ def paypal_return_handler(request): (r,i,p) = invoicemanager.process_incoming_payment(ti.transtext, ti.amount, "Paypal id %s, from %s <%s>, auto" % (ti.paypaltransid, ti.sendername, ti.sender), + ti.fee, + settings.ACCOUNTING_PAYPAL_INCOME_ACCOUNT, + settings.ACCOUNTING_PAYPAL_FEE_ACCOUNT, payment_logger) if r == invoicemanager.RESULT_OK: # Matched it! |
