summaryrefslogtreecommitdiff
path: root/postgresqleu/paypal/views.py
diff options
context:
space:
mode:
authorMagnus Hagander2013-12-08 15:08:45 +0000
committerMagnus Hagander2013-12-08 15:54:50 +0000
commitd1c5e87f6edf30df62d892f3c91fa3f8ef0e3280 (patch)
treea2f0f5cecfb87d572ae94990721be8ee524c8018 /postgresqleu/paypal/views.py
parent361e0d856b857e5b7d20a439bf8fc06be6359a76 (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.py3
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!