| Both sides previous revision Previous revision Next revision | Previous revision |
| other_stuff:remote_authorisation [2025/10/01 04:09] – [Assign the users as authorisers] Jonna Quismundo | 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. |
| |
| |
| {{ :other_stuff:remoteauth.png?400 |}} | {{ :other_stuff:remoteauth.png?400 |}} |
| |
| * **Authoriser:** Enter the name of the user here. Type the first few characters of their username and press the Tab key on the keyboard to select the user from a list of users with usernames that start with what you have typed. | * **Active:** This is checked by default. If this is checked then the user's assignment is active and they can act as an authoriser. If it is not checked then the user cannot act as an authoriser. This is useful when an authoriser is to be removed as an authoriser for a period of time and then added back in again e.g. when they go away on holiday. |
| * **Master list:** Enter the name of the master list containing the items that the user can authorise. The user will only be able to authorise lines on requisitions for items that appear on the list you select here. | * **Authoriser:** Enter the name of the user here. Type the first few characters of their username and press the //Tab// key on the keyboard to select the user from a list of users with usernames that start with what you have typed. |
| | * **Master list:** Enter the name of the master list containing the items that the user can authorise. Type the first few characters of the master list's name and press the //Tab// key on the keyboard to select it from a list with names that start with what you have typed. The user will only be able to authorise lines on requisitions for items that appear on the master list you select here. |
| * **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. |
| * **Active:** This is checked by default. If this is checked then the user's assignment is active and they can act as an authoriser. If it is not checked then the user cannot act as an authoriser. This is useful when an authoriser is to be removed as an authoriser for a period of time and then added back in again e.g. when they go away on holiday. | * **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. |
| |
| Click on the **OK** button to save the new assignment or the **Cancel** button to cancel it. | Click on the **OK** button to save the new assignment or the **Cancel** button to cancel it. |
| ===== 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: |