PQM home page

• Document Version Management DVM

FD DVM.pdf

• Extended user management

FD Project USERS.pdf

• Mail exchange
FD Mail exchange.pdf

• Double safety Document Management (@Project)

FD Project revision.pdf

• Project Management
Not yet available. Planned functionalities:
- Scheduling and allocating tasks
- Meeting management

Other functions that are linked to PQM (but will be licensed separately):
• eSign
FD eSign.pdf

• eStamp
FD eStamp.pdf

• Anonymous File transfer

FD Network login.pdf

PQM-S81E02/ 12-27-05 © innotec GmbH 1

 DVM
Function & Design Specification

Document Version Management

Page 1 of 31
 DVM
Function & Design Specification

Imprint
© 2005 innotec GmbH
Published by: innotec GmbH
Eisenwerkstraße 1
D-58332 Schwelm
http://www.innotec.de
Comos is a product of innotec GmbH.
The software and hardware names mentioned in this manual, in most cases, are also registered trade marks
and as such are subject to statutory regulations.
Comos® is the registered trademark of innotec GmbH.
This manual is protected by copyright laws. All rights, even those including translation, reprint and
duplication, be it partially or in whole, are reserved. No part of the documentation may be reproduced,
distributed or processed using electronic systems, copied or disseminated in any form whatsoever
(photocopy, microfilm or a different process), also not for teaching purposes, without the written consent of
the publisher.

The Comos license is linked to the license floppy disk and the related adapter (dongle). Loss of the license
floppy disk or adapter (dongle) automatically leads to loss of the license.

For any questions in connection with the documentation, please contact:

[email protected].

Comos Hotline Support:

Monday to Friday between 08:30 and 17:00
Telephone: +49 (0) 228 6480 577.

FD DVM FDDVM81E03 Status: See Document history

Page 2 of 31
 DVM
Function & Design Specification

Document history
Version Version EN Date Author Comment
DE
0.1 05.10.2004 MSC/FRO Beta 1
0.2 05.28.2004 MSC/FRO Beta 2
0.3 12.03.2004 ARD/FRO Beta 3
0.4 04.05.2005 FRO Beta 4
0.5 04.27.2005 AWO Corrections MSC
1.0 07.06.2005 AWO/MSC Release
2.0 10.17.2005 AWO Administrative issues
2.1 12.08.2005 FRO Comparison with and summary of Manual
chapters
3.0 12.22.2005 AWO Translation of DE 2.1

Assignment number Description

A538 DVM documents for checkin and checkout
A539 DVM – additional assignments

Author: Date: Signature:

Aliki Wolff

Translation:
Aliki Wolff 07.06.2005
12.22.2005

Released by:
Frank Roscher

Page 3 of 31
 DVM
Function & Design Specification

Table of contents
Document Version Management ....................................................................................................................... 1
Imprint ............................................................................................................................................................... 2
Document history .............................................................................................................................................. 3
Table of contents ............................................................................................................................................... 4
1 Introduction and overview......................................................................................................................... 6
2 Definitions ................................................................................................................................................. 7
3 Functional specifications/ User interface .................................................................................................. 8
3.1 Basic status ........................................................................................................................................ 8
3.1.1 Import ........................................................................................................................................ 8
3.1.2 Open .......................................................................................................................................... 9
3.1.3 Checkout.................................................................................................................................... 9
3.1.4 Checkin.................................................................................................................................... 10
3.1.5 Document versioning............................................................................................................... 10
3.1.6 Export ...................................................................................................................................... 12
3.1.7 Reload...................................................................................................................................... 12
3.1.8 Version history ........................................................................................................................ 12
3.1.9 PQM options............................................................................................................................ 13
3.2 Interaction with other Comos functionalities .................................................................................. 13
3.2.1 Redundant document administration (@Project) .................................................................... 13
3.2.2 Automatic allocation of the DVM placeholder ....................................................................... 14
3.2.3 Revisioning.............................................................................................................................. 14
3.2.3.1 In the basic status................................................................................................................. 14
3.2.3.2 With redundant document administration ........................................................................... 14
3.2.4 Anonymous file access (“Network login”).............................................................................. 14
3.3 Interface........................................................................................................................................... 15
3.3.1 Single application (DVM container context menu)................................................................. 15
3.3.2 Bulk application through own interfaces................................................................................. 16
3.3.3 Module options of the project properties: PQM options ......................................................... 17
3.4 Management of rights...................................................................................................................... 18
3.5 Sending E-mail ................................................................................................................................ 19
3.6 Development specifications / Implementation details.................................................................... 20
3.7 DLL ComosDDMSafe..................................................................................................................... 20
3.7.1 Class DDMSafe ....................................................................................................................... 20
3.7.1.1 Sub....................................................................................................................................... 20

Page 4 of 31
 DVM
Function & Design Specification

3.7.1.2 Function............................................................................................................................... 21
3.7.1.3 Property ............................................................................................................................... 22
3.7.2 Class DDMVersion.................................................................................................................. 23
3.7.3 Class DDMCheckout............................................................................................................... 23
3.7.4 Class DDMVersions: Property ................................................................................................ 23
3.7.5 Class DGNDVMImport........................................................................................................... 23
3.7.5.1 Function............................................................................................................................... 23
3.7.6 Class QueryView..................................................................................................................... 24
3.8 DLL DGNImportLL.dll................................................................................................................... 24
3.8.1 Class DGNScan ....................................................................................................................... 24
3.8.1.1 Sub....................................................................................................................................... 24
3.8.1.2 Function............................................................................................................................... 24
3.9 Customizing options through Script events..................................................................................... 24
3.9.1 DVM Scripts for documents.................................................................................................... 24
3.10 Important data structures in the database......................................................................................... 26
3.10.1 Selection list ............................................................................................................................ 26
3.10.2 Project options ......................................................................................................................... 26
3.10.3 DVM specifications for documents (DVM base object) ......................................................... 27
3.10.3.1 “DVM | DDM” tab .......................................................................................................... 27
3.10.3.2 “Document properties” tab (File attributes) .................................................................... 28
3.10.3.3 “History” tab.................................................................................................................... 29
3.10.4 DVM queries ........................................................................................................................... 30
3.10.5 Base data customizing ............................................................................................................. 30
3.10.6 Document types ....................................................................................................................... 30

Page 5 of 31
 DVM
Function & Design Specification

1 Introduction and overview

Objective of version management: Revised and versionized management of all kinds of documents within
Comos. At present, PQM includes following possibilities:
• Manage and revise any external documents for AsBuilt and Project documents
• Automatic transfer of documents between Project to AsBuilt and vice-versa
• Support of QS phase models (DQ, OQ, IQ, PQ) for the pharmaceutical industry
• For this, the following basic technologies are offered:
• Import
• Open
• Checkout /checkin
• Export / Reload
• Version history

Page 6 of 31
 DVM
Function & Design Specification

2 Definitions
Project management
The term “Project management” here must be seen from the operator’s point of view and must not be
confused with the “Project management” right. The “Project management” right controls the export and
import of Comos projects etc.
Comos operator mode
The version management can also be used in the operator mode.
In the basic state, planning data in Comos is called planning project, regardless of whether the planning data
pertains to the documentation of the as-is state or to the planning of changes.
If you use Comos as operator, then a separate ITX file is available. To a large extent, the terms “Plant” and
“Project” are swapped in this ITX file: The “Open project” dialog window is called “Open plant” etc. In the
renamed “Open plant” dialog window, you also have a “New plant” mouse menu (from a technical point of
view, this menu still generates a Comos project).
The following definitions apply in the operator mode:
• Plant: As-built state
• Project: The individual modifications etc. that are planned.
• Comos project: In the released area, contains the as-built state (i.e. the plant in the above sense) and the
accompanying projects in the working layers.
Documentation that is shown as pure project document (e.g. order lists), is never released into the plant, and
thus exists only in the projects.
Similarly, the @Project document branch is not released into the plant.

Page 7 of 31
 DVM
Function & Design Specification

3 Functional specifications/ User interface

3.1 Basic status
3.1.1 Import
Access rights
The user requires “Full access” (“Full control”) for access to the drive and folder. This obviously is also
applicable when working with an anonymous user, see 3.2.4 Anonymous file access (“Network login”).

