Re: Proposed changes in trunk: adding mappings to entity_credit_account for addresses, etc

["Chris Travers" <..hidden..>]

On Wed, Aug 6, 2008 at 8:58 AM, Chris Travers <..hidden..> wrote:
> Currenty, in trunk, all addresses, contact info, etc are mapped back
> to a company or person entity.  We do not have mappings per
> customer/vendor account.
>
> I have had at least one request for contract (entity_credit_account)
> to address mappings in the following way:
> 1)  Every entity_credit_account can only have one billing address
> 2)  Any number of contacts per entity_credit_account record
> 3)  One bank account listed per entity_credit_account (for automated payments)
> 4)  Notes that can be attached to either the entity or contract

Currently the technical proposals include:

1)  New mapping tables eca_to_contact and eca_to_location which are
similar in strcture to company_to_contact and company_to_location.
These, along with person_to_contact and person_to_location should
probably be moved into an inherited tree of tables for better
management similar to what we do with notes.  The old tables would
continue to be used for contact info which is not mapped to a
contract.

2)  New stored procedure API's which retrieve contacts and locations
by credit_id rather than company_id.

3)  A partial index on eca_to_location as follows:
CREATE UNIQUE INDEX eca_to_location_billing_u ON
eca_to_location(credit_id) WHERE location_class = 1;

4)  A new field in entity_credit_account:  bank_account_id REFERENCES
bank_account(id)

5)  A new eca_note table and note class:
INSERT INTO note_class (id, class) values (3, 'Entity Account');

CREATE TABLE eca_note(FOREIGN KEY (ref_key) REFERENCES
entity_credit_account(id), CHECK (note_class = 3)) INHERITS (note);

There are still a few UI considerations to sort out to make everything
generally applicable, but I think they are manageable.

Best Wishes,
Chris Travers