I have created a SharePoint List (on 365 Enterprise) for logging accidents and incidents in our business. The list is populated using an InfoPath form that presents the user with the relevant fields that need to be populated based on the nature of the incident.

A key part of the process is the generation of a unique incident reference which is formed from: projectID/year/month/day/sequential number

To generate the sequential number I had set the list up with a custom field. On submitting the form, the submit rules would determine the last-used number for that year, increment it and use that as the sequential number for this list entry. A new view of the form would appear, advising the user of their unique reference.

Everything was working fine until the need arose to record the home address and telephone numbers of injured parties. This is personal information which should not be visible to all users of the list. I considered options for making these fields viewable only to the person creating the record in the list, but one of the processes in the case of an injury is to print out the accident form, gain signatures and attach the scanned document back to the injury record. I would therefore also need to hide the attachments or handle them through some other mechanism. The most straightforward approach was to allow individuals to see only the records that they have created in the SharePoint list. Unfortunately this has caused the unique reference generation to fail. Each user can only see their own items and the code will return their last-used number, rather than the last-used number in the list.

I considered using SharePoint Designer workflows to manage the unique reference generation, but there is usually a lag between submitting the form and the workflow running. The reference number needs to be available immediately.

My next strategy was to use a second list, accessible to all, to handle the sequential numbering. I have no trouble bringing in the number currently stored in the list, but I am struggling with getting the list to update.

The second list consists of 3 fields: ID,Title,Tally. I have used the Title field to store the Year Number.

I have created a CAML file and loaded it as a Data Connection:

<?xml version="1.0" encoding="UTF-8"?>
<Batch OnError="Continue">
    <Method ID="1" Cmd="Update">
        <Field Name='Tally'></Field>
    <Where>
                <Eq>
                   <FieldRef Name='Title' />
                   <Value Type='Number'>2015</Value>
                </Eq>
        </Where>
    </Method>
</Batch>

I have set up a web service (submit data) data source connecting to the _vti_bin_/lists.asmx location of the site and selected UpdateListItems. I have determined the list GUID and set this as the default value of a text field on the main list that isn't visible to the users. This text field is used in the listName setting in the data connection wizard. I've set the update field to /Batch.

enter image description here

I've tried various combinations of settings in the Submit Rules to try to get the value of the Tally field to change, but nothing is working.

Questions: Is it possible to update a secondary list using only OOB InfoPath Rules? I need a single submit button to determine the unique reference and submit all the fields to the main list. Am I even close to the workable solution?

有帮助吗?

解决方案

It is possible to set up a secondary data source in InfoPath to read/write to another list in your site (https://support.office.com/en-us/article/Add-a-data-connection-to-a-SharePoint-document-library-or-list-3233d77d-95af-4245-a124-dca2f6d5d02e) -- although it would seem that you run the risk of a concurrency issue -- even in your current scenario, since SharePoint does not have a concept of isolated thread-safe transactions, if two users are submitting forms with a second or so of each other, they could both end up grabbing the same number during the time it takes SharePoint to look up the current number, increment it, and save it back. Do your requirements definitely require that the numbers reset each year? If not, a safe implementation would be to append the Item's built-int ID to your generated reference (i.e. projectID/year/month/day/[currentItem.ID]). This would be easier to implement, gaurantee of no duplicates, and would work regardless of permissions. The downside being that your numbers could never be reset back to 1 for each year (unless you created a new list each year).

许可以下: CC-BY-SA归因
scroll top