title: Anywhere re-orders the sequence of the transactions
body: <p>We noticed that Anywhere is grouping and ordering the transactions such that the transactions for the parent [i.e.: Work Order] were sent first and then the transaction for the child records [e.g.: Specifications]</p>
  
  <p>Scenario:
  Step 1. Alter the description on the WO
  Step 2. Enter Specification values
  Step 3. Change the WO Status to COMP</p>
  
  <p>The resulting transactions are sent as follows
  Step1 and Step3 are grouped and sent to Maximo
  On success
  Step 2 is sent to Maximo</p>
  
  <p>We want the messages to be sent in the same order that they happened and the reason for this is the validations we have in place in Maximo</p>
  
  <p>e.g.: We validate if the child table has records [in our case, we check if the specifications are populated] before we Complete a WO</p>
  
  <p>Due to the re-order of the events\transactions we are unable to COMP a WO from the device as the child transaction never gets to Maximo because the Parent transaction failing due to missing child data [catch 22]</p>
  
  <p>We found the piece of code in the [/MaximoAnywhere/apps/WorkExecution/common/js/platform/model/PushingCoordinatorService.js] JS file that does this re-order and we commented out the reorder</p>
  
  <pre><code>//if (!transaction.json[PlatformConstants.TRANSACTION_LOCK_FORUPDATE])
  //{
  //    Logger.trace("[PUSHING] Trying to shrink/merge transactions and lock transactions");
  //    var self = this;
  //    var promise = this._shrinkSubTransactions(metadata, transaction);
  //    
  //    Logger.trace("[PUSHING] going to perform async operations");
  //    promise.then(function() {
  //        self._pushSubTransactions(transaction, deferred);
  //    });
  //}
  //else
  //{
      Logger.trace("[PUSHING] going to perform async operations");
      this._pushSubTransactions(transaction, deferred);
  //}
  </code></pre>
  
  <p>Once this was done we were able to COMP the WO from the device as the events/transaction are now sent in the same order as they occurred</p>
  
  <p>However, we have noticed that this has created another undesirable problem where on an error the device ends up with two Work Orders the one with the error and the one it refetched from Maximo</p>
  
  <p>Scenario: We have an active timer running on the WO and we click on the clock. This will bring up the Stop Timer View and we select [Complete Work]</p>
  
  <p>So there are two things that should happen the timer should be stopped and the status should be changed.
  Due to some validation error from Maximo this transaction fails. The result is that we end up with the same wok order twice one with the new status and the error message and one it re-fetched from Maximo</p>
  
  <p>Once we go into the record with the error and undo the change we end up with two identical WOs on the device</p>
  
  <p>Apart from the above issue, there needs to be a way to clear the local data from the device without having to delete the app</p>