I too have faced this situation. It seems to be a refresh at the time of submitting the web form causing the DocumentUniqueID to regenerate. One solution i could think of for the time being is to retrieve the DocumentUniqueID from the source field and assign it to another normal HTML field/NotesField present in the form.
You can create an normal HTML field using html syntax like or else go for a NotesField If you use a NotesField just add an id parameter like “DocUNIDTarget” on the HTML tab of the field’s properties.
Now add an id parameter like “DocUNIDSource” on the HTML tab of the field properties of your NotesField where you generate the DocumentUNID.
After this, you can retrieve the DocumentUNID Value from the source field and pass/store it to the newly created field using JS code. Something like:
var sourceField=document.getElementById(“DocUNIDSource”);
var targetField=document.getElementById(“DocUNIDTarget”);
targetField.Value=sourceField.Value;
Now, you will have your original DocumentUNID passed to the target field. You can do the value retrieval in any suitable event of your form. Choose an appropriate event to code the above lines. You can even call the code in a button onclick() event.
The UNID is, at its heart, a time stamp. The UNID is assigned when a Notes document is created. On the web, the document is created when it is saved for the first time, not when the form is opened – there is no persistent document at the Notes/Domino level until the document is saved into the database. In order to have a valid UNID in the browser at the time of initial creation, you would need to create and save the document on the server before sending it to the user for the first time.