We don't use SOP anymore but did for over a decade, during which we experienced this problem periodically (unrelated SOP documents getting assigned the same mstrnumb value). We had a custom Sales Transaction Entry window and I always figured the problem was likely caused by the customization, but perhaps not since others have seen this issue.GP maintains the "next mstrnumb" in SOP40100.NXTMSTNO. Every time we'd have a problem with unrelated SOP documents sharing the same mstrnumb value, it was because NXTMSTNO had somehow been updated to a lower value; it really should only ever increment.We finally fixed it for good with a trigger on the SOP40100 table (definition attached to this post). With the trigger enabled, any attempt to update NXTMSTNO to a value lower than its current value will be replaced by an update that will simply increment it by 1.I never cleared this with Microsoft, but we ran with this trigger in production for at least three years on GP 2013 (after which we stopped using SOP so it wasn't needed) and never saw a recurrence of the "jumping" mstrnumb problem.Note that there is an implicit reliance on the fact that there is always one and only one record in SOP40100. A statement such as "set @nxtmstno_i = (select nstmstno from inserted)" would fail if multiple rows were being updated in a table.