fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terence Monteiro <tere...@sanjosesolutions.in>
Subject Re: All Share Accounts
Date Tue, 17 May 2016 09:01:45 GMT
On Sun, May 15, 2016 at 7:17 AM, Nayan Ambali <nayan.ambali@gmail.com>
wrote:

> Terence,
>
> For this use case buildig report is better solution than getting this list
> directly from API.
>
​​

What about reporting ​on a mobile or tablet application? It's true that
reporting API can be used here by submitting Report SQL from the mobile
app, but what if data can be cached on a mobile app once and at any future
time, instead of again sending SQL to the server and have it do expensive
DB JOINs and GROUP BY I want to implement client side reporting by simply
using the JSON?

Consider also the following scenarios:

   1. I want a list of pending share applications which need approval to be
   displayed on superuser dashboard. If I could just query
   /accounts/share?active=false and get the list of inactive shares that would
   be ideal, but even otherwise if I got collection of all share accounts, I
   could even filter on the client side. With the current API, I need to
   iterate over all clients and for each, make a request to
   /clients/:id/accounts and extract the share accounts from that
   2. I am a SACCO staff in charge of a group of say 20 members. I want to
   get a list of all share accounts of those members (e.g. so that I can pay
   them dividends). Wouldn't it be helpful to have a way to get all share
   accounts which I have access to (of my 20 members)?
   3. In offline scenario, if I have collection data cached on a device, I
   have a requirement to use the same cached information to generate a report
   - it would be good to have a single query to fetch the collection
   initially, cache it and use it at a later point to get the needed
   statistics.

But I agree with you that there should be a API for /shares that returns
> the collection of shares with sensible filters and limits.
>

​Yeah, for consistency sake, since other API's like clients,
savingsaccounts and loanaccounts have this, I don't see why we wouldn't
want to implement it for shares as well.​ My aggregation examples in the
previous mail, there may be an alternative way of doing it. However, for
these scenarios above the API solution seems the most logical and practical
approach.

-​Terence
​

