While I do all my accounting with Tryton, all my supporting statements are still
on paper and I attach a copy of the corresponding account move to each
supporting statement. Everything is archived in multiple folders (expenses,
revenues, bank, taxes, misc).
Up to now I copied the account move manually in pre-printed forms for generic
account moves (see attachment piece_comptable.odt) and the reference number I
used in my ledger was the same than the unique number printed on those forms.
With the switch to tryton, I have many more account moves because I'm no longer
using some of the not-so-clean shortcuts I was used to use (like recording
expenses directly as credit of the bank account instead of going through a
proper invoice recorded in a supplier account) and it would be really useful if
I could print all those account moves instead of copying them manually.
I believe that this should be a relatively easy enhancement to implement.
The only possibly tricky part is how to put two account moves per A4 page if we
want to keep the same layout than I used to use (with an A5 paper in landscape
mode for each account move). That said this is not a requirement and any
solution that doesn't waste a full page per account move while still ensuring
that account moves can't be split over multiple pages is OK (except for account
moves that have an unreasonable number of moves of course). Note that we can
defer this to the user side by using a full landscape A4 and letting the user
print in 2 pages per sheet mode.
- why not put both the move number and post_number like that no need to have two
cases
- why not put date, journal post date and origin on the same line
- I think it is better to always show description even if empty
- For the account use rec_name and not a custom format
- I think you use a stronger lines for the table as other reports
- Generally we don't put so much spacing between tables or it should be a page
break.
- For post date, you should test only if the date is filled
- Use ternary operator instead of and/or
- Use rec_name for journal
About your comments, please note that I started from general_journal.odt so most
of your comments actually apply to general_journal.odt too...
> why not put both the move number and post_number like that no need to have two
cases
general_journal has two cases to showing "Posted _number>" or "Draft" so I
build on this to show the state of the account move as part of the table title...
> why not put date, journal post date and origin on the same line
Because journal name and origin are often long strings (the latter in
particular) and we waste less space by giving them more width by default.
> I think it is better to always show description even if empty
OK.
> For the account use rec_name and not a custom format
OK, but this is a left-over from general_journal.odt.
> I think you use a stronger lines for the table as other reports
Actually I use two line width. The same as other formats for interior lines and
a larger one to split the multiple parts (header part, lines part).
> Generally we don't put so much spacing between tables or it should be a page
break.
As I explained, my goal is to print the report and cut the individual account
move. The additional space makes it easier to cut the paper and later attach it
to the corresponding supporting statement. So this is a feature.
> For post date, you should test only if the date is filled
OK.
> Use ternary operator instead of and/or
> Use rec_name for journal
Attaching a new version of move.odt that includes your suggestions. The only
detail that I don't know how to fix is how to include the "Draft" string on the
same title line so that a draft move shows "Draft Account Move (#123)" as title.
I could include the logic in a field but then the "Draft" string would no longer
be translatable...
- The first title doesn't have the style "Table Heading"
- I will put border on the table as it is done on every other standard report
- Other reports don't use a table for general information like date, journal etc.
- Why not putting each move on his own page?
About the print of state, I think we should wait #3679 (closed)
It would be nice to get this done, I believe your last comments are minor and you should be able to fix it easily yourself and merge it. I just unassign myself because I'm tired of the weekly mail.
That said I'd like to not put each move on its own page. As I explained, my use case is to print the move for archival and I print multiple move per pages to save paper and clip them together with the supporting papers. It wpuld be wasted paper to have a full page for each move.
For 4.3 (default) I needed to update move.odt to use new names.
At the same time I added the journal code as well as a column for 'Party'.
As to single opérations, I'm satisfied with this and hope this gets
committed as soon as possible with the addition of the translated report field names.
BTW: In the attached updated move.odt, I use the hybrid page size (21x27,94) and language set to none as indicated in Issue5464, to show that it seems to work nicely.
one more point, although not necessarily restricted to this report,
it would be nice to have the date-time of edition indicated, which greatly
helps during multiple pass revisions.
This could be easily done with a standard report header or footer, for example.
Page numbers would also be useful.
Also, how to get on the origin line the 'comma' form with the origin type prefixed? For example, 'Fiscal year, 2016' or 'Invoice, FF16-132'
This is what the move lines form on journal entries displays.
I'm getting big-winded, but there was one more point in the account column where
blank lines are printed if line.description is blank. It would save a *lot* of space on multpage outputs to only print one line in absence of any line description...
I quickly tried with an <if test=...> clause, but couldn't seem to get satisfaction... unfortunately I'm not very experienced yet with the report enging.
regardless of the actual report (move.[f]odt) provided (which can be tailored to local needs without python code changes), please push this capability for v5.
To include in 5.0, it is too late as the translation window is already open (and the main languages are already fully translated).
But I still do not see the common need for such report. I understand in msg15689, it is for a particular use case when still doing accounting manually on paper. But this is not the general common usage of Tryton.
I'm not doing accounting on paper, I keep a paper copy of my accounting because it's one sefe way to archive accounting. I have to store all received invoices anyway and I like to attach the corresponding move.
Common or not, there are valid use cases and it's really a pity that this languished for so long.
In any event, and in particular for moves that are exceptional (eg 'OD' moves)
the accounting move accompanied with its justification are typically stored in a folder for consultation during the revision process by certified accountants as well as during audit.
BTW Complete journals need to be printed by period for archiving,
not just the general journal. The move is one entry in the journal.
In the mémo pratique comptable that I sent to the Tryton foundation (or in a more recent version), please refer to the Chapter 'Les obligations générales permanentes'
There are naturally other sources of pertinent requirements as well.
FWIW, the initial clause <for each="move in objects"> needs to be changed in 5.8 to <for each="move in records"> in move.odt. This is due to https://bugs.tryton.org/#9654 as documented in the migration notes to 5.8.
The contents and format of the default report risk debate, so guess I'll start:
(these hold true for all accounting reports)
need explicit mention of move.journal code (at least) and optionnally the name
the account.rec_name is used instead of separating account.code and account.name... typically account codes are <= 8 characters... Given most (at least european) account plans have rather verbose account names, it would probably be easier to read the account.name and party in a separate field.
NB: many journal moves have only the move.description and no line.descriptions so the report in this case has cramped into the tiny account field all three, with a huge description field blank... one idea I've seen done in some accounting packages is to layer the account.name, line.party and line.description into one field taking, in this case, between 1 and 3 lines.
the currency symbol is repeated in each and every monetary field whereas accounting software usually reports in a single currency.
So either the currency symbol shoud be mentioned once (for the whole report) or in the labels - such as 'Debit (€)' and 'Credit (€)' which is what we've chosen. There is missing already critical real-estate in the reports for large numbers (in the tens, hundreds+ of thousands) without adding these symbols... and wrapping is ugly. (the review report wraps already at 10K!)
Otherwise, customising the report remains naturally the work-around.