Scope:
Import of any OLE-capable files. The import gets the file format. The file is stored as copy in the Comos
document folder.
Import metadata: During import, if the metadata of the document are to be evaluated, your system must have
the NTFS file system.
Exclusion: The Comos documents (Reports, Report templates) are not imported.

DGN documents
References are preserved for DGN files.
For this, the user is forced to first check in the referenced documents and only then the DGN main document.
A copy is generated in Comos, which gets the name of the original DGN document and not a SystemUID
like for other document types.
The Comos copy gets “DocObj” with which you can identify the references that the DGN document has.
With the help of this DocObj, you can also navigate to the referenced DGN documents. Inversely, you can
navigate from the referenced documents to the DGN main document.
During export, a common folder is created to which the DGN main file and the referenced DGN files are
copied. If a file is referenced many times by DGN main files, then this file is also exported and multiplied
many times.

Single import:
Drag&Drop: Evaluation of the project module option DragDrop-Import for PQM.
• Disabled: Drag&Drop does not generate any DVM documents.
• Enabled: In the Project module options, the specification DDMRoot | Library object for documents,
Link type, is evaluated. This specification determines the base object of the document imported through
Drag&Drop. If this base object has the DQM tab, then the document imported using Drag&Drop
becomes a DVM document.

Bulk import:
Comos menu | Extra | Query | DVM queries | Bulk import. The query is created as follows:
• Create new base object of the Action class
• System tab, Select ControlType switch

Page 8 of 31
 DVM
Function & Design Specification

• ComosBulkCheckIn.BulkCheckIn

Drag&Drop a large number of selected objects into a unit. For this, one of the two requirements must apply:
1. Automatic document allocation is active. For this, in the DVM queries |Bulk import query in the current
session, you must set the Document group field once. Comos marks the last set entry even if the query is
closed. If Comos is closed, the settings are deleted. Or:
2. In the project module options, in the DDMRoot | Library object for documents specification, a DVM
base object is set.
Please note: If the bulk import contains DGN files that refer to other not yet imported DGN files, then this
DGN file is ignored during bulk import. The user is informed through an info window.

Creating document versions:

All versions are automatically created during checkout and checkin. The import generates the first version.
Checkout is possible only now.
In Comos, a document object is created as version container for this file. Under the version container are
objects that enable technical access to versions. In the Navigator, these version-related subobjects are not
visible and access (e.g. from the mouse menu) is possible only via the version container.
The version containers are also not visible in the Document object query or in the Object Matcher.

Effect on the import source:

The original is alternately preserved or deleted.
DGN: The import source is always preserved.

3.1.2 Open
Opens a window (deviating from the Comos standard) with various options for DVM documents. Everything
else is self-explanatory.

3.1.3 Checkout
Creates a copy of the last version. (Also see 3.1.5 Document versioning .) This last version can also be the
first version generated by the import. The copy is created in the checkout directory. If the requirements for
metadata (NTFS) exist, then the DVM administration information is saved there. Other information can be
saved.
If no metadata can be saved, then an ASCII file *.cfo is created.

DGN files
In DGN main files, all referenced DGN files are copied with Read only status, but are not checked out. A
referenced DGN document (which itself has no other references) can be checked out normally.
• Single checkout:
From document mouse menu.
• Bulk checkout:
Comos menu Extra | Query | DVM queries | Bulk Checkin/ Checkout. The query is created as follows:
Right mouse button in the base data:
|New |New query |Applications |User defined.

Page 9 of 31
 DVM
Function & Design Specification

Open object query, mark column, right mouse button |Options, Administration tab:
Enter extension object “comosddmsafe.queryview”.

Undo checkout
If you want to discard any change to a document, you can simply undo the checkout process (available from
the document context menu). In this way, the last version is restored.

The local copy can be kept or deleted.

3.1.4 Checkin
Generates a new version. (Also see 3.1.5 Document versioning .) For this, another copy of the file is
generated in the Comos document directory and is created below the original. In the Navigator, another
(invisible) version object is generated for the technical access.

DGN files
For DGN files, even during import, it is checked whether all referenced documents were checked in before
the DGN main file. This is particularly applicable when references are added while processing the DGN file.
• Single checkin:
From document mouse menu.
• Bulk checkin:
Comos menu Extra | Query | DVM queries | Bulk Checkin/ Checkout. The query is created as above.

3.1.5 Document versioning

The versioning of a document results in a copy (version) of the document being stored in Comos. The
version generated in this way is henceforth locked against further changes.
It is the purpose of the versioning to create clearly defined, comprehensible change statuses of a document,
which can be viewed any time. For this reason, the versions of a document are read-only for all users.
Generated versions can no longer be edited.

Import
With the import of a document in Comos, it is versionized at the same time.

Checkout
To edit a document, you must first check out the document. For this – exactly like a checkin process –
special rights are needed. A checked out document can be edited only by the user who checked it out. During
the checkout process, a copy of the document is stored in the directory specified in the PQM module options.
The copy gets a cryptic name which reflects the owner structure of the Comos document (system full name).
During checkout, you can specially select to use the name of the source file instead of the system full name
(PQM options!).

Page 10 of 31
 DVM
Function & Design Specification

At present, the setting is not yet saved. Thus, you must always reset the Use original file names by
checkout option if needed.
Please note: If using the original filename, then at present, the user must ensure that the documents are not
mutually overwritten. If the SystemFullName is used, then it can never cause overwriting because this name
is always unique.
The checked out file can be edited in Comos as well as outside Comos.

Checkin
With the checking in of a checked out document, it is versionized once again.
To checkin a document, it must first be checked out.
During checkout and checkin of a document, the user is prompted to enter a relevant remark.

Version history
All versions are accessible from the context menu of a document. To open a version write-protected, double-
click it.

Project versions, Unit versions toggle switch:

Page 11 of 31
 DVM
Function & Design Specification

You get the above toggle switch when

• both the @NameSystem and the @Project nodes are created,
• both nodes are activated in the project options,
• the document is referenced in both nodes. (For example, simply copy the document groups and insert in
@Project)

3.1.6 Export
The export essentially corresponds to another checkout variant.
With the export, you have the option to export a DVM document to a different directory from the defined
default checkout folder. The reason is the request that these documents must be specially available for
subcontractors.
While a document is exported, this document can be edited only by the subcontractor.

Permanent export
The Permanent export option can be selected in the Export mask.
Function: A document that was exported and reloaded from Comos is exported again directly after reloading.
Consequence: It cannot be edited in Comos.

3.1.7 Reload
With Reload you can bring exported DVM documents back to the system.

DGN documents
See Import.

3.1.8 Version history

Tabular display of DVM administration and write-protected opening of the version.

Page 12 of 31
 DVM
Function & Design Specification

3.1.9 PQM options

• Set working folder for checkout.
• Use original file names during checkout. Otherwise, the SystemFullName is used.

3.2 Interaction with other Comos functionalities

3.2.1 Redundant document administration (@Project)
A “double document administration” is introduced in Comos 8.0: besides the @NameSystem node a
@Project node can also be maintained. Both nodes come with the automatic document administration
functions (with a small exception).
In connection with PQM it is practical to combine the double document administration with the working
layers. In this case, the two nodes @Project and @NameSystem do not have equal authorization, rather
depend as follows:
• As development version: in @Project. Checkin and checkout is only here.
• As working version: in @NameSystem. The working version results from a development version
through release.
Below are the deviations from the PQM basic status.

Import
Is done simultaneously in the development and working area.

Open
No deviation from basic status.

Checkout
Checkout is only in the development area.

Checkin
Checkin is only in the development area. As you know, this produces a version, but this time in the
development area. In the working area, the last non-write-protected version there is overwritten by the
current version of the development area. The last non-write-protected version can also be produced through
the initial import.

Generate working versions

This function is not displayed over the Comos interface. Using Script or similar tool, set a write-protect
(“lock”) on the last working version. This write-protect is the technical conversion of a “release”. Working
versions appropriately write-protected and released are no longer overwritten by the current development
version. The next time when a development version is generated, a new working version is created and from
there, it is overwritten.

Version history
The working area versions and the development area versions are displayed.

Page 13 of 31
 DVM
Function & Design Specification

