Analytic Balance report fails when many entries: '<Paragraph at 0xb47494c>Code' too large on page 2

Hello,
 I am attaching 2 patches here.

Both the patches are the solution:
The first patch : All accounts on separate page ( look at the header, on separate page).
The second patch : All acounts on a continuos manner. (header comes once only).

Please notify for the best ergonomical way.

Thanks.

Hello,

Thank you for you patch, the accounting balance work now. Four us the best ergonomical way is the second patch with all accounts on a continuos manner.

So Jay,

I think it's better to package that 2nd patch both for 5-0 and trunk branch
so it gets included in next 5.0.4 release.

Thank you again.

Raphaël Valyi

On Wed, May 13, 2009 at 3:42 PM, Alexis Deméaulte <
<email address hidden>> wrote:

> Hello,
>
> Thank you for you patch, the accounting balance work now. Four us the
> best ergonomical way is the second patch with all accounts on a
> continuos manner.
>
> --
> Analytic Balance report fails when many entries: '<Paragraph at
> 0xb47494c>Code' too large on page 2
> https://bugs.launchpad.net/bugs/365132
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenObject Addons Modules: In Progress
>
> Bug description:
> Hi,
>
> This bug can be seen on trunk, but it shows up only if you have enough
> entries.
> To trigger it, go in Financial Management > Configuration > Analytic
> Accounting> Analytic Accounts
> then select some account and print the analytic balance.
>
> It looks like if all entries fit within the page, then it's OK.
> But as soon as you have many accounting moves, then you likely involve more
> different accounts and the balance takes more than one page and it breaks.
> Empirically I can confirm that in our real production accounting data, if
> we extend the time frame of the balance, then with a short period, the
> balance prints, by increasing the period, the balance reports grows untill
> it finally breaks.
> In the attached screenshot, you can see how it looks when it's just small
> enough not to break (it's actully the page 2 of a 3 pages reports, but pages
> 1 and 3 are almost empty and only have the header basically).
>
> Here is the stack trace:
>
> Traceback (most recent call last):
> File "/opt/openerp/openobject-server/bin/service/web_services.py", line
> 605, in go
> (result, format) = obj.create(cr, uid, ids, datas, context)
> File "/opt/openerp/openobject-server/bin/report/report_sxw.py", line 645,
> in create
> return self.create_single(cr, uid, ids, data, report_xml, context)
> File "/opt/openerp/openobject-server/bin/report/report_sxw.py", line 733,
> in create_single
> pdf = create_doc(rml2, logo, title.encode('utf8'))
> File "/opt/openerp/openobject-server/bin/report/interface.py", line 199,
> in create_pdf
> obj.render()
> File "/opt/openerp/openobject-server/bin/report/render/render.py", line
> 50, in render
> result = self._render()
> File "/opt/openerp/openobject-server/bin/report/render/rml.py", line 36,
> in _render
> return rml2pdf.parseString(self.xml, images=self.bin_datas,
> path=self.path,title=self.title)
> File
> "/opt/openerp/openobject-server/bin/report/render/rml2pdf/trml2pdf.py", line
> 803, in parseString
> r.render(fp)
> File
> "/opt/openerp/openobject-server/bin/report/render/rml2pdf/trml2pdf.py", line
> 226, in render
> pt_obj.render(self.dom.documentElement.getElementsByTagName('story'))
> File
> "/opt/openerp/openobject-server/bin/report/render/rml2pdf/trml2pdf.py", line
> 792, in render
> self.doc_tmpl.build(fis)
> File "/opt/server-trunk/bin/reportlab/platypus/doctemplate.py", line 702,
> in build
> File "/opt/server-trunk/bin/reportlab/p...

Thank you for the feedback Raphael and Alexis.

Applied on trunk and 5.0 both.

Thanks.