Terence,
The requested API is implemented and merged into develop.
Pagination with associations won't work. So when fetching all share
accounts, you will not get any transactions and charges as part of each
entity.
This is how it is implemented even in savings, loans.
Thanks,
Nazeer
On Tue, May 17, 2016 at 2:31 PM, Terence Monteiro <
tere...@sanjosesolutions.in> wrote:
> On Sun, May 15, 2016 at 7:17 AM, Nayan Ambali <nayan.amb...@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 <
> > tere...@sanjosesolutions.in>
> > wrote:
> >
> > > Hi Nazeer,
> > >
> > > On Fri, May 13, 2016 at 4:44 PM, Nazeer Shaik <
> > > nazeer.sh...@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 <
> > > > tere...@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.sh...@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 <
> > > > > > tere...@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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
