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.

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

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

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!
 

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.