The best, most definitive, and most correct way to do this is to not mix your "test" and production data in the same database in the first place.
Testing against production is going to result in a major, serious event for the business at some point. For that matter, the number of people who even have access to that production database should be minimal, for ...
A quick solution might be to make a trigger in the Work_Area table that checks the Interests table to see if that field already exists, and if it does not then insert it as a new record. This would prevent the need to manually add an author's new interests, just add their new article and let the interests table take care of itself
I find your design a bit backword, can a delivery_note_partner_A exist without a corresponding delivery_note?
Assuming that is not the case, I would suggest:
CREATE TABLE delivery_note
( delivery_note_id ... NOT NULL PRIMARY KEY
Depending on how much processing of the notes for each partner you are going to do, you may consider something like: