Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.incubator.apache.org
Date: Thu, 30 Jun 2016 10:20:09 +0000 (UTC)
From: <nikhilpawar@yahoo.in.INVALID>
Reply-To: <nikhilpawar@yahoo.in>
To: "dev@fineract.incubator.apache.org" <dev@fineract.incubator.apache.org>
Cc: Nayan Ambali <nayan.ambali@gmail.com>, Dayna Harp <dharp@mifos.org>,
	Mifos Software Development <mifos-developer@lists.sourceforge.net>,
	=?UTF-8?Q?Markus_Gei=C3=9F?= <mgeiss@mifos.org>,
	Ed Cable <edcable@mifos.org>,
	Nazeer Shaik <nazeer.shaik@confluxtechnologies.com>
Message-ID: <1579040934.19179.1467282009936.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <CANs+V4F4B86wRBkdQTwmxB8Xb5YRokuJk=Z39+ZJhbgVg2VLuw@mail.gmail.com>
References: <885106974.2890046.1467203862137.JavaMail.yahoo.ref@mail.yahoo.com> <885106974.2890046.1467203862137.JavaMail.yahoo@mail.yahoo.com> <CAF0gLvxmUv131H_JBeUyU+AAE3-HqhN3xnj4sAQw3Tg6LrYMQg@mail.gmail.com> <CAMqKwS+tOkE6xt=YB1san=HjyG+N6JODiv4m4c-GfCgNodk1JQ@mail.gmail.com> <30B433A1-9724-4978-A278-9320CFF29329@theupscale.in> <CAPy9_B8v6XwyqCWqfTirgkAZgRk6SXsobAno2cSm+4-2NY1n5g@mail.gmail.com> <CANs+V4GtGN2Gf62GacGfPjXsrtnScco1Q15q0mRGoui1L50=iQ@mail.gmail.com> <CAPy9_B_RUis8_Au36x-mYhfHXqgLg5FvPdGzvW2ySFN9GjdtxA@mail.gmail.com> <CANs+V4F4B86wRBkdQTwmxB8Xb5YRokuJk=Z39+ZJhbgVg2VLuw@mail.gmail.com>
Subject: Re: [IMPORTANT] Query regarding standard address table
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_19178_195304003.1467282009930"
archived-at: Thu, 30 Jun 2016 10:23:41 -0000

------=_Part_19178_195304003.1467282009930
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I could not convince myself with your third point.Let me explain by taking =
a simple use case of slum dwellers in Mumbai.In Mumbai there is one governm=
ent scheme named as 'SRA' wherein slum dwellers are given houses in buildin=
g in exchange of their slums.In between this exchange, there is a time slot=
 of 4-5 years wherein slum dwellers have address proof of their slums( whic=
h is not in existence now) and are currently living in temporary accommodat=
ion( whose address proof) they don't have.Only in such cases it makes sense=
 to store two addresses( permanent and current). In rest of the cases, we w=
ould rather go with permanent address, instead of storing two same address.=
So is there still a need of storing a boolean value.Let me know your view o=
n this.
Regards,Nikhil
      From: Saransh Sharma <saransh@theupscale.in>
 To: dev@fineract.incubator.apache.org=20
Cc: Nayan Ambali <nayan.ambali@gmail.com>; NIKHIL PAWAR <nikhilpawar@yahoo.=
in>; Dayna Harp <dharp@mifos.org>; Mifos Software Development <mifos-develo=
per@lists.sourceforge.net>; Markus Gei=C3=9F <mgeiss@mifos.org>; Ed Cable <=
edcable@mifos.org>; Nazeer Shaik <nazeer.shaik@confluxtechnologies.com>
 Sent: Thursday, 30 June 2016 3:29 PM
 Subject: Re: [IMPORTANT] Query regarding standard address table
  =20
See, the flow is generic while adding addresses for the customer the basic
flow should be,

1 Address Type as suggested by Srinivasan but it should not duplicate the
same address type we should be able to add more, addressType as per the
requirements once the addressType is created it should not create the same
addressType again

