If you have ever done a job search in the SAP area, you might notice that recruiters often split vacancies into two categories: technical and functional.
Who are they, those technical and functional people?
Frankly speaking, a functional consultant is the person who deals with the functional configuration of the SAP system, with business processes in different areas. It can be Finance, Logistics, Authorisations and so on. On the other hand, technical consultants are those who deal with levels below the business process: programming, system administration and so on. Mostly this means ABAP and Basis people.
However, sometimes I saw requirements, and you could see them too, for “technical Finance consultant”. I will assume it reflects the limitations of a recruiter who probably does not know the market very well. If you learn what it means – feel free to comment below or write to SAP Expert.
In the meantime, I think that the functional/technical categorisation misses at least one important component. It is another level of consulting skills, less often mentioned: solution consultant.
Who is a solution consultant? This is a person who sees the question in a wider sense than it was asked, and presents a solution that answers the question and also gives customer the best experience.
I was recently involved in an interesting conversation about one particular problem in SAP Finance, and this can be an example of the differences between Technical, Functional and Solution consultants.
Someone asked the following question.
Our company in Canada has a requirement to store bank details with a length of 21 characters, consisting of a 12-digit account number and a 9-digit routing number. How can we achieve this in SAP?
To give you some background, SAP’s standard field for bank account number is 18 characters long.
The answers in the conversation clearly differentiate between approaches. Of course, I have re-compiled them slightly from the original words of the conversation.
- Functional consultant: The maximum length we can allow through OY17 is 18 characters. I don’t think that you will be able to store the full number there. Maybe, you can try to use the IBAN field that has enough length.
- Technical consultant: The standard field length is 18 characters. Can we write a functional specification and increase the length to the required 21 characters?
- Solution consultant: Your bank details consist of two components, which are independent of each other. One of them is the bank account number, and the very logical place to store this number is the bank account field. It has enough space for the 12-digit value. The second part is the routing transit number, which is a requisite of a bank, but not a specific bank account. You can store this number in the Bank Number field of bank master data. Alternatively, use the Bank Reference Key field in the vendor bank details.
Let’s now analyse the difference.
- The best solution proposed by the Functional Consultant is to use the IBAN field, which is available in SAP. However, this solution is not future-proof. Canada does not use IBANs at this moment of time. But who knows if the Canadian Government ever decided to turn in that direction?
-
never change
SAP standard objects!The answer provided by the Technical Consultant was to increase the length of the SAP standard field in the table that holds bank details (namely LFBK). However, this is not the only table that would require the change, simply because bank information is copied across to different tables when a payment program runs: REGUH, PYORDH and so on.It means that these tables will require changes as well. Together with them, all the programs that move data between the tables may require re-visiting and checking for the field definitions. Add here the necessity to revisit the DMEE engine structures that may use bank details to produce payment files. And because you are changing SAP standard objects, you risk losing support if anything happens with the system or data. This is a snowball, isn’t it?
- The answer from the Solution Consultant does not require any ABAP development in the system, and uses the fields specifically designed for the purpose of SAP. Bank Number field in bank master data in SAP is designed to hold the information for the local bank processing. It may be the same or be different from the Bank Key – you can control this within the transaction OY17. Value “1” in the Bank Key field of that transaction forces you to use Bank Number as the bank key, value “4” allows you to enter the value manually. The latter may be the case if you use another numbering convention for the banks in your system, like using SWIFT code or manual sequential number. If you need to have bank account and routing transit number to sit together in the output, it is easy to achieve with any method you use for the output creation.
A Solution consultant does not simply answer the question “how to put a 21-digit number into an 18-character field”, but gives the solution that allows storing data properly and is future proof.
Who are you: functional, technical or solution consultant?
