New transaction report

[dadinva]

Geert Janssens-4 wrote
> I'm afraid I don't understand what you are writing here exactly. What
> needs to 
> be exported in a way that isn't as is ? Isn't your report working in the
> state 
> this is ?
> 
> Also what is the preferred end result ? Is your report intended to
> complement 
> the existing transaction report or to supersede it ? That is, does your 
> implementation do everything the original report did and some more, or
> does it 
> only do other things from the original report ?

I am exporting functions from the gnctimeperiod-utilities.scm file which are
used in the transaction.scm report and will be used in a couple of other
reports I have planned.  They work for now since I have the file in
config.user.

This report is intended to replace the original transaction report.  I
changed 2 or 3 defaults versus the original but if they are changed back the
results are exactly the same as the original.  None of the original features
have been removed.  The original version displays transactions between a
range of dates which can be sorted on multiple items such as description or
account name.  This version does that but also lets you consolidate entries
so that only one entry is shown which is the sum of multiple entries.  It
also allows you to use a find or search command to limit the items
displayed.  It expands the menu selection for the date range to allow the
user to select a predefined date range in addition to using the custom date
ranges previously available.  The most recent addition was to display the
output in a multiple column format.

 
Geert Janssens-4 wrote
> 1. It introduces loads of new strings. This is fine in itself, however
> many of 
> them are not marked for translation. That should certainly be fixed at
> some 
> point.
> 
> 2. There are lots of small whitespace issues. While this is not really a 
> problem with your code itself it clutters our version management. I would 
> really like to see all trailing whitespace removed (unless part of a
> literal 
> string that's split over multiple lines). Also empty lines should not have
> any 
> other whitespace. And preferably stick to spaces for indentation. I know
> some 
> text editors are not really consistent in this and several other scm files
> in 
> our repo don't adhere to this. I prefer to keep these inconsistencies to a 
> minimum and avoiding them upfront is a very effective method :)

Afraid I don't know how to mark strings for translation.  I agree a load of
them have been introduced.  They basically fall into four categories:
1 Strings for selecting a date - the majority of the new strings
2. strings for the find command
3. strings for consolidating items
4. strings for multiple-column display

I have attached two new versions of the files which have the tabs changed to
spaces and the trailing spaces removed.  The transaction.scm file also has
added an additional find command for searching in the reconcilition field.

transaction.scm
<http://gnucash.1415818.n4.nabble.com/file/n4691244/transaction.scm>  
gnctimeperiod-utilities.scm
<http://gnucash.1415818.n4.nabble.com/file/n4691244/gnctimeperiod-utilities.scm>  



--
View this message in context: http://gnucash.1415818.n4.nabble.com/Re-New-transaction-report-tp4691133p4691244.html
Sent from the GnuCash - Dev mailing list archive at Nabble.com.