Improve the management of forms and header report

Registered by Eric Caudal - www.elico-corp.com

This development could be valid for all reports in OpenERP
When issuing reports, most of the time, the same kind of reports appears periodically (monthly financial statement, weekly inventory or daily sales etc...).
When you issue those report you have to reenter all the filter information and headers to reprint the report. Additionally, currently the report header is not even managed when this is a crucial points in company management ("the directors like to have the same set of report over time to be able to compare and manage the difference").
My proposal is to be separated in 2 different aspects:
1.- Possibility to manage generic specific report headers in all reporting forms with the following features:
- "header" is a RML code, added between the company header and the report (could be empty)
- default RML header given by the system (defined int the object model?)
- possibility to change the default RML proposed by the system,
- possibility to "save as", copy and delete a specific header
- headers would be stored in a table including report name/id and versioning and obviously a separate form to manage them
- a one2many field in the report form could allow to select the report header
Implies a major change in the way all the reports are managed but backward compatibility should not be an issue.

2. possibility to save the filter options of a report form
- Default set of filter given by the system
- possibility to change the default set of filter and save it
- possibility to "save as" (current filled in values), copy and delete a specific set of filter
- Set of filters would be stored in 2 tables, one header with form name, filter name and permissions and the second detailed with fields and values.
- a tickbox would allow the user to choose the default settings or use a specific set of filter
- a one2many field in the report form could allow to select the specific filter
New forms have to be deployed but backward compatibility should be preserved.

3.- Generalize this system as a "form filling template", available in any form.
- a template management framework/object model has to be decided, available for any form.
- Default form filling template proposed by the system with all form fields defaulted (to be defined in the object model?)
- Possibility to change the default form filling template, per user.
- Possibility to create a form filling template, available for a user, all users or a defined set of permissions
- possibility to "save as" (current form values), copy and delete a specific "form filling template"
- "form filling template" would be stored in 2 tables, one header with form name, "form filling template" name and permissions and the second detailed with fields and values.
- Create forms to manage the "form filling template" and possible versioning.
- Depending on implementation, a tickbox with one2many field or a specific action would allow the user to load a specific "form filling template" into a form.
- Next step: sub-form management (possibility to add +1 depth in "form filling template").

If the option of additional/satellite action feature choosen, then backward compatibility should be preserved.

This has great and practical application on day to day basis:
eg: you could imagine filling an invoice and save all the fields so that you can repeat that invoice over the time or having a partner template that would be used to start filling your partners.
This form filling template would allow the users to automate many tasks saving as a template.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.