CustomerModel Proposal

[Willem-Jan Zijderveld]

Hello everybody,

Last week I decided to start contributing to Vespolina. After spending some time on IRC with some useful conversations, I started on the CustomerBundle.
I started thinking about the model, expanding the basic properties there are at the moment.

Below a proposal of the model. Before I created the needed documents (and long before creating a PR), I want others to take a look at it.
Although I 'designed' this with MongoDB in mind, it should be quit easy to make it work with an ORM implementation.
I named the model Account because I saw inspiran mentioning on IRC, that he might want to use Account instead of Customer in Vespolina.

-------------------------------------------------

Account:
accountId
type: (personal, business)
valuta: // ISO_4217
companyName
address[]:
type: (invoice, delivery)
street
streetNumber
streetNumberSuffix
postalCode
region/state
country
contact[]:
primary: boolean
firstName
lastName
email
phone[]:
type // mobile, work, private
number
dateOfBirth
jobTitle
department


AccountGroup:
name
taxCategory

-------------------------------------------------
Note: The address[], contact[] and phone[] would become embedded documents.

There are a few things I'm not quit sure about and sure like some feedback.

- Personal vs Business
First of all I'm not sure about the way we should handle and save company information.
It depends if we want to make a big distinction between personal and business accounts.
We can also decide to create a separate model for companies and reference those from the Account when needed. But then we probably need to save the address information in both models, so that isn't a really great options.
I like to hear other ideas and feedback on that!

- AccountGroup
I added AccountGroup separately. Just because I don't really have an idea what to do with it. So please feel free to tell me if anything is missing :)

- CRM
Also, I don't have much knowledge of CRM systems, so I might forgot some things that we really need.

And a minor disclaimer: I think I've read all the Wiki's, discussions and documentation there is about the CustomerBundle, but I still might have missed some information that would result in a different model design.

Willem-Jan

[Willem-Jan]

Just noticed I forgot to include 'city' in the Address model. Just think that one in there :)

[Daniel Kucharski]

Hey Willem-Jan,

Great news to join the team.  I indeed would like to see that
Vespolina can easily link with existing CRM systems.

About the model you are presenting, in general i'm fine with the
fields mentioned, although I'm thinking maybe we should group the
fields different.

I was having a look at both OpenBravo and SAP I like their Business
Partner concept, which is a generic way of dealing with accounts,
customers, employees, contact persons(check
http://wiki.openbravo.com/wiki/ERP_2.50:Configuration_Manual/Business_partners#Business_partners
)

Business Partner contains generic information such as the type (person
or organization), name, description, addreses and contact information.
 A business partner can be associated with multiple Roles which
contain role specific information.  An example would be the role
'Account' which indicates that the business partner is buying from
your company.  Other roles could be 'Employee', 'Supplier',..
 Vespolina would then provide basic roles and allow the developer to
add additional ones.  The concept of Roles facilitates also specific
use cases such as subscription based services.  You would then have a
Membership role where you could add fields related to subscription
based services (eg. "membership_level",
"gold_partner_level_since", ...)

BusinessPartner:
  id:
  name: (generic name)
  type:  ( 'person' || 'organization')
  addresses[]
  contacts[]
  roles[]
  taxClass,

RoleProspect:
   prospect_type:
   prospect_source

RoleContactPerson:
  contact_type: ('CEO' || ... )

RoleAccount (or we can call it RoleCustomer)
   account_group:
   company_name:
   contacts[]:  (referencing multiple Business Partner which should
have ContactRole)
   taxId

RoleEmployee
   employee_id:
   employee_since ...
RoleSupplier:
   supplier_id...
RoleMember:
   membership_level

As a bonus we can easily integrate map business partners roles to a
role based authorization model
Whe still should create individual classes & managers to handle
different kinds of entities (customers, suppliers, ...) and store them
in their own collections,  but lots of functionalities can be shared
amongst these entities.

[Luis Cordova]

sugarcrm too

[Daniel Kucharski]

After lot of thinking & discussion with Richard I would propose to
make it a bit simpler:

- We use a Partner (or Business Partner) class as base, which contains
amongst
- short name, long name, address(es), communication channel info
(tel, email, fax, ...)
- a discriminator is used to make the difference between person or
organization
- if it's an organization, we store a hash of organizational
specific info (eg. $aPartner->getOrganizationData('tax_unique_id') )
- we can do the same with person if needed

- Employees, Customers, Contact Persons are just partners.
- Creating partners is performed through a partner manager, which
setups the same partner (eg setting up discriminator field for
individual/organization).

$aNewPartner = $partnerManager->createPartner( $partnerType ); //
$partnerType = 'organization' or 'person'


- Modeling of contact persons of an organization can be done by
embedding partners:

PartnerGoogle:
name: Google
contacts:
PartnerLarryPage:
name: Larry Page
PartnerEricSmith:
name: Eric Smith


- Persisting: or we store each type (employee, customers, vendors)
into it's own account or we store them all in a big partners
collection/table. My current preference goes to storing them
individually to make it less complex to query / comprehend.

Let me know what you guys think about it.

On Mar 1, 2:13 pm, Daniel Kucharski <dan...@xerias.be> wrote:
> Hey Willem-Jan,
>
> Great news to join the team.  I indeed would like to see that
> Vespolina can easily link with existing CRM systems.
>
> About the model you are presenting, in general i'm fine with the
> fields mentioned, although I'm thinking maybe we should group the
> fields different.
>
> I was having a look at both OpenBravo and SAP I like their Business
> Partner concept, which is a generic way of dealing with accounts,

> customers, employees, contact persons(checkhttp://wiki.openbravo.com/wiki/ERP_2.50:Configuration_Manual/Business...

[Willem-Jan Zijderveld]

Hi all,

Finally had some time to look at this again.

I think we should start with the Roles, but just with a very basic setup.

Just a discriminator field to determine the role. And I think we should go with a default partner role Customer (decided in the manager, not in the Model). 

Embedding partners seems fine with me. Would have to think how we would do this best in the ORM, but that shouldn't stop us from continuing.

About the data storage considering Individual or Organisation partners. I prefer we don't save it in a hash. For MongoDB is doesn't make a lot of a difference.

But for MySQL it does. Not only is the data not searchable, queries that include the TEXT field will be slow*, and that is something you probably don't want on a large table with partners. I think we should at least keep the option open in the model (not enforce a type). And let the manager decide what data it expects. So people can implement their own method as they like.

And if we should store the different type of Partners (by role). I think we should determine first how much data each role would get.

If it isn't that much data, I think we should store it in 1 collection/table. Also because I think people usually don't have much different roles in a single application. It mostly will be a bunch of one role, and only a few of the others (although that would make separate collections/tables better, performance wise?).

I already started with some models. More for myself, to get a picture how it would work out. I didn't really started with the Documents yet, I wanted to know where we are heading first :) https://github.com/beeldspraak/VespolinaPartnerBundle

In my current models, I assume a VespolinaCommonBundle with the Address and Contact models, as we probably will need those both in other Bundles. In this current setup I assumed the Contact would have al the information about phones/email and optional more addresses.

Willem-Jan

* Queries with TEXT/Blob fields in the result that are processed with a temporary table are processed on disk. http://dev.mysql.com/doc/refman/5.5/en/blob.html