Blogs
-
Ariba user management and approvals done the smart way
-
Building Ariba documents approval flows with focus on purchase requisitions – do’s, don’t s and corporate
practices from own experience
- Building Ariba documents approval flows with focus on purchase requisitions – dos, don’t s and corporate best practices from own experience CONTINUED – Edits, Changes, Filter Rules and Approvable Edit Rules
Ariba user management and approvals done the smart way medium.com
SAP Ariba is quite complex software giving customers high degree of freedom to create users according to their liking and respecting most of the requirements coming from the business and existing IT infrastructure. Despite very complex possibilities and flexible settings, the process of user creation and maintenance can feel cumbersome, lacking some crucial features and, let’s be honest, not very user friendly. Same thing is true about creation and updates of Ariba approvables lookup tables.HOUSTON, WE HAVE A PROBLEM…
It is not uncommon, especially in large corporations, that Ariba admins either from business or IT side get overwhelmed by the sheer volume of requests and changes they need to process to keep up with the latest developments in those areas and rollouts are not any easier. The bigger the company and Ariba usage, the bigger the issue. The fact that the import tasks are based on manually created csv files does not help. Easy to solve you say — give the rights to the people, countries, decentralize! Well, not so fast. Most of those who try this approach in large corporation environment fail miserably. To make sure that the import tasks won’t lead to one big mess in the system, admins needs to be pretty good in working with csv files and understand in detail all the intricacies of Ariba files structure. Do you think it is possible to train twenty people to this level, let them work in parallel with the imports and have a good night sleep knowing that everything will work just fine? That is very unlikely. At the same time Ariba does not allow you out of the box to effectively limit admin rights to manage only a particular localized set of data like specific modules, groups, countries, approval tables etc., meaning that most of the work remains in hands of handful ‘’lucky’’ ones — the central administrators.LIGHT AT THE END OF THE TUNNEL
Have you ever heard “When you find no solution to a problem, it’s probably not a problem to be solved but rather a truth to be accepted.”? Well maybe not in this case. What if I would tell you, there is a solution. Because there definitely is one. ADAPPT Solutions created software that can help to solve just that and much more. ADAPPTool is cloud-based software delivered as service meaning you need no additional hardware resources and data are accessible pretty much anywhere, anytime. It creates csv files precisely in the structure Ariba expects and loads them to Ariba automatically via Cloud Integration Gateway. It allows you to actually create local admins, who are limited in their rights to manage certain modules, countries etc. Thanks to a tagging system you can let certain ADAPPTool admins to manage users belonging only to certain module or country, let some of them manage only approval tables and even limit which part inside one specific lookup table belonging to a given country or organizational unit they can edit. You can allow them to assign only predefined groups and do so only for specific organizational units. ADAPPTool also ensures there are no invalid data in the loaded files that would be simply ignored, or even worse, result into an error. This would be definitely an issue for decentralization, but let’s admit it, even experienced admins can make a mistake once in a while when files are created manually. ADAPPTool doesn’t allow that. Apart from the fact that you can avoid any errors by creation of predefined data directly in the tool, it can be fetched also from directory services like Active directory from Microsoft or Ariba APIs (plants, suppliers etc.).
Decentralization brings benefits also to your internal customers themselves. Since the tool is available 24/7, no one needs to wait until the central admin 7 time zones behind wakes up to address the issue directly in Ariba. Local ADAPPTool admin can address this right away. Central admins can also avoid the familiar back and forth with the change requestor often necessary to finally figure out what is their idea about the resulting behavior or settings. No one also needs to ask about their current settings, because it is possible to check this anytime in the tool. Where Ariba gets plus points for complexity and wide range of possibilities, it loses points for user friendliness and overall UX. There is no way to get a nice comprehensive overview of particular Ariba user. You need to go through the “fun” exercise of clicking around, opening several places and tabs in Ariba UI or download several csv files. Ariba user management and information about individual users is very fragmented and there are way too many places to search for information about particular user. To see the basic information you have one tab, to see the rights assigning groups another tab etc. ADAPPTool fixes just that offering single 360° user profile overview showing all important information including user’s organizational data or assigned groups. This significantly simplifies user creation and editing. The tool can help with wide variety of user management issues. Let me give you an example. What if you have only one Ariba base currency like USD or EUR, but your company is present all over the world? Makes users limits maintenance complicated, right? Wrong! ADAPPTool can take exchange rates from Ariba API and creates the files sent to Ariba already with recalculated amount in the base currency. ADAPPTool local admins don’t have to care — they can set the limits in their local currency. Simple as that. But wait, there is more. What if you got a new employee? He should receive standardized access rights for Ariba. You have to create few csv files and load them to Ariba in a certain sequence, that is clear…Wait a minute — what if I’d tell you that this Ariba user can be created automatically? Yeap, ADAPPT API can do just that. If there is a new user created or updated in your directory, it is possible for ADAPPTool to pick this up.
ADAPPTool user management for SAP Ariba
Users created in ADAPPTool can be then, same as f.ex. any group coming there from Ariba API, used in any type of approval table (purchase requisitions, good receipts etc.) or in any particular approval node. No more confusion about not working approvals only to find out later that the user was not even created yet, there was a typo in his ID and so on. You can also manage your approval tables in much more effective and user friendly way. Use modern features like drag and drop to rearrange order of your approval tables rows or simply copy some of the rows and slightly adjust only to save even more time.GET IN TOUCH
To get a better idea how easy to manage can those processes be thanks to ADAPPTool, check short two minutes videos on Youtube dedicated to Ariba user management and approval lookup tables or visit ADAPPT webpage https://www.adappt.solutions/. Still not convinced? Feel free to reach out to ADAPPT via e-mail info@adappt.solutions to ask for free live demo or consultation. Guys at ADAPPT approach each project individually and take advantage of the flexible nature of the tool to make sure that the final setup suits your needs as much as possible. Try it out and learn how much time you can save and spend on more meaningful tasks. If you ever wondered what are the best practices and the most effective way to approach Ariba user and approvals management, the search is over. It is never late to upgrade and change what doesn’t work. Make your life easier — migrate your existing users and approval tables now and relax.Building Ariba documents approval flows with focus on purchase requisitions – do’s, don’t s and corporate practices from own experience medium.com
Building Ariba documents approval flows with focus on purchase requisitions – do’s, don’t s and corporate practices from own experience - PART I: Approval Rules The possibilities how to set up purchase requisitions (PR) approvals in Ariba are manyfold. Sometimes you might wonder what are the best practices, what are the possibilities and how to satisfy your business needs. Wonder no more, I got you covered. In this article compiled from experiences of several big multinational corporations I will talk specifically about PR approvals, but the general logic how thy system works can be applied also for other types of documents – good receipts (GR), supplier data updates (SDU) for catalog uploads and many others.Let’s start with the basics – how to access the release strategy workflow. In top right corner of your screen select “Manage” and then “Approval Processes”. Then select relevant Approvable Type. In our case it will be “Requisition”. Make sure that you are in the right realm for given Approvable Type. For purchase Requisitions it will be the child realm. You can create new or just click on the Title of existing one to adjust. When looking at specific flow already, make sure to click “edit” in top right corner so all the below mentioned options would be visible for you.
In this article we will focus on “Approval Rules” tab which defines the main flow for given document type. Approval Process Diagram shows you all the approval nodes that are set in your system por particular document approvable type. That obviously doesn’t mean that each of the nodes will be relevant for every purchase requisition. This will depend on the conditions set for given node, uploaded approval lookup table behind the node, should you decide to use it and on the PR proprieties.
You can create separate nodes also for different scenarios e.g. – create one to put RPA which should add freight to the PRs, specific nodes for freetext/ad-hoc requisitions for buyers to check the pricing and the supplier and so on.
The nodes themselves can be organized sequentially in series, meaning the document needs to pass through approval in the previous node before it can be sent for approval to the following one, or in parallel, meaning approvers in both nodes need to approve so the document would progress to the next approval step.
Let’s check following areas you can find in the UI for each approval node: Conditions and Action.
CONDITIONS
While setting up conditions, you can work with logical operators like “None Is True” or “All Are True” to define how the conditions should work together. Some of them will need to be satisfied together, for some of them only one of the cases will be enough to trigger the desired action. You can build quite complex structures of conditions with their own sub-conditions etc. You can use those logical operators to connect conditions consisting of some predefined system conditions like “Requisitions Has Supplier”, “Requisition has items without a supplier”, “Approvable Has Ad-Hoc Line Items” or so called “Field match conditions” where it is up to you to select the relevant field out of hundreds of available ones (this task can get quite tricky) and define fields’ values that will trigger the approval (for example procurement unit needs to be XY or PR amount must be greater than certain threshold). User level maintained PR approval limit is relevant for approvals too. You can set up for example condition saying that the node will be relevant only and approval will be necessary only if the amount exceeds approval limit of the requester.ACTION
As soon as you set up the Conditions steering relevance of each created approval node, you need to decide on the action which should be performed in case the node will relevant for given PR. You have 2 options. Either you decide to “Add Approvers and Groups”, in that case you are presented with dropdown of choices about who should be added as approver with additional possibility to define which Group should be included in the approval or you opt for usage of Approver Lookup Table which gives you far more flexibility.Approver Lookup Tables
Approver Lookup Table option obviously expects you to define content of such a table. It should be created in csv format file and you can select requisition proprieties which will be relevant for PR approval relevance assessment. You can do this by looking for relevant Field Names after clicking on “Add column”. You can then freely choose the Column header name which wil represent selected field in your csv table. For each field you can also select the Operation, in other words if the field value should be exactly the one you specify to trigger the approval, if it will be enough that the value starts wit the root you specify or if it should contain some part of the expression you specify etc. For amounts you have a possibility to choose from the expected selection of equal, greater, smaller, is (not) null etc.Frequently used Field names are usually those corresponding to plants, internal orders, requestors ID, amounts net or gross, supplier ID, procurement units, commodity codes, GL account, account category etc. For supplier data update type of approvable it could be Catalog subscription names where you can take advantage of some, e.g. country specific, naming convention to route catalogs to appropriate approvers. Technically to define for the system that ,considering given propriety/table cell, all values should be considered valid, fill in “*”, same as you would in SAP backend software. In case that the system will be presented with a requisition with proprieties that will match the defined combinations in the Approval lookup table, the PR will be considered for approval. There are several Approver Type Fields in Action area, where, depending on where you put your tick-mark, you can define different types of approvers to be involved in particular table a) Group – one of the groups created in your system. Advantage is you don’t need to change the approval tables all the time, but you need to maintain which users will belong to this group. Another option is b) User or c) Approver list. In both b) and c) you define in appropriate lookup table column ID(s) of Ariba users who should approve. The only difference is that for User you select only one ID, but you can put multiple to Approver List and separate them by colons. All users in the approval List will be asked to approve, but approval of the first one doing this will do. You can also combine User and Approver List. There is no rule that Approver List needs to contain more than one user ID. Hence if you fill-in both User and one user ID into the Approver list you can achieve a situation where both will have to approve in the given scenario.
Option d), Approver Field Path is used to define approvers not based on specific user ID, but rather based on specific role in the process. For example filling in Approvable.Requester.Supervisor will involve specific PR requestor’s supervisor maintained in the requestor’s user profile. For each defined combination of PR proprieties and corresponding approvers you can define a Tooltip. In other words a text message which will be delivered to the approvers informing them about why they should be involved in particular PR approval.
TIP: Translations of the tooltips can be either a) written in the local language directly in the lookup table or b) there can be translation of given tooltip to multiple languages. To achieve that you will have to reach out to Ariba support and submit the translations. The syntax usually starts with "@" and it is filled in the usual tooltip place in the approval table. E.g. @approve as supervisor” would be displayed to approvers as “Approve as supervisor” to users with English as system language and “Als Supervisor genehmigen.” For users with German. if you intend to use special characters like “ü” or “í” for Ariba tooltips, make sure the csv is encoded in UTF-8 format, otherwise they might not be displayed properly. If the UTF-8 itself does not help, you can fill-in HTML code signs instead. For example “Proszę” to be displayed as “Proszę” to approvers in polish etc.
Column Required which contains values TRUE or FALSE defines if for given rule, i.e. lookup table row, approval will required or if the involved approvers will be only informed as “watchers”
TIP: Approver lookup tables work with top-down logic, meaning Ariba will start on the first row and will proceed until it finds a row with a rule applicable for given requisition. This effectively means that you shut put more specific special rule on top of more general ones so they will have a chance to be applied. If the system will find the more general rule first, but for the given situation there is also another applicable more specific rule, it might assign different approvers then intended. Best practice is therefore the put most specific rule high and to create one general fallback rule on the last row. For purchase requisitions this could mean that you fill-in all columns with * to say that the row is applicable for every purchasing unit, commodity code etc. and put user’s supervisor to Approver Field Path. That way you make sure that every PR will have appropriate approval. In case there is no relevant rule/row, systems go through the approval table and even though the approval node was triggered because the conditions were satisfied, no approval will be assigned. It is also possible to tick mark “Add Multiple Approvers” in the Action. System will then add approvers from all relevant rows which will be found, incl. the fallback rule of created.
TIP: But what if you want to combine both approaches and trigger multiple relevant approver table rows and at the same time define a fallback last row rule for undefined general scenarios, with one little catch - that you don’t want the fallback rule defined approver to be involved together with above defined multiple specific approvers in case system finds any? Solution is to create parallel, almost identical, nodes. Alle conditions will be set the same as well as the loaded approver lookup tables. The only differences will be that for first node you tick-mark “Add multiple approvers” and won’t include the fallback rule in the table and for the second node you leave this field unchecked so system will always look for the first valid hit only and add the fallback rule to the approval table. If multiple specific rows will be valid for given requisition, then based on first approval node system will assign multiple approvers from different rows. In the second node Ariba will find only the first valid row, but since the approvers should not be duplicated, PR approval will involve this approver only once in the flow. Fallback rule is I the second table, but since there is higher positioned special rule, system won’t get to the fallback. One valid hit was already found higher in the table so Ariba won’t proceed to the bottom of the table. In the first node the fallback rule is not set at all. If there is no special rule relevant for given PR created, system won’t find anything in the first approval node table, where no fallback rule is defined, which means it won’t find any special rule in the second, basically duplicated, approval table either (remember – they are both the same difference being only the fallback rule) and will go all the way down to add approver from fallback rule present in the second approval table, e.g. user’s supervisor.
To involve Third Party users in the approval process, you can add column with header “PasswordAdapter” to the approval table. In case you assign only enterprise users on a given row you don’t have to fill-in anything there. If you decide to include IDs of your third party users, fill-in “ThirdPartyUser” to tell Ariba where to look. It is not possible to combine users of both types. PasswordAdapter is for Ariba distinguishing factor for users – you can have user with exactly same ID as soon as there is this distinction between enterprise and 3rd party one represented by PasswordAdapter. What if you would like to involve in the approvals not only requestors’ supervisors, but in case of higher amounts also supervisors of the supervisors? That is when the Chain rule comes into play. Directly to the right from Title “Approval Rule Editor” there is an inconspicuous link called “Action” (Different from “Action” further down on the page). You can click on it and tick-mark “Chain this rule”. You will then get right underneath two tabs: Base rule and Chain rule. For the base rule you can then select action” Add supervisor” and for Chain rule “Add supervisor of Approver”. The chain will then respect Spend Limit value maintained for involved users acting as supervisors. TIP: Few tips about adjusting and creating csv files in Microsoft Excel. Using Excel for working with csv files can much more convenient then text editors, because with the right settings, the comma separated values populate the right cells and the intended structure of a table is kept – values belonging to the same column are one on top of the other etc. which is not the case while opening csv files in text editor. However be careful that the file saved in excel is really what you want to load into Ariba – for example make sure you did not lose leading zeros for values where applicable and that the csv is still encoded in UTF-8 to not get into troubles with special characters.
TIP: If you want to bring approver lookup tables maintenance to the next level, you can use one of the third-party applications, for example Ariba ADAPPTool from ADAPPT SOLUTIONS. Adapptool allows creation of approver tables in a structured manner with data coming from your directory services or Ariba APIs, making sure you will never input invalid data resulting in unfunctional approval flows (Ariba doesn’t have built-in validation for the csv uploads). It is also user friendly and allows to limit application users’ rights to specific country, Ariba module etc. which allows you to decentralize the workload coming from the frequent manual csv editing and upload requests. It also means that the users don’t need to be as highly trained as if they should perform those tasks in Ariba. It is not a good idea to let twenty users like that perform changes in the system at the same time. They also don’t need you as central admin to make the requested edits, there are not back and forth clarifications about what they actually request so the change is processed faster, and they also have constant overview of the settings without having to reach out to central Ariba admins. You can use modern features like drag and drop to rearrange the priority of created approval tables rows, copy them to be adjusted and more. The resulting csv files are then automatically loaded to Ariba via CIG. The tool allows similar approach to Ariba user management, offering some additional features Ariba lacks, like 360° user profile overview, approval limit recalculation to base currency based on exchange rate, automated user creation of user when he is created in your Azure Active Directory or HR system, ability to replace leaving user everywhere - for every user having him as supervisor or in every approval table he is involved in one click etc. Your existing user base can be migrated pretty easily.
I created this article since I still remember how hard to figure out some of the settings (that are now crystal clear to me) in the approvals area were. I hope that this post helps those who struggle during their initial system setup, wondering about the basic options, but my ambitions is also that even some of the veterans could hopefully find something new and useful to be implemented for them too.
Cheers!
Adam
Building Ariba documents approval flows with focus on purchase requisitions – dos, don’t s and corporate best practices from own experience CONTINUED – Edits, Changes, Filter Rules and Approvable Edit Rules medium.com
This post intends to supplement the previous Approval Rules one, focusing now on the settings outside the primary approval flow explained there. To understand the problematic and Ariba documentation better it is very useful to understand the distinction between “edit” and “change” of approvable document the way Ariba does. For Ariba, “edit” describes changes done to the document while being already in the approval process in status Submitted. “Change” on the other hand, describes a situation where the PR was created and approved, PO was generated, but to make some additional changes the original requisition has to be “changed” and a new version of the PR needs to be generated. Changes apply for documents in Ordered status.APPROVABLE EDIT RULES
Very often Ariba admins get confused about what is the difference between “Filter Rules” and “Approvable Edit Rules”, but in reality the distinction is pretty simple: Approvable Edit rules influence how the approvals will behave when certain conditions are met. They determine whether users can modify (“edit”) an approvable, e.g. purchase requisition, after it has been submitted, meaning they are applicable for documents with status ‘’Submitted’’. The conditions can be built the same way and with the same logic as for Approval Rules. One of the possible sub conditions could check if someone in the approval process changed some predefined fields in the PR. The conditions can be combined so another sub condition could specify that only authorized users with a specific user group assigned are allowed to change the fields without retriggering the approval. Those could be buyers, tax managers, charge managers etc. You can then define corresponding action to be triggered if the conditions are met: should this edit have no effects, should the PR be resubmitted , reapproved or should the edit be forbidden altogether.· Edit with resubmit — approval engine starts entire approval again from the beginning
· Edit requires reapprovals — will cause that a re-approval will be needed on the approval node that is in the flow after the node where the change was made.
E.g. screenshot below — Budget Approver approves and Audit Buyer approves afterwards. Budget approver realize only later that there is a need to change something and edits the PR. The engine will then go back to Audit Buyer to reapprove. In other words this action can invalidate of some approvals which were already done.
If the user making the edit is not in the approval flow at all, this would then take the approval back to the first approval node almost like in the edit with resubmit.
· No edit possible — edit button is not visible.
You can also notice buttons “Move Up” and “Move Down”(Do not forget to be in edit mode). This allows you to change order of individual Edit rules. Similarly as for the approver lookup tables, Ariba prefers and applies first the rules which are higher than the others. In practice when you decipher behavior of certain approvable approval process, you need to start looking at the rules placed higher to see if they are applicable and only then proceed to the next Rule. This Rules hierarchy is important f.ex. in case that an approver would have roles/groups assigned in multiple rules — that is when the hierarchy of the rules would be applied.
FILTER RULES
You can use Filter rules to filter the approval requests generated by the approval process. Same as for edit rules, the order of filter rules is important. Only first valid will be taken into consideration. For example, you can add a filter rule to remove duplicate occurrences of the same approver or remove requestor himself. You can also Remove approvers and auto-approve the changed requisition if the quantity or amount on individual line items has not increased and there were no changes to additional fields you could have specified in the rules. In case user or group appears in the flow multiple times, you can decide to keep only the first or only the last occurrence. See the example below: Budget User is twice I the flow without additional filter rule:
If you decide to Retain First Approver — this will keep the user or group only in the first node where they appear:
If you decide to Retain Last Approver — this will keep user or group only in the last node where they appear:
TIP: What if you want to skip requisition approval altogether, for example when PR changed, version 2 of the requisition was generated as a consequence of this, but you would like to keep the approval in place only for requisitions changed more than certain threshold? Technically speaking the question would be how to skip certain approval nodes. Business often asks for this in connection to price changes. Apart from creating approval node conditions as usual, you can add the condition saying that the original conditions are valid only for the first version of the requisition. There is predefined field available to do that. You can then create another set of conditions for this approval node which will be relevant for V2 and following versions of requisitions by adding the corresponding field to conditions defining that version value should be 2 and higher. After that you can add to those new versions conditions a condition demanding that total cost change in percentage needs to be higher than let’s say 10% for the approval node to be triggered. Similarly, you can create condition, working in tandem with the percentage one, specifying that the difference between current and previous version amount in absolute values needs to be above certain threshold. Unfortunately, similar fields comparing two versions of purchase requisition to be used in Conditions to set this up have to be, at least at this point in time, created by Ariba support, so you will have to reach out to them.
Hope that this helps you to understand the approvals settings and the complexity behind better.
Cheers!
Adam