Created on 2014-02-20.11:13:12 by rhertzog, last changed 1 week ago by risto3.
Since we fixup the report format anyway, +1 to see this committed so we can remove our patchset.
Forgot to mention, too, that 'Général Journal' is doubled up... once in the 'header' section, and again in the main section.
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 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.
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.
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.
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/issue9654 as documented in the migration notes to 5.8.
In addition to Lefebvre, here are two useful references: http://rfcomptable.grouperf.com/article/0387/ms/rfcompms0387_5654386.html http://bofip.impots.gouv.fr/bofip/2899-PGP.html (B. Périmètre du contrôle de la comptabilité informatisée)
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.
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.
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.
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.
Is not a dump of the database enough to archive accounting?
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.
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.
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.
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.
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.
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.
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.
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.
issue3679 is solved.
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
amsg17374: Finally I would prefer to use IF TEST... CHOOSE TEST... WHEN TEST like in account_invoiice/invoice.odt, rather duplicating strings, but only prviding one logic for the title.
Hi Raphaël, I attached a quick version using a hack with tables, but at least it does, what seems to be intended.
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.
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...
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 <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 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 OK.
About the layout: - 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 PS: be sure to follow: https://code.google.com/p/tryton/wiki/ODTGuideLines
Attaching move.odt that is part of review4131002 on request of ced.
I submitted a proposed fix for this in review4131002
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.
|2021-02-23 09:38:32||risto3||set||messages: + msg64782|
|2021-02-19 12:37:01||reviewbot||set||messages: + msg64709|
|2021-02-19 11:23:25||risto3||set||messages: + msg64708|
|2021-02-19 11:20:29||risto3||set||messages: + msg64707|
nosy: + reviewbot
|2021-02-18 23:50:11||ced||set||reviews: 4131002 -> 4131002,347601003|
status: in-progress -> testing
|2021-02-18 23:49:29||ced||set||assignedto: ced|
messages: + msg64700
priority: wish -> feature
|2020-12-01 18:00:28||risto3||set||messages: + msg62327|
|2018-11-04 12:47:12||risto3||set||messages: + msg44765|
|2018-09-26 14:58:38||ced||set||messages: + msg44144|
Showing 10 items. Show all history (warning: this could be VERY long)