Hi Pierre, A quick note on the pros mentioned by you: integrating BIRT to the RDBMS is optional. You can do that or call the APIs of the entity engine and in fact this is how reports are currently implemented (it's called scripted data set source in BIRT). You can also fully integrate with the framework (uiLabels, java source code, services API, you name it).
Taher Alkhateeb On Wed, Mar 25, 2015 at 2:41 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > To Report or Not To Report, that is the question? > > First: > > I agree with the viewpoint that optionals in special purpose don't change > the experience of apps in the applications stack. A good example > modification to a longer existing issue regarding the field > parentCustRequestId. In such cases we should assess whether the > implementation should be brought to the appropriate component in the > applications stack. > > > > *Reporting with framework elements in components* > > > - *Pro* > - This is quit easily done, with screens, forms, ftl files and > services in groovy, java and javascript files. > - Often integrated in the component that is used to register the > transactions, e.g. accounting, order, product, etc > - Works well with screen prints etc. > - Utilises features from the framework stack (e.g. security, entity > engine > - ...... > - *Con* > - For extra functionality in the report additional effort is necessary > - For long reports extra burden on the transaction engine. > - For BI purposes it might prove to complex. > - Accesses data through features from the framework stack (e.g. > entity engine) > - Additional complexity in component > - .... > > *Reporting through report engine* > > - *Pro* > - Accesses data directly from the rdbms > - Opens opportunity to do scheduled reporting and have them delivered > by email, ftp etc. > - Optional > - Adds explicitly to the OFBiz value proposition (especially if we > change the name to reports). OFBiz does reporting! > - Can be offloaded to a separate OFBiz instance > - Functions can be added to generate reports via eca's > - .... > - *Con* > - additional learning curve > - other kind of contributors and committers required > - ... > > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Wed, Mar 25, 2015 at 12:01 PM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > Thanks Taher, > > > > I agree on Birt being useful in general, and in OFBiz certainly (Jacopo > at > > least thinks it could be better implemented, that's another topic). > > My question was more is it useful for existing accounting reports? Jacopo > > seems to say that there were already FOP implementations what went > > overridden, why? Do we need Birt there? > > > > Jacques > > > > > > Le 25/03/2015 11:52, Taher Alkhateeb a écrit : > > > >> Hi Jacques, > >> > >> I already provided an answer earlier in this thread while you were > typing > >> the question. > >> > >> Taher Alkhateeb > >> > >> On Wed, Mar 25, 2015 at 1:45 PM, Jacques Le Roux < > >> jacques.le.r...@les7arts.com> wrote: > >> > >> Le 25/03/2015 11:34, Jacopo Cappellato a écrit : > >>> > >>> On Mar 25, 2015, at 10:55 AM, Jacques Le Roux < > >>>> jacques.le.r...@les7arts.com> wrote: > >>>> > >>>> Can we say that the Birt reports are better? Do they always work (I > >>>> got > >>>> > >>>>> some issues there) > >>>>> > >>>>> No, I wouldn't say that (of course you are free to think otherwise, > >>>> it is > >>>> just the *we* part that I disagree with). > >>>> > >>>> OK to sum up, why do we have Birt there then? (question not > >>> specifically > >>> intended to you Jacopo) > >>> > >>> Also just tried http://demo-stable-ofbiz. > >>> apache.org/accounting/control/ > >>> > >>>> FinancialSummaryReportOptions?organizationPartyId=Company where Birt > is > >>>>> not and all reports fail, normal? > >>>>> > >>>>> I am not sure I understand... I got the same errors with or without > >>>> Birt: > >>>> the request maps are not defined; I don't see how this bug fits into > >>>> this > >>>> conversation. > >>>> > >>>> Same with trunk demo, OK to be revisited :/ > >>> > >>> But for example, the balance sheet report: > >>> > >>>> https://localhost:8443/accounting/control/BalanceSheet? > >>>> organizationPartyId=Company > >>>> is not a Birt report and works well; however the if you click on the > >>>> "Export as pdf" button you get an error when Birt is active while it > >>>> works > >>>> when Birt is inactive. > >>>> > >>>> So again, why do we have Birt there then? (question not specifically > >>> intended to you Jacopo) > >>> > >>> Jacques > >>> > >>> > >>> Jacopo > >>>> > >>>> Jacques > >>>> > >>>>> Le 24/03/2015 16:36, Jacopo Cappellato a écrit : > >>>>> > >>>>> The accounting component has financial reports implemented as screen > >>>>>> widgets (html/pdf/csv) that the Birt component overrides with > >>>>>> different > >>>>>> ones implemented with Birt. > >>>>>> This is actually one example about a specialpurpose component that > is > >>>>>> overriding/hiding functionality that is already provided by the > >>>>>> applications with a different one: you can't see them when Birt is > >>>>>> enabled. > >>>>>> > >>>>>> Jacopo > >>>>>> > >>>>>> On Mar 24, 2015, at 4:23 PM, Pierre Smits <pierre.sm...@gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>> Don't we also have dependencies on birt? Regarding reporting in > >>>>>> > >>>>>>> accounting > >>>>>>> and order? > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>> Pierre Smits > >>>>>>> > >>>>>>> > >>>>>> > >>>> >
