Document approvals: designations, approvers, the Approval Monitor, and submitting a purchase order

Steps 2 to 5 of setting up document approvals: the submitter designation, the approvers under it, the Approval Monitor row, and submitting a purchase order. It follows Step 1, where you built the approval setting. The running example is GadgetSphere’s setting PO-KV03 for branch GS-KV-03: one of two approvers at level 1 on every purchase order, and the finance director at level 2 from RM 10,000.

Read the warning in Step 5 before you rely on a two-level rule: the purchase order is set to FINAL as soon as the first approver approves, so the second level is a recorded second opinion, not a second gate.

1. Step 2: create the submitter designation and link it to the setting.
2. Step 3: put the approvers under the designation, with a level.
3. Step 4: tell the Approval Monitor that a PO may stand on its own.
4. Step 5: submit a purchase order for approval.

Step 2: Create the submitter designation and link it to the setting

Purchase Order Applet → Settings → Branch → select your branch → Designation

A designation is a group with a code. Here you need exactly one: the designation whose code matches the setting’s Submitter Designation Code. For GadgetSphere, create it on GS-KV-03 with Code Staff, Name Branch purchasing staff, and Approval Setting PO-KV03.

Two rules the form does not show:

• One designation per code per setting, across the whole tenant. Once a Staff designation is linked to PO-KV03, a second Staff linked to the same setting is refused, even on another branch. For another branch’s approvers, build another setting (Step 1) and link a Staff designation to that one.
• You do not need designations for the approvers themselves. A BRANCH-MGR or FIN-DIR designation is harmless, but BigLedger never reads it when routing a Staff document. The approvers go under Staff, in the next step.

Most common failure here: the code does not match exactly, or the designation is linked to a different setting. Nothing complains now; it shows up at submission as the “Submitter designation_code is not created” error (the first entry in Common mistakes). That message means “no designation with this code is linked to the setting you picked”.

Step 3: Put the approvers under the designation, with a level

Purchase Order Applet → Settings → Branch → select your branch → Designation → Staff → Designation Employee

Here you add the approvers and, for each one, an Approval Level. The level is a number: 1 is the first person to see the document, 2 is the next, and so on. Each person you add takes the designation’s code and its linked setting with them — that is how BigLedger finds them.

For GadgetSphere, under Staff:

Two people at level 1 is deliberate — it means either of them can clear the first level, so a purchase order does not sit still while one of them is on leave. You control how many of them have to act with the level’s Approval Quorum (Step 1).

Every approver needs an e-mail address on their employee record. The whole approval flow is driven by e-mail. If the address is blank the approval still gets created, but the approver is never told; you will see APPROVER_EMAIL_IS_EMPTY in the Email Notification Status column and nothing will happen until someone chases it by hand.

Step 4: Tell the Approval Monitor that a PO may stand on its own

Purchase Order Applet → Settings → Approval Monitor

This one catches almost everybody, and the symptom looks nothing like the cause.

The Approval Monitor holds pairs of document types and answers one question: must the second document have been converted from the first before it can be submitted for approval? For purchase orders, BigLedger always asks that question about the pair Purchase Requisition → Purchase Order.

If there is no Approval Monitor row for that pair at all, the check errors, and on the purchase order’s Approval tab the Add button is greyed out with the tooltip “Purchase Order needs to be converted from Purchase Requisition” — even for a perfectly ordinary standalone PO.

So create the row:

GadgetSphere leaves it unticked because branches raise purchase orders directly. Tick it only if your policy is that every purchase order must come from an approved requisition — in which case BigLedger will additionally check that the source requisition exists and was approved, and will copy that requisition’s submitter onto the new approval.

Step 5: Submit a purchase order for approval

Purchase Order Applet → open a saved purchase order → Generic Doc Approval tab

Now the daily use. Open a purchase order, go to the Generic Doc Approval tab, click Add, choose the submitter (the employee raising it) and the Approval Setting (PO-KV03 for a GS-KV-03 order), and save. Then select the row in the grid and click Submit For Approval.

