The recursive quickfill code had several expensive
function calls that could be moved out of the recursion.
In addition using qof's string cache would result in
an expensive call to g_str_hash for each iteration, which
quickly degraded performance on huge accounts.
I have removed the use of qof's string cache from quickfill
which considerably improves performance of opening the
register for a huge account at the expense of slightly
more memory overhead.
For example I saw register load time reduce from 75 seconds
to 2 seconds, while using 20kb more memory.
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.
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.
