Incoming Transmittal Workflow - HxGN SDx - Update 64

Incoming Transmittal Workflow - HxGN SDx - Update 64 - Administration & Configuration

Administration and Configuration of HxGN SDx

Language

English

Product

HxGN SDx

Search by Category

Administration & Configuration

SmartPlant Foundation / SDx Version

The following information describes the incoming transmittal workflow template (SDAIncomingTransmittalLifeCycle). It explains what can and cannot be changed.

The steps that make up the workflow are described in the following table.

What does the workflow look like?

If you choose to edit the workflow, do not remove any steps marked as mandatory.

SHARED Tip For information on how to upgrade a workflow template, and the changes that have been made in various updates, see Upgrading workflow templates.

Step name	Description	Mandatory?	Comments
Branch based on completion of transmittal preparation	Routes the workflow to the Prepare Transmittal step on click of SAVE AS DRAFT in the New Transmittal window. Validate transmittal has documents step on click of FINISH in the New Transmittal window.	No
Prepare Transmittal	Allows the creator to relate documents to the transmittal and assign the recipients. The next step is Validate transmittal has documents.	No
Validate transmittal has documents	Checks whether at least one document is attached to the transmittal. If yes, routes the workflow to the Validate ToUser or ToRole step. If no, routes the workflow to the Update missing information step.	Yes	This step is needed to ensure the transmittal has at least one document to share.
Validate ToUser or ToRole	Checks if the To user or To role has been selected. If yes, routes the workflow to the ValidateFromAndToUserAreNotSame step. If no, routes the workflow to the Update missing information step.	Yes	This step is needed to ensure the transmittal has a recipient.
ValidateFromAndToUserAreNotSame	Checks if the From user and To user are the same. If they are different, routes the workflow to the ValidateNonSectionedTransmittalDocs step. If they are the same, routes the workflow to the Update missing information step.	Yes	This step is needed to ensure the transmittal has a recipient.
ValidateNonSectionedTransmittalDocs	Checks whether the documents attached to the transmittal are signed off. If yes, routes the workflow to the SetTransmittalStateToISSUED step. If no, routes the workflow to the Update missing information step.	No
SetTransmittalStateToISSUED	Changes the status of the transmittal object to ISSUED. If this step is removed, the transmittal object status will not be modified. The next step is SetTransmittalIssuedState.	No
SetTransmittalIssuedDate	Sets the issued date on the transmittal object. The next step is Check Due Date.	No
Check Due Date	Checks if the due date is provided in the form. If accepted, the next step is RunAndAttachSDAXmtlReport. If rejected, the next step is SetProjComsDueDate.	No
SetProjComsDueDate	Sets the due date on the transmittal object, as mentioned in Due date in the create form. The next step is RunAndAttachSDAXmtlReport.	No
RunAndAttachSDAXmtlReport	Runs the configured report to generate and attach the transmittal cover letter. The next step is Check for to cc users.	No
Check for to cc users	Checks if To CC users are mentioned. If yes, routes the workflow to the Propagate recipient To Cc users step. Otherwise, routes the workflow to the Propagate recipient to user/to role step.	No
Propagate recipient To Cc users	Identifies the users mentioned in the To user and To role boxes to send a task to. The next step is Transmittal receipt notification.	No
Transmittal receipt notification	Informs the user that a transmittal has been received. This is a notification step. The next step is Propagate recipient to user/to role.	No
Propagate recipient to user/to role	Identifies the users mentioned in To user and To role to send a task to. The next step is Transmittal Issued.	No
Transmittal Issued	Allows the user to accept or reject the transmittal. If accepted, the next step is SetTransmittalStateToCOMPLETED. If rejected, the next step is SetTransmittalStateToREJECTED. The user also has the option to cancel the transmittal. It is then attached to a different workflow, SCLBCancelledTansmittalLifeCycle.	Yes	This step is needed as, otherwise, the recipient will not be able to download the transmittal contents.
SetTransmittalStateToREJECTED	Changes the status of the transmittal object to REJECTED. If this step is removed, the transmittal object status will not be modified. The next step is SetLCRejectedDate.	No
SetLCRejectedDate	Sets the rejected date on the transmittal object. The next step is SetLCRejectedByUser.	No
SetLCRejectedByUser	Sets the rejected user on the transmittal object. The next step is Transmittal Rejected.	No
Transmittal Rejected	Allow the user to rework the transmittal. The next step is Prepare Transmittal.	Yes	This step is needed as, otherwise, the recipient would not be able to rework the transmittal.
SetTransmittalStateToCOMPLETED	Changes the status of the transmittal object to COMPLETED. If this step is removed, the transmittal object status will not be modified. The next step is SetTransmittalCompletedDate.	No
SetTransmittalCompletedDate	Sets the completed date on the transmittal object. The next step is Run and attach report for completion.	No
Run and attach report for completion	Runs the configured report to generate and attach the transmittal cover letter. The next step is Transmittal Completed.	No
Transmittal Completed	Informs the user that the transmittal is complete. This is a notification step. This is the last step in the workflow.	No
Update missing information	Allows the creator of the transmittal to either correct the information provided or prevent from sending an empty transmittal (without any documents). The next step is Validate transmittal has documents.	Yes	This step is needed, as otherwise, the missing information cannot be provided, and the documents cannot be shared with the target organization.