Voucher Approval: Go is the access point*

Workflows > Usecase > Voucher Approval > Go is the access point

Use case: Go is the primary point of access for vouchers (usually EHF or pdf e-mail receival). The external system need to integrate with the voucher approval workflow

Given that Go is the access point of new vouchers, integrating with the voucher approval workflow can be beneficial for many different situations (not just the "approval" per se). Some examples of relevance:

Limitations*


The workflow currently support supplier vouchers (incoming invoices or incoming credit notes), but will be expanded to other voucher type as we release new voucher types in the journal entry vouchers service. It is important that you contact and discuss your intended workflow with the api team, as the team need to set the correct privileges for your integration.

3-way matching:

  1. External system place a purchase order

  2. Supplier invoice is received in Go, and goods are received with a receipt

  3. The client need to match the supplier invoice with the purchase order and the inventory receipt in order to approve, post and make a payment to the supplier.

External approval systems:


External systems may have an approval workflow functionality dedicated for certain industries and user groups, and/or support advanced approval routines beyond the functionality provided in Go. The client need to have the primary approval workflow in the external system.

Supplement data:


The external system may possess data and information relevant for the voucher, that is not available in Go (references, descriptions, special vat cases etc.).

Incorporating the integration in the approval settings


If the third party integration have the access privelige VoucherApproval, the integration can be set as a "user" in the approval settings of the client (via the user interface).

The most common setup is to have the integration set as the one and only approver, optionally with a controller as the final step. However, the client may have some approval steps in Go before or after the integration is involved - the client can use the setup they see fit for their routines.

The general workflow steps will in any case be as follows:

  1. A voucher is at some point sent to the integration for approval

  2. The integration poll the endpoint GET /VoucherApproval, and get informed that a new voucher is sent to the integration, retreiving the identifier and the voucher type in the process*

  3. The integration retrieve the voucher details using the journal entry voucher endpoint that correspond with the voucher type sent to approval

  4. The integration retrieve the page images and/or EHF xml using the journal entry voucher endpoints

  5. The integration update the voucher if needed, using the journal entry vouchers PATCH endpoints corresponding with the voucher type

  6. When ready, the integration either approves or rejects the voucher and provide a mandatory comment that should reflect the events occured in the integrated system.

*Important note: The endpoint include a filtering option to request only new approval events, and this might be usefull when polling for new vouchers for approval. You should, however, include an unfiltered request once a while, in order to crossreference that your integration still is the current approver of the vouchers. Users in Go have on option of returning the voucher to Go (meaning you no longer have the voucher for approval), and the approval settings also support a mechanism for automatically returning a vocher after x number of days. If you integration is no longer the approver, you will no longer have access to perform any of the steps in point 3-6 above

Explanation of various rules and validations in place for the workflow

  • Updates to the voucher can only be made when your integration have the voucher for approval

  • Rejecting the voucher, will send the voucher back in the journal entry view in the user interface, in effect removing it from the approval flow and sending it back to the initial starting point

  • If your integration is the one and only approver, approving the voucher will mean that Go will attempt to post the voucher, returning any error messages back to you if the attempt to post fail. You then need to either update the voucher to correct accordingly and approve again, or reject the voucher if not.

  • If the approval setup on the client have at least one additional level of approval with editing rights, after the level of your integration, no particular validations will occur (validations related to posting the voucher)

  • If the approval setup on the client have additional level of approval rights after the level of your integration, but none of the additional levels have editing rights, validations related to posting the voucher will occur

  • If there is an approval level after your integration set up with a manager setting (department manager/project manager/subproject manager), this means that the system will attempt to send the voucher to the manager of the department/project/subproject set in the voucher header. The system will validate wheter the manager is a user with access to approval, returning an error message if not.