Word of caution not to be the creator of your own “next DBA emergency”. There might be triggers firing, batches running and/or applications reference and processing data on your inconsistent data. Even an ETL (without the “L”) running to extract and send data to an extern company, spoiling your boss happiness soon.
Why is it called Transactional Replication? Because it is supposed to guarantee all or none of the unit of work completed and the actions in the same sequence. One of the principal concepts of this type of replication and a major factor in which article goes into which publication. That might be one of the main reasons why you went with this type of replication in the first place, or not? Most applications and developers will rely and take your word for it.
So may be skip each problematic transaction as an unite, one by one. Or as an alternative set the “Agent Profile” to “continue on data consistency errors”, if you gone skip many transactions. This would not take much more effort. Knowledge and understanding of your replication schema, data, systems, company’s business and the root source of the conflict will be crucial on deciding on an appropriate approach to resolve the conflict.
If you encounter one conflict, you should make sure all objects are in synch. Proper steps should also be taken to prevent data conflicts in the future as well.
This article might need a proper disclaimer or may be a red warning. (My apology if I missed it.)
(As English is not my first language, I beg you please to ignore grammar and spelling.)