PQM options
No deviation from basic status.

3.2.2 Automatic allocation of the DVM placeholder

The following technology is available if the following query is used:
Comos menu | Extras | Query | DVM queries | Bulk import.
Alternately, even the bulk import can be used through Drag&Drop if a document group is currently set in the
query.
During import, DVM can automatically assign a DVM placeholder to the imported document files. This
DVM placeholder delivers the DVM base object. With the data structure, i.e. the position of the DVM
placeholder, the imported document can also be imported automatically.
The mechanism is already known from the Comos document administration. There, for new documents,
Comos checks whether there is a document group in the @NameSystem node on the Document tab that has
exactly the same name. If yes, the new document is referenced in the document group.
The automatic document allocation for DVM goes a step further.
1. In the Unit / Locations tab, there is a labeling system.
Example: <Projectroot> |A1 |T1
2. In the Document tab, there is the @Project node and under it a document group system.
Example: <Projectroot> @Project |01 |01
3. In the planning project, on the Base data tab in the local <@Private> |@UZ node there is a structure
that rebuilds the structure of 1 and 2:
Example: <@Private> |@UZ |A1 |T1 |01 |01 <DVM-placeholder>
The DVM placeholder delivers specifications, base object etc., otherwise it has no content.

3.2.3 Revisioning
3.2.3.1 In the basic status
Checked in files: may be revised. Alternately, information on which revision belongs to which version can
be saved.
Checked out files: Revisioning depends on the Revision is possible in checked out state project option.
If “yes”, as above.

3.2.3.2 With redundant document administration

Revisions only in the development area. Revisioning creates a consecutive revision file in the development
area and a revision file in the working area. However, in the working area, the last non-write-protected
revision file is overwritten by the current revision file. Thereby, the revision file of the working area is not a
copy of the revision file of the development area. Instead, two revisions are actually carried out, one for the
version in the development area, one for the version in the working area.
The document version in the working area is indeed produced as copy of the version in the development area
(see above), but it can still differ, due to variables evaluated differently etc.

3.2.4 Anonymous file access (“Network login”)

If files are imported through an anonymous file access, then the logged-in anonymous user requires “Full
access” or “Full control”.

Page 14 of 31
 DVM
Function & Design Specification

Any restriction in this right leads to failure of the version management functionalities. For example, the
“Delete files after import” function requires the delete access. In extreme cases, failure of functionalities can
lead to instability and subsequent data loss.
For anonymous file access, see the document F&D Network login.

3.3 Interface
The mouse context menu changes completely when a document is subject to the DVM. Many standard
commands that are no longer needed are hidden. For this, the DVM commands are displayed as described
below.

3.3.1 Single application (DVM container context menu)

Single application through the context menu of an unspecific DVM document:
Import

Single application through the context menu of the document.

Open
Check out
Check in
Undo checkout
Version history
DVM options

Page 15 of 31
 DVM
Function & Design Specification

Open document:

3.3.2 Bulk application through own interfaces

Query “DVM documents bulk import”
See Automatic allocation of the
Document group: must come from
@Project
Target nodes: Unit or location
Source directory: The files to import are
searched here

Options:
Filename contains unit structure: During
import, it is checked if there is a structure
of the planning objects which matches the
name. Otherwise, this document is not
imported.
Create unit structure: During import,
additional planning objects are created,
which are determined from the filename.
Separator: self-explanatory.
Use filenames as description: the

Page 16 of 31
 DVM
Function & Design Specification

imported filename overwrites the

description imported by the DVM
placeholder.
Delete source file after import: self-
explanatory.

“Bulk checkin/ checkout” query

“Export” mask

3.3.3 Module options of the project properties: PQM options

Project properties: Module options tab, PQM-Options specification tab

Page 17 of 31
 DVM
Function & Design Specification

Checkin
Checkin mechanism
Determines the behavior during checkin.
Values:
• All versions: A version is created per document during each checkin.
• All versions with revision: A revision is created during each checkin.
• Number of revisions is project dependent: Stipulates how many versions can be saved per document.
Library object for documents
The base object that is used during initial import of a version document is defined here.

DVM: E-mail options

email from, email server (SMTP):
The Email options are set here. An E-mail address must be specified for Comos, as well as a valid SMTP
server. With this information, the document mail order can then be used in Comos.

PQM: General
DragDrop-Import for PQM
This option controls the Drag&Drop behavior of external files to the Navigator. If it is enabled, the import is
carried out automatically.
Default working folder
This field is the default for the user’s checkout folder.

3.4 Management of rights

New function rights: Document checkout and Document checkin.

Page 18 of 31
 DVM
Function & Design Specification

See also 3.7.1.2 Function.

3.5 Sending E-mail

