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 <
[email protected]> 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 <
>> [email protected]> wrote:
>>
>> Le 25/03/2015 11:34, Jacopo Cappellato a écrit :
>>>
>>> On Mar 25, 2015, at 10:55 AM, Jacques Le Roux <
>>>> [email protected]> 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 <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>> Don't we also have dependencies on birt? Regarding reporting in
>>>>>>
>>>>>>> accounting
>>>>>>> and order?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>>
>>>>>>
>>>>
