ContactPackage
Name and address information is potentially a lot more complex than a simple address book. The basic plan for the Contact package is that it provides a cross referenced list of information relating to each base contact. The simple view of this would be a name with perhaps an address plus phone number and email address, but this can quite easily expand rapidly with works address, or holiday home contact details or a combination of email addresses. A 'name' may be a supplier and there may be contact details for a number of linked person names and their associated phone and email details. It is this complex tree that it is hoped we can make manageable with a recursive view of the data tree.
Check the page history to view the different tacks taken on contacts.
Now XREF table has been tweaked to handle a number of groups of additional contact information in parallel. The first group of options is a list of contact record types from which multiple choices can be made. One of the things that has always annoyed me in Sage is the fact that a supplier and a customer may well be the same person, but they have to have two records. This way we can simply tag them as both. A more important facet of this facility is the ability to add other groupings of client records such as 'venue' for the events management system, or 'maintainer' for the security management version. The contact Xref type table manages the extra fields available, and further provides a role filter on that data. For example the accounts group of records can be limited to an accounts user.
There are a number of different types of extra records. Starting with a single entry record, where only one of that type of record can be added such as for a VAT number. More generally though, the reason for wanting to add this flexibility was the need to handle perhaps several phone numbers or email addresses, and the xorder field allows those to be ordered as required. Another layer of the jigsaw is to add address information. In the UK, these can be simple house name/number plus postcode, and while the information can be added in the xref table in that format, the helper address package is used to display information in full format, and allow searching of postcode information by road name or town. A second NLPG helper package allows working with UPRN references from the NLPG database, which is the preferred method for council sites to identify properties. With the increasing availability of postcode data from other countries a full coverage should become possible over time. Initially, the country and zone tables have been imported from commerce and are used as the top level selector for manually handled address data.
The contact table then simply becomes entries in the liberty_content table, using the TITLE field the displayable contact name, and allowing all of the other LC management tools to be used. Other text data can then simply be managed as comment records attached to those records. Additional
Now we are ready to import data from the other systems. My accounts have been done in Sage for many years and so the main supplier list is there along with primary customers, but my on-line customer base is in paypal and we just add the invoice data to sage. So the first problem is importing sage data followed closely by importing papal data. This will give a fairly complete contacts listing for our business activities, and we can then add missing information on top of that. The plan of attack is to build a complete list of products to use with the commerce package from the paypal line item information, and then link that back to the current paypal shopping basket based pages as we migrate customers.