InfoPath Dev

After painstakingly creating an expense report solution for our department with a repeating table for expense items, my boss shot it down.  Here's why -

He wants a solution where he can work on his expense reports over time.  IE - submit a line item for a particular job, forget it about it, then come back later and submit more line items.  Then he can submit the collection of expenses for a particular job whenever he finishes (it's annoying because he is the only one who works on his expenses this way).  He wants to able to get out of a cab, take a picture of his receipt, submit that one item, and then come back and enter more expenses later.  (this all has to be submitted to sSharePoint)

 One of the problem with the repeating table for the expenses is that it is harder to filter on data that is merged into one SharePoint item later.

 So here is what I'm thinking . . . I don't know if it will work. 

- Line item form (maybe hosted in a SharePoint web part) that has employee contact, job, and expense line (expense type, code, price, item, and date) with a submit button.

- Line item form is submitted to a doc library with workflow that populates back end expense list.

- A "final", complete expense report form that pulls all expense items for a particular job (picked by employee) from the backend list into a repeating table, with a "submit final" button.  This form could be hosted in a Sharepoint web part directly below the line item form.

- Final form submits to doc library with approval workflow.

 

Is this a logical solution?  Does anyone have  a better idea?  The only thing I can't wrap my head around with this solution is - if the final form is not approved, how do I remove (or mark items rejected) in the expense item list? 

Thanks in advance for ANY input. 

 My brain hurts. 

Are expense reports approved in entirety? Or is it possible you'll approve my cab and my lunch, but not my very nice expensive dinner?

If they are NOT approved in entirety, but by line item, you may want a different approach than having a final form that pulls all the items together, but that's a business process question....See, I'm thinking, if items are approved on a line by line basis, you may want the result to be a ShP list, instead of another form.... but I think I see the issue -- people will want to submit chunks of this data as a group. So I'll guess that it gets approved or rejected as a group (but it still seems that you may want to do something more granular there).

I'm kind of wondering about the need for the expense list -- wouldn't you be able to promote the properties from your non repeating line item form to the library it submits to and then use a data connection to that library to get that info into your "final" form?

We use qRules so much these days that I tend to think of everything as a potential qRules solution. But you are going to need to write code or use qRules to copy the data into your final form, regardless of the source.... So, if I were using qRules for this, I'd probably use my line item form to submit to a ShP list directly (with the pictures from the receipts going to a pic library, and links to them in the new list item). Then, I'd have my final form, and it would get all the items for the selected job (probably using the FilterOwssvr command to get just the items I need). I'd use CopyTable to copy into my main data source, including the id for the list item. My list that I was submitting to for the line items would have a field for status (submitted / approved / rejected). Then, in my final form, I'd have a submit button that submits the form to whoever is supposed to approve... and would update the SharePoint list items with submitted. Then, for each line item, I'd have option buttons that displayed when items were submitted -- for approve / reject. Give the approver the option to approve / reject all, of course.... and then that submit would also update the list items with the appropriate status.

But again, that is a qRules-centric approach.

Well, we don't use Qrules.  I suppose if my boss wants to be stubborn about this, we might move in that direction.

I guess I don't necessarily need a backend list .  Is there a way to merge the expense lines of the initial form into a final form?  With pictures?

I wonder if you could use the merge forms function in ShP?

So, your form would use a repeating group, but you wouldn't let users insert or delete sections. That way, the schema would be right, but to the user it would be a single item at a time. Then in the library they could select the line items they want to submit as a group and use the merge funcionality? Here's a bit more on that....

That's exactly what I was pondering, Hilary, and thanks a lot for your time.  I've learned more about Infopath and SP in this forum than I have in ANY book.  It's people like you, Clayton, and others that make that possible.  And you do it for no fee or reward.  I'm sure there's a whole bunch of IT karma headed your way . . .

Anyway, the expense item section in my form was already set up as a repeating table with the insert capability turned off (I had just modified the original form which was repeating for obvious reasons).  The solution you posted is a definate (and probable) possibility.

But to take a step further . . . would there be a way to merge the forms automatically based on rules?  Say if User =, and Job Number =, then merge the expense items?

 

Thanks again!

I don't know of a way to "auto-merge" forms.... I think it would require some code. You may want to search the forum -- I took a quick look, but definitely saw more questions than answers on this....

Now I'm having issue merging.  I am running SharePoint Enterprise Server 2010.  I navigated to the Merge View, selected mulitple items, click on merge, and . . . . . . nothing happens.   Is there anything that needs to be set up in the background besides the merge settings on the form?

Well, I got merge to work, but that's just not going to do for our situation.  It puts too much responsibility on the end user. 

Anyone else have any ideas?