| Age | Commit message (Collapse) | Author |
|---|
|
Transferwise re-invented interest and call it cashback (it's the same as
interest..), and we already knew how to classify these transactions. So
instead of leaving them as pending, automatically book them against a
predefined account.
|
|
|
|
Due to the new transferwise restrictions, creating payouts would crash.
This change attempts to make it complete the parts that work and leave
the rest for a manual approval in the transferwise web interface,
hopefully keeping the rest of the system working.
When half way complete, send a notification to the user to go complete
it manually.
|
|
Turns out we need to do this both for primary ands secondary amounts
(which makes sense). Clarify the comment a bit further after more
research that still shows Wise API returns that incoming payments are
actually outgoing. Sigh.
|
|
It's just for display and they're easier to identify this way.
|
|
Clearly missed one field in the update, that was still referencing the
old API structure.
|
|
So remove the scheduled job that handles them, as well as the database
table that stores them.
|
|
Unfortunately, Wise decided one is no longer allowed to access
information about ones own transactions when in Europe, unless
registered as a European payment provider. This is of course stupid, but
what can we do.
Attempt to re-implement the transferwise support over their new
activities API.
Unfortunately there are likely bugs still hiding around, since for
example amounts are now returned in some self-invented html-like markup
like '<positive> 2,000 EUR</positive>' instead of as a number like
before (and sometimes they are returned as <positive> with a negative
number inside). But we have to start somewhere...
Unfortunately, it seems there's a permanent loss of funcionality in that
the account number (IBAN) of the sender is no longer available anywhere
in the API. This means that in practice, automatic refunds of transfers
are no longer possible. (This information appears to also no longer be
available on their website). We keep the refund functionality itself in
the system for now, as we might want to extend it later with the ability
to refund while manually specifying an IBAN number.
|
|
|
|
|
|
|
|
Our check only worked properly if the primary currency was the one we
used, and it seems wise can open a new balance and just chance the
primary currency on us, so update the check.
|
|
It seems on some records, wise returns 'No information', and on some it
returns '', so explicitly check for both these inthe backoff
functionality.
|
|
If we receive a transaction with type UNKNOWN and an empty description,
delay processing it for up to 2 hours. It seems some data is simply not
available immediately. The 2 hours is a guess on how long, and hopefully
a decent mix between working and delay.
|
|
Apparently it takes longer to get our data sometimes
|
|
Seemsfor card cashback (unlike account cashback) they explicitly set the
sender to null (instead of just leaving it out), so we need to turn that
into an empty string before trying to save it into a not null field.
|
|
We perviously hadnled empty references and missing referenes, but not if
they both existed and were NULL.
|
|
|
|
|
|
|
|
BIC codes can somehow be 8-11 chars in wise sender records. We
still don't care about the BIC code, just the IBAN, so just make
the regexp for getting it a bit more forgiving.
|
|
Preivous code incorrectly assumed there would be at least some fee to
the payouts, so it would cause a crash if it was free. Their docs still
say it shouldn't be free, but their API disagrees, so make the addition
of the fee entry conditional.
|
|
Sometimes (newer entries?) transferwise adds both the BIC and the IBAN code,
and do so in the same field. This is undocumented and not even incuded in
their examples, but seems to be persistent enough to process so we get
working account numbers in more cases.
|
|
|
|
This can happen for non-bank transfers. We should just record it and
leave it as an entry to deal with manually.
|
|
|
|
Missed completely in 03938de8ae7cfac271e01d83457e844fdd3f12d0. Oops.
|
|
This becomes a requirement on Oct 1 to support statement fetching (which
we use both to update accounting and to fetch monthly statements) and
for funding transfer requests (which we use for refunds and payouts).
Initially it's optional and has to be enabled separately in the
transferwise account.
This method uses a RSA public/secret keypair (stored on the invoice
payment method, so this needs to be generated before the requirement can
be enabled, and the public part of the key needs to be uploaded) to sign
a token when making the request. Note that the actual request itself is
not signed, only the login.
Fixes #56, though the funding is not fully tested yet due to the sandbox
not containing all functionality and no payments being queued up in
production.
|
|
Apparently it's forbidden to create recipients with only one name, there
has to be at least two parts separated by a space (but can be more than
two parts). If this happens, just duplicate the name with a space in
between, as the name of the recipient is actually completely irrelevent.
|
|
This was already done once in 8289e05cd but had not been properly
maintained.
|
|
This will work differently for conferences and non-conferences once we
add proper timezone support, so abstract it out into a separate couple
of functions. For now they both return the same thing, but this will
change in a later commit.
In passing, fix missing datetime.now() -> timezone.now() conversions.
|
|
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.
|
|
It seems there are more combinations in names that are OK to receive
from but not OK to send to... Since the name isn't compared to anything,
just replace the comma with a space. (This is similar to 954fb04c4 which
disallowed digits)
|
|
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.
|
|
|
|
|
|
|
|
|
|
TransferWise doesn't send statements automatically, and downloading them
is limited by the single-user-per-account-system. But since their API
allows downloading of a PDF statement between arbitrary dates, use that
to download the statements once per month and email them as an
attachment.
The function is optional and turned on/off on a per-paymentmethod basis.
|
|
It appears some banks can actually pass along an accountnumber being
Unknownbankaccount, which will then (of course) fail to validate.
|
|
It really makes no sense beyond that, so just limit it when loading to
make sure the system doesn't crash. If the sender can't manage to get
the important parts into the first 200 characters, it will just have to
be handled manually.
|
|
TREASURER_EMAIL is supposed to be used in templates, but actively by the
code, but usage in the wrong way had snuck in. Remove that, and to deal
with that add a field to TransferWise configuration for
notification_receiver.
While at it, put a comment in the config file explaining what it's for.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
