Creating an Electronic Signature

[natursalus]

Hello,

My current project is meant to manage Deviation reports. The Deviation report is like a lenghty form with several sections, each to document a particular step in the Deviation Management process.

Since it is necessary to document which user fills in which section, is it possible to implement a sort of Electronic Signature with FM?

For example, the first part of the lengthy Deviation Report is "Deviation Identification and Submission". After this part has been complimented the deviation reporter, let's say user 1, needs to sign it electronically and send an electronic notification of the Deviation Submission to another user 2. Then, user 2 sees the Deviation Notification and fills in the Deviation Assessment section, after doing that he/she signs it electronically and sends it to the person, user 3, responsible for the next step in the Deviation Management process.

So by the time the Deviation report has been completed and can be closed it is necessary to be able to know which user wrote what, where and when.

Part of my project structure is:

People --< PeopleDeviation >-- Deviation

People table

__kpPeopleID

NameFirst

NameMI

NameLast

NameFull

JobTitle

Department

....

PeopleDeviation table

__kpPeopleDeviationID

_kfPeopleID

_kfDeviationID

Deviation table

__kpDeviationID

DesviationCode

DesviationType

DesviationDescription

Clearly I cannot just use the People table since the same person could sign out electronically in different places of the same Deviation layout. So what additional table and what relationship do I need to establish?

Thanks

[bcooney]

Not sure you need a join table. Let's say each section and its fields are on a tab in a Deviation form view, why not have CompletedSection1Date and CompletedSection1Author fields (a set for each section). The user completes their tab and enters the completed date and selects their StaffID from the CompletedSection1Author popup. With these fields, you could calc a status for the Deviation.

I suppose you could use a join table (and a portal to it on the Deviation form), but also include a SectionID (I'd have a table for this value list) in the record so you can calc the status of completion of the Deviation.

[natursalus]

Hello bcooney,

Since through the different sections of the Deviation form view, the same user could be signing out more than once, wouldn't I run into trouble with the following relationship: User --< Deviation?

Shouldn't I be setting up something like: User --< UserDeviation >-- Deviation?

Many thanks for your help

[bcooney]

Signing out? That's the first you've mentioned this. What do you mean? Are you referring to some sort of record lock problem? I assumed from your description that the record is passed from user to user after each section is completed.

All I really see is that you've got several fields, that are grouped in sections, but are all in the same table, Deviation. You seem to need to capture a completion date and userID for each group of fields.

There isn't really a need for a join table unless you need a log of section completion.

[natursalus]

I assumed from your description that the record is passed from user to user after each section is completed.

That's correct.

All I really see is that you've got several fields, that are grouped in sections, but are all in the same table, Deviation. You seem to need to capture a completion date and userID for each group of fields.

That's correct

There isn't really a need for a join table unless you need a log of section completion.

Okay, I think that I understand now. There is no need to establish any relationship as long as the completion date and the UserID are captured.

Just a final thought, is there any way to avoid the modification of the contents of the completion date and UserID once they have been filled in?

Thanks

[bcooney]

" avoid the modification of the contents of the completion date and UserID once they have been filled in?"

That gets tricky, because often they need to legitimately edit the fields. You could log the edit. You could make the fields admin only if they aren't empty. Read up on RLA (record level access).