Firstly - synthetic keys are not an evil that needs to be eradicated, they are a valid and efficient way to handle composite keys (association keys made up of more than one field).
In your case, you would need to decide if the association between customer and monthly sales activity should be a salesman level or at a salesman and branch level. If the former, then you simply could not load the branch code into the customer table. If its the latter, you could create your own handling of the composite key, or you could leave the synthetic key in place.
The same analysis should be performed on the other synthetic key.
Building in your own handling of the composite key is unlikely to perform better in reload or in the front end.
monthly sales activity table and
items master table you have filed like itmes#,
if you have same underlined data in that filed in both the tables,
create a..composite key with vndr# and items#,
or if you don't have same underlined data in items# in both the tables rename that in one table.
to avoid second synthetic key,
create composite key with branch_cd and cus_salesmen.