| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This code was copy/pasted between several different places, so
centralize it into the InvoiceManager class to reduce the risk of
furhter off-by-one mistakes when editing.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
It has been deprecated, and instead we should use "in" and "not in", so
make that change across the board.
|
|
Disencouraged by pep8 due to hard-to-read
|
|
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
Surprisingly many of these were pure copy/paste errors from the same
source...
|
|
|
|
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!
|
|
This udpates adyen, braintree, paypal and trustly to use the new
rendering functions.
|
|
Turn it into a settings.py variable instead, so this mistake isn't made
next time.
|
|
Need to match this one to not generate errors and thus emails to
treasurer@.
|
|
We can't do that inside a @transaction.atomic block. It's also not
necessary, because paypal_error is only called before any database
modifications are made, and returns out of the view directly.
|
|
Instead, as of now we run all content over https always. The enforcment of this is
placed in the webserver, which makes it impossible to miss it on some feature.
This retires the setting SITEBASE_SSL, and changes SITEBASE to be https.
It also retires DISABLE_HTTPS_REDIRECTS, which has no use anymore.
And finally, SESSION_COOKIE_SECURE is now set by default, and needs to be turned
off in local development environments.
|
|
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.
|
|
|
|
Since our lookup to paypal can take a long time, sometimes a second
notification fires while we're still looking up the first one. To avoid
a key conflict in the db, repeat the check for existing transactions
before writing the new one, and if it's already in there, ignore the
new one. We assume that the result is going to be the same for both
of them.
|
|
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.
|
|
|
|
In passing, fix a couple of bugs that this uncovered.
|
|
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 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).
|
|
This makes sure we don't end up with huge amounts of error logs for
each donation before someone manually flags it in the database.
We do the matching simply based on the transaction text. If somebody
else makes a payment with that specific text we'll do a false match,
but this can never happen for actualy payments since they have the
invoice information in the title.
|
|
We already did this for Adyen payments, and it's good to know for followup
in our budget works if nothing else...
|
|
|
|
Seems paypal have changed which fields include the transaction text,
which is obviously something we need to match the invoices.
|
|
In order to pay these invoices, it's necessary to be able to view them
on the website, which previously required a community login attached to
the invoice. We now genereate a secret URL for each invoice (based on a
SHA256 hash of the invoice itself and some random nonce). If this URL
is used to access the invoice, a login is no longer required.
It's still more convenient to use the logged in version of course, since
that lets you view your invoice history. Also, all autogenerated invoices
such as those from confreg and membership will still be using the logged
in version.
|
|
Therefor, we need to convert it to utf8. It is supposedly win1252, but that
should be close enough to latin to work.
|
|
Now uses a decorator instead of manual checks inside each view.
Also add SSL decorators to the new invoice and paypal code to make sure
it's served over SSL.
Finally, define two new settings for SITEBASE and SITEBASE_SSL to override
the website names in a local sandbox install. Makes it possible to for example
test the full paypal workflow, since we need to be able to pass an actual
working URL to paypal in that case.
|
|
This means that the payment flow comes right back from paypal, and we can
flag the invoice as paid as the users browser gets there. We'll then redirect
back to the invoice specification or conference registration as part of the
same workflow, so no manual refreshes are required.
|
|
Separate collecting of paypal information from matching payments.
Implement payment matching for membership fees.
Implement sending of reports of unmatched payments as well as general
activity reports.
|
