A family of Microsoft relational database management systems designed for ease of use.
Before you implement a solution, respond to DBG's comment as well as to my expanded comment here. It will do no good to implement a technically effective, but contextually inappropriate approach.
If you are redundantly storing the price as part of the transaction, do you do that to preserve the "PriceAsOfPurchaseDate" price as part of the transaction? Or, are you just copying the price because the table is set up that way? In the latter case, what I'm trying to say is that sometimes tables get set up with fields that duplicate fields in other tables out of lack of in-depth knowledge of good table design.
This is a tricky case, because, as I just noted, there is a scenario where price can justifiably be stored as part of transaction. In that context it reflects "PurchasePriceAsOfPurchaseDate", which may differ from prices charged to other customers or on different days.
The "ListPrice" is the one stored in the product table. It is the price from which discounts are calculated, for example. A good customer might get a 10% discount, so the PurchasePriceAsOfPurchaseDate represents the price minus that 10%.
Another customer on the same day might pay full ListPrice.
Also, over time ListPrice can change due to rising costs, or even to lowering costs.
If you don't record the PurchasePriceAsOfPurchaseDate you might have trouble getting accurate historical reports.
So, before we go off creating code to just routinely copy a duplicate value from one table to another, you need to be able to justify that duplication for legitimate business reasons.