>
> On Sat, May 14, 2016, 3:43 PM Terence Monteiro <
> terence@sanjosesolutions.in>
> wrote:
>
> > Hi Nazeer,
> >
> > On Fri, May 13, 2016 at 4:44 PM, Nazeer Shaik <
> > nazeer.shaik@confluxtechnologies.com> wrote:
> >
> > > Hi Terence,
> > >
> > > Can you tell me what is the use case to have all share accounts?
> > Currently
> > > it is implemented per client basis as I don't really find use of
> > returning
> > > all share accounts.
> >
> >
> > ​Some use cases:​
> >
> >
> >    1. ​A Financial Institution having micro savings and credit recently
> >    added shares. This FI has 500,000 clients and in a month about 1% of
> > these
> >    clients apply for shares so we have 5,000 clients with share accounts.
> > The
> >    management wants to know some information such as:
> >    1. Total number of share accounts
> >       1.  with the existing functionality I'll have to do something like
> >          1. Initialize a total share accounts counter
> >             2. Get list of clients, f
> >             oreach Client
> >                1. Get accounts for that client
> >                2. Ignore savings and loan accounts, pick shareaccounts
> >                3. Increment the counter by number of share accounts
> >                3. ​Report the result​
> >
> >             4. The efficiency of the above is 500,000 - the number of
> >             clients and the number of requests is also 500,000
> >             2. ​if we had a get all share accounts facility, I could
> >          1. call it and get the share account list and count in 1 request
> >             2. Number of clients having share accounts:
> >       1.  with the existing functionality I'll have to do something like
> >          1. Initialize a total clients having share accounts counter
> >             2. Get list of clients, f
> >             oreach Client
> >                1. Get accounts for that client
> >                2. Ignore savings and loan accounts, pick shareaccounts
> >                3. Increment the counter if share accounts length > 0
> >                2. ​if we had a get all share accounts facility, I could
> >          1. call it and get the share account list
> >             2. populate a Hash / Map object which tells whether a client
> >             has the share account or not
> >
> >             3. ​return the number of keys in the hash (number of clients
> >             which have a share account)​
> >
> >             3. Total value of shares bought by all clients
> >       1. ​with the existing functionality, I'll have to iterate through
> >          clients and for each ​client
> >
> >          1. get share account list and iterate over it and for each share
> >             account
> >             1. get the number of shares and the unit price and multiply
> to
> >                get the share value for that client
> >                2. Add this to a counter
> >                2. if we could get all shares in 1 API call, I could
> iterate
> >          over it and
> >          1. multiple the share unit price with number of shares and sum
> the
> >             product
> >             2. If I have multiple share products and want a breakup of
> >    share accounts # based on share product and client to gauge which
> > products
> >    are more popular again with the existing API it's painfully
> inefficient
> > for
> >    both application programmer and use
> >    ​.
> >
> > ​
> > ​I could think of any number of similar reporting or aggregation
> functions
> >
> > We are returning truncated data as data size will be more in case of
> > > returning all share products and client is not really going to use
> entire
> > > available data. In case of single product we are returning the complete
> > > data.
> > >
> >
> > ​This is fine but as API designers we can build flags like?fields=a,b,c
> to
> > get a truncated list. So an application developer builing on top of the
> API
> > can ​choose which fields they want and hence reduce the data size so this
> > is an alternative design which imo has the benefits you mention but
> doesn't
> > limit the application options and wider usability of the API.
> >
> >
> > > Thanks,
> > > Nazeer
> > >
> > >
> > > On Fri, May 13, 2016 at 4:31 PM, Terence Monteiro <
> > > terence@sanjosesolutions.in> wrote:
> > >
> > > > Hi Nazeer,
> > > >
> > > > Thanks for your response. I'm aware this is one way of getting the
> > share
> > > > accounts for an individual client. I wanted to know if there is a way
> > to
> > > > get for all clients. For instance if I GET
> > > > /fineract-provider/api/v1/savingsaccounts, I get all the savings
> > > accounts.
> > > > One use case of this is where say out of 5000 clients 5 have share
> > > > accounts. If I had to do a per client method, I'd have to make 5000
> > > > requests. But I'd like a way to query all share accounts of all
> clients
> > > in
> > > > a single query - in this case I should get 5 share accounts returned
> > and
> > > > since each has a clientId. Also considering the REST pattern, if
> > > > /path/to/resource/<resourceId> gives me a single resource object,
> then
> > > > /path/to/resource should give me all the objects of that resource.
> > > >
> > > > A second question I have is regarding the get all share products API.
> > > This
> > > > currently returns a truncated set of fields. Let's say I have 1 share
> > > > product only on the server. If I do GET
> > > > /fineract-provider/api/v1/products/share I get:
> > > >
> > > > {
> > > >     "totalFilteredRecords": 1,
> > > >     "pageItems": [
> > > >         {
> > > >             "id": 2,
> > > >             "name": "SACCO Shares",
> > > >             "shortName": "SAS",
> > > >             "totalShares": 100000
> > > >         }
> > > >     ]
> > > > }
> > > >
> > > > However, if I do /fineract-provider/api/v1/products/share/2 , I get
> the
> > > > full product:
> > > >
> > > > {
> > > >     "id": 2,
> > > >     "name": "SACCO Shares",
> > > >     "shortName": "SAS",
> > > >     "description": "k-Mayra SACCO Shares",
> > > >     "currency": {
> > > >         "code": "ETB",
> > > >         "name": "Ethiopian Birr",
> > > >         "decimalPlaces": 2,
> > > >         "inMultiplesOf": 10,
> > > >         "nameCode": "currency.ETB",
> > > >         "displayLabel": "Ethiopian Birr [ETB]"
> > > >     },
> > > >     "totalShares": 100000,
> > > >     "totalSharesIssued": 10000,
> > > >     "unitPrice": 5,
> > > >     "shareCapital": 50000,
> > > >     "minimumShares": 1,
> > > >     "nominalShares": 10,
> > > >     "maximumShares": 1000,
> > > >     "marketPrice": [],
> > > >     "charges": [],
> > > >     "allowDividendCalculationForInactiveClients": false,
> > > >     "lockinPeriod": 0,
> > > >     "lockPeriodTypeEnum": {
> > > >         "id": 4,
> > > >         "code": "savingsPeriodFrequencyType.invalid",
> > > >         "value": "Invalid"
> > > >     },
> > > >     "minimumActivePeriod": 0,
> > > >     "minimumActivePeriodForDividendsTypeEnum": {
> > > >         "id": 0,
> > > >         "code": "savings.lockin.savingsPeriodFrequencyType.days",
> > > >         "value": "Days"
> > > >     },
> > > >     "accountingRule": {
> > > >         "id": 1,
> > > >         "code": "accountingRuleType.none",
> > > >         "value": "NONE"
> > > >     }
> > > > }
> > > >
> > > > So in the former query, lot of information is missing.
> > > >
> > > > --
> > > > Best Regards,
> > > > Terence Monteiro,
> > > > Mob: +91 96633 13728
> > > > www.sanjosesol.com
> > > >
> > > > <http://goog_1610728024>
> > > > "Providence", No. 36,
> > > > Ahmed Sait Road,
> > > > Frazer Town, Bangalore - 5.
> > > >
> > > > On Fri, May 13, 2016 at 4:19 PM, Nazeer Shaik <
> > > > nazeer.shaik@confluxtechnologies.com> wrote:
> > > >
> > > > > Hi Terrence,
> > > > >
> > > > > As part of existing API, you can get share accounts along with
> other
> > > > > accounts for selected client.
> > > > >
> > > > > https://localhost:8443/fineract-provider/api/v1/clients/1/accounts
> > > > >
> > > > > The response :
> > > > >
> > > > > {
> > > > >     "loanAccounts": [],
> > > > >     "savingsAccounts": [],
> > > > >     "shareAccounts": []
> > > > > }
> > > > >
> > > > > Thanks,
> > > > > Nazeer
> > > > >
> > > > > On Fri, May 13, 2016 at 4:08 PM, Terence Monteiro <
> > > > > terence@sanjosesolutions.in> wrote:
> > > > >
> > > > > > Hi Devs,
> > > > > >
> > > > > > Is there a way to get all the share accounts similar to the
> savings
> > > and
> > > > > > loan accounts if I don't have the share account id and I want
to
> > full
> > > > > list?
> > > > > > I'm able to get a single share account with:
> > > > > >
> > > > > > GET /accounts/share/<accountId>
> > > > > >
> > > > > > However, if I skip the accountId, I get:
> > > > > >
> > > > > > {
> > > > > >     "timestamp": 1463135795016,
> > > > > >     "status": 500,
> > > > > >     "error": "Internal Server Error",
> > > > > >     "exception": "java.lang.NullPointerException",
> > > > > >     "message": null
> > > > > > }
> > > > > >
> > > > > > Can you confirm whether this is issue is known or whether it
> needs
> > to
> > > > be
> > > > > > tracked.
> > > > > >
> > > > > > --
> > > > > > Best Regards,
> > > > > > Terence Monteiro,
> > > > > > Mob: +91 96633 13728
> > > > > > www.sanjosesol.com
> > > > > >
> > > > > > <http://goog_1610728024>
> > > > > > "Providence", No. 36,
> > > > > > Ahmed Sait Road,
> > > > > > Frazer Town, Bangalore - 5.
> > > > > >
> > > > >
> > > >
> > >
> >
>

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