Closed rafaelbn closed 9 years ago
A more general approach is to use account.analytic.line corresponding to the analytic account of the project, because there can be manual entries or entries proceeding of issues that are not registered as tasks works. Using project_timesheet, we will have also task works as analytic entries. In v9, the situation gets better because the data model will be unified (at last!).
@rafaelbn It looks like you need internal reporting data. It seems to me that reporting Tree Views and Pivot Tables would serve those needs better than a HTML/PDF "fixed" report.
The Task Report on my presentation that you mention has a different purpose: it is the report to deliver to the customer at the end of the intervention/visit. So, it is one page per Task.
@pedrobaeza your suggestion makes sense. it means that the report will require timesheets to be installed, correct?
@dreispt, yeah, you need that dependency.
"Note: As this is for reporting your client some one can expect reports in account.analytic.account (Contracts) and account.analytic.line ("Invoice task") but this is not the case."
@dreispt This is for customers nor internal. This are reports to send to customers. For internal purposes we use (as you said) report module with tree views and pivot tables.
@pedrobaeza if v9 will unified data model, I agree. We must use account.analytic.line.
The timesheet related modules are currently at https://github.com/OCA/hr-timesheet Since this report will heavily depend on timesheet /analytic lines, maybe it's best hosted there? (cc @eLBati @yvaucher @guewen )
@dreispt How could I move this issue to hr-timesheet?
These is also a https://github.com/OCA/project-reporting that could be more appropriate. But I wpuld like to have a second opinion before doing anything (cc @yvaucher @gurneyalex)
Hi, the modules seems to me to be mainly project oriented. So I think https://github.com/OCA/project-reporting is the best candidate
I updated requirement adding Project Issues. It's not a good idea make such a report and forget issues. So, adding project issue definitely set that we must use account.analytic.line as we have timesheet_ids in project.issue.
Anyway all is related with project so OCA/project-reporting looks much more better.
Definitely as we have a project-reporting repo reports related to project should go there.
And shouldn't it be named project_customer_report
(referring to issue title) ? naming it only project_reports might not be well named in case we want multiple type of reports on project.
Please if you are interested give a feedback about what you expect for this module in https://github.com/OCA/project-reporting/issues/9
Customer's project reports
Hi, (I open this discussion here because we must mix functional and technical skills to specify and develop a good module).
Maybe I mistake project in Github and there is another better.
Why this module?
I need to develop a module to satisfy requirement of my customer, but I prefer to discuss here the functionality and fit this to my customer than develop my customer's need and after that try to send this to OCA.
The only report I have seen from @dreispt about this is here described: http://www.slideshare.net/dreispt/service-management-at-securitas-using-openeerp, and is a very specific one.
I guess even thought clients want a specific report we can have a general use one which is the base of the rest.
Note: As this is for reporting you client some one can expect reports in account.analytic.account (Contracts) and account.analytic.line ("Invoice task") but this is not the case.
What we have:
Which variants of report could we need:
Requirements:
1. Report must contain this information:
\ Header
\ Body
2. Wizard:
Let see who is interested in and get some more ideas.
Check https://github.com/serviciosbaeza/serviciosbaeza-odoo-addons/tree/8.0/project_task_work_print from @pedrobaeza