Documents can get a button in the properties window, which sends E-mails automatically. The button then
gets a Script that uses the Document mail order plugin, however, without calling its interface. The Script
sets the necessary data (recipient, Text etc.) for the PlugIn.
Example:
Set DocDisp = CreateObject(“CPlugInDocDispatch.DocDispatch")
MailTo = “[email protected]”
MailCC = “Guido.Machmü[email protected]”
MailSubject = “Test”
MailText = “Hello Guido”
DocDisp.add A, A.Description & “_” & A.Name
DocDisp.SendMail MailTo, MailCC, MailSubject, MailText

Page 19 of 31
 DVM
Function & Design Specification

3.6 Development specifications /

Implementation details
3.7 DLL ComosDDMSafe
3.7.1 Class DDMSafe
3.7.1.1 Sub
CheckOut
CheckOut ()
Causes the CheckOut as described above.

UndoCheckOut
UndoCheckOut ( )
Undoes the function for the | Checkout context menu.

CheckIn
CheckIn ( ByVal Comment as String )
Causes the CheckIn as described above. Parameter Comment.

ShowHistory
ShowHistory ( )
Delivers the function for the | Version history context menu.

LinkedFileToComosFile
LinkedFileToComosFile ( )
Background: A document can be imported to the Navigator using Drag&Drop. Thereby, it is possible to also
import the document only as “Reference”. Effect: The document is not imported to the Comos document
folder. Note: In DVM there is no option to import using a “Reference”.
This function transfers a referred document to the Comos document folder.

ShowDDMOptions
ShowDDMOptions ( )
Delivers the function for the | DVM options context menu.

SetRevisionLinkOnVersion
SetRevisionLinkOnVersion ( ByVal pltdoc as IComosDDocument, ByRef Rev as
IComosDDevice )
Called: When a DVM document is revised. Alternately, sets the reference between the revision and the DVM
version.

Page 20 of 31
 DVM
Function & Design Specification

3.7.1.2 Function
GetPhysicalCheckOutName
GetPhysicalCheckOutName ( Optional ByVal FNWithGen as Boolean = False )
as String
During checkout, a copy of the document file is placed in the checkout folder. This function returns the path
and filename of the copy in the checkout folder. (Note: Hence also analyzes the PQM option Use original
filename.)

IsDDMCObject
IsDDMCObject ( ByVal CDev as IComosDCDevice ) as Boolean
Checks whether a base object is a DVM base object. Technical: searches for the specification DDM | DDM.

CheckRights
CheckRights ( ByRef Doc as IComosDDocument, ByVal r as DDMRights ) as
Boolean
Checks which relevant rights exist for DVM:
CheckIn = 0
CheckOut = 1
Administrator status = 2
Undo = 3 (this is an “artificial” right, which does not exist in the Comos user management. It contains
CheckIn and CheckOut.)

IsCheckInAllowed
IsCheckInAllowed ( ) as Boolean
Executes the IsDocumentCheckInAllowed Script block. This Script block is available for all
document base objects, but can be used exclusively in DVM.
Called: When a version is created (Import or CheckIn).
In the Script block, events are defined in which no versions are to be allowed. If such an event occurs, then
the Script block must return a string. The string is displayed in an information window and at the same time,
a checkin is prevented. Technical: If the Script delivers a string bigger than the null character, the string is
displayed and the checkin is prevented.

IsCheckOutAllowed
IsCheckOutAllowed ( ) as Boolean
See IsCheckInAllowed.

IsUndoCheckOutAllowed
IsUndoCheckOutAllowed ( ) as Boolean
For the function | Undo checkout. See IsCheckInAllowed.

MakeTmp
MakeTmp ( ByVal D as IComosDDocument) as String

Page 21 of 31
 DVM
Function & Design Specification

Parameter D = Version (through import or CheckIn). From the document version, the function generates a
physical copy in the Windows Temp folder and delivers back the FullfileName. Example: Open dialog
box of a DVM document, Show last version.

MakeTmpWithName
MakeTmpWithName ( ByVal D as IComosDDocument, ByVal TMPPaht as String,
ByVal MakeWriteable as Boolean ) as String
See MakeTmp. In addition, you can specify the filename of the copy and decide if the copy is write-
protected.

MakeFirstCheckIn
MakeFirstCheckIn ( ByRef Filename as String ) as Boolean
Function that is called for the import. The import, automatically and only, generates the first version of a
document.

3.7.1.3 Property
DDMFileStatus
DDMFileStatus ( ) as DDMFileStatus (read only)
Determines the status of a document from the DVM view. In detail, it can be:
DDMFile_CheckedOut = 0 (Integer)
DDMFile_NotCheckedOut = 1 (Integer)
DDMFile_CheckedOut_ButNotExists = 2 (Integer)
DDMFile_CheckedOutbyAnotherUser = 3 (Integer)

WorkingFolder
WorkingFolder ( ) as String (read only)
Delivers the working directory, which is set in the PQM options.

CurrentCheckOut
CurrentCheckOut ( ) as _DDMCheckout (read only)
Delivers the current CheckOut object, i.e. the document which is checked out at this moment. See
DDMCheckOut.

Versions
Versions ( ) as _DDMVersions (read only)
Delivers the DDMVersions object, also see there.

CheckInKind
CheckInKind ( ) as MenuCheckInKind (read only)
Is defined in the PQM module options of the project. See Module options tab, PQM options specification
tab, Checkin group: Checkin mechanism. In detail, it can be:
OnlyOneVersion = 1 (Integer)

Page 22 of 31
 DVM
Function & Design Specification

AllVersions = 2 (Integer)
OneVersionPerRevision = 3 (Integer)
CountedVersion = 4 (Integer)

3.7.2 Class DDMVersion

Provides all properties that a document receives in the context of DVM. All properties mentioned below
refer to a single version. The DDMVersions class (note the plural “s”!) then includes all DDMVersion
objects.
VersionNumber ( ) as Long (read only)
User ( ) as String (read only)
DateCheckOut ( ) as Date (read only)
DateCheckIn ( ) as Date (read only)
Comment ( ) as String (read only)
Filename ( ) as String (read only)
ComosObj ( ) as IcomosBaseObject (read only) (Refers to the document object)
RevisionLink ( ) as IcomosDDevice (read only) (Reference to a relevant revision)

3.7.3 Class DDMCheckout

Is returned from CurrentCheckOut. In detail:
VersionNumber ( ) as Long (read only)
User ( ) as String (read only)
DateCheckOut ( ) as Date (read only)
Filename ( ) as String (read only)
ComosObj ( ) as IcomosBaseObject (read only) (refers to the document object)

3.7.4 Class DDMVersions: Property

Contains all DDMVersion objects. This collection returns:
Item ( ByVal Index as Long ) as DDMVersion (read only) (This is the DDMVersion
object)
Count ( ) as Long (read only) (number of included DDMVersion objects)

3.7.5 Class DGNDVMImport

3.7.5.1 Function
Import
Analyzes the DGN file for external references. For each reference an error string is generated, which is blank
when the referenced file is already in Comos. The error string contains the name of the referenced file and
the error code if the referenced file is not yet in Comos.

Page 23 of 31
 DVM
Function & Design Specification

So, you don’t get a complete list of all referenced DGN documents, rather only a list of the DGN documents
that are referenced incorrectly.

3.7.6 Class QueryView

Extension class for the object queries. Is created as follows:
Open object query, mark column, right mouse button | Options, Administration tab: Enter extension object
comosddmsafe.queryview.
In the result, you get the query Bulk checkin/ checkout as described above.

3.8 DLL DGNImportLL.dll

3.8.1 Class DGNScan
3.8.1.1 Sub
OpenFile
Opens the DGN file.

Close
Closes the DGN file

3.8.1.2 Function
GetXRefs
Returns the complete list of references. Is called by DGNDVMImport.

3.9 Customizing options through Script events

3.9.1 DVM Scripts for documents
OnMenuCreate(Popup,Context) , OnMenuExecute(ID,Context)
With these two scripts, you can control what to see in the mouse menu.

OnDocumentCheckIn (Document), OnDocumentCheckOut (Document), OnDocumentUndoCheckOut

(Document)
These scripts are called at the CDevice of the document object, when a document is checked in or out.
Thereby, for example, even the “File-Info” (file attribute) is matched (for this, see 3.10.3.2 “Document
properties” tab (File attributes)).
Example 1:
Function OnDocumentCheckIn (Document)
' Event : Beim Einchecken eines Dokumentes
' Input : eingechecktes Document - Objekt

Set DDMS = CreateObject("ComosDDMSafe.DDMSafe")

Page 24 of 31
 DVM
Function & Design Specification

Set PropReader = CreateObject("DSOleFile.PropertyReader")

Set DDMS.Document = document
Set DDMV = DDMS.Versions.Item(1)

FL = DDMV.FileName
Set DocProp = PropReader.GetDocumentProperties(FL)
document.spec("FileInfo.Title").Value = DocProp.Title
document.spec("FileInfo.Author").Value = DocProp.Author
document.spec("FileInfo.Category").Value = DocProp.Category
document.spec("FileInfo.Comments").Value = DocProp.Comments
document.spec("FileInfo.Company").Value = DocProp.Company
document.spec("FileInfo.Keywords").Value = DocProp.Keywords
document.spec("FileInfo.Manager").Value = DocProp.Manager
document.spec("FileInfo.Subject").Value = DocProp.Subject

End Function

Example 2:
Function OnDocumentCheckOut (Document)
' Event : Beim Auschecken eines Dokumentes
' Input : ausgechecktes Document - Objekt

Set PropReader = CreateObject("DSOleFile.PropertyReader")

FL = Document.spec("DDM.File").Value
Set DocProp = PropReader.GetDocumentProperties(FL)

DocProp.Title = Document.spec("FileInfo.Title").DisplayValue
DocProp.Author = Document.spec("FileInfo.Author").DisplayValue
DocProp.Category = document.spec("FileInfo.Category").DisplayValue
DocProp.Comments = document.spec("FileInfo.Comments").DisplayValue
DocProp.Company = document.spec("FileInfo.Company").DisplayValue
DocProp.Keywords = document.spec("FileInfo.Keywords").DisplayValue
DocProp.Manager = document.spec("FileInfo.Manager").DisplayValue
DocProp.Subject = document.spec("FileInfo.Subject").DisplayValue

End Function

IsDocumentCheckinAllowed
Controls whether and when the document may be checked into the DVM.
Example:
Function IsDocumentCheckInAllowed (Document,FileName)
'Event : Vor dem Einchecken eines Dokumentes
'Input : einzucheckendes Document - Objekt und FileName - String

Page 25 of 31
 DVM
Function & Design Specification

'If the function returns more than "", checkin is not possible.

Res = ""
Crlf = chr(10) & chr(13)
Set PR = CreateObject("DSOleFile.PropertyReader")
Set DocProp = PR.GetDocumentProperties(FileName)
If DocProp.Author = "" Then
Res = "Invalide Metadate: Author not set!"
End If
If DocProp.Title = "" Then
If Res > "" Then Res = Res & Crlf
Res = Res & "Invalide Metadate: Title not set!"
End If
IsDocumentCheckInAllowed = Res
End Function

3.10 Important data structures in the database

3.10.1 Selection list
System project, @System | DDM | CheckInKind
This list is used in: Project properties, Module options | PQM options tab, Checkin mechanism field.
System project, @System | DDM | CheckOutFolder
This list is used in: Project properties, Module options | PQM options tab, Checkout mode field.

3.10.2 Project options

The project specifications explained below must be present in the module options in the PQM options
| DDM (=Description | Name) tab. The module options are available in the system project under
@PROPAR.

“DVM: Checkin” group

Project specification Checkin mechanism
Display type: Input field, Display: Combo box
Name: CheckInKind
Values: are obtained from the system project, @System | DDM | CheckInKind.
Only current version
All versions
All versions with revision
Number of versions is project dependent
In this setting, the Number of versions input field is used.
Depending on the selected option, the document versions are saved and can be called. If the version storage
mechanism is converted, then all version files that are not required will be deleted.
Example: If converted to Only current version then all versions created until now will be deleted, with the
exception of the current version.

Page 26 of 31
 DVM
Function & Design Specification

Project specification Number

Display type: Input field, Display: Text field
Name: MaxVersionCount
Type: Number
Project specification Library object for documents
Display type: Reference, Display: -
Name: DDMRoot
Stipulates which base object is to be applied for documents that will be imported to the DVM. Depending on
the import method, even deviating base objects can be set.

”DVM: e-mail options” group

Is analyzed during document mail order and is a compulsory requirement there.

“DragDrop-Import for PQM” project option

Display type: Checkbox, Display: -
Name: Active
Switches the Navigator to DVM mode. While importing files through Drag&Drop, the following is checked:
Searches for the last set @Project document group (Options in DVM bulk import).
If it is not found, then the Library object for documents field, the PQM tab is analyzed.

3.10.3 DVM specifications for documents (DVM base object)

3.10.3.1 “DVM | DDM” tab
This tab is not visible on the planning side and controls the DVM. All following specifications will be set
through Comos, except Locked. A description is specified for Locked.
• Name: Checkout
Description: Checked out
Display type: Checkbox
• Name: Comment
Description: Comment
Display type: Memo field
• Name: DateCheckIn
Description: CheckIn – Date
Display type: Input field
• Name: DateCheckOut
Description: CheckOut – Date
Display type: Input field
• Name: DDMFileLink
Description: File link
Display type: Checkbox
• Name: DDMNextNameByCDevice
Description: Name generation by base object
Display type: Checkbox

Page 27 of 31
 DVM
Function & Design Specification

• Name: DES001
Description: Comment
Display type: Description
• Name: DocumentRevisionMode
Description: Revision mode
Display type: Input field
• Name: File
Description: File
Display type: Input field
• Name: Locked
Description: Locked
Display type: Checkbox
Is used during redundant document management. When a version is saved, a new working version is
created on the next matching between the development and working area. See 3.2.1 Redundant document
administration (@Project).
• Name: Revision
Description: Revision
Display type: Link
• Name: User
Description: User
Display type: Input field
• Name: VersionNumber
Description: Version number
Display type: Input field

3.10.3.2 “Document properties” tab (File attributes)

All metadata that is written to the physical file is collected here. To edit the metadata, you need the
dsofile.dll component. The dll is installed by a Runtime component on the PC, but is not a
development by innotec. The dsofile.dll is a Microsoft library.
The functionality of the dsofile.dll is only supported by systems with NTFS format. The saved
metadata is lost, as soon as the files are saved on a non-NTFS system.
As standard, this Microsoft technology is indeed released, but is not supported by Microsoft and there are no
warranty claims either. This technology can be officially used for Office documents, but from Windows
2000 onwards this technology can be used for all OLE-conforming document files.
Please note: Use the dsofile.dll at your own responsibility. innotec does not support this component.
To view this metadata later, proceed as follows:
• Select the file in Windows Explorer
• Right mouse button | Properties
• File info tab in document properties
The title and author are mandatory fields.
Company-specific requests with regard to metadata are covered by various Scripts, see chapter 3.9.1 DVM
Scripts for documents. In the example database from innotec, the metadata was processed as follows:

Page 28 of 31
 DVM
Function & Design Specification

• Name: Author
Description: Author
Display type: Input field
• Name: B
Description:
Display type: Frame
• Name: Category
Description: Category
Display type: Input field
• Name: Comments
Description: Comments
Display type: Memo field
• Name: Company
Description: Company
Display type: Input field
• Name: Keywords
Description: Keywords
Display type: Input field
• Name: Manager
Description: Manager
Display type: Input field
• Name: Subject
Description: Subject
Display type: Input field
• Name: Title
Description: Title
Display type: Input field

Access to file attributes on Citrix

Access to the file attributes from non-Office documents on Citrix Client drives is not possible.

Access to file attributes on Windows

Basically, even in Windows, there is a problem with access to the file attributes of non-Office documents on
Client drives. However, in Windows, a workaround is possible:
1.) On the Client machine, release for example “C:\ComsCheckout” for the user to whom the computer
belongs, or for a somewhat bigger group.
2.) During checkin/import, access to "<\\ClientMachineName\ComosCheckout>"

