Contact information is not consolidated and as a result non-optimal

[dalers]

Created as a maintenance task based on discussion between @timschofield and @pakricard in "New HR system" #894.

I agree with the premise and believe webERP could only benefit from the simplification (assuming the work is not left "good enough for now" but someone sees it through all the way to the end). The master contact (edit: corrected) record can simply be the compilation of all the needs of all modules (one level of refactoring or pre-optimisation could be tolerated if the future gain would be significant - classic judgement call ;-) ).

There may be a "best way" for third-party code to extend the master contact (edit: again, either bad auto-correct or maybe my fingers) information for their own purposes, but it should not be the concern of webERP beyond speculating that such a method exists (webERP's concern should be that webERP code uses and only uses the master contact record).

@pakricard : I think it would be a massive code improvement to compile all addresses in webERP in a table (suppliers, customers, shipments, etc). I guess that was the idea behind addressbookid but it is a wide system change and we should tackle it independently in another discussion and time.

@timschofield It still is in my mind to do. It's probably a mistake to allow that field through for now though

[timschofield]

I like the idea of this, and I have been reading through how other ERPs that have an address book module actually use it. It is very intrusive as it affects many areas of webERP, so needs careful planning. Also consideration needs giving to purchase and sales orders, buth future and historic as both currently save a snapshot of the address in their respective database tables.

I have moved this to discussions, as it is a feature request, not a bug.

Tim

[dalers]

I have moved this to discussions, as it is a feature request, not a bug

I had originally thought of this as maintenance or architecture refactoring for simplification and simpler code. Iiuc, you see it as a feature that makes user's lives simpler by consolidating managing contact information.

Unless there is a direct user benefit in return for doing some amount of work, at least the short-term benefit of the work to those doing the work will be insignificant - if not negative. I tend to have pushed a "simpler is better" motto lately but appreciate your point @timschofield :-)

I agree with making this a discussion thread - it's certainly not broken behavior (unless maybe from the perspective of the maintenance team? :-) ). "Tomatoe, tomatoe" or maybe "Through the looking glass"? ;-)

[dalers]

both currently save a snapshot of the address in their respective database tables

Can a snapshot be considered just that, a snapshot? The master contact record would presumably be the record of truth, and divergence from the current record to the snapshot over time would have to be tolerated. Does that make sense?

[dalers]

or the snapshot has to be updated if the master record is updated (i.e. trigger updating the snapshot if the master record is updated), potentially including transforming the current master record format to that of the snapshot and in the process abstracting the actual data source to the existing code (assuming existing code only reads the snapshot). Does that makes sense? Am I talking crazy talk?

[andrewgaluski]

This is something I have on my list as well. The ability to have a "Contact", then use/assign a contact (with a Role) to a Vendor/Customer. Also - along the same line of thinking - one address book. Similar concept for 'entities'. Create an "Entity" to store master information. "Use as Vendor" creates supplier. Use as Customer - created debtors etc. SO an entity that is a partner and a customer or a Customer AND a vendor has one entity, one each for the children records so existing code can JUAT look at existing tables and the Master Data Entity drives the data to the needed 'sub records'. That may duplicate some data however it is a step in the right direction and allows for existing code to be refactored as time allows to utilize the entity record.

[dalers]

how other ERPs that have an address book module actually use it.

It may not look like an address book module. In Tryton (https://tryton.org), a "party" is the lowest-level (highest-level?) data structure that defines an entity. A party can be a user, a company, an employee, a customer, a supplier, etc. as needed by a particular module. When creating a new customer for example, an existing party must be selected or a new party must be created first.

It's probably not worth looking at Tryton in any deeper detail because differences would become overwhelming (Tryton is OO-on-steriods compared to webERP) but the general concept could still be applied to webERP. While Tryton modules can artibrarily extend the master party record as needed for module-specific fields, the master contact in webERP could simply be all the fields that all the modules require (consolidating where possible).