When importing MT940 files, AqBanking will (sometimes?) put
all transactions under a single AccountInfo, even when there
are multiple accounts in the file. Luckily the correct account
information can be recovered from the transaction information.
This patch will try to use the account information in the
transaction before trying to use the saved account state.
Patch by Jethro Beekman.
On the theory that in countries where multiple languages are in use similar
date and number formats will apply regardless of language, and especially
that the default currency will be the same regardless of language.
Also ensure that the specified language is in the list passed to gettext;
the net effect of which is that the user will effectively get the requested
localization behavior.
This commit improves payment type deduction by first checking
whether an AR or AP account is found in the transaction.
If not, fall back to previous heuristic of positive action
means customer payment, negative action means vendor
action. The logic can still go wrong (no means to declare
an employee payment, and credit notes are interpreted as
opposite sign payments). Needs a follow up to fix that.
If the transaction is marked as a (business feature) payment,
extract the address of the bill/invoice associated with the
payment, or the owner if there's no bill/invoice yet.
There was nothing in the duplicate file that was different
from the original one except for the plugin_page parameter
initially passed in. Turns out we don't need anything
from the plugin_page except for the very generic GtkWindow
which is actually a member of the generic GncPluginPage
base object. So pass that window instead and avoid the
need for differentiation.
Bug 725296 reports that setting LANG=sv_SE fails to set the language.
This turns out to be an error in gettext, but it can be worked around
by setting LANG=Swedish_Sweden. That broke looking up the localized
account directory, so this special-cases "Swedish_Sweden" and
"Swedish_Finland" when looking up the account directory.
It's possible for OSX to create locales that while legal aren't
supported by setlocale, and we have account trees for some of these.
Retrieving the locale from NSLocale ignores the fixup done in
gnucash-bin to ensure that a reasonable and supported locale is used.
Release notes snippet for this change:
The default date completion when entering partial dates has been
changed from "always complete in current calendar year" to
"complete to a sliding window starting 11 months before current month".
For example if you enter "1/23" (January 23rd) while today is
December 10th 2015, the date will be expanded to
January 23rd 2016 rather than 2015.
If you prefer to keep the old behaviour, you can restore to it
via Edit->Preferences->Date/Time->Date Completion.
In addition if you were already using the sliding window
before, but didn't change the previous 6 months before
default, you will now also get the new default 11 months before.
Again if you prefer the old behaviour it can be restored via
the same Preference.
This commit adds code to check & repair that removes the read only status of the bogus transactions so the user can go in the AP/AR account and delete these bad transactions.
Translators: this commit introduces a new translatable string.
When auto-completing a transaction that was originally created in another
account with a different currency the balancing code will try to apply
conversions in the wrong direction if one edits the transaction. Explicitly
setting the transaction currency to the current register's currency
prevents the conversions being applied and allows the transaction to
balance correctly.
When a transaction with existing splits had its currency changed, the
function would change the values to use the new currency's denominator
without changing the actual value. The balancing code would then apply
the price of the the new "other" split to the amount, changing it as
well. Changing the transaction currency back would convert the value in
the other split correctly so that it would equal the amount that the
balancing code wouldn't change anything. I actually detected this bug
when I wrote the test but didn't recognize it as a bug.
The new code first calculates a new price and then applies it to each
split so that the transaction balances correctly in the new transaction
currency. This also round-trips correctly
This is a follow-up commit to fix the core of the issue.
With this commit gnucash is more liberal at accepting
counter formats. It will accept either li, lli, I64i and
whatever is defined for G_GINT_64 or PRIx64 on the user's
platform. Internally the code will always convert the
specifier set by the user with PRIx64, which should always
be the correct one on any platform.
Additionally a few extra tests were added to stress the
counter format code a bit more.
even if bill is already posted and results in extra $ posted to A/P
This adds a test in gncInvoice to return NULL it already posted.
Adds checks in dialog-invoice to test for already posted invoices. Messages
user and refuses to post entire selection if more than one selected.
Translators: This adds a message string.