3.10.3.3 “History” tab

Contains all procedures since the time a document was created by DVM. The list can thus be very long
sometimes. The history for a document is filled for following actions: Import, Document mail order, Checkin
/ CheckOut.

Page 29 of 31
 DVM
Function & Design Specification

• Name: DDM019
Description: Procedures
Display type: List

The column specifications in the list are created as follows:

Name: Action
Description: Action
Name: Data
Description: Data
Name: Date
Description: Date
Name: Description
Description: Description
Name: User
Description: User

3.10.4 DVM queries

The queries for the DVM are not a technically compulsory requirement for using the DVM. But, without
these queries, it will be more complicated to use the DVM to a large extent. The queries must be created at
the following location:
@System | @O Interface | @Query
Advantage: If queries are created here, then they also appear in the | Extra | Query Comos menu.
• DVM documents bulk import
Create new base object in Action class
System tab, Define ControlType switch
ComosBulkCheckIn.BulkCheckIn

• Bulk checkin / checkout

Right mouse button in the base data:
|New |New query |Applications |User-defined.
Open object query, mark column, right mouse button |Options, Administration tab:
Enter comosddmsafe.queryview extension object.

3.10.5 Base data customizing

To use automatic document allocation, the document groups and the base data in the @Privat @UZ node
must be matched with each other.

3.10.6 Document types

• Undefine |Undefined document
Basically not a technical requirement for DVM. This document type activates the following capability: if
Comos finds a document type that is exactly called “Undefine”, then the value in the Extension field is
ignored and instead, the file type is determined from the file transferred using Drag&Drop.

Page 30 of 31
 DVM
Function & Design Specification

All other file types can work only exactly with the specified file extension or it pertains to an administration
document without file extension.

Page 31 of 31
 Project “USERS”
Function & Design Specification

Project “USERS”

Page 1 of 14
 Project “USERS”
Function & Design Specification

Imprint
© 2005 innotec GmbH
Published by: innotec GmbH
Eisenwerkstraße 1
D-58332 Schwelm
http://www.innotec.de
Comos is a product of innotec GmbH.
The software and hardware names mentioned in this documentation, in most cases, are also registered trade
marks and as such are subject to statutory regulations.
Comos® is the registered trademark of innotec GmbH.
This documentation is protected by copyright laws. All rights, even those including translation, reprint and
duplication, be it partially or in whole, are reserved. No part of the documentation may be reproduced,
distributed or processed using electronic systems, copied or disseminated in any form whatsoever
(photocopy, microfilm or a different process), also not for teaching purposes, without the written consent of
the publisher.

The Comos license is linked to the license floppy disk and the related adapter (dongle). Loss of the license
floppy disk or adapter (dongle) automatically leads to loss of the license.

For any questions in connection with the documentation, please contact:

[email protected].

Comos Hotline Support:

Monday to Friday between 08:30 and 17:00
Telephone: +49 (0) 228 6480 577.

FD Project USERS FDUSR81E01 Stand: See Document history

Page 2 of 14
 Project “USERS”
Function & Design Specification

Document history
Version Version Date Author Comment
DE EN
1.0 12.12. 2005 FRO
1.0 12.22. 2005 AWO Translation of DE 1.0

Assignment number Description

Author: Date: Signature:

Mark Schimmang 12.12. 2005
Frank Roscher 12.12. 2005

Translation:
Aliki Wolff 12.22. 2005

Released by:
Frank Roscher 12.22. 2005

Page 3 of 14
 Project “USERS”
Function & Design Specification

