fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saransh Sharma <sara...@theupscale.in>
Subject Re: [IMPORTANT] Query regarding standard address table
Date Thu, 30 Jun 2016 09:59:54 GMT
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 service
> > 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
design
> > >> >>> questions and I wanted community's opinion on that.
> > >> >>> When you make a credit check query, the credit bureau expects
you
> 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
> > >> >>
> > >>
> > >
> > >
> >
>

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