Choose the submitter first and the setting second. Choosing the submitter fills Submitter Designation with their Job Title from the Employee applet; choosing the setting replaces it with the setting’s Submitter Designation Code — which is what the approver lookup needs. The other order leaves the Job Title there, and unless it happens to equal the setting’s code the submission fails with the designation error in Common mistakes.

An approval that arrives with no setting at all — through the API, for example — is routed differently: BigLedger looks for a setting for this document type whose Submitter Designation Code matches the submitter’s Job Title, and falls back to the designation Staff when none does. That fallback is why Staff is the conventional code.

What happens next, in order:

1. The approval goes to Pending Approval.
2. BigLedger works out how many levels apply from the document total and the Min Approval Amounts.
3. It creates one request per approver at level 1 and e-mails each of them.
4. The e-mail contains a link. The approver clicks it and lands on a plain web page showing the document number, date, total, currency and lines, with Approve and Reject buttons and a remarks box. Remarks are compulsory. Approvers can also work from the Approval Request screen inside the applet if they prefer.
5. When level 1’s quorum is met, level 1’s outstanding requests disappear and level 2’s approvers are e-mailed.
6. When the last required level approves, the approval status becomes APPROVED and BigLedger stamps the final approval date.

If anyone rejects, the whole approval goes to Rejected, the submitter gets an e-mail with the rejection remarks, and every outstanding request is cleared. The purchase order itself is untouched — it stays exactly as it was. To try again, fix the document and click Resubmit, which starts a fresh cycle from level 1.

What success looks like for this part

The Staff designation on GS-KV-03 is linked to PO-KV03, with the two level-1 approvers and the finance director at level 2 under it, each with an e-mail address; the Approval Monitor has the Purchase Requisition → Purchase Order row, with Document Conversion Required unticked if your branches raise purchase orders directly; and a test purchase order submitted with the submitter first and the setting second shows PENDING_APPROVAL, PROCESSOR_SUCCEED and EMAIL_SENT_TO_APPROVER. Then run the whole task’s success check, which carries the order through to APPROVED and FINAL.

Common mistakes in this part

“Submitter designation_code is not created in bl_fi_mst_branch_designation” No designation with the approval’s Submitter Designation code is linked to the setting you picked — either it was never created, it is linked to another setting, or the submitter was chosen after the setting and put their Job Title there (Step 5). Go back to Step 2. The message also asks you to contact a developer — you don’t need to; it is a configuration gap, not a bug.

“There is no approver assigned in bl_fi_mst_employee_branch_designation_link” The designation exists but nobody is in it. Step 3.

“Resigned submitter cannot submit document” The employee you chose as the submitter has a resignation date on their entity record that has already passed. Pick a current employee, or clear the resignation date if it was entered by mistake.

“EmployeeBranchDesignationLink_IS_NOT_FULLY_CONFIGURED” You asked for more approval levels than you have distinct levels of people. If Total Required Approval Levels is 2, at least one person must sit at level 1 and at least one at level 2.

The approver says they never got an e-mail Check the Email Notification Status column on the approval grid. APPROVER_EMAIL_IS_EMPTY means the employee record has no e-mail address. FAILED_GENERIC_DOC_APPROVAL_PENDING_APPROVAL_NOTIFICATION means the tenant has no e-mail template configured for pending approvals — nothing was sent at all, so no amount of waiting will help.

The approver logs in but their Approval Request list is empty BigLedger matches approval requests to the signed-in user through their employee record. If the login has no matching employee in the Employee applet, the screen errors with “Cannot find your email … from Employee Applet”. The e-mail link still works in the meantime.

Someone finalised the purchase order while it was waiting That is not a fault; nothing stops it. If the sign-off matters, control who holds the permission to finalise purchase orders rather than expecting the approval to block them.

One more, expecting delegation, escalation or reminders that are not there, is on the front page.

Related documentation

• Purchase Order Applet — the field-level reference for Approval Settings, Approval Monitor, Approval Request and Approval History.
• Purchase Requisition Applet — the same approval loop on requisitions.
• Stock Requisition Applet — has the Approval Settings screen, but no way to submit against it yet.
• Workflow Design Applet — the other thing that looks like approvals, and what it actually does.
• Employee Applet — where approvers’ job titles and e-mail addresses live.