Table of contents
Project “USERS”............................................................................................................................................... 1
Imprint ............................................................................................................................................................... 2
Document history .............................................................................................................................................. 3
Table of contents ............................................................................................................................................... 4
1 Objective/ Area of use ............................................................................................................................... 5
2 Administration........................................................................................................................................... 6
2.1 Login / Rights for the administration ................................................................................................ 6
2.2 Base data............................................................................................................................................ 6
2.3 Preparing the user management......................................................................................................... 7
2.4 Preparing USERS project .................................................................................................................. 8
2.4.1 Create/ open project................................................................................................................... 8
2.4.2 Company hierarchy / User......................................................................................................... 9
2.4.3 User group objects ................................................................................................................... 10
3 Planning project....................................................................................................................................... 11
3.1 Project properties............................................................................................................................. 11
3.2 Rights for the “Group_<Suffix>” user groups.......................................................................... 11
3.3 Creating objects ............................................................................................................................... 11
4 Scripts ...................................................................................................................................................... 14

Page 4 of 14
 Project “USERS”
Function & Design Specification

1 Objective/ Area of use

Keywords: USERS project, USER project, user project, extended user management, user objects, user
planning objects
The user planning objects complement to the user management. For this, the user planning objects are linked
with the user management. The following working techniques make it mandatory to work with user planning
objects:
• Project-specific user groups
With the help of the user planning objects, the user can assemble the required user groups in the projects.
In that case, the user management will only contain a few groups. These groups then represent a “rights
bundle”, but no longer map the group composition.
An interesting side effect of this is that you no longer need an administrator login for composing and
reorganizing the groups. Instead, object rights are used as a means of controlling the administration of
the group composition.
• Hierarchical structure of the personnel structure
Any company, department and group structure can be mapped. The only condition being that there are
users at the end of a branch, who are then assigned to group link objects, thereby receiving rights.
• Free attribution
During the description of users or user groups, you are not bound by predefined fields in the software.
Instead, you can create any tabs and specifications. In this way, any desired piece of information can be
saved and managed. In addition, it is easy to access this information (via the specification queries).
• Electronic signatures (eSign)
Signing reports or specifications.
• Project management of PQM
In particular, the “Tasks” and “User information” plug-ins necessitate the user planning objects.

Page 5 of 14
 Project “USERS”
Function & Design Specification

2 Administration
2.1 Login / Rights for the administration
The sole area of activity for which an administrator login is mandatory is working in the user management.
Otherwise, no administrator is needed later in practice. Instead, in the planning data, you can protect the
Group_<Suffix> objects (described below) and the USERS project through object rights, so that not
everybody can change the group membership. Each user having the corresponding object rights for
Group_<Suffix> can determine who is in the group and thus issue or withdraw access rights.
For this, the Read completely and Write object rights, and the Project options and Set user rights function
rights are sufficient (depending on the work step). In addition, the Project management metaright is needed
to create the USERS project.

2.2 Base data

<Base project>
In the StandardDB, following base objects are prepared for the USERS project:

The base objects are controlled through a specification:

The hierarchy is: |Company |Department |User and |Usergroup|User.

If you want to work with a test project first, you should concentrate on the following objects: PQM |USR
User administration |S Structures

Page 6 of 14
 Project “USERS”
Function & Design Specification

Properties of the Group objects

Group objects, Users |Group members tab:
Aside from the list, here you will also find the UM030 |Project member specification. This
specification must not be deleted. It is not visible on the planning side, and is an auxiliary object for the
member list: In the planning project, if a user is dragged to the “Person” list, then this UM030 specification
is copied and created (but is not visible in the Navigator).

2.3 Preparing the user management

Administrator rights are required for this step.
Comos menu: |Administrator |System |User management

User properties in the user management

If the user planning object is evaluated by a user, then the Rights tab is automatically ignored in the user
management. The working areas will be evaluated and entered as normal.

Group properties
The user groups define the rights that the users will have later:

Hence, in the case of user planning objects, there are no additional rights.

Page 7 of 14
 Project “USERS”
Function & Design Specification

The user groups must have key names with which Comos can identify them:
Group_<Suffix>, description: any
The Members tab remains empty:

For user groups with the “Group_” prefix, the Members tab is blocked. The working areas are evaluated as
normal in the “Group_” user groups.

2.4 Preparing USERS project

2.4.1 Create/ open project
Unless already done, create the following project:
Name: USERS
The name is mandatory. The USERS project must not be renamed.
Type: Engineering, Description: any.
Other project properties: Leave default.
In the StandardDB, a USERS project is already prepared:

The following steps are carried out on the Units tab. In the StandardDB, the tab is renamed as “User” in the
USERS project.

Page 8 of 14
 Project “USERS”
Function & Design Specification

2.4.2 Company hierarchy / User

Unless already done, create the hierarchical structures of the companies, departments and users in the
USERS project. Because drag-and-drop is restricted to the topmost level (directly under the globe), first
create a unit and then assign a new base object to this unit: PQM |USR User administration |S
Structures |01 Company

The required hierarchy can now be created via the mouse context menu. The hierarchy is |Company
|Department|User. It is not necessary to create all hierarchy levels.
Please note: There must be an object from the “User” object class at the last level.

Company / department properties

These properties can be edited, added or deleted as necessary.

User object properties / Prepare new users for the member list
The Group object is created with a standard name. First, this name must be replaced. Instead of “01” or
whatever value is there, enter the name of a user:

The names of the objects from the “User” object class must be written identical to the entries in the user
management (Comos logins)!
Observe upper case/lower case!
Now, click the Login button:

Page 9 of 14
 Project “USERS”
Function & Design Specification

If the “Create new Comos user” query appears, this can have two reasons:
• The spelling of the Name is incorrect (differs from entry the in the user management)
• The user has not logged into Comos yet.
If you want to avoid errors at all events, then it is recommended to proceed as follows: The users first log
into Comos once. This will create the entries in the user management. Then, you can work with the group
objects in the USERS project. Now, the “Create new Comos user” query should not appear, otherwise, a
write error has occurred.
If the name is written correctly, then the user properties from the user management are displayed. If you are
an administrator, you can edit the user properties. In other words: As an alternative to the choosing
|Administrator |System |User management , administrators can also use the group objects to maintain the
user management.

2.4.3 User group objects

It is not advisable to already create group objects in the USERS project. The reason for this is that, although
possible from a technical point of view, creating group objects in the USERS project could cause confusion.
• All planning projects using the USERS project see all user groups created there. Hence, even those
groups that are not required in the concrete planning project.
• Most details, e.g. the member list, would be simply ignored in the planning projects.
Therefore, the group objects should be created only in the planning projects.

Page 10 of 14
 Project “USERS”
Function & Design Specification

3 Planning project
3.1 Project properties
Options tab, “Enable user project” option.

Effect of the “Enable user project” option

• The USERS branch appears on the Units tab. This branch is a link to the USERS project.
• Importing and exporting projects can become slower, but even in the worst case this slackening is below
the observation threshold (1%).
• Objects from the USERS project may be set in specifications of type “Link”. (Normally, reference
specifications across projects are not allowed)

3.2 Rights for the “Group_<Suffix>” user groups

If not done so already, the rights must now be assigned to the “Group_” user groups from the user
management! The principle begind this is as follows:
1. Groups in the user management receive the rights.
2. Groups in the user management transfer their rights to the Groups objects in the planning project.
3. The Groups objects transfer their rights to the member list (i.e. to the Group objects).

3.3 Creating objects

Group objects / Group objects
In the StandardDB, these objects are prepared in the project mouse menu:

Alternative: At the topmost level (directly under the project root) create a new unit. Assign the following
base object to this object:

Page 11 of 14
 Project “USERS”
Function & Design Specification

Name: @Groups
Now, the prepared user groups can be created with the mouse context menu. The names of the user groups
must be written exactly like the entries in the user management:

Name: Group_<Suffix>
These “Group_<Suffix>” objects are the member list, and thus transfer the user group rights to the users
later.

Page 12 of 14
 Project “USERS”
Function & Design Specification

Group object properties /Maintain member list

In the Group object properties, open the Users |Members tab. In the USERS user management branch,
search for the member (this branch is displayed from the USERS project). Drag the user object to the
“Person” list:

Alternative: In the list, call the mouse menu |Select (Alt +F2). A Navigator opens, which displays the
USERS project.

Remove members from the list

