What about this scenario:
Site A is functioning well and persists orders 1 to 10
Site B is passive but kept up-to-date so effectively it has copies of orders 1 to 10.
Lightning strikes after order 10 is placed on Site A but before it's copied to Site B.
Site B becomes active while repairs take place on Site A
Because Order 10 is not available from Site B User has to resubmit it.
It happens not straight away, so the which was Order 10 on Site A gets number 12 on Site B.
At the same time another, totally irrelevannt order takes Number 10 on Site B.
Now, what will happen when Site A comes back to life?
GUID will prevent orders "No.10" from overlapping, but same order with No.10 on Site A and No.12 on Site B will still be duplicated.
There will be 2 identical deliveries instead of one, 2 following invoices instead of one, missing payment, penalties, disputes, etc.
Whole idea of using GUID or any other kind of auto-generated "across different instances" identifiers is faulty.
Unique entries of orders or any other business objects must be identified by natural keys defined by business logic, nothing else.
IDENTITY is perfectly good as an internal identifier within a database.
Just don't include it into replication process. Let target database generate its own IDs'.
_____________
Code for TallyGenerator