ooops <field name="postalCodeGeoId" type="id"></field> which would point to a entity Postalcode with a one to one would point to postalCodeLine with a one to one
BJ Freeman sent the following on 7/26/2008 11:07 AM: > the Postal Address in the data book > has: > address1 > address1 > and > directions. > > the postaladdress entity has: > toName name > attnName name > > which to me should be using the postaladdress to PartyContactMech only > > > these should be removed > postalCode short-varchar > postalCodeExt short-varchar > and just use the > <field name="postalCodeGeoId" type="id"></field> > which would point to a entity Postalcode with a one to many (parent to > child) would point to postalCodeLine with a one to many (parent to child) > The reasoning for the refactor is the would like to change the > PostalAddress to point to a new Entity Address line > with a one to many (parent to child) relation > it would have a sequence number for getting the proper output. > this would allow flexibility that is used in other countries. > the Postal address would also point to new entity AddressDirections > > > David E Jones sent the following on 7/26/2008 10:16 AM: >> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote: >> >>> the databook figure 2.8 has it the way I figure it should be. >>> is there a reason it was implemented the way it was. >>> 1) postaladdress has party information >> Could you be more specific? >> >>> 2) it has Postal Code instead of being in the geography boundary >> It actually has both. >> >> -David >> >> >> >> > > > >