Mouse context menu on a person in the list: |Remove link.

Navigation
From the planning project, you can go directly to the objects in the USERS project: Right-click on an object
from the USERS branch, choose |Navigate |Object in own project from the mouse context menu.

Page 13 of 14
 Project “USERS”
Function & Design Specification

4 Scripts
Link to users in the user management
In the release database, on the Person data tab of the Person base object you will find the UM031
specification. This specification makes the user management accessible in the user planning objects.
The lines at the end are thus the core of this script:
Set App = ComosUser.Workset.Globals.Application
App.ShowpropertiesOnMdiChild ComosUser, false, "",

These lines of script opten the properties of the user from the user management.
The remaining script helps find the user in the user management or crea

Page 14 of 14
 Comos Mail exchange

Comos Mail exchange

Page 1 of 7
 Comos Mail exchange

Imprint
© 2005 innotec GmbH
Published by: innotec GmbH
Eisenwerkstraße 1
D-58332 Schwelm
http://www.innotec.de
Comos is a product of innotec GmbH.
The software and hardware names mentioned in this documentation, in most cases, are also registered trade
marks and as such are subject to statutory regulations.
Comos® is the registered trademark of innotec GmbH.
This documentation is protected by copyright laws. All rights, even those including translation, reprint and
duplication, be it partially or in whole, are reserved. No part of the documentation may be reproduced,
distributed or processed using electronic systems, copied or disseminated in any form whatsoever
(photocopy, microfilm or a different process), also not for teaching purposes, without the written consent of
the publisher.

The Comos license is linked to the license floppy disk and the related adapter (dongle). Loss of the license
floppy disk or adapter (dongle) automatically leads to loss of the license.

For any questions in connection with the documentation, please contact:

[email protected].

Comos Hotline Support:

Monday to Friday between 08:30 and 17:00
Telephone: +49 (0) 228 6480 577.

FD Mail exchange FDMail81E02 Status: see document history

Page 2 of 7
 Comos Mail exchange

Document history
Version Version Date Author Comments
DE EN
0.1 12.08.2005 MSC/FRO Beta 1
1.0 12.12.2005 FRO Release
1.0 12.22.2005 AWO Translation of DE 1.0
2.0 12.27.2005 AWO Small correction

Assignment number Description

Author: Date: Signature:

Mark Schimmang 12.08. 2005
Frank Roscher 12.08. 2005

Translation:
Aliki Wolff 12.22. 2005

Released by:
Frank Roscher 12.22.2005

Page 3 of 7
 Comos Mail exchange

Table of contents
Comos Mail exchange ....................................................................................................................................... 1
Imprint ............................................................................................................................................................... 2
Document history .............................................................................................................................................. 3
Table of contents ............................................................................................................................................... 4
1 Objective ................................................................................................................................................... 5
2 Requirements............................................................................................................................................. 5
3 Interface / Application ............................................................................................................................... 5
4 Controlling mail dispatch through Scripts................................................................................................. 6

Page 4 of 7
 Comos Mail exchange

1 Objective
With the Document mail exchange plug-in, you can send the latest version of a document to E-mail accounts.

Further development
The Document mail exchange plug-in will be replaced by the “Mail Management” component. The planning
of its functional scope includes:
• Receive and send documents that are managed in Comos
• Digitize and manage paper mailing

2 Requirements
Generate a dispatchable document version
To use the plug-in, a dispatchable document version must already exist. Such a version can be created in two
ways:
• Version of a version management document
Using drag-and-drop, drag a file that was imported to the version management to the paperclip symbol in
the lower text field of the plug-in window. If the corresponding file is not yet imported to the version
management, then drag-and-drop is blocked.
Not available for crp files (Reports).
• Version of a report (crp files)
At present, reports cannot be imported to the version management. Therefore, you revert to the revision
interface for reports. Using drag-and-drop, drag a report to the paperclip symbol in the lower text field of
the plug-in window. The latest temporary revision file is created automatically through the current
revision printer. This file is sent by E-mail and is not available in Comos afterwards.
Please note: The revision file to send is not the last entry in the Revision tab, rather a completely new
revision is created.
It is not possible to reimport the version files.

Project properties
Project properties, Module options tab, PQM options sub-tab.
“DVM: email options” group
E-mail from
A common sender is set here. This sender is entered if no other information is available.
E-mail server (SMTP)
The E-mail server that sends the E-mail must be entered here. Example: mail.comos.de.

3 Interface / Application
To start the plug-in, , click the [Document mail exchange] icon in the plug-in symbol bar.

Page 5 of 7
 Comos Mail exchange

Send / Cc
Enter a valid E-mail ID directly in the field.

Attachments
The document versions to send will be dragged to the lower field with the paperclip. For reports, a current
revision copy is automatically created. For all other documents, one must use versions of the version
management.
[Extended]
Opens an object query for documents. In this way, you can search for specific documents and send them as
document version.
[Send]
The login is entered as sender.

4 Controlling mail dispatch through Scripts

