| Thread Previous • Date Previous • Date Next • Thread Next |
We have not heard from our customers or prospects that a flexible period is needed, and no-one has noticed it has ‘gone’. As for my POV, it is based on what our customers and prospects have said, based on what they have seen. (We show everyone the partner aging module). All feedback we have had regarding the ‘work’ that needs to be done during monitoring of aged balances tells us that something interactive, searchable, filterable and dynamic is preferred. We also have another module, partner account history (README attached), that reviews ALL transactions in a single place (invoices, payments, refunds/credits, manual entries, etc). These two things seem to match more closely how our customers (perhaps many users in the USA – not sure?) manage and monitor aged balances. They need quick access to the overview of what is outstanding, to be able to drill down by partner and then to be able to trace back over the history of transactions for a particular customer or supplier (usually while that customer or supplier is on the phone) checking transactions one by one. On this day I paid X, do you have that? On this day you billed Y, do you have that? Until there is a resolution about the validity of the aged balance, and an agreement to get it resolved. So – without understanding the need for the report, I can’t offer more feedback because I don’t have anyone asking for an Aging report. I don’t know what I would change about it. Everyone we have showed these two modules to uses them instead of a report. Hope that helps. Modules in BETA, feedback and testing appreciated. My PERSONAL view is that I don’t like reports – the moment they are printed they are out of date. I prefer dashboards! Ray. From: Humberto Arocha [mailto:humbertoarocha@xxxxxxxxx] Sent: Monday, October 28, 2013 1:13 PM To: Ray Carnes; openerp-community Subject: Re: [Openerp-community] What financial reports for the OpenERP community ? Regarding your approach I can see you have gone the SQL VIEW approach, We have gone the TransientModel Approach, We have reused the menu, model from openerp and some of the same functionalities in the module, We liked the flexibility given by the original report of allowing you to set the span period, In your module you have set a static span period. Now that I have given my PoV, I will appreciate yours, What would you get rid, what would you add? Regards. 2013/10/28 Ray Carnes <rcarnes@xxxxxxxxxxxxxxxxxxx> This is how we deal with it. We haven’t found anyone who wants a ‘report’ after showing them this. They can still export this view if they need it printed. Ray, From: Openerp-community [mailto:openerp-community-bounces+rcarnes <mailto:openerp-community-bounces%2Brcarnes> =ursainfosystems.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Humberto Arocha Sent: Monday, October 28, 2013 12:36 PM To: Frédéric Clementi Cc: openerp-community Subject: Re: [Openerp-community] What financial reports for the OpenERP community ? I would like to add up to this topic, other reports that have not been discussed yet, Aging Reports, We have being working in this reports, and we would like to share views with you, thus what is repeated get trimmed and what is needed to be enhanced get its overhauling. http://bazaar.launchpad.net/~vauxoo/addons-vauxoo/7.0/files/head:/account_aged_partner_balance_vw/ Any ideas? Until now, Openerp Default report, just gives us for each period asked what was collect/paid or billed, but does not consider y full view that can be used to Assess the allowance for doubtful accounts, As you would know, this is an indicator used by auditors to check how bad are the receivables in the current trend of a company collection. But changes in collection or billing is not what is really needed auditors need the real quantities of money owed, to try to make their best guess and assess. In this report,still WIP, we have added two new options that gives us three options total, * Original One of Openerp, * Distributed Debts on Periods. * Detailed Documents on Periods. I would like you to have a look on this reports, We are intented to propose in the future this report to the AFR ones. we want to get rid of the mako reports, in order that everyone can add the own reports on top of them. We would create new module with the mako reports to top this module. Regards. Regards. 2013/10/28 Humberto Arocha <humbertoarocha@xxxxxxxxx> Ok, Good Day, Comm Guys. Thanks to all you guys who have been aware of this thread and have been keeping up-to-date First we there were two reports and them keep from fighting each other, they draw a Line, I'll keep in RML, you'll keep in Webkit, an the promise: don't mess with my type of report. When we began to coordinate efforts, I think (now) we did it the wrong way, We focused on the type of the report and not on the background of the problem. (And now I think that) It was not about to build reports in different types of engine reports, instead it was on building a common ground that in the future would avoid friction among the stakeholders, And I think that we have to begin to build a common ground agnostic from the report engine, an API, something that with little effort can be used no matter your report engine of preference To avoid beginning a fight about whose reports are better than whom. If we build this common ground we can afford to please almost everyone, anyone else can then create his own report in his preferred report engine, ReportLab, Jasper, Webkit, Pentaho, BIRT, etc. We cannot think the same: If two people think the same someone is thinking by the other. So today, this is what is drawing our attention, And it has been wonderful because in early stages we can fix wrong-designed approaches, and make then better. In the meantime, I will withdraw the MP that I have submit, because we have step on the ground of webkit, now it has become a territorial war. (In good sense), :-) We will keep from messing with webkit, While, we have to make agreements in building an Accounting Financial Reports Agnostic, An API, something where everybody can plug and create their own reports on top of Our API + Preferred Report Engine. There are good features in the reports and in order to be coherent we should both recede. Lately our module have become less dependant on parsers or special features that are only available to a particular tools, in order to keep our customers more open to new tools this way we have being building this agnostic approach I am talking about, It is good for the sake of survival letting two different or more of the same kind to adapt and survive. Then What I will ask you Comm Guys from this Issue is make a coordinated effort, I liked rml, and I like webkit, but none of them can be superseded by the other, each one has its weakness and strengths. That was the reason to step on your side. Now we should schedule an agenda, to begin our new roadmap to 8, with common grounds. PD.: making wired reports like Excel one is an awful idea, can be done with no hassle making webkit to print reports in html, I Think is prettier, but feel free to disrgard my comments Best Regards. Hbto. 2013/10/28 Frédéric Clementi <frederic.clementi@xxxxxxxxxxxxxx> English Doc for account_financial_reports_webkit here -> http://bit.ly/16g3uSZ Cordialement, camptocamp INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS Frédéric Clementi Project Manager Business Solutions +41 21 619 <tel:%2B41%2021%20619%C2%A010%2041> 10 41 www.camptocamp.com <http://www.camptocamp.com/> 2013/10/25 Nhomar Hernández <nhomar@xxxxxxxxx> 2013/10/25 Frédéric Clementi <frederic.clementi@xxxxxxxxxxxxxx> So Nhomar ask me a documentation about 'account_financial_reports_webkit' so he could compare more easily. That's what I did... here it is as attachement. Put a public link the list in launchpad block attachments ;-) We are almost sure the "Merge" of concepts and a clean up will be necesary in both modules, to be able to merge such concepts. Yo have good points and we too and IMHO think both are already audited, then, maybe we must move feature by feature before a merge. We are open to discuss and merge, honestly mantain the FInancial reaports almost by ourselve is so time consuming, it is better if we make a better approach. Maybe, and Just maybe due to this feature is only reporting we can start a new "merge" branch backporteable to 7 - 6.1 and future 8 to manage three computation. Another point is the IFRS compliance which become even mode difficult, or an estandard GAAP included, we dont have any of them we have part of one or another. Let's make a better proposal. For the moment: Lets read the documentation it is a good start. Regards -- -------------------- Saludos Cordiales Nhomar G. Hernandez M. +58-414-4110269 <tel:%2B58-414-4110269> Skype: nhomar00 Web-Blog: http://geronimo.com.ve <http://geronimo.com.ve/> Servicios IT: http://vauxoo.com <http://vauxoo.com/> Linux-Counter: 467724 Correos: nhomar@xxxxxxxxxxxxxx nhomar@xxxxxxxxxx twitter @nhomar _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
Attachment:
partner_aging_README.pdf
Description: Adobe PDF document
Attachment:
partner_account_history_README.pdf
Description: Adobe PDF document
| Thread Previous • Date Previous • Date Next • Thread Next |
