| Both sides previous revision Previous revision Next revision | Previous revision |
| other_stuff:remote_authorisation [2026/01/16 17:18] – [Assign the users as authorisers] Gary Willetts | other_stuff:remote_authorisation [2026/01/19 13:03] (current) – [The authorisation statuses of requisitions] Gary Willetts |
|---|
| |
| <WRAP center round important> | <WRAP center round important> |
| Only response requisitions (those made in response to request requisitions, called internal orders - see the [[purchasing:ordering_from_one_store_to_another#internal_orders|6.04. Ordering from one store to another]] page for details, can be remotely authorised). Other requisition types or response requisitions made manually can **not** be remotely authorised. | Only response requisitions (those made in response to request requisitions, called internal orders (see the [[purchasing:ordering_from_one_store_to_another#internal_orders|6.04. Ordering from one store to another]] page for details), can be remotely authorised). Other requisition types or response requisitions made manually can **not** be remotely authorised. |
| </WRAP> | </WRAP> |
| |
| * Deny | * Deny |
| |
| ===== Authorisation by masterlist/vertical program ===== | ===== Authorisation by masterlist/vertical program or by store/facility ===== |
| In the remote authorisation module authorisers can only authorise the requisition lines which belong to items on the master list they are able to authorise for. | In the remote authorisation module authorisers can be set to authorise requisition lines which belong to items on the master list they are able to authorise for or which come from a particular store or facility. Or a combination of both! |
| |
| A masterlist can be used to represent a vertical program so this method can also be thought of as authorisation by vertical program. | A masterlist can be used to represent a vertical program so this method can also be thought of as authorisation by vertical program. |
| |
| Authorisers can also be set up with **auto-authorisation**, where transactions will automatically be authorised if the user has not approved or denied the transaction before the set **auto-authorise period** has elapsed. | Authorisers can also be set up with **auto-authorisation**, where transactions will automatically be authorised if the user has not approved or denied the transaction before the set **auto-authorise period** has elapsed. |
| |
| |
| * **Uses auto-authorisation:** If this is checked then, after the number of days set in the **Auto-authorisation period (days)** field, any requisition lines that are waiting for authorisation by this user will be automatically authorised. | * **Uses auto-authorisation:** If this is checked then, after the number of days set in the **Auto-authorisation period (days)** field, any requisition lines that are waiting for authorisation by this user will be automatically authorised. |
| * **Auto-authorisation period (days):** The number of days after which any requisition lines waiting for authorisation by this user will be automatically authorised by the system. | * **Auto-authorisation period (days):** The number of days after which any requisition lines waiting for authorisation by this user will be automatically authorised by the system. |
| * **Approval level:** | * **Approval level:** A whole number starting from 1. Level 1 authorisers will approve first. When they have approved then level 2 approvers can see and approve or reject a requisition. When they have approved a requisition then level 3 authorisers will be able to see and choose whether to approve or reject the requisition. The lines from the requisition on an assigned master list will only be authorised when a highest level authoriser has authorised them. There can be as many authorisation levels as required. A higher level authoriser will not be able to see requisitions awaiting approval unitl a lower level authoriser has approved it. |
| * **Store approval:** This is not checked by default. If this is checked, you can set the rule to only need approval if the request comes from the stores checked in the list. If store approval and no masterlist is set, then all items for the requisition need approval. If masterlist and store approval are both set, then only require approval if from the requesting store and if the item is part of the masterlist. A request from facility (not a store) can also be included by adding a tag "remoteAuthorisation" in the name. | * **Store approval:** This is not checked by default. If this is checked it means that the user will only be asked to approve a requisition if the request comes from the stores selected in the table. If store approval and no masterlist is set, then all items for requisitions from the selected stores need approval. If a masterlist and store approval are both set then approval is only required for requisitions which contain any of the items on the masterlist **and** that come from the selected stores. A requisition from a facility (not a store) can also be included in the list by adding a tag "remoteAuthorisation" set to True to the name record (see the [[names:adding_and_editing#tags_tab|5.01. Names: using, adding and editing]] page for details on doing that). |
| * **Allow to authorise existing pending requisitions:** If checked then the user can authrosie requidsitions that are already exist and are pending authorisation. If not checked then the user will only be able to authorise requisitions that are created after this time. | * **Allow to authorise existing pending requisitions:** If checked then the user can authrosie requidsitions that are already exist and are pending authorisation. If not checked then the user will only be able to authorise requisitions that are created after this time. |
| |
| ===== Using the remote authorisation system ===== | ===== Using the remote authorisation system ===== |
| ==== Requesting authorisation ==== | ==== Requesting authorisation ==== |
| You do **not** need to request the authoristion of a requisition. When the remote authorisation system is turned on as described above, when a requisition that requires authorisation is **confirmed**, an authorisation request is automatically emailed to all active authorisers who are assigned to authorise a master list containing any of the items on the requisition. | You do **not** need to request the authoristion of a requisition. When the remote authorisation system is turned on as described above, when a requisition that requires authorisation is **confirmed**, an authorisation request is automatically emailed to all active authorisers who are assigned to authorise a master list containing any of the items on the requisition, and/or which is from the stores or facilities selected in their settings. |
| |
| The only types of requisition that can be authorised using remote authorisation are response requisitions created automatically in the supplying store in response to an internal order (internal orders are also called request requisitions). See the [[purchasing:ordering_from_one_store_to_another#internal_orders|6.04. Ordering from one store to another]] page for details on internal orders. | The only types of requisition that can be authorised using remote authorisation are response requisitions created automatically in the supplying store in response to an internal order (internal orders are also called request requisitions). See the [[purchasing:ordering_from_one_store_to_another#internal_orders|6.04. Ordering from one store to another]] page for details on internal orders. |
| {{ :other_stuff:reg_auth_pending.png?600 |}} | {{ :other_stuff:reg_auth_pending.png?600 |}} |
| |
| There is also an additinal Authorisation tab on these requisitions, which shows the authorisation history of the requisition: | There is also an additional //Authorisation// tab on these requisitions, which shows the authorisation history of the requisition: |
| |
| {{ :other_stuff:screenshot_2021-10-06_at_13.05.22.png?600 |}} | {{ .:pasted:20260119-125846.png?700 }} |
| |
| This particular screenshot shows that two authorisers have been requested to authorise lines on this requisition. | This particular screenshot shows that three authorisers at different levels have been requested to authorise lines on this requisition. The level 1 authoriser (user aaaa) has authorised the requisition, it is available and waiting for authorisation by user bbbb (level 2). If they also authorised it then it will become available for user cccc (level 3) to authorise, bnut it is niot yet available to them. If emails have been sent to multiple authorisers at any level they will also be shown in the list. |
| |
| The authorisation status can have a few different values: | The authorisation status can have a few different values: |