2 State Type we can load it from CodeValues

3. There are some cases when the customer have same address for case like
Permanent and Residential a boolean for sameAddressType should be
introduced or isBoth kind of boolean should be introduced and once the
addresses are same it should not create new address type with the following
one,

On Thu, Jun 30, 2016 at 3:20 PM Nikhil Pawar <nickrp89@gmail.com> wrote:

> Latitude and longitude are also the attributes along with other fields of
> the address table.
>
> Regards,
> Nikhil
>
> On Thu, Jun 30, 2016 at 3:15 PM, Saransh Sharma <saransh@theupscale.in>
> wrote:
>
> > What about geo mapping ? which enables the latitude and longitude from
> > google maps or some other service
> >
> > On Thu, Jun 30, 2016 at 2:41 PM Nikhil Pawar <nickrp89@gmail.com> wrote=
:
> >
> > > Hello All,
> > >
> > > Please find the attached schema diagram of the proposed Address and
> > > related configuration tables.
> > > A quick description of the diagram:
> > > Address table:
> > > The fields of the address table would be configurable. The user can
> > select
> > > the field via field configuration table.
> > > Rest of the fields are self explanatory.
> > >
> > >
> > > On Thu, Jun 30, 2016 at 1:48 PM, Ankit Sharma <ankit@theupscale.in>
> > wrote:
> > >
> > >> Hi team,
> > >> We have already made addresses - official, residential and permanent
> as
> > a
> > >> standard feature of CB.
> > >> Looking forward on this.
> > >>
> > >> Ankit Sharma
> > >> Upscale
> > >>
> > >> > On 30-Jun-2016, at 1:42 PM, Ashok <ashok@confluxtechnologies.com>
> > >> wrote:
> > >> >
> > >> > +1
> > >> >
> > >> > It makes sense to have a standard address with minimal fields to
> > >> support CB
> > >> > or any other integrations and can be extended/configurable by
> > >> organization.
> > >> >
> > >> > Thanks and Regards,
> > >> > Ashok
> > >> >
> > >> > On Wed, Jun 29, 2016 at 6:19 PM, Nayan Ambali <
> nayan.ambali@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> >> Dayna, Markus,
> > >> >>
> > >> >> I feel, adding standard address to customer solves other problems
> > too,
> > >> >> example address can be made mandatory before activating client,
> > >> address can
> > >> >> be capture along with customer creation, Geo location based servi=
ce
> > on
> > >> >> Android can built.
> > >> >>
> > >> >> i vote for adding client address as standard(out of box) feature.
> > >> >>
> > >> >> Thanks
> > >> >> Nayan Ambali
> > >> >>
> > >> >>
> > >> >>
> > >> >> Thanks and Regards,
> > >> >> Nayan Ambali
> > >> >> +91 9591996042
> > >> >> skype: nayangambali
> > >> >>
> > >> >>> On Wed, Jun 29, 2016 at 6:07 PM, <nikhilpawar@yahoo.in> wrote:
> > >> >>>
> > >> >>> Hello Devs,
> > >> >>>
> > >> >>> While designing the credit bureau module, I came across few desi=
gn
> > >> >>> questions and I wanted community's opinion on that.
> > >> >>> When you make a credit check query, the credit bureau expects yo=
u
> to
> > >> send
> > >> >>> the address along with few other identifiers.
> > >> >>>
> > >> >>> In order to fetch the address fields in a more hassle free and
> less
> > >> error
> > >> >>> prone way, I was thinking if we can standardize the address as
> core
> > >> table.
> > >> >>> By standardizing this address table, we may remove the need for
> > >> defining
> > >> >>> custom data table for storing addresses.
> > >> >>>
> > >> >>> Let me know your thoughts on this proposal of mine.
> > >> >>>
> > >> >>> Regards,
> > >> >>> Nikhil
> > >> >>
> > >>
> > >
> > >
> >
>


------=_Part_19178_195304003.1467282009930--