You may have answered your own question! If you have a relationship such that selecting the customer, will give you a few options:
1. Just show the other related fields on the layout (don't allow edit!). This however is only as current as the data in the related fields.
2. Historically, any of these fields can be set in the record. Then should there be changes in the related fields, your "historical" data is correct. Use the auto-enter lookup for these fields based on the relationship.
Sent from miPhone
if you are on the invoice layout and the invoice table has a customer ID field that is set by your drop down choice then you can leverage a relationship from Invoice::customerID -> customer::customerID to show the customer address.. etc on the invoice without "denormalising" the data into invoice::customer_address, invoice::customer_city etc...
The only reason to store the customer data in the invoice table is to capture historical data for the customer at the time of invoice.
For most businesses, it makes good business sense to copy this data into the invoice. Consider the following imaginary conversation between customer service and the customer:
"Yes we shipped the products to you yesterday. What is your current address? Oh, I see that we had a different address on file and shipped them to...."
If you link to the data--which is a good way to go in most situations, you lose that record of what address was current at the time that the order was filled.
Thank you beverly!
The record historical is my concern also, I created on the Invoice table text fields for shipment like: ShipAddress, ShipCity, etc...
I would like that the current address info would be stored in these fields for shipment for future research.
This is my idea:
When I click on Costumer drop down, then the ShipAddress is set up with related address on Accounts table like a "suggestion", but if I want change the shipment address, I can edit the address info and this new address will be stored in this invoice record.
Yes! A lookup auto-enter can be manually changed (unless you prohibit this in various ways).
Sent from miPhone