Has anyone created a Purchase request form and process in M-Files?

I'm sure that many people have done similar things. You could even create the "form" as a simple word document and push it through a workflow for approval; the only thing that would need some code is the integration to the (payment?) system, although that would be largely specific for that system. I guess if you have specific sign-off limits then that too might need some code, although some off-the-shelf components might help. 

Do you have a specific question? 

Hi Craig,

Thanks for the reply. We currently have an Excel file in use, and manual workflow. Was looking to remove an additional file, have it within M-Files as a form/meta data card and then have this information pushed in to our finance system - this we know can be done, we just want to avoid extra files if possible. Another thought I had was a SharePoint front end and M-Files workflow underneath. Avoiding the creation and storage of another Office document would be ideal.

Thanks.

Hi Craig,

Thanks for the reply. We currently have an Excel file in use, and manual workflow. Was looking to remove an additional file, have it within M-Files as a form/meta data card and then have this information pushed in to our finance system - this we know can be done, we just want to avoid extra files if possible. Another thought I had was a SharePoint front end and M-Files workflow underneath. Avoiding the creation and storage of another Office document would be ideal.

Thanks.

The decision about whether this should just be a "pure" object, or whether it's an object with a file, will probably be defined by the data you need to capture (which is probably dependent upon your specific process).

I suppose the question I'm asking is: what guidance are you looking for here?  I'm not trying to be awkward or argumentative, I just don't know where to start.

If you don't need line-item data to be structured separately, and just need to be able to route something around to people so that you have an audit trail of the process, then this feels like something that could be done within M-Files, potentially without any code.  Have you tried modelling this to see what works for you and what doesn't?

We have something already modelled within M-Files, but more work is needed, and I'm wondering if it is worth the effort as although it 'works', it feels clunky. 

The metadata card we have now has the ability to add an individual line as a product you wish to order. But for each line, you need to create another object to be added as a line on the metadata card. Each object has additional information you can add such as the quantity you want and the price. This is where it feels like it is too clunky, would rather just have the ability to add this information on the metadata card on a line if possible. If it isn't, this is where the possibility of using a SharePoint form/website would likely be preferable. 

Obviously M-Files isn't built for this, and it feels like it's squeezing a simple idea in to it which will have limited functionality.

Hope that makes sense.

It definitely does make sense.  M-Files wants to manage those objects (representing the line items) individually, and it can be awkward when users want to work with them as a group (e.g. as the entire purchase order).

There are a few options for this, some easy, some hard.  I'll ignore the hard ones.

One easy option is to have a document which gets populated with the data and then routed around.  This way the document has only the top-level header metadata, but it has a table or something within it that the users can fill in.

If that doesn't work for you then a form somewhere else may be also work, then route the resulting item around using M-Files' workflow.