As long as your application allows users to specify the primary key you'll get these primary key violation conflicts. In a non-replicated environment the users would not be allowed to this same operation: the primary key would prevent them from creating the duplicate row.

I would suggest to adapt the application such that it allows the users to update the rows instead of deleting and then recreating them. Plus make the users aware of the problem they're creating when deleting and recreating the same values.

An alternative approach could be to have the software not physically delete the rows upon the ned user's request, but instead update a column indicating the row is not to be shown anymore, i.e. 'soft-deleted'. When recreating a previously 'soft-deleted' row, you do not insert a new row but update the soft-deleted row to remove the 'deleted' marking. This way the row's guid will remain the same. A conflict will still occur if the laptops haven't been synced in time, but this conflict will only be a type 2(Column update conflict) which is easy to resolve once you know which is the latest update. The application logic for creating a new row is going to be a little more complicated, as well as you now need to check for the "deleted" column in any and of the queries referencing this table. But it does solve your problem