Repairing corrupt workflow data/ reprocessing data

I'm new to OS and am principally responsible for integrating an OS based
application that has been written for us by an outside vendor.   It's a
reconciliation management system in which the OS steps correspond to various
steps in the analysis of the reconciliation request.   For example,
verifying dealer tagging and whether a payment has already been made on the
account relate to specific steps in the xml document that controls the
workflow.

Occasionally, data problems cause the workflow to generate incorrect
results; after fixing the data, we need to re-process the affected
reconciliations.   Most of the time we can do this simply by doing this
update:

update OS_CurrentStep set Step_ID = 2, Action_ID = null, Owner = 'system',
Start_Date = sysdate, Finish_Date = null, Status = 1, Step_State = null
where Entry_ID in (select ProcessSeq from claim where <*** various criteria
***> ).
(NB: claim is the repository of reconciliation requests.   The application
populates this with account numbers and customer information; then analyzes
it to check existing payment status and customer eligibility).
After committing this update, the workflow engine reprocesses the updated
reconciliations from Step 2, which is basically the condition of a
reconciliation just after it's been submitted by the user of the
application.
However, it sometimes happens that the reprocessing runs into integrity
violations, suggesting that the data in OS_HISTORYSTEP, OS_CURRENTSTEP,
etc., is corrupt.   I have not been able to figure out a way to adjust this
data to allow existing reconciliations to be cleanly reprocessed.  Initially
I get an error message similar to this:

java.sql.SQLException: ORA-00001: unique constraint
(TRU_CLM.OS_HISTORYSTEP_PK_IND) violated

        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
        at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
  
This implies that deleting the related records from OS_HISTORYSTEP would fix
this, but I ran into the foreign key constraints on OS _HISTORYSTEP_PREV and
OS_CURRENTSTEP_PREV.   So I deleted the corresponding records from those two
tables, and then from OS_HISTORYSTEP.   Then I re-attempted the original
update to OS_CURRENTSTEP as described above.   This time I got similar
results.
Is there any way to wipe the OS tables clean of references to a particular
data record, and allow the workflow to reprocess?