I suspect your data structure would benefit from further normalization.
Based on how I understand your description, one store can have many
locations, and one location can have many UPC Codes (items). In a
well-normalized relational database, this would require three tables, not
one.
The first table would hold StoreID and any other fields related ONLY to the
store (e.g., address, etc.).
The second table would hold LocationID, and any other fields related ONLY to
the location (e.g., Location Short Name, Description, ...)
The third table would hold UPC Codes, and any other ...
But this is just a start! Your inventory record would consist of the fields
you described, plus probably an InventoryID field, and a date/time field to
record WHEN that store in that location had that many of that item.
And we're still not done. Rather than repeatedly storing the same StoreID
(by default or by data entry), you would benefit from using a
mainform/subform construction. The main form would have Store and Location
fields, while the subform would be based on that junction table. By setting
the subform to use the mainform's (i.e, the 'parent's) StoreID and
LocationID, you NEVER have to re-enter the StoreID or the LocationID for
multiple items (UPC Code) from the same Store/Location.
Each time you move to a new location (and/or store), enter those once in the
main form and let Access handle entering them into the appropriate subform
controls.
Good luck!
Regards
Jeff Boyce
Microsoft Access MVP
--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.
Any code or psuedocode included in this post is offered "as is", with no
guarantee as to suitability.
You can thank the FTC of the USA for making this disclaimer
possible/necessary.