A button that enables automatic mailing is added to documents in their properties window. The button then
gets a Script that uses the Document mail exchange plug-in, however, without calling its interface. The
Script transfers the necessary data (recipient, text, etc.) to the plug-in.
Example:
Set DocDisp = CreateObject(“CPlugInDocDispatch.DocDispatch")
MailTo = “[email protected]”
MailCC = “Guido.Machmü[email protected]”
MailSubject = “Test”
MailText = “Hallo Guido”
DocDisp.add A, A.Description & “_” & A.Name

Page 6 of 7
 Comos Mail exchange

DocDisp.SendMail MailTo, MailCC, MailSubject, MailText

Page 7 of 7
 Dual Document Managemnt
Function & Design Specification

Dual Document Management

(@Project)

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 1 von 10
 Dual Document Managemnt
Function & Design Specification

Impress
© 2005 innotec GmbH
Published by: innotec GmbH
Eisenwerkstraße 1
D-58332 Schwelm
http://www.innotec.de
Comos is a product of innotec GmbH.
The software and hardware names mentioned in this documentation, in most cases, are also registered trade
marks and as such are subject to statutory regulations.
Comos® is the registered trademark of innotec GmbH.
This documentation is protected by copyright laws. All rights, even those including translation, reprint and
duplication, be it partially or in whole, are reserved. No part of the documentation may be reproduced,
distributed or processed using electronic systems, copied or disseminated in any form whatsoever
(photocopy, microfilm or a different process), also not for teaching purposes, without the written consent of
the publisher.

The Comos license is linked to the license floppy disk and the related adapter (dongle). Loss of the license
floppy disk or adapter (dongle) automatically leads to loss of the license.

For any questions in connection with the documentation, please contact:

[email protected].

Comos Hotline Support:

Monday to Friday between 08:30 and 17:00
Telephone: +49 (0) 228 6480 577.

Project revision FDProRev81E01 Status: See Document history

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 2 von 10
 Dual Document Managemnt
Function & Design Specification

Document history
Version Version Date Author Comments
DE EN
0.1 12.08.2005 MSC/FRO Beta 1
1.0 12.12.2005 FRO Release
1.1 12.30.2005 AWO Translation of DE 1.0

Assignment number Description

Author: Date: Signature:

Mark Schimmang 12.08. 2005
Frank Roscher 12.08. 2005

Translation:
Aliki Wolff 12.30. 2005

Released by:
Frank Roscher 12.30.2005

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 3 von 10
 Dual Document Managemnt
Function & Design Specification

Contents
Dual Document management (@Project).......................................................................................................... 1
Impress .............................................................................................................................................................. 2
Document history .............................................................................................................................................. 3
Contents............................................................................................................................................................. 4
1 Aim / Basic principles ............................................................................................................................... 5
2 Using revisions in working layers (with @Project)................................................................................... 5
3 Administration........................................................................................................................................... 6
1. Revision base objects..................................................................................................................... 6
2.Creating @NameSystem ................................................................................................................ 6
3. Creating @Project ......................................................................................................................... 7
4. Activating automatic referencing .................................................................................................. 7
5. Base objects of the document groups ............................................................................................ 7
6. Modifying PrintManager ............................................................................................................... 7
4 Application ................................................................................................................................................ 7
The project / plant revision................................................................................................................ 8
Example............................................................................................................................................. 8
Making revisions by using dual document management................................................................... 9
Additional columns for the Plant revision option............................................................................ 10
Interaction between document groups and documents.................................................................... 10
Interaction between the revisions of different layers....................................................................... 10
5 Implementation........................................................................................................................................ 10
RevisionMaster.dll........................................................................................................................... 10

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 4 von 10
 Dual Document Managemnt
Function & Design Specification

1 Aim / Basic principles

The main area of application of the dual document management is the maintenance of a project revision in
operator mode. Here you work with working layers in which the conversion projects or extension projects of
a plant are managed. The original data of the plant is located in the released area.
• The plant revision (@NameSystem branch) is created in the released area of the project and is thus
visible in each working layer.
• The project revision (@Project branch) is only created in the layers. Revisions initially only have an
effect in this layer.
• Selected project revisions are transferred into the plant revision within a controlled process.
Main functions:
• Individual or group revisions that are independent of the original stock of data.
• Automatic referencing to the project revisions.
• The project / plant revision is made available if the @NameSystem branch and the @Project branch
both exist at the same time.
Exception: Page numbering is not made available via groups.
Please note that the entire @Project branch is layer-independent and is not affected by a release. That means
in particular that documents that are located here in the original are lost if a release is made with the “Delete
working layer at release” option.

2 Using revisions in working layers (with

@Project)
From a technical point of view it is possible to use working layers and to carry out revisions in these working
layers without using the @Project branch. In such a case the following happens:
Technically speaking, the revisions are stored as objects (which are invisible in the Navigator) underneath
the original document, in the working layer at that. However, the comparison of the names of the objects
works across layers. The name of a revision is therefore the same as the index that is displayed.
Hence if you attempt to create a revision with an index that exists already in another working layer (or in the
released area), it will be rejected by Comos. An error mesage will appear, informing you that there is already
a revision with the same index in another working layer.
Since you cannot set the index manually, it is then no longer possible to carry out a revision for the
document. To be more precise, you can only continue to make revisions in the working layer that has the
highest index.
The index number cannot be set manually because it not only ensures that the revisions are unique but is also
used to make a statement on the sequence of the revisions.

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 5 von 10
 Dual Document Managemnt
Function & Design Specification

3 Administration
Please note:
In this documentation, the term “project revision” refers to the revision of the @Project branch within the
working layer.
The most recent project revision is also kept on hand as a “plant revision”. On release, only this plant
revision kept on hand is transferred to @NameSystem branch.
See also the “Background: comparison across layers” section of the Manual.

1. Revision base objects

It is recommended (but not absolutely necessary from a technical point of view) to create separate
revision base objects for the project revision (revision in the working layer, hence @Project) and the
plant revision (revision of the released area, hence @NameSystem).
A corresponding @Project revision base object can be created underneath a revision base object.
This object is then automatically used in the project / plant revision:

Exception: a @Project revision base object is not evaluated for the root object @Revision.
Additional condition: the @Project revision base object must possess revision elements that are the same as
those of the “parent object”, both in number and as regards their name.
Effect:
• The descriptions of the revision elements may deviate and are then output on the Revision tab in the
column headers.
• The attributes (specifications) may deviate. This primarily concerns eSign. In other words, the project
and the plant revision can use different signatures.

2.Creating @NameSystem
The @NameSystem branch is to be created in the released area of the project and is thus visible in each
working layer.

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 6 von 10
 Dual Document Managemnt
Function & Design Specification

3. Creating @Project
The @Project branch is created in the working layers and thus contains only the references of this layer.
Revisions initially only take effect in this layer.
@Project branch: the keyname @Project must be used explicitly.
(If only one document group exists at the topmost level, then this is not interpreted as @Project, but
instead is automatically regarded as @NameSystem.)
Please note that the entire @Project branch is layer-independent and is not affected by a release. In
particular, this means that documents whose original is located here are lost when using the “Delete working
layer at release” option when a release is carried out.

4. Activating automatic referencing

Project options, Options tab,
Group „Automatic referencing of documents“:
• Default (@NameSystem)
• @Project
These two options control whether or not references to the documents are to be created automatically in the
@NameSystem branch and in the @Project branch. From a technical point of view, this option is not an
essential prerequisite for carrying out the revision (nor for the project / plant revision either). But it is not
possible to make practical use of the revision function without automatically referencing documents.
If the above-mentioned @Project option is not activated, then you cannot search for plant revisions in the
Release Manager. See the “Application” section.

5. Base objects of the document groups

Set the revision type.

6. Modifying PrintManager
PrintManager: you need to modify the queries for the PrintManager. Recommendation: delete the old
“Revision” column and show the new revision columns.
Please note that the revision rectangles in the report always show revisions from @Project only.

4 Application
No originals in the @Project branch! It is possible that the original of a document is located in the
@Project branch. But that is not recommended:
The entire @Project branch is layer-independent and is not affected by a release. In particular, this
means that documents created in the @Project are lost when using the “Delete working layer at
release” option when a release is carried out.
In addition, originals from the @Project branch are not included into the joint project / plant
revision.

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 7 von 10
 Dual Document Managemnt
Function & Design Specification

The project / plant revision

In addition to the above-mentioned preparations, the following applies: a project / plant revision is only
available if the original document is located under a unit or a location, if a reference to the document exists
both in the @Project branch and in the @NameSystem branch, and if the properties of the original
document are called.

Example
In the following example you can see the original document PFPA.3 Signals list at the left (it is
located on the Units tab):

On the right, the PFPA document groups exists twice, and both groups have a reference to the original
document.
Provided this is the case, you open the properties of the original document. Either select the | Properties
command at the original document or the | Properties of the original document command at the reference.

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 8 von 10
 Dual Document Managemnt
Function & Design Specification

There is now an additional option on the Revisions tab. It is used for switching between the displayal
of the project and plant revision:

Making revisions by using dual document management

Revisions can only be carried out using project revisions.
If you switch to the Plant revision option, then the buttons to carry out a revision are deactivated:

The buttons are deactivated because the plant revision is created automatically by Comos in the working
layer (plant revision that is on hand).
The project revisions are used as described previously.
The most recent project revision overwrites the current plant revision. If you wish to save a plant revision
permanently, you need to write a script that sets the plant revision to write-protected. After that Comos
automatically creates a new plant revision, and only this new plant revision is overwritten.
Alternatively, the following attributes can be used:
Revision base object, SYS tab, Name: Locked, type: checkbox
Each plant revision is write-protected as long as the checkbox is activated. Thus, the number of plant
revisions equals the number pf porject revisions. If the checkbox is deactivated, a plant revision is created
that is not write-protected and, as a consequence, will be overwritten.

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 9 von 10
 Dual Document Managemnt
Function & Design Specification

Please note that the term “overwrite” is not to be taken literally. For technical reasons, the revision file of the
plant revision ist not a copy of the revision file of the project revision. In fact, two revisions are carried out
instead, one for the plant revision and one for the project revision. Theoretically, it is possible that these two
revisions differ, for example because variables are evaluated differently.

Additional columns for the Plant revision option

Locked
Specifies whether or not a plant revision is write-protected. In the initial state, an on-hand plant revision is
created in the working layer that is not write-protected.
Project revision
If “No” has been set here, then the plant revision comes from the released area. Otherwise, the cell will
contain text of the type “Test3-4”. The string in front of the hyphen is the name of the working layer, the
number after the hyphen is the index of the (on-hand) plant revision.

Interaction between document groups and documents

Revisions can be carried out for document groups in the normal way. If a document is includeded in a group
revision, the group revision is entered as “project revision”.

Interaction between the revisions of different layers

In the case of project revisions, the different working layers do not interact. Plant revisions are compared
across layers by means of the Release Manager. The Release Manager is described in the Manual.

5 Implementation
RevisionMaster.dll
Property RevMode at RevisionInfo. Here you can set which revision information is to be returned.
• 1 = project revision (default) [this relates to @Project]
Here this relates to the working layer.
• 0 = plant revision [this relates to @NameSystem]
Here this relates to the released area.
By means of this property you can also specify in a report which revision information is to be output on the
report.

H:\FD-Dokumente (Versionen)\Englisch\Projektrevision\FD Projektrevision.doc

Seite 10 von 10