This is a fairly complex topic, but the good news is that once you master the technique of analyzing this with Fiddler, the problem becomes fairly simple to isolate and resolve.

The pzTransactionID is an artifice used to keep the browser and the server in synch.  Every time a new database transaction starts on the server, a new pzTransactionID is created and associated with that database Transaction.

In order for any POST request (like a reloadSection or a FinishAssignment) from the client to be accepted by the server, the client must send a pzTransactionID which matches what the server believes to be the current pzTransactionID.  If there is a mismatch, the POST request is rejected, and you see the error message that you show above.

Very simplistically, this prevents an Application from posting something to the database, the user using the browser Back button to return to the previous screen, and resubmitting the same thing.  After the first post, the database would commit the data and the pzTransactionID would change.  Using the "back" button brings back the previous cached screen, with the (now stale) previous pzTransactionID.  When the user tries to POST it again, it is rejected because the transaction id is incorrect.

Commits in flow processing happen automatically after FinishAssignment, and if you use Fiddler to capture the traffic, you will see that in the Response  to a FinishAssignment, you usually will receive a new pzTransactionID.  It is this ID that will be used in the subsequent POSTS by the Browser.

If you capture all of the traffic in Fiddler and then wait for the error to occur, extract the 2 pzTransactionIDs from the error message.  You will almost always see both IDs in the Fiddler trace.  It is then up to you to determine why the stale one was used instead of the new one.  Common reasons are:

• You have a UI action list which sends multiple POSTs, one of which is a FinishAssignment.  All the requests will use the same pzTransactionID.  If the FinishAssignment processes first, the other POSTS will get rejected because their ID is stale.  You need to change your application to avoid the race condition. A timeline view of the concurrent POSTS will reveal the problem.  And you should never have anything in a action list which comes after a FinishAssignment.
• You have an activity on the server which does an explicit commit.  This changes the pzTransactionID.  Since you are doing this yourself and not allowing normal flow processing to handle the commit, the new ID is not passed back to the client.  Hence the next POST fails, as it uses the old ID

These are almost the only 2 ways this type of issue occurs. But there are literally hundreds of ways you can get into one of those 2 ways.  You will need to have some expertise in Fiddler to do the above analysis, but if you have that expertise, this is not a hard exercise to complete.

Almost always the problem is due to a bad design.  There have been a few cases where it is due to a defect in the Pega code, but those defects have been very few and far between.  It is a mistake to search the PDN, find one such fix, and ask for it. It is very unlikely to fix your issue.  You must do the analysis first to determine the root cause.