AM_POSTINGFILL
Recruitment\AM_POSTINGFILL
Start of the Workflow
Initialization (Start)
The process begins at the "Start" activity.
The workflow waits here, assessing the initial conditions of a request.
Activity A9: Load Account Format
Purpose: To format and load account details for financial postings.
Process:
The workflow starts by accessing data about accounts from XML nodes.
It retrieves necessary parts like ledger and key details, possibly from a database.
These details are formatted into a specific account format.
The formatted account is attached as an attribute to the XML node.
This ensures that all account data needed for processing is available and correctly structured.
Activity A8: Post Position
Purpose: To ensure a position is posted if it hasn’t been done already.
Process:
Checks if the position is already posted. If not, proceeds to post it.
Executes the posting action and updates variables to prevent re-posting.
Logs completion of the posting for record-keeping.
Activity A1: Finance Approval
Purpose: To secure approval from the finance department for a posting request.
Process:
The request is sent for approval from financial personnel.
Waits for two days for the approval response.
If approval is delayed, it retries indefinitely until an approval is granted.
This stage is critical to ensure compliance and financial oversight.
Activity A7: Save Approval Comments
Purpose: To save any comments made during the approval process.
Process:
Reviews historical approval actions.
Identifies comments made by approving personnel.
Saves these comments into the system to maintain a complete record of the approval process.
Activity A3: Change to Reject Status
Purpose: To update the status of a request to "Rejected."
Process:
When certain conditions are met, the request’s status is changed to reflect rejection.
This involves updating the relevant database tables to ensure the status is correctly recorded.
Ensures clear communication about rejected requests for further processing or review.
Activity A10: Save Rejection Comments
Purpose: To record comments when a request is rejected.
Process:
Checks historical records for any rejection comments.
Verifies and saves these comments into the system.
This helps in keeping a full documentation of reasons behind rejections, aiding in future evaluations.
Error Handler
Purpose: To manage any errors that occur during the workflow, ensuring they are appropriately addressed.
Process:
If an error is detected, the "Error" activity is triggered.
The system notifies the relevant user or personnel about the error.
The error handler waits for a resolution for up to two days.
If the error persists, it retries the notification indefinitely until the issue is resolved.
This ensures continuous awareness and management of errors within the workflow.
NoTransition Handler
Purpose: To handle scenarios where there is no valid transition from one activity to another.
Process:
The "NoTransition" activity is activated when a planned transition is not possible.
It acts as a checkpoint to identify why a transition can't proceed.
The system notifies relevant personnel to investigate and address the transition issue.
This ensures that the workflow has a mechanism to deal with unexpected or invalid transitions, maintaining process integrity.
NotAccepted Handler
Purpose: To manage requests that are not accepted during the workflow.
Process:
When a request is marked as "Not Accepted," the "NotAccepted" handler is triggered.
The system notifies the appropriate user or team about the rejection.
It waits for potential resolutions for up to two days and retries notification if necessary.
This ensures that "Not Accepted" requests are addressed promptly, with feedback or further actions as needed.
End of the Workflow
Finalization (End)
Once all activities and transitions are complete, the process flows to the "End" activity.
The workflow concludes, ensuring all necessary actions are taken and documented.