Managing the delete process in the client is a little more complex. Mostly because all solutions allow deletes in lots of different ways, and you need to trap all of the deletes, and record the unique ID of each deleted record, so that it can be sent to the server. Otherwise it will re-appear next time someone else does a modification.
Any process that is deleting records in the sync client, should be done via scripts so that you capture the unique ID. You can do a check if the record has been synced before by looking at the SyncUTC field. If there's a value in this field, it must be captured for deletion. If the field is empty, then it doesn't exist on the server, and so the record can be deleted without issue.
When you delete a record, make sure you set the field RESTfm::RESTfmDelete using the following calc :
DictReplace ( RESTfm::RESTfmDelete ; $tableName ; List ( DictGet ( RESTfm::RESTfmDelete ; $tableName ) ; $id ) )
This appends the ID to a list of IDs in the RESTfm::RESTfmDelete field, organised as a key, based on the table name. When the next sync process runs, this record will be pushed to the server, and the server side record will be marked as deleted.
The next time other clients do a sync, they will get the details of this record, including the delete flag. The sync process will then automatically delete those records via a cascading delete from the RESTfm table. No user interaction is required, but you do need to build your data model on the assumption that this will happen.
The nature of syncing means that you can finish syncing one table, but get a failure because the network drops out, half way through the second table. So if you're using deletes, it's technically possible to have a sync delete an invoice record, but fail before being able to delete the matching invoice IDs. You can work around that by adjusting the sync order, to do invoices first, and use a cascading delete for invoice items. It won't affect the process if a record is already deleted when the sync happens.