DMS, Version and Revision

Hi Bitten,

Since I don't have access to the full standard, I cannot give an official answer. But reading some of the free material, which includes the introduction, my guess is that we do. The standard is quite old (published in 2001) and we have many hundreds of customers running IFS Document Management, and my guess is that several of them try to adhere to this standard. If they could not, because of limitations in our product, we would have heard about it.

Would @xeam-eran have some insight, perhaps?

Hi Mathias,

many thx for your swift reply.

Even the standard is old, it still applies as no newer revision exists 😉 I’m not aware if aother international standard describe how to work with document management of versions and revisions?

Could you maybe please guide me in direction of more information as for how to work with the IFS Document Management module? Is there e.g., any e-learings available (on YouTube or other SoMe), online courses to attend or could we invite an IFS Document Management specialist to share knowledge with us (DK)?

I have tried to navigate IFS Cloud Documentation but most often run into ‘To make use of this URL please browse to this section from within the product documentation inside IFS Cloud’ which I do not know where or how to access?

Br,
Bitten

I’m glad to hear you want to learn about IFS Document Management! 

All the documentation you will ever need is right there, when following the link you mentioned. Here is a small guide on how to navigate:

Then we have trainings/e-learning in IFS Academy which I am sure you as a customer can access, but I don’t know how you can do it. I suggest you contact your IFS sales person or representative so that they can sort you out there.

Good luck!

Hi,

Sorry for late response on Mathias’ nudge, but here are some thoughts.

As for Mathias I don’t have access to the complete standard (IEC 82045-1), but in general terms the standard implies that the EDM system (Electronic Document Management) should support:

• viewing and reproduction of documents (presentation aspect)
• identifying and classifying documents (organisational aspect)
• managing document versions and changes (life cycle aspect)   - In IFS this is achieved through revisions handling.
• managing the relationship between documents and the associated product (product aspect)  - In IFS this is achieved through its Document-Object connections functionality (any business object!).

So, I would say IFS DMS (“Docman”) in general supports the requirements of the standard. Now I know your question was specifically about the third bullet above so let’s dive into that a bit.

The thing you possibly can argue about is the difference between “versions” and “revisions” handling. The term “version” is often used when referring to each copy of a file as a result of every time you save your file. Whereas “revision” is the numbering or identification of the document (and its checked in file) that is used when a new revision is to be produced and released for publication. In IFS DMS only the latter applies, but all historical document revisions (and their respective file) are saved and can be viewed if necessary.

There might though be an opening to utilizing some of the possibilities that comes with the “versions” approach – such as having the option to look into an older version of the file and also restoring to that version – at least as long as you are within the cycle of a specific document revision, and you are editing the file several times (using the Edit button in IFS and saving/closing the file).  Note! that the version history is reset every time you check in the file to IFS, but as long you want to have access to the different versions while developing a file over several days this might be an option.

The solution for this approach would be by setting your check-out path in IFS DMS to a folder on a file service that provides a version handling functionality, such as SharePoint/OneDrive.

Please note that I put all aspects and liability aside – relating to synching or network issues and all other problems that can occur from this – but it could be something to consider if you want to try.

/Erik

Thank you, Erik for taking your time to provide a more detailed answer.

From a product developing perspective (where I come from), it is important for us to be able to document and access all the minor iterations of the document i.e. the versions, before the final  document revision - incorporating all the minor iterations / changes / improvements - is reviewed, approved and released.

Each document revision goes hand in hand with the released IFS part described by the document revision, whereas the documents versions (in our use story) would be all the minor changes / improvements registered on the way to the final approved and released revision.

Having the document versions stored on e.g., OneDrive and revisions stored in IFS could be a solution, yes. But where to map which versions are funnelled to which revisions? And again, why not incorporate the version and revision functionality into one and same DocMan system ;-) 

Thank you

/Bitten

Thanks, Erik, and thanks Bitten for the comments.

A suggestion: Don't make the version vs revision thing more complicated than what it is. Although IFS does not automatically keep "versions" for each edit + check in flow, it's not very hard to manually create a new revision as often as you want to. That's what I do, when I feel I have reached a point where I don't want to lose my recent work and where the current "version" of the file is different enough to the one in the previous revision.

You can have both versions and revisions in IFS, but the versions will also be revisions, from an IFS terminology viewpoint. I know some customers use a separate numbering schemes for versions vs revisions, or at least for all preliminary revisions that are used up to the point where a revision is approved and released. Some use, say, A, B, C, etc. for the "versions" (let's say) and 1, 2, 3, etc. for the revisions.

For sure, an automatic "version" might be more convenient, but it doesn't seem to be something a majority asks for. In fact, I think I can count only a handful of times where we have got the question about being able to keep track of "versions".

Good luck!
 

Thanks for sharing your use case and feedback Bitten, and I agree, having both version and revision functionality in IFS Docman would be a dream for such business cases you describe.

I also agree with you Mathias, there has been few occasions over the years where this has been such a strong requirement that it result in stopping from using IFS Docman. At the same time, you will not achieve the same result using the Revision field for both versions and revisions since the fundamentally strong functionality that comes with object connections – and its three “connection types” [fixed, latest revision, latest released revision] – would in certain scenarios give unwanted behavior. Like showing a (preliminary) version connected to a product or a functional object.

Anyhow regarding your question Bitten, the simpler solution I hinted about can maybe work in some cases, and the tracking/connection between the versions and their superior revision would then be through the file name, at least as long as the file naming is set to “Standard” and not Original file name. And again, remember that the versions in this setup are reset after check-in.

Take care,
Erik

At the same time, you will not achieve the same result using the Revision field for both versions and revisions since the fundamentally strong functionality that comes with object connections – and its three “connection types” [fixed, latest revision, latest released revision] – would in certain scenarios give unwanted behavior. Like showing a (preliminary) version connected to a product or a functional object.

You are right. The above approach should work well with Update Revision = "Latest Released Revision" (LRR) though, which is a quite common, and good, option. "Play" how much you like with multiple preliminary revisions if you need to and, when a revision is finally released, the objects that used LRR will get the new revision connected.

It might not be related to exactly this, but one can play around and use the Doc Sheet explicitly as well, to create other kind of work flows that might work for you.