SQLite backend.
Release Note: This bug caused data loss if you saved your SQLite3
database to a different file or database.
The problem is that in SQLite3 (though not in MySQL or PgSQL) the
subquery ((SELECT DISTINCT guid FROM transactions)) (note the double
parentheses) returns only the first guid in the subquery's results.
Some transactions are loaded by special queries and those queries are
also used to retrieve the transaction's slots so they weren't affected.
First change is to ensure gncEntry rounding is consistent. Internally
calculated values in the entry are never rounded. Consumers of
gncEntry's calculated values can request them either rounded or not.
Next use a pragmatical approach for calculating values on invoices based on
the entry values: do the rounding such that we never
create an unbalanced transaction while posting
That means
- round each entry's net value before summing them in net total
- accumulate all tax totals on invoice level per tax account before rounding
and round before before summing them in a global tax total
Hopefully this will catch a few more rounding issues in this area.
A complete solution can only offered if we allow users to manually correct
tax entries. This requires changes to user interface and data format
so that's not going to happen in gnucash 3.x.
strptime/strftime supports various modifiers to their parameters.
'E' and 'O': alternate locale-specific formats
(used in default format for Persian, Oriya, Azerbaijani)
'-': padding
(used in default format for Czech)
GnuCash passes dates as integer y/m/d without using locale-specific
formats, so we need to strip out 'E' and 'O' from the format when
scanning dates or determining separators in gnc-date.
None of '-', 'E', or 'O' are supported by boost (and '-' causes
errors), so strip them out from formatters in gnc-datetime as well.
See https://bugzilla.gnome.org/show_bug.cgi?id=795247.
This will probably need more refinement because the multiplications
are still missing rounding methods, but the changes in this commit
will already allow guile code to correctly create entries.
The transfer dialog was set up as a child of the reconciliation dialog.
However as the latter is closed it's child dialogs are closed as well.
At least that's the behaviour on Windows. This didn't happen on Fedora 27.
Regardless it's fixed by making the account register the parent of the transfer
dialog.
When the reconcile column was moved, the default sort order was not
altered for the change so fixed it. Also added enum so model columns
can be referenced by name which hopefully will make it easier to read.
This is used in conjunction with (gnc:options->sxml) to extract
html table cells.
From SXML tree, retrieve, from a <table>, the th/tr/td cells as a list
of string.
Clearer syntax helped find flawed test - while set-tm:mday directly
accepts 1-31, set-tm:mon accepts 0-11 to represent 1-12, therefore
must minus 1. set-tm:year accepts 92 to represent 1992, therefore must
minus 1900.
We want to sanitize render-options-changed, therefore it must return
an html-object. Unfortunately this is not accessible to
app-utils/options.scm. If we move this function to
report-system/html-utilities.scm, it can access html-objects.
Also rename it to gnc:html-render-options-changed
The previous names were remnants of old transaction.scm and were not
exactly consistent. Use more descriptive names.
The only user-visible change is elimination of <br/> in the
common-currency account header, because this will be sanitized. The
table col-headers cannot unfortunately accept a (gnc:make-html-text)
object therefore we cannot add <br/> at all. I vote to display
e.g. "Debit (USD)" instead.
This commit will add a filter to include/exclude closing
transactions. In conventional reports, they are usually disruptive to
the regular periodic reporting and the default ensures they are not
included.
This commit also changes income-gst-report.scm to use the closing
filter just created, and disable its UI.
This commit will modify the custom sorter to reuse 'split-sortvalue
comparators. The original purpose of these functions was to *compare*
splits *during* table generation to determine whether a subtotal group
was changed. These functions can be easily reused by the custom sorter
to *sort* splits *before* table generation.
Also modify the sortkey renderer logic to catch all non-date,
non-account sortkeys into the generic string renderer.
This function checks whether the sortkey can be grouped. Instead of
manually creating list, test it dynamically.
Sortkeys whose 'renderer-fn is defined can be grouped.
