Issue 3696

Add a report to allow printing of account moves
Nosy list
ced, reviewbot, rhertzog, risto3, roundup-bot, timitos, yangoon
Assigned to

Created on 2014-02-20.11:13:12 by rhertzog, last changed 20 months ago by roundup-bot.


File name Uploaded Type Details
move.odt risto3, 2017-03-25.11:11:54 application/vnd.oasis.opendocument.text view
move.odt yangoon, 2014-06-30.21:28:31 application/vnd.oasis.opendocument.text view
move.odt rhertzog, 2014-03-14.17:10:25 application/vnd.oasis.opendocument.text view
move.odt rhertzog, 2014-03-08.22:53:56 application/vnd.oasis.opendocument.text view
piece_comptable.odt rhertzog, 2014-02-20.11:13:11 application/vnd.oasis.opendocument.text view


New changeset f9dd547af7f4 by Cédric Krier in branch 'default':
Print general journal from moves
New changeset fb89dcf7c374 by Cédric Krier in branch 'default':
Print general journal from moves
Author: [hidden] (risto3)
Date: 2021-02-23.09:38:32

Since we fixup the report format anyway, +1 to see this committed so we can remove our patchset.

Author: [hidden] (risto3)
Date: 2021-02-19.11:23:25

Forgot to mention, too, that 'Général Journal' is doubled up... once in the 'header' section, and again in the main section.

Author: [hidden] (risto3)
Date: 2021-02-19.11:20:29

Nice to see this advance... +1 for the approach.

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 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 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, 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.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-02-18.23:49:29

Indeed we could reuse the general journal report. By the way we could also remove the wizard as it is just a form to select dates.

Author: [hidden] (risto3)
Date: 2020-12-01.18:00:28

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 as documented in the migration notes to 5.8.

Author: [hidden] (risto3)
Date: 2018-11-04.12:47:12
In addition to Lefebvre, here are two useful references: 
(B. Périmètre du contrôle de la comptabilité informatisée)
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-09-26.14:58:38
I do not find in the designed book where it is said that account moves must be printed on paper. Please provide the page number where this is stated.
Author: [hidden] (risto3)
Date: 2018-09-26.14:32:16
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.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-09-26.14:06:35
Do you mean that in French, you are legally obliged to print your accounting on paper and that you can not store and archive it in numeric format?

For the justification piece archive, this can be done simply by attaching a the document (as now most of them are digital) or a scan on the record.
Author: [hidden] (risto3)
Date: 2018-09-26.13:54:29
no, not at all.

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.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-09-26.09:35:20
Is not a dump of the database enough to archive accounting?
Author: [hidden] (rhertzog)
Date: 2018-09-26.09:29:06
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.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2018-09-25.18:35:38
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.
Author: [hidden] (risto3)
Date: 2018-09-25.17:54:22
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.
Author: [hidden] (risto3)
Date: 2017-03-25.11:31:01
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.
Author: [hidden] (risto3)
Date: 2017-03-25.11:24:42
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.
Author: [hidden] (risto3)
Date: 2017-03-25.11:18:23
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.
Author: [hidden] (risto3)
Date: 2017-03-25.11:11:54
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.
Author: [hidden] (rhertzog)
Date: 2017-01-16.12:03:56
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.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2014-09-12.19:31:32
issue3679 is solved.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2014-07-10.00:38:55
Few comments on the last report:

- 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 issue3679
Author: [hidden] (yangoon) Tryton translator
Date: 2014-07-01.10:08:31
amsg17374: Finally I would prefer to use 

like in account_invoiice/invoice.odt, rather duplicating strings, but only prviding one logic for the title.
Author: [hidden] (yangoon) Tryton translator
Date: 2014-06-30.21:28:31
Hi Raphaël, 
I attached a quick version using a hack with tables, but at least it does, what seems to be intended.
Author: [hidden] (rhertzog)
Date: 2014-06-30.16:23:56
Any chance you could give some guidance on how to go further with this ticket? I have answered your questions and provided an updated file.
Author: [hidden] (rhertzog)
Date: 2014-03-14.17:10:25
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...
Author: [hidden] (rhertzog)
Date: 2014-03-14.16:31:48
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

general_journal has two cases to showing "Posted <post_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


> 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

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


> Use ternary operator instead of and/or
> Use rec_name for journal

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2014-03-08.23:21:53
About the layout:

- why not put both the move number and post_number like that no need to have two
- 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
- For post date, you should test only if the date is filled
- Use ternary operator instead of and/or
- Use rec_name for journal

PS: be sure to follow:
Author: [hidden] (rhertzog)
Date: 2014-03-08.22:53:56
Attaching move.odt that is part of review4131002 on request of ced.
Author: [hidden] (rhertzog)
Date: 2014-03-07.00:15:54
I submitted a proposed fix for this in review4131002
Author: [hidden] (rhertzog)
Date: 2014-02-20.11:13:11
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.
Date User Action Args
2021-03-16 22:14:17roundup-botsetmessages: + msg65570
2021-03-16 22:14:12roundup-botsetmessages: + msg65569
nosy: + roundup-bot
status: testing -> resolved
2021-03-07 23:37:10reviewbotsetmessages: + msg65272
2021-02-23 09:38:32risto3setmessages: + msg64782
2021-02-19 12:37:01reviewbotsetmessages: + msg64709
2021-02-19 11:23:25risto3setmessages: + msg64708
2021-02-19 11:20:29risto3setmessages: + msg64707
2021-02-19 00:04:06reviewbotsetmessages: + msg64701
nosy: + reviewbot
2021-02-18 23:50:11cedsetreviews: 4131002 -> 4131002,347601003
status: in-progress -> testing
2021-02-18 23:49:29cedsetassignedto: ced
messages: + msg64700
priority: wish -> feature

Showing 10 items. Show all history (warning: this could be VERY long)