I am looking to find a way so that cases in separate modules can interact
with each other (e.g. update each other). I have a case type called
individuals in one module, and a case type called businesses in another
module. I would like to be able to associate certain businesses with
certain individuals, e.g. to have a form in the individuals module which
allows me to select one of the businesses from the businesses module. I
would then save this information to the individual's case properties. This
process would also update the selected business as I would load information
about the individual (e.g. name) into the business's case properties.
I think this could be achieved it it was possible to have a lookup table,
the rows of which were cases from another module (e.g. businesses). Is this
possible? Currently I am just making do with a lookup table that has a list
of businesses, in a form in the individual's module. Obviously this doesn't
interact with or update the businesses module.
I don't think a parent-child relationship would be appropriate here because
a business may be associated with many individuals, and therefore in many
occasions users will not want to create a new business case but rather find
one that already exists in the system: either as a row in a lookup table or
preferably, as mentioned above, as a case in its own right.
We had to do something like this in our previous projects: linking two cases together by a common value. We had:
cases to describe a piece of equipment (mobile phone for example). Values here would be serial_number (the key), manufacturer, model, etc…
cases to describe a mobile phone user. Values here would be name, location, phone_serial_number, etc
As you notice, a phone and an user are linked by the phone serial number: mobile_user.phone_serial_number and mobile_phone.serial_number
The "user" case would hold the phone serial number. However, the "mobile_phone" serial number would not hold the user serial number. Why so ?
storing the relation between a phone and an user at a single place avoids data duplication, making the whole system much easier to update / maintain
in CommCareODK, we didn't need to know (in the "mobile_phone" case display) that a phone was given to an user. It would have been nice, but it is not a requirement
in CommCareODK, we did need to know (in the "mobile_user" case display) the serial number of the phone associated to a user (for verification purpose, so our field team would know if unregistered phone swapped occurred, which could happen when phone breaks)
we built an Access / Excel system that would link all these data together (SQL queries, etc) for our M&E / detailed reports / phone maintenance operations.
So if you don't really need in CommCareODK to see how many persons are linked to a business, I'd continue with what you have now (a regularly updated lookup table of businesses and a one way link Individual -> Business) and leverage some kind of database / report analysis to build the list of individuals per business.
Regards,
Charles
···
On Sunday 14 June 2015 10:45:40 John Skelton wrote:
> Hi all,
>
> I am looking to find a way so that cases in separate modules can interact
> with each other (e.g. update each other). I have a case type called
> individuals in one module, and a case type called businesses in another
> module. I would like to be able to associate certain businesses with
> certain individuals, e.g. to have a form in the individuals module which
> allows me to select one of the businesses from the businesses module. I
> would then save this information to the individual's case properties. This
> process would also update the selected business as I would load information
> about the individual (e.g. name) into the business's case properties.
>
> I think this could be achieved it it was possible to have a lookup table,
> the rows of which were cases from another module (e.g. businesses). Is this
> possible? Currently I am just making do with a lookup table that has a list
> of businesses, in a form in the individual's module. Obviously this doesn't
> interact with or update the businesses module.
>
> I don't think a parent-child relationship would be appropriate here because
> a business may be associated with many individuals, and therefore in many
> occasions users will not want to create a new business case but rather find
> one that already exists in the system: either as a row in a lookup table or
> preferably, as mentioned above, as a case in its own right.
>
> Thanks for any ideas!
>
> John
>
>
Thanks very much for your reply and advice - you understood perfectly what
I need. In some ways it might be preferable to continue with a lookup table
anyway, and as you suggest I can do the analysis of business-individual
outside of CommCare. I would, though, be interested to know if it is
possible to link two case types in this way!
Thanks
John
···
On Monday, June 15, 2015 at 11:45:34 AM UTC-1, Charles Flèche wrote:
>
> Dear John,
>
>
>
> We had to do something like this in our previous projects: linking two
> cases together by a common value. We had:
>
>
>
> - cases to describe a piece of equipment (mobile phone for example).
> Values here would be serial_number (the key), manufacturer, model, etc…
>
> - cases to describe a mobile phone user. Values here would be name,
> location, phone_serial_number, etc
>
>
>
> As you notice, a phone and an user are linked by the phone serial number:
> mobile_user.phone_serial_number and mobile_phone.serial_number
>
>
>
> The "user" case would hold the phone serial number. However, the
> "mobile_phone" serial number would __not__ hold the user serial number. Why
> so ?
>
>
>
> 1. storing the relation between a phone and an user at a single place
> avoids data duplication, making the whole system much easier to update /
> maintain
>
>
>
> 2. in CommCareODK, we didn't need to know (in the "mobile_phone" case
> display) that a phone was given to an user. It would have been nice, but it
> is not a requirement
>
>
>
> 3. in CommCareODK, we did need to know (in the "mobile_user" case display)
> the serial number of the phone associated to a user (for verification
> purpose, so our field team would know if unregistered phone swapped
> occurred, which could happen when phone breaks)
>
>
>
> 4. we built an Access / Excel system that would link all these data
> together (SQL queries, etc) for our M&E / detailed reports / phone
> maintenance operations.
>
>
>
>
>
> So if you don't really need __in CommCareODK__ to see how many persons are
> linked to a business, I'd continue with what you have now (a regularly
> updated lookup table of businesses and a one way link Individual ->
> Business) and leverage some kind of database / report analysis to build the
> list of individuals per business.
>
>
>
> Regards,
>
>
>
> Charles
>
>
>
>
>
>
>
>
>
> On Sunday 14 June 2015 10:45:40 John Skelton wrote:
>
> > Hi all,
>
> >
>
> > I am looking to find a way so that cases in separate modules can
> interact
>
> > with each other (e.g. update each other). I have a case type called
>
> > individuals in one module, and a case type called businesses in another
>
> > module. I would like to be able to associate certain businesses with
>
> > certain individuals, e.g. to have a form in the individuals module which
>
> > allows me to select one of the businesses from the businesses module. I
>
> > would then save this information to the individual's case properties.
> This
>
> > process would also update the selected business as I would load
> information
>
> > about the individual (e.g. name) into the business's case properties.
>
> >
>
> > I think this could be achieved it it was possible to have a lookup
> table,
>
> > the rows of which were cases from another module (e.g. businesses). Is
> this
>
> > possible? Currently I am just making do with a lookup table that has a
> list
>
> > of businesses, in a form in the individual's module. Obviously this
> doesn't
>
> > interact with or update the businesses module.
>
> >
>
> > I don't think a parent-child relationship would be appropriate here
> because
>
> > a business may be associated with many individuals, and therefore in
> many
>
> > occasions users will not want to create a new business case but rather
> find
>
> > one that already exists in the system: either as a row in a lookup table
> or
>
> > preferably, as mentioned above, as a case in its own right.
>
> >
>
> > Thanks for any ideas!
>
> >
>
> > John
>
> >
>
> >
>
>
>
> --
>
> Charles Flèche
>
> mHealth Advisor
>
> Télécoms Sans Frontières http://www.tsfi.org
>
> Première Urgence - Aide Médicale Internationale http://www.pu-ami.org
>
>
>
I notice you dismissed the idea of using parent-child case relations here
because “because a business may be associated with many individuals" -
however, the parent-child feature allows for a one-to-many relationship
like you describe. I'd consider the following design:
"Register Individual" form in the "Business" module that has you first
select a business to associate with the individual, then fill out the
information about the individual, then open a new "Individual" case as a
sub case of the parent. You can load up any information from the business
case into the individual case as you need in this form.
Do you think this would work? Please let me know if I'm misunderstanding
your requirements.
Best,
Will
···
On Tue, Jun 16, 2015 at 12:24 PM, John Skelton wrote:
Hi Charles,
Thanks very much for your reply and advice - you understood perfectly what
I need. In some ways it might be preferable to continue with a lookup table
anyway, and as you suggest I can do the analysis of business-individual
outside of CommCare. I would, though, be interested to know if it is
possible to link two case types in this way!
Thanks
John
On Monday, June 15, 2015 at 11:45:34 AM UTC-1, Charles Flèche wrote:
Dear John,
We had to do something like this in our previous projects: linking two
cases together by a common value. We had:
cases to describe a piece of equipment (mobile phone for example).
Values here would be serial_number (the key), manufacturer, model, etc…
cases to describe a mobile phone user. Values here would be name,
location, phone_serial_number, etc
As you notice, a phone and an user are linked by the phone serial number:
mobile_user.phone_serial_number and mobile_phone.serial_number
The "user" case would hold the phone serial number. However, the
"mobile_phone" serial number would not hold the user serial number. Why
so ?
storing the relation between a phone and an user at a single place
avoids data duplication, making the whole system much easier to update /
maintain
in CommCareODK, we didn't need to know (in the "mobile_phone" case
display) that a phone was given to an user. It would have been nice, but it
is not a requirement
in CommCareODK, we did need to know (in the "mobile_user" case
display) the serial number of the phone associated to a user (for
verification purpose, so our field team would know if unregistered phone
swapped occurred, which could happen when phone breaks)
we built an Access / Excel system that would link all these data
together (SQL queries, etc) for our M&E / detailed reports / phone
maintenance operations.
So if you don't really need in CommCareODK to see how many persons
are linked to a business, I'd continue with what you have now (a regularly
updated lookup table of businesses and a one way link Individual ->
Business) and leverage some kind of database / report analysis to build the
list of individuals per business.
Regards,
Charles
On Sunday 14 June 2015 10:45:40 John Skelton wrote:
Hi all,
I am looking to find a way so that cases in separate modules can
interact
with each other (e.g. update each other). I have a case type called
individuals in one module, and a case type called businesses in another
module. I would like to be able to associate certain businesses with
certain individuals, e.g. to have a form in the individuals module
which
allows me to select one of the businesses from the businesses module. I
would then save this information to the individual's case properties.
This
process would also update the selected business as I would load
information
about the individual (e.g. name) into the business's case properties.
I think this could be achieved it it was possible to have a lookup
table,
the rows of which were cases from another module (e.g. businesses). Is
this
possible? Currently I am just making do with a lookup table that has a
list
of businesses, in a form in the individual's module. Obviously this
doesn't
interact with or update the businesses module.
I don't think a parent-child relationship would be appropriate here
because
a business may be associated with many individuals, and therefore in
many
occasions users will not want to create a new business case but rather
find
one that already exists in the system: either as a row in a lookup
table or
preferably, as mentioned above, as a case in its own right.
Hi Will,
Thanks for the suggestion. This almost works. The only problem is that I
might have an Individual who I want to register and track who remains
entirely unrelated to a Business initially. At a later point I might want
to associate the Individual to a Business (this is when they begin an
apprenticeship). The way you suggest would be the solution if I wanted the
individual to be associated with the business from the outset, but I can't
guarantee this so, as far as I can see, this would probably not be an
across-the-board solution.
Thanks!
John
···
On Thursday, June 18, 2015 at 4:02:15 PM UTC-1, William Pride wrote:
>
> Hello John,
>
> I notice you dismissed the idea of using parent-child case relations here
> because “because a business may be associated with many individuals" -
> however, the parent-child feature allows for a one-to-many relationship
> like you describe. I'd consider the following design:
>
> "Register Individual" form in the "Business" module that has you first
> select a business to associate with the individual, then fill out the
> information about the individual, then open a new "Individual" case as a
> sub case of the parent. You can load up any information from the business
> case into the individual case as you need in this form.
>
> Do you think this would work? Please let me know if I'm misunderstanding
> your requirements.
>
> Best,
> Will
>
> On Tue, Jun 16, 2015 at 12:24 PM, John Skelton <jske...@lr.mercycorps.org > wrote:
>
>> Hi Charles,
>>
>> Thanks very much for your reply and advice - you understood perfectly
>> what I need. In some ways it might be preferable to continue with a lookup
>> table anyway, and as you suggest I can do the analysis of
>> business-individual outside of CommCare. I would, though, be interested to
>> know if it is possible to link two case types in this way!
>>
>> Thanks
>> John
>>
>>
>> On Monday, June 15, 2015 at 11:45:34 AM UTC-1, Charles Flèche wrote:
>>>
>>> Dear John,
>>>
>>>
>>>
>>> We had to do something like this in our previous projects: linking two
>>> cases together by a common value. We had:
>>>
>>>
>>>
>>> - cases to describe a piece of equipment (mobile phone for example).
>>> Values here would be serial_number (the key), manufacturer, model, etc…
>>>
>>> - cases to describe a mobile phone user. Values here would be name,
>>> location, phone_serial_number, etc
>>>
>>>
>>>
>>> As you notice, a phone and an user are linked by the phone serial
>>> number: mobile_user.phone_serial_number and mobile_phone.serial_number
>>>
>>>
>>>
>>> The "user" case would hold the phone serial number. However, the
>>> "mobile_phone" serial number would __not__ hold the user serial number. Why
>>> so ?
>>>
>>>
>>>
>>> 1. storing the relation between a phone and an user at a single place
>>> avoids data duplication, making the whole system much easier to update /
>>> maintain
>>>
>>>
>>>
>>> 2. in CommCareODK, we didn't need to know (in the "mobile_phone" case
>>> display) that a phone was given to an user. It would have been nice, but it
>>> is not a requirement
>>>
>>>
>>>
>>> 3. in CommCareODK, we did need to know (in the "mobile_user" case
>>> display) the serial number of the phone associated to a user (for
>>> verification purpose, so our field team would know if unregistered phone
>>> swapped occurred, which could happen when phone breaks)
>>>
>>>
>>>
>>> 4. we built an Access / Excel system that would link all these data
>>> together (SQL queries, etc) for our M&E / detailed reports / phone
>>> maintenance operations.
>>>
>>>
>>>
>>>
>>>
>>> So if you don't really need __in CommCareODK__ to see how many persons
>>> are linked to a business, I'd continue with what you have now (a regularly
>>> updated lookup table of businesses and a one way link Individual ->
>>> Business) and leverage some kind of database / report analysis to build the
>>> list of individuals per business.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Charles
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sunday 14 June 2015 10:45:40 John Skelton wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> > I am looking to find a way so that cases in separate modules can
>>> interact
>>>
>>> > with each other (e.g. update each other). I have a case type called
>>>
>>> > individuals in one module, and a case type called businesses in
>>> another
>>>
>>> > module. I would like to be able to associate certain businesses with
>>>
>>> > certain individuals, e.g. to have a form in the individuals module
>>> which
>>>
>>> > allows me to select one of the businesses from the businesses module.
>>> I
>>>
>>> > would then save this information to the individual's case properties.
>>> This
>>>
>>> > process would also update the selected business as I would load
>>> information
>>>
>>> > about the individual (e.g. name) into the business's case properties.
>>>
>>> >
>>>
>>> > I think this could be achieved it it was possible to have a lookup
>>> table,
>>>
>>> > the rows of which were cases from another module (e.g. businesses). Is
>>> this
>>>
>>> > possible? Currently I am just making do with a lookup table that has a
>>> list
>>>
>>> > of businesses, in a form in the individual's module. Obviously this
>>> doesn't
>>>
>>> > interact with or update the businesses module.
>>>
>>> >
>>>
>>> > I don't think a parent-child relationship would be appropriate here
>>> because
>>>
>>> > a business may be associated with many individuals, and therefore in
>>> many
>>>
>>> > occasions users will not want to create a new business case but rather
>>> find
>>>
>>> > one that already exists in the system: either as a row in a lookup
>>> table or
>>>
>>> > preferably, as mentioned above, as a case in its own right.
>>>
>>> >
>>>
>>> > Thanks for any ideas!
>>>
>>> >
>>>
>>> > John
>>>
>>> >
>>>
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Charles Flèche
>>>
>>> mHealth Advisor
>>>
>>> Télécoms Sans Frontières http://www.tsfi.org
>>>
>>> Première Urgence - Aide Médicale Internationale http://www.pu-ami.org
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "commcare-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to commcare-user...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Sorry for not getting back to you sooner on this. We cannot currently have
functionality that supports the use case that you suggested, but we may be
able to have functionality like this in the future. If you could describe
what you would need in a UserVoice case http://dimagi.uservoice.com/ we can
try to garner support for this functionality.
Thanks,
···
--
Nate Haduch
Technical Support Analyst
Dimagi, Inc | 585 Massachusetts Ave | Suite 3 | Cambridge, MA 02139
Hi Will,
Thanks for the suggestion. This almost works. The only problem is that I
might have an Individual who I want to register and track who remains
entirely unrelated to a Business initially. At a later point I might want
to associate the Individual to a Business (this is when they begin an
apprenticeship). The way you suggest would be the solution if I wanted the
individual to be associated with the business from the outset, but I can't
guarantee this so, as far as I can see, this would probably not be an
across-the-board solution.
Thanks!
John
On Thursday, June 18, 2015 at 4:02:15 PM UTC-1, William Pride wrote:
Hello John,
I notice you dismissed the idea of using parent-child case relations here
because “because a business may be associated with many individuals" -
however, the parent-child feature allows for a one-to-many relationship
like you describe. I'd consider the following design:
"Register Individual" form in the "Business" module that has you first
select a business to associate with the individual, then fill out the
information about the individual, then open a new "Individual" case as a
sub case of the parent. You can load up any information from the business
case into the individual case as you need in this form.
Do you think this would work? Please let me know if I'm misunderstanding
your requirements.
Thanks very much for your reply and advice - you understood perfectly
what I need. In some ways it might be preferable to continue with a lookup
table anyway, and as you suggest I can do the analysis of
business-individual outside of CommCare. I would, though, be interested to
know if it is possible to link two case types in this way!
Thanks
John
On Monday, June 15, 2015 at 11:45:34 AM UTC-1, Charles Flèche wrote:
Dear John,
We had to do something like this in our previous projects: linking two
cases together by a common value. We had:
cases to describe a piece of equipment (mobile phone for example).
Values here would be serial_number (the key), manufacturer, model, etc…
cases to describe a mobile phone user. Values here would be name,
location, phone_serial_number, etc
As you notice, a phone and an user are linked by the phone serial
number: mobile_user.phone_serial_number and mobile_phone.serial_number
The "user" case would hold the phone serial number. However, the
"mobile_phone" serial number would not hold the user serial number. Why
so ?
storing the relation between a phone and an user at a single place
avoids data duplication, making the whole system much easier to update /
maintain
in CommCareODK, we didn't need to know (in the "mobile_phone" case
display) that a phone was given to an user. It would have been nice, but it
is not a requirement
in CommCareODK, we did need to know (in the "mobile_user" case
display) the serial number of the phone associated to a user (for
verification purpose, so our field team would know if unregistered phone
swapped occurred, which could happen when phone breaks)
we built an Access / Excel system that would link all these data
together (SQL queries, etc) for our M&E / detailed reports / phone
maintenance operations.
So if you don't really need in CommCareODK to see how many persons
are linked to a business, I'd continue with what you have now (a regularly
updated lookup table of businesses and a one way link Individual ->
Business) and leverage some kind of database / report analysis to build the
list of individuals per business.
Regards,
Charles
On Sunday 14 June 2015 10:45:40 John Skelton wrote:
Hi all,
I am looking to find a way so that cases in separate modules can
interact
with each other (e.g. update each other). I have a case type called
individuals in one module, and a case type called businesses in
another
module. I would like to be able to associate certain businesses with
certain individuals, e.g. to have a form in the individuals module
which
allows me to select one of the businesses from the businesses module.
I
would then save this information to the individual's case properties.
This
process would also update the selected business as I would load
information
about the individual (e.g. name) into the business's case properties.
I think this could be achieved it it was possible to have a lookup
table,
the rows of which were cases from another module (e.g. businesses).
Is this
possible? Currently I am just making do with a lookup table that has
a list
of businesses, in a form in the individual's module. Obviously this
doesn't
interact with or update the businesses module.
I don't think a parent-child relationship would be appropriate here
because
a business may be associated with many individuals, and therefore in
many
occasions users will not want to create a new business case but
rather find
one that already exists in the system: either as a row in a lookup
table or
preferably, as mentioned above, as a case in its own right.
--
You received this message because you are subscribed to the Google
Groups "commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to commcare-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thank you for getting back on this: I will describe this in more detail on
a UserVoice case.
Best regards,
John
···
On Monday, June 29, 2015 at 2:31:18 PM UTC-1, nhaduch wrote:
>
> Hi John,
>
> Sorry for not getting back to you sooner on this. We cannot currently have
> functionality that supports the use case that you suggested, but we may be
> able to have functionality like this in the future. If you could describe
> what you would need in a UserVoice case http://dimagi.uservoice.com/ we
> can try to garner support for this functionality.
>
> Thanks,
>
> --
> Nate Haduch
>
> Technical Support Analyst
> Dimagi, Inc | 585 Massachusetts Ave | Suite 3 | Cambridge, MA 02139
>
>
> On Thu, Jun 18, 2015 at 2:29 PM, John Skelton <jske...@lr.mercycorps.org > wrote:
>
>> Hi Will,
>> Thanks for the suggestion. This almost works. The only problem is that I
>> might have an Individual who I want to register and track who remains
>> entirely unrelated to a Business initially. At a later point I might want
>> to associate the Individual to a Business (this is when they begin an
>> apprenticeship). The way you suggest would be the solution if I wanted the
>> individual to be associated with the business from the outset, but I can't
>> guarantee this so, as far as I can see, this would probably not be an
>> across-the-board solution.
>>
>> Thanks!
>> John
>>
>>
>>
>> On Thursday, June 18, 2015 at 4:02:15 PM UTC-1, William Pride wrote:
>>>
>>> Hello John,
>>>
>>> I notice you dismissed the idea of using parent-child case relations
>>> here because “because a business may be associated with many individuals" -
>>> however, the parent-child feature allows for a one-to-many relationship
>>> like you describe. I'd consider the following design:
>>>
>>> "Register Individual" form in the "Business" module that has you first
>>> select a business to associate with the individual, then fill out the
>>> information about the individual, then open a new "Individual" case as a
>>> sub case of the parent. You can load up any information from the business
>>> case into the individual case as you need in this form.
>>>
>>> Do you think this would work? Please let me know if I'm misunderstanding
>>> your requirements.
>>>
>>> Best,
>>> Will
>>>
>>> On Tue, Jun 16, 2015 at 12:24 PM, John Skelton < jske...@lr.mercycorps.org> wrote:
>>>
>>>> Hi Charles,
>>>>
>>>> Thanks very much for your reply and advice - you understood perfectly
>>>> what I need. In some ways it might be preferable to continue with a lookup
>>>> table anyway, and as you suggest I can do the analysis of
>>>> business-individual outside of CommCare. I would, though, be interested to
>>>> know if it is possible to link two case types in this way!
>>>>
>>>> Thanks
>>>> John
>>>>
>>>>
>>>> On Monday, June 15, 2015 at 11:45:34 AM UTC-1, Charles Flèche wrote:
>>>>>
>>>>> Dear John,
>>>>>
>>>>>
>>>>>
>>>>> We had to do something like this in our previous projects: linking two
>>>>> cases together by a common value. We had:
>>>>>
>>>>>
>>>>>
>>>>> - cases to describe a piece of equipment (mobile phone for example).
>>>>> Values here would be serial_number (the key), manufacturer, model, etc…
>>>>>
>>>>> - cases to describe a mobile phone user. Values here would be name,
>>>>> location, phone_serial_number, etc
>>>>>
>>>>>
>>>>>
>>>>> As you notice, a phone and an user are linked by the phone serial
>>>>> number: mobile_user.phone_serial_number and mobile_phone.serial_number
>>>>>
>>>>>
>>>>>
>>>>> The "user" case would hold the phone serial number. However, the
>>>>> "mobile_phone" serial number would __not__ hold the user serial number. Why
>>>>> so ?
>>>>>
>>>>>
>>>>>
>>>>> 1. storing the relation between a phone and an user at a single place
>>>>> avoids data duplication, making the whole system much easier to update /
>>>>> maintain
>>>>>
>>>>>
>>>>>
>>>>> 2. in CommCareODK, we didn't need to know (in the "mobile_phone" case
>>>>> display) that a phone was given to an user. It would have been nice, but it
>>>>> is not a requirement
>>>>>
>>>>>
>>>>>
>>>>> 3. in CommCareODK, we did need to know (in the "mobile_user" case
>>>>> display) the serial number of the phone associated to a user (for
>>>>> verification purpose, so our field team would know if unregistered phone
>>>>> swapped occurred, which could happen when phone breaks)
>>>>>
>>>>>
>>>>>
>>>>> 4. we built an Access / Excel system that would link all these data
>>>>> together (SQL queries, etc) for our M&E / detailed reports / phone
>>>>> maintenance operations.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So if you don't really need __in CommCareODK__ to see how many persons
>>>>> are linked to a business, I'd continue with what you have now (a regularly
>>>>> updated lookup table of businesses and a one way link Individual ->
>>>>> Business) and leverage some kind of database / report analysis to build the
>>>>> list of individuals per business.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Charles
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sunday 14 June 2015 10:45:40 John Skelton wrote:
>>>>>
>>>>> > Hi all,
>>>>>
>>>>> >
>>>>>
>>>>> > I am looking to find a way so that cases in separate modules can
>>>>> interact
>>>>>
>>>>> > with each other (e.g. update each other). I have a case type called
>>>>>
>>>>> > individuals in one module, and a case type called businesses in
>>>>> another
>>>>>
>>>>> > module. I would like to be able to associate certain businesses with
>>>>>
>>>>> > certain individuals, e.g. to have a form in the individuals module
>>>>> which
>>>>>
>>>>> > allows me to select one of the businesses from the businesses
>>>>> module. I
>>>>>
>>>>> > would then save this information to the individual's case
>>>>> properties. This
>>>>>
>>>>> > process would also update the selected business as I would load
>>>>> information
>>>>>
>>>>> > about the individual (e.g. name) into the business's case properties.
>>>>>
>>>>> >
>>>>>
>>>>> > I think this could be achieved it it was possible to have a lookup
>>>>> table,
>>>>>
>>>>> > the rows of which were cases from another module (e.g. businesses).
>>>>> Is this
>>>>>
>>>>> > possible? Currently I am just making do with a lookup table that has
>>>>> a list
>>>>>
>>>>> > of businesses, in a form in the individual's module. Obviously this
>>>>> doesn't
>>>>>
>>>>> > interact with or update the businesses module.
>>>>>
>>>>> >
>>>>>
>>>>> > I don't think a parent-child relationship would be appropriate here
>>>>> because
>>>>>
>>>>> > a business may be associated with many individuals, and therefore in
>>>>> many
>>>>>
>>>>> > occasions users will not want to create a new business case but
>>>>> rather find
>>>>>
>>>>> > one that already exists in the system: either as a row in a lookup
>>>>> table or
>>>>>
>>>>> > preferably, as mentioned above, as a case in its own right.
>>>>>
>>>>> >
>>>>>
>>>>> > Thanks for any ideas!
>>>>>
>>>>> >
>>>>>
>>>>> > John
>>>>>
>>>>> >
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Charles Flèche
>>>>>
>>>>> mHealth Advisor
>>>>>
>>>>> Télécoms Sans Frontières http://www.tsfi.org
>>>>>
>>>>> Première Urgence - Aide Médicale Internationale http://www.pu-ami.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "commcare-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to commcare-user...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "commcare-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to commcare-user...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>