fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thisura Philips <ttcphil...@gmail.com>
Subject Re: Does the changes in apache fineract platform necessary to fix FINERACT issues
Date Mon, 10 Apr 2017 19:04:44 GMT
Hi Markus,

There is a limitation in implementing this in the backend. In the database,
we are storing only the "classification_enum" in the "acc_gl_account"
Classification Enum has the following values for respective account types.
          ASSET - 1
          LIABILITY - 2
          EQUITY - 3
          INCOME - 4
          EXPENSE - 5
The values can't be used to reflect the ascending order of names. Therefore
ORDER BY "classification_enum" won't work in the sql query.
There fore we have two options.
          1. Write a sorting function to sort the result set based on the
classification_enum and then on gl_code.
          2. Change the classification_enum values to reflect the ascending
order of account types and add ORDER BY classification_enum ASC, gl_code ASC
The changed enums will look like follows.
           ASSET - 1
           LIABILITY - 5
           EQUITY - 3
           INCOME - 4
           EXPENSE - 2
What is the best option? From the maintenance point of view, I think the
first option is better. But from the performance point of view, the second
option is better.

I have sent this PR <https://github.com/apache/incubator-fineract/pull/330> to
order the results according to gl_code. But there is no use of that if we
can't have the same with classification_enum as the first preference is
given to classification_enum.

Your ideas will be a great help to resolve this issue.

Thanks and Regards.

On Mon, Apr 3, 2017 at 11:20 AM, Thisura Philips <ttcphilips@gmail.com>
wrote:

> Hi Markus,
>
> Exactly, it should be independent from the client.
> At the moment account in charts of accounts are ordered using orderBy
> directive.
> I will send the response from the platform ordering them as expected in
> this issue. <https://issues.apache.org/jira/browse/FINERACT-389>
>
> Cheers!
>
> Thanks & Regards.
>
> On Mon, Apr 3, 2017 at 10:56 AM, Markus Geiß <markus.geiss@live.de> wrote:
>
>> Hey Thisura,
>>
>> features like the one you've mentioned should find their place within the
>> platform.
>>
>> Just imagine we have not only the community-app but also an android app
>> plus additional UIs we even don’t know about.
>>
>> It is best practice to implement those kind of changes within the
>> backend, so you don’t need to reimplement them with every client.
>>
>> Cheers
>>
>> Markus
>>
>> -----Original Message-----
>> From: Thisura Philips [mailto:ttcphilips@gmail.com]
>> Sent: Thursday, March 30, 2017 05:12 AM
>> To: dev@fineract.incubator.apache.org
>> Subject: Does the changes in apache fineract platform necessary to fix
>> FINERACT issues
>>
>> Hi devs,
>> Just a little bit of misunderstanding.
>> Let's take an example. The ticket at [1] <https://issues.apache.org/jir
>> a/browse/FINERACT-389> requests to arrange the accounts that fall under
>> one account type in order of their GL codes.
>> This could be done easily with the changes at [2] <
>> https://github.com/openMF/community-app/pull/2157>. But this change is
>> in community-app.
>>
>> My question is, whether the fix is correct. Do we need to correct these
>> at the platform level? Or is the suggested fix in [2] <
>> https://github.com/openMF/community-app/pull/2157>.
>>
>> [1] https://issues.apache.org/jira/browse/FINERACT-389
>> <https://issues.apache.org/jira/browse/FINERACT-389>
>> [2] https://github.com/openMF/community-app/pull/2157
>> <https://github.com/openMF/community-app/pull/2157>
>>
>> Thanks and regards.
>>
>> --
>> T.T.C Philips (BSc.Eng (Undergrad))
>> Computer Science and Engineering,
>> Sri Lanka Institute of Information Technology(SLIIT)
>>
>
>
>
> --
> T.T.C Philips (BSc.Eng (Undergrad))
> Computer Science and Engineering,
> Sri Lanka Institute of Information Technology(SLIIT)
>
>
>
>


-- 
T.T.C Philips (BSc.Eng (Undergrad))
Computer Science and Engineering,
Sri Lanka Institute of Information Technology(SLIIT)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message