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
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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?
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?
ASKER
Ramuar,
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).
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.
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.
ASKER
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.
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.
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Got a solution using an InfoPath only number generator but will certainly use an SQL one soon.
Article will be a big help :D
Article will be a big help :D
I can give you some detail, but the actual solution itself is being copyrighted subject to being produced for sale.
:-)