Ensuring unique numbers in InfoPath forms

I have an InfoPath form that submits to a SharePoint forms library.

The forms are for tracking invoices and include a generated reference that should be sequential and unique.  The number is based on the department and the highest number so far +1.
E.g. invoices generated for Finance, IT, Legal, HR, IT would be
FI000001, IT000002, LE000003, HR000004, IT000005 respectively.

Currently this works fine; when the form is generated it calculates max(ID)+1 from the existing forms, pads the number with zeroes and prefixes it with the department code.

Each department now needs to make their invoices visible only to members of their department (using permissions, a view on a list isn't enough).
The permissions I can do fine using item level permissions in a SharePoint workflow.

Problem is, in the above example, if Legal were to generate a new invoice then the only existing invoice they'd see would be LE000003, so InfoPath would generate LE000004.  Number 4 is in use by HR though.  The next reference should have been LE000006 but InfoPath can't see 4 or 5.

Short of making a separate number fountain I can't think of a way to get around this problem.

Points to either an answer or helpful comments :)
Thanks in advance
Who is Participating?
Robbie_LeggettConnect With a Mentor Commented:
I decided to write an article which is a step-by-step tutorial to creating a unique, incremental numbering system for InfoPath. It can be found here:



I achieved a fantastic solution to this by using an incemental numbering DB in SQL and connecting InfoPath to it through a web service.
I can give you some detail, but the actual solution itself is being copyrighted subject to being produced for sale.
NBSO_ISSConnect With a Mentor Commented:
Database solution is definitely the way to go.
We have similar requirements here and using a database solution also allows us to save additional data from the forms that can easily be queried or drawn from the database for reports.
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

You need to do the increment on the server when the form is submitted and have the form requery the server, get the new ID, and set it in the form. You cna hen concat your 2 char prefix to it and save it.

This topic is the most-often asked question in this forum. I replied to another person last week. There must be at least two dozen forum threads on this. Have you actually tried to search for them?
DhopeAuthor Commented:

Yes, I searched.  If I haven't found the right link please point me to where it is.

Can't see how simply requerying the library will work.  The form filename must be the same as its reference and InfoPath will not rename a form after it's been submitted.
Also, a SPD workflow fires on any new or modified forms and SPD workflows that update fields in a form have a habit of failing if that form is still open by the submitting user (a scenario that would almost always be the case if the form was still open and being requeried).
I think he is talking about re-querying the SQL database.  The increments would have to be done in SQL and filled into the form.
What you want is a web service that contains a function which goes to the database creates and saves the new ID and returns it to the form.  Once this function is created, in the form, create a connection for receiving the ID.  At submission time, set all of the variables in the connection to values from the form then "Query using data connection".  After the query, you set the ID in the form to the ID returned from the data connection.
If you require further explanation, let me know.
DhopeAuthor Commented:
Sounds a lot like the number generator described in my question :)  I've set up something using SharePoint lists that achieves a similar (if not as elegant as SQL web service) solution.

At submit time, it creates a new item in a 'NumberGenerator' list (using CAML to submit to a list), refreshes the data connection and use max(@ID)+1 for the next number.
It works with multiple users submitting at the same time and avoids the problem with permissions mentioned earlier.
It is very much the same.  I guess the big difference in this case is you could use SQL to easily differentiate between Finance, IT, Legal and HR.  It is actually very simple to set up.  
DhopeAuthor Commented:
Current system is only a stopgap, we'll be extending OOTB workflow with K2 Blackpoint in the next month or two.

I'm going to keep one list of numbers, even though they'll be spread over departments.  This is because some departments have the same prefix despite different permissions (e.g. Debt Trading and Debt Syndication will both have DBT for the prefix but wouldn't be able to see each others' invoices).
The prefixes are only really for the benefit of Accounts (who will be able to see everything) but the permissions may be applied more finely than the prefixes.
DhopeAuthor Commented:
Got a solution using an InfoPath only number generator but will certainly use an SQL one soon.
Article will be a big help :D
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.