Standard workflow in Ibistic is defined by the approval hierarchy that you set up in "offices and users". This hierarchy is displayed sideways, as a sort of folder structure, where the top approver is placed to the far left in the image, and the other approvers/acceptors are in the offices to the right (as you create these offices). Please note that this model does not necessarily represent the traditional image that you associate with the company. This model represents the approval hierarchy
for the invoices/expense documents. Some companies would perhaps have an approver common to several divisions/teams in a company. It is also possible to have acceptors and approvers in the same office. These kinds of offices would probably be quite similar in both Ibistic and the organizational chart of the company - Tasha Teamleader would approve the invoices accepted by Beverley Barista. But in case Tasha can only approve items up to a certain limit, it would need approval from higher up in the hierarchy. This is where the "parent offices" come into play.
In essence, it would be a good idea to spend some time thinking about how exactly your organization and your approval hierarchy works, before setting it up in Ibistic.
In this article, you will get an overview of how the workflow functions, and what you would need to think through, to set up an approval hierarchy that reflects the needs of your organization. Here you will find a more technical walkthrough on how to set up offices
The acceptor is usually the person that has received the goods/services, and in principle, has the responsibility to check that the received invoice corresponds with what has been ordered/received.
The approver is often the superior of the acceptor, and usually has a formal authority to approve the purchase in accordance with the budget.
An acceptor has no approval privileges, which means that an invoice never can be transferred to the accounting system if the invoice has only been accepted. Some companies wish to only deal with approvers, in those cases where the employees have authorization to approve their own purchases within a limit. See the section for number of signatures to get an image of how the invoices will flow through the system in that case:
Accounting → approver → accounting.
The accounting user is the one who distributes invoices to the correct acceptor, and will transfer the invoice to the accounting system when it has been coded and approved. The accounting user can see all invoices that are currently in the workflow, regardless of where the user has been created in the hierarchy. These users are often also the admins of Ibistic locally.
The image below shows a typical setup of a hierarchy in Ibistic. You can see the main office, sub-offices, and some of the users. At the top of this image, you see the main office. All offices are shown as houses, and all users are shown as a person. The main office is placed a little bit to the left of everything else. This means that everything else is operating inside (or under) that office, including Montgomery Manager, Marketing, and Sarek Salesman. In this picture, we have opened the sub-office Sales. Within this office we find Sarek Salesman, Spock Salesman, and Tasha Teamleader. It is possible to create an office within this office as well, and continue in this way as much as needed.
In a typical workflow, Spock and Sarek Salesman will get the role as acceptor, and Tasha and Montgomery will get the role of approver. Unless you specify otherwise, accountants will receive all new invoices. It does not matter where in the hierarchy the accountants are placed. But in this case, we can assume that the accountants are in the office Accounting. Let's assume that an accountant distributes an invoice to Sarek Salesman. The moment Sarek confirms his acceptance, Ibistic will automatically start looking for an approver in the same office, and send the invoice to this person. In this case, that approver is Tasha Teamleader. When Tasha has approved, the invoice will be sent back to the accounting users for transfer to the accounting system.
Let's take the example above one step further, and say that Tasha has a limit to the amount that she can approve. She receives an invoice for £1100,- but she is only authorised to approve £1000,-. When she approves, the invoice will in this case be marked "approved (requires further approval)", and sent to an approver in the parent office. Only when Montgomery Manager approves, will the invoice be marked Approved, and sent back to accounting. The user at the top of the hierarchy should not have a limit to their authorized amounts, as large invoices naturally will end up with this user for approval.
Even if an acceptor in Ibistic is meant to do different things than an approver, it is really no technical difference between these in the system. Ibistic really sees an acceptor as an approver with 0,- as their amount limit. When you set up the hierarchy in offices and users, this can be good to have in mind. No matter how many people have accepted the invoice, it will not be able to be transferred to the accounting system. For that, you will always need one approval which covers the entire amount on the coding line.
Number of signatures
A site is set up to require either one or two signatures. This means that an invoice must fulfill the requirement for signatures before it is able to be transferred to the accounting system. If an invoice does not meet this requirement as an accounting user tries to transfer the invoice, the invoice will be stopped, and the system will display an error message. The accounting user will then have to distribute the invoice one more time to get the remaining signature(s).
Both acceptance and approval counts as one signature. But remember that the invoices will always need an approval which is authorized to cover the entire amount. If there is an amount limit, the invoice will continue on up the parent offices until it finds an approver which covers this amount.
Let's for a moment forget about any amount limits that you would like to apply. The easiest possible path for each setup can be described like this:
Requires one signature:
- Accounting → Acceptor → Approver → Accounting
- Accounting → Approver → Accounting
At the top bullet point here, it is only the Approver that is authorised for the full amount (Acceptor always has 0,- amount limit). So in this case, we meet the requirement for both number of signatures, and amount limit.
Requires two signatures:
- Accounting → Acceptor → Approver → Accounting
- Accounting → Approver → Approver → Accounting
Now let's assume we have several approvers in the main office. In the image below, all approvers are marked with a red box. If Tasha Teamleader isn't authorized to approve the full amount, the line will be passed on for further approval. It will be completely random which approver receives the invoice for approval in the main office, unless Tasha specifies someone.
If you wish, you may specify an office approver who will always receive invoices that arrive for approval in that office, unless anyone else is specified. There may be one such approver for each office. The approval of the office approver does not hold any more "weight" or authority than any other approver, when all other things are equal. Having an office approver merely means that invoices will be routed to this person by default. Read this
article to learn how to set up office approvers.
Authorised amounts per office
To make the administration simpler, it is possible to set up amount limits on all approvers within an office. Then it is not neccessary to set up amount limits for every approver. Having an authorised amount limit on an office, will affect all approvers in that office, and in all sub-offices. Read more about amount limits here
We often receive questions about why it is required to approve an invoice even if you know that it will require further approval from others. Why doesn't the system send the invoice directly to a person who is authorised to approve the full amount?
Imagine an organisation with 500 employees: Sarek Salesman has ordered an expensive strobelight for use in product demonstrations. It is well within the budget of the department, but none of the approvers are authorized to approve that much on a single invoice line. So let's imagine the invoice is sent directly to Chekov Chairman, without other approvals first. Chekov Chairman doesn't necessarily know who Sarek Salesman is, or why the expense is necessary in the first place.
But if Chekov is able to see that the item has been approved by two other approvers that he knows, he will be better suited to approve himself, or ask them if he has any doubts/questions. So the system lets you take advantage of the trust that exists between co-workers so that you more easily can make decisions.