SAP Bank keys for North America - Implementing banking & electronic payments

I decided to write this blog post because over the last 2 years or more, I have been working on a number of projects / clients where I had to take over or use North America SAP Banking configuration of prior SAP consultants (in many cases "just configurators"). Unfortunately, I have seen a series of recurring mistakes being done by the majority of them because of the lack of knowledge of the North American banking system and common practices (for USA and Canada). Many of these consultants were either local or offshore and from different Big 5 consulting / implementation partners and some smaller SI's as well.

These series of recurring mistakes are due to the lack of knowledge of what it is a "Bank Key" in SAP or what it should be and what it is used for.

Bank Keys in SAP are used for two different things and places:

• Identify our own House banks where our own (Company's) bank accounts are registered / created
• Pre-requisite piece of Master Data information to be able to register Banking information for either Vendors and/or Customers to be used for Electronic Payments.

Bank Keys in SAP are created by country and their number will depend on certain rules and conventions that are specific to that particular country that you are creating the bank key for. One country will not use the same Bank Key and naming convention than another country. It will all depend on that country's Financial System. The Bank Keys are then going to be used to be able to perform and route electronic payments, if you do not create your bank keys properly, your electronic payments will not be routed properly or will be rejected by your bank because you are not providing the right and expected information to your bank.

Canada Bank Keys

Canadian Bank keys, look similar to US bank keys, but are completely different one to another. Canadian Bank keys are made of 2 different pieces of information, the first 4 digits represent the Financial Institution number assigned in the Canadian Banking / Financial system with a leading zero.

Ex.

• 0003 - Royal Bank of Canada
• 0004 - TD Canada Trust
• 0001 - Bank of Montreal
• 0010 - CICB - Canadian Imperial Bank of Commerce
• 0002 - Scotia Bank
• 0006 - National Bank of Canada

What is a Routing Number?

A routing number identifies the financial institution and the branch to which a payment item is directed. Along with the account number, it is essential for delivering payments through the clearing system.

EFT Routing Number

An Electronic Fund Transactions (EFT) routing number is comprised of a three-digit financial institution number and a five-digit branch number, preceded by a "leading zero".

Example : 0XXXYYYYY

•     0 : Leading zero
•     YYY : Institution Number
•     XXXXX : Transit / Branch Number

The electronic routing number is used for routing electronic payment items, such as direct deposits and wire transfers. 

Example of an SAP Bank Key record for Canada

As you can see, they are created by Country Code (Ex. CA, US or MX). Then the Bank Key is numeric for Canada as described above.

Then you have the Bank Name and address information, SWIFT Code (8 or 11 long) and the Bank Number for Canada is equal to the Bank key number entered.

The Bank Key should never be defined as the "SWIFT Code", there is another field to define the SWIFT code.

Below is a Void cheque image for a Canadian type of cheque where from there you will be able to pick the right routing information for a given Bank Account or Vendor information for you to properly create in SAP to ultimately execute electronic payments.

USA Bank Keys

The routing number (a.k.a. RTN or routing transit number) is a 9-digit number that serves to identify the specific financial institution responsible for the payment of a negotiable instrument. 

In same cases in the US it is also called ABA routing number (American Bankers Association #).

Where is the routing number on my check?

The sample graphic below shows where the routing number can be found in the bottom left corner of your checks.

Routing number format

The routing number consists of 9 digits:

The ABA Routing Number is of the form XXXXYYYYC

•     XXXX is Federal Reserve Routing Symbol
•     YYYY is ABA Institution Identifier
•     C is the Check Digit

Read more about the Routing number at Wikipedia website.    

Example of an SAP Bank Key record for USA

What is a SWIFT Code?

SWIFT code (also known as ISO 9362, SWIFT-BIC, BIC code, SWIFT ID or SWIFT code) is a standard format of Business Identifier Codes approved by the International Organization for Standardization (ISO). It is a unique identification code for both financial and non-financial institutions. (When assigned to a non-financial institution, a code may also be known as a Business Entity Identifier or BEI.) These codes are used when transferring money between banks, particularly for international wire transfers, and also for the exchange of other messages between banks. The codes can sometimes be found on account statements.

The SWIFT code is 8 or 11 characters, made up of:

•     4 letters: Institution Code or bank code.
•     2 letters: ISO 3166-1 alpha-2 country code
•     2 letters or digits: location code
•         if the second character is "0", then it is typically a test BIC as opposed to a BIC used on the live network.
•         if the second character is "1", then it denotes a passive participant in the SWIFT network
•         if the second character is "2", then it typically indicates a reverse billing BIC, where the recipient pays for the message as opposed to the more usual mode whereby the sender pays for the message.
•     3 letters or digits: branch code, optional ('XXX' for primary office)

Where an 8-digit code is given, it may be assumed that it refers to the primary office.

Business Partner

Once the Bank Keys have been created in Tcode FI01 (Create) 02 (Change) 03 (Display) or in Fiori App "Manage Banks", they can be used in the assignment and definition of our own House Banks and also for Business Partner (Vendor / Customer) Banking data under the "Payment Transactions" BP tab.

A given Business Partner can easily use the same Bank Key as our own House Bank if this BP also has a Bank Account at our own same Bank branch. In that case, you do not need to create a 2nd bank key, as we are talking about the same record that will be used in both scenarios.

As you can see in the image below, Bank Key CA - 000300002 needs to be previously created before being able to assign it to Business Partner 1000009. (In some cases, it can be created while doing the BP creation but you still need to provide all the same Data (Ex. Country, Key, address, SWIFT, Bank Number).

Common Mistakes done creating Bank Keys

When defining Bank Keys, I have seen several mistakes done by SAP resources that have all sort of downstream impacts in the system configuration and later on while interacting with the Banks:

1. Defining the Bank Key using a SWIFT code
2. Defining the Bank Key as consecutive numbers
3. Thinking that the Bank Key that is used by the House Bank is different from a Business Partner Bank Key
4. Modifying SAP standard country settings to force bank key of a different length or type (alfa or numeric)

• Defining the Bank Key using a SWIFT code - A NO, NO !!!

Not knowing what should be the Bank key or what a bank key looks like for a given country, has led to many SAP Finance resources to define them using the SWIFT codes as if it were the Bank Key. This in most, if not 100%, of the cases is never correct. The Bank Key is normally used as a key piece of routing information by the banks to execute payments and most of the standard DMEE's (Electronic Payment files) map and use them at a certain point inside the DMEE. 

If instead of providing a numeric Bank Key, we provide the SWIFT code, then the bank will reject our payments and we will not be able to pay vendors.

Below you will see a screenshot of a configuration done by a Consultant from a Big SI (really big) that because he/she did not know how to define properly a Bank Key for our own House Banks, he/she had to end up hardcoding in the DME config the Bank Key because the Bank was rejecting their payment files. Standard SAP DME config passes the Bank Key created in Tcode FI01 (Table BNKA), this was due to him/her using the SWIFT as Bank Key for the House Bank, which is absolutely wrong.

He/She ended up harcoding and putting a DME condition (IF) based on the country, to pass a constant. That should have been the Bank Key that is is "hardcoding here" if he/she should have done it properly from the get go.

• Defining the Bank Key as consecutive numbers

At another client, I have seen Bank Keys being defined as consecutive numbers (Ex. 1, 2, 3, 4 ...) without any logic and without respecting what it should be used for that Country as per the Bank Financial System. This will also generate an issue like in the above previous example when passing routing information to the bank in the DME files resulting in payments being rejected.

• Thinking that the Bank Key that is used by the House Bank is different from a Business Partner Bank Key

As mentioned before, Bank Keys for House Banks and Business Partners (Vendors / Customer) are and should not be different from one another. They are a piece of Master Data (Bank Master) that can be used by either of them. 

At this other customer, the consultants did not advise the client properly, and the client was defining a series of Bank Keys for own House Banks and another one completely differently for Business Partners. This is another big mistake, also done by the same Big SI.

• Modifying SAP standard country settings to force bank key of a different length or type (alfa or numeric)

I have also seen in some of these prior customers, that these SAP resources have modified standard SAP delivered country settings (Table T005) to force and allow them to entry Bank Keys that are different in length to the one that is supposed to be entered for a given country or to enter alphanumeric Bank keys when the Key should be numeric. 

Modifying SAP standard delivered country settings should be a "NO-NO !", unless you really have a compelling reason to do so. While working with some Banking Directory Services, you might have to do it, but in most cases it is part of the instructions that they provide you; so you have proper justification for it.

Data Migration for Bank Keys

Bank Keys are a pre-requisite Master Data object before being able to create Business Partners, in that you are planning to perform electronic payments to Vendors / Customers (BP's). You need to build and have this data prepared and loaded before starting to create Business Partners.

Also, our own House Banks will need to have these specific Bank Keys created previously so then you can configure the House Bank/s (in Tcode FI12_HBANK). So you will need them as part of your configuration. Normally these are just a few (3, 4 or 7, 8 records) that you can create them manually or you can build yourself a small LTMC file just for your configuration. 

S/4 HANA Data Migration Cockpit has a standard Data Migration object called "Bank Master" that can be used to migrate these Bank keys, either for your configuration or for your BP's. In most of the cases, you will end up with 2 different files. 1 small one for your config that you will also have to upload before you transport your House Bank and migrate (upload in S4) your Bank Accounts and then a 2nd file which should be bigger that will contain all the Bank Keys needed for your BPs, as they are a pre-requisite. 

Understanding this is really key to have a successful Data Migration approach for Business Partner Bank Keys that should be completely different for the Bank Keys associated to your House Banks. Unfortunately, I have also seen a lot of people confusing them. 

Banking Directory Data services 

Dealing with Bank Key Master Data and having clean Bank Keys data is key in case you want to implement Electronic Payments in SAP and avoid payments being rejected. Collecting these info from your Vendor (or Customers) should be part of your Business Partner creation process, but if you are doing it for the 1st time, collecting the data from them and also having the Bank Keys uploaded in the system could be quite an effort.

Having payments being rejected by your bank, will cost you money as banks charge you for rejected payments and also could create issues with your vendors because they will not receive your payments  on time and eventually they could cut services or goods delivery if you do not pay promptly.

There are certain companies and services out there in the market that can sell you Bank Directories that can be uploaded in SAP and will be ready to consume. Same as you would upload the Data with the Data Migration cockpit or maintain it manually.

Some of these services, are quite costly, but really convenient.

SWIFT Bank Directory: quite expensive but so far the best one and easy one that I have used. Comes with a file ready to load in SAP with standard SAP Bank directory upload program. They provide Worldwide financial institutions information, not just for 1 country.

Accuity Bank Directory: expensive as well but require the installation of custom Abap programs to upload in SAP (provided as transports by them). Their information is not that easy to deal and upload compared to SWIFT. They also provide Worldwide financial institutions information.

Canadian Payment Association (CPA): Their service is called "Financial Institution branch directory". I have not used it for a while, but they used to have a file ready to be uploaded in SAP with standard programs, same as SWIFT. They seem to only provide Canadian banks info, not worldwide as SWIFT or Accuity.

If you are looking to find some individual Bank Routing information for free out there on the Internet, there are some pages that give you (one at a time) information that you could use as Bank Keys info for Canada and US.

http://canada-banks-info.com/

https://us-banks-info.com/

Defining your Bank Keys properly is KEY for your House Bank configuration and your Electronic Payment setup in SAP and ultimately for a successful banking implementation. 

Consultants that have the right banking knowledge for the country and market that you are trying to implement is vital for this. Not all consultants know about this and end up taking the wrong decisions that have many ripple effects down the road. In the majority of those cases, those consultants never stick around long enough to see the unintended consequences of their lack of knowledge and experience in the subject.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

From customization to standardization in SAP, how to avoid falling again into traps from the past

The world of large ERP implementations where we were starting from a blank page and doing several months of blueprinting sessions are far gone. Organizations do not have that luxury and those types of budgets anymore. Now we need to focus on Rapid deployment, lean and standard processes.

How were we used to do SAP implementations in the past?

We used to do large implementation projects with 7, 8 or 10 Consultants for Finance, another similar number for Materials, Sales and so on. At the end all adding up close to 100 hundred SAP Consultants easily. And we were not implementing SAP at Walmart, just at a normal company …

We would do 4 to 6 months of Blueprint sessions where we would look into every single thing out there in a process and configure SAP accordingly and mimicking the legacy process into SAP configuration. We would configure even the smallest things that SAP allows us to configure (Ex. Optional or required fields on Finance Posting Keys, changeable fields on a posted Finance document, just to name a few of those ones out there, but the list could be big). All because we had the time and budget to do it and an “open bar” policy for these type of things. And these were the standard things that SAP configuration allowed us to do.

Then we would look into all sort of business requirements that were not standard SAP and we would do custom developments for them. Tons and tons of lines of Abap code for custom reports, custom Transactions, customize SAP standard delivered screens and even customize and append Standard SAP Tables because the business had a requirement.

(Before you jump, I would never, ever recommend customizing an SAP screen or appending a standard SAP table …)

This would lead to months of development and testing and re-testing, many times even all the way up to the cut-over weekend because some of those developments were complex and intricate. In some cases putting more than one go-live at risk ( … I am sure you can relate to some of these examples and you are now remembering some cases in your mind …)

Then after go-live, you would continue doing new developments over the subsequent years whenever the business would come up with a new requirement. Instead of analyzing the situation, trying to find solutions within standard SAP and adapt the process; NO we would develop something new. A new “Z” Transaction and new “Z” field and new Z something.

You end up after a couple of years of following this approach in a complete ZAP environment (SAP with Z), where you do not recognize the system anymore. Everything that the users do starts with a Z, transactional or reports, all would start with a Z.

Several years ago, I remember working for a customer; where it took me a while to adapt to their SAP system. You would click SAVE and a bunch of things were happening in the past that would change the complete behavior of the system. Screens that had extra fields that you would not recognize because there were not part of SAP standard. And the worst thing is that most of this was not documented anywhere because it was done many years ago and they did not have a lot of discipline. It was in someone’s head that luckily could still be around or not. This client had been in SAP for 15 years at the time. Coming easily from SAP versions 3 or 4. The amount of custom at this client was insane. (And it is still that way because they are still using their old ECC).

Another client, in complete different industry…. We went to do an assessment to implement S/4. They too have been using SAP for ages … We were analyzing their processes and we asked them to provide us the list of Z Tcodes and Z reports to analyze them and see which ones we could replace with standard SAP. They came up with more than 150 just for Finance, Materials and Sales. 150 custom developments are a lot. Someone would say, I have seen more than that. Oh yes, I have seen more than that too. But it is still a lot …

Some of these clients they have even customized and created their own entries in the IMG, with custom IMG options to maintain all these extra customizing that they have created over the years. Customized the IMG !!! A bit too much.

And I have a couple of other similar examples too of big companies but not as big as a Boeing or Walmart.

How much does it cost to maintain all of that? A lot !!

What is the impact of having all of these undocumented solutions?  It cannot be measured

Then you bring outside people (like me at one of these clients) and for someone that knows SAP, all of a sudden, he needs to learn it all again. That has a cost for organizations too that have to pay for that long ramp-up period.

These has other consequences too. All of these clients cannot do upgrades anymore because it would cost them a fortune; more than doing a brand new implementation. Some are still stuck in versions 4.6 or 4.7 that are way out of maintenance from SAP. This client even ended-up hiring a company from India that provides support for SAP environments that are out of maintenance. Like a generic aftermarket auto-parts manufacturer but for SAP solutions.

These customers cannot comply with new legal requirements delivered by SAP via OSS Notes and for sure they cannot benefit from new developments or new technologies as well.

Now, what can we / you do to change that? 

Not easy and definitively it takes time …

Over the years, SAP has run out of opportunities to sell new implementations to the Walmarts, Boeings, Airbus of the world (just to name a few). All the big guys and not so big too they were already in SAP. Those big ones are the ones who, “to some point”, they can still afford to have big implementations. But the others, no. So, they started looking some levels down in the pyramid to sell projects. But those companies did not have the same budgets and luxury that the big guys had. They needed to find a new approach for that market.

That is when we started seeing more and more implementations in the market using the Best Practices packages from SAP, with pre-delivered configuration for different scenarios, with pre-built configuration guides, process flows and testing scripts. All this pre-built material helped reduce the costs and accelerate the delivery. Many of the Consulting companies had picked up these documents, added their own logo, fonts, colors, added some of their own flavor and would sell them to customers as “accelerators”. Many are still doing it with every version.

We were starting from a good base, and we did not need to configure everything from the ground up.

But this was fixing some part, but we were still doing a lot of custom developments.

 

Some companies started seeing and putting all these variables together:

• high or impossible to upgrade costs,
• high maintenance costs of their own customization developments and
• lack of standardization

In the meantime, SAP launched SAP Simple Finance which later turned into S/4 HANA with their In-Memory Database. Promoting digital Transformation, Machine Learning technologies and a completely new UI like Fiori that would simplify the user experience making it in line with the type of intuitive user interfaces that we have today in our cell phones.

They also replaced their ASAP Methodology by their new “SAP Activate Methodology”. This new methodology got away from the traditional waterfall approach and got closer to Agile but still with certain reminiscences from waterfall.

 

For these clients something needed to be done, they wanted to be able to adopt new technologies. They were in outdated platforms too at risk with the OS and their Databases too.

As I mentioned before, some of these clients were (and a lot still are); in systems that are way beyond salvation, there is no “brownfield” option for an upgrade … So a new “greenfield” implementation was the only way out for them. Complete re-design from scratch.

This was the tipping point for them.

So they said, “… Let’s do a “greenfield” implementation … but how can we avoid falling into the same traps and making the same mistakes we did 20 years ago?. The industry has changed and those big & gigantic SAP programs where everything could be customized cannot be executed anymore. There is no more money and time for all of that.

As I mentioned, SAP Activate is Agile with a flavor of waterfall (a mix of the best of both worlds).

Within the methodology, as key part of this Standard vs. Custom approach is in the “Fit to Standard Analysis”.

We stopped doing detailed Blueprint workshops and started to do “Fit to standard” workshops.

The business users would explore the SAP best practices and standard business processes such as order-to-cash, procure-to-pay or hire-to-retire that are mapped for S/4HANA

We would show them the standard SAP delivered processes, show the fit on the client processes or see where their processes could fit in regards to standard and then question and challenge the parts that were not a fit.

In plain words we would ask “… Mr. Customer, tell us why you cannot use this standard process to do “xyz” and you need to customize it. Please justify it … ”

 

Out of those “Fit to standard” exercises a list of gaps would emerge. There are 2 possible solutions for them Adopt or Adapt.

·       Adopt the SAP process and become standard.

·       Adapt but using SAP standard configuration and still remain standard.

These last 2 would have some process reengineering and change management to do.

OR …

·       Adapt the system and customize / develop a tailor-made solution.

A complete fit-gap exercise ensures greater visibility of the gaps that the standard S/4HANA is unable to offer. In such cases, a fit-gap strategy decides if a system’s enhancement, a customized application, or activating a business add-in will address the identified gaps.

This is where companies should make a shift on their approach.

These companies implemented rigorous revision processes before approving any custom developments.

They created “design review committees” where they would scrutinize each and every single development asking Why is it needed? How will it be done? And most importantly, What happens if we don’t do it? What is the monetary impact? What is the business impact if not done? Is there a standard workaround that could be used instead?

Custom developments like some of the ones that used to be done in the past by some reckless consultants that would modify standard SAP code, are completely out of question. Even putting enhancement spots.

Some are going even further these days and the moment they hear something starting with Z, they shut it down right away. I personally faced this to address a business requirement where we would use a series of standard function modules and BAPIs but all wrapped up in a Z program. I was not even allowed to present it to the committee.

This process needs to have rigorousity and needs to be unbiassed for at least 2 main reasons.

1.       Keep your project budget under control, otherwise you end up with an endless list of custom developments that put you at risk to meet your go-live date. AND

2.       Avoid over customizing your system beyond the point of no return, like I described earlier where some systems become ZAP (SAP with a Z) and you cannot upgrade them anymore unless you are willing to invest a fortune on it.

These “design review or design authority committees” are made of different technical and non-technical people such as Solution Architects, Development Team Lead, System Integrator executives, Integration Managers, some line of Business executives and other individuals with many years of experience too. Another member of this committee is SAP itself. Clients would hire SAP Max Attention services to be part of this decision making process of reviewing these developments to add another level of scrutiny and legitimacy.

In some cases, during an S/4 HANA assessment project we had SAP Max Attention within this committee early on when we were doing the proposal for a future project, and we had to justify every custom development in front of them for them to provide an opinion to the customer if the development was justified or not.

In other cases, Max Attention was an integral part of the project on an ongoing basis and was a permanent member of this committee.

The committee will act as the guardian of your solution, protecting you from yourself, protecting you from falling into the old habits of deviating from standard SAP solutions and overly customizing your system.

In many cases, this will get a lot of business people upset and feeling that they are losing functionalities and information. This is where you will have to work redesigning your process and in change management with your people.

But this strategy will pay off in the long run as you will stay within standard SAP, and allow yourself the possibility of doing upgrades and adopting new technologies as they are released by SAP.

S/4 HANA on-premise is a system that has been constantly evolving since its launch in 2015, every year there is a new release with new features and functionalities. Staying standard will allow you to adopt them faster and reduce maintenance costs too.

 

Remember:

You have a decision to make …

Do you want to address every single business requirement not matter if it requires doing custom development, making you spend a fortune, increasing your maintenance costs and putting you at a disadvantage for an SAP upgrade? This should be part of the past way of doing business.

OR

You prefer to reduce implementation costs, reduce your maintenance costs while staying standard, invest in change management and process reengineering and allow you to adopt new functionalities and technologies faster whenever they are released? This should be your future vision and approach. Today this should be a no brainer decision for all organizations.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

Understanding S/4 HANA Adobe Forms for Functional Consultants

SAP has used over the past (many) years different technologies and development languages to build outputs / printouts for different processes (Ex. PO printout, Customer Invoice and/or Check printing and many more too). Some of these technologies can still be used if you want, but now a days you have better, easier and a more robust technology that can be used. This is Adobe Lifecycle Forms in S/4 HANA or some call them Adobe forms.

In the past, we used to do many of these mentioned outputs with SAPScript technology. These was ok for that time, but it is a little bit of a tedious language and adjusting drawings and positions takes a lot of try & error and definitively not really user friendly. Also, if you needed extra information that was not part or accessible in the original SAP delivered form; you most likely needed to create a "custom print program" to be able to accommodate the extra info or logic needed. We all know by know what custom means in terms of future upgrades and maintenance costs ...

Then after SAPScript came Smartforms, which it was the 1st possibility of dealing and producing Adobe PDF type of outputs. I worked with it a bit, but unfortunately being a Finance consultant I still had to deal with SAPScript as Smartforms was not widely available or used in Finance. It was more available for modules like SD for their Customer Invoices and related outputs.

But today since the inception of S/4 HANA, SAP has introduced a newer, better and more user friendly technology called "Adobe Forms".

Before being able to use this technology, some technical pre-requisites need to be in place in your S/4 HANA environment which your Basis and infrastructure team will have to work on it first. For this to work, you will an ADS Server (Adobe Document Server) to be installed in your landscape. And this runs in JAVA, so you will need to install it in a JAVA based server. I know from the past that the PI/PO server was JAVA based, so a couple of clients were sharing it for both technologies. Once that is in place, then they will have to connect them and after that you will be able to start using it. If you try to use it without this being in place, you will get a lot of errors and you will not even be able to display a form nor create one.

It is funny that I have to highlight that, as one would think this should be standard out of the box for any S/4 implementation; but apparently it is not ... This year, I went into a client where another SI was kicked out for doing a terrible job, and among many of my findings were that these guys designed all the outputs by still using the old SAPScript technology and the ADS server was non-existent in the client landscape.

Note: Don't ask me more technical questions about the ADS server as I am just a Functional guy, not a Basis resource.

How do we use and deal with these forms in S/4 HANA ?

As we were used to before with SAP, they have delivered a series of standard forms for each of the available outputs for the different processes that we can always leverage to start from them and add / remove / modify them as we see fit as per client requirements. Like adding a logo, changing columns or adding extra information that is not standard delivered.

As usual and in proper development practices, you should "never" modify an SAP standard form. You should ALWAYS create a copy and work with your own custom form. 

To access these forms, you can use Tcode SFP and enter (or search) the form name that you want to work with.

In my example, I will be working with the Vendor Payment Advice form which is a typical form that we use in Finance for payments.

Then you go Display and you will start looking at the definition and design of the Form. 

Within the Context tab, you will see a lot of the Structures that the form deals with and their individual fields that are available for the form to be added in the output. 

Here you can browse through the different Structures and fields and can take note of any extra fields that you might want to include in your customized form to add it to you Functional Specification document so then your Abaper can add them.

From my example (Payment Advice), you can clearly identify these structures as being the ones that are also available when we execute payments or when we build or deal with DMEE's. So any field that you want from those structures can be added to your form. There are fields at the header level and line item as usual. Same for any other forms for any other processes.

If for example, I want to add to my form "Payee Bank account #" and "Payee Bank Name", I just need to provide those technical field names (ZBNKN and ZBNKA) to be added to the form. 

Another possibility that you have, is to go to the Properties Tab and double click in the Interface name (Ex. FI_FPAYM_DATA). These will bring you another screen where you can then display the Structures definitions that we were seeing in the prior step in a more technical way as if you were displaying them in SE12.

Or, you can copy the Interface name and paste it right when you call Tcode SFP in the Interface field and display it. (Same result).

After you double click in any of the Type Name's for the Import Form Interface, you will see that structure the same way as you would see it in SE12 with all its technical definition, data type, length and so on ... Very useful when you want to see how big is the information you will be adding / removing to/from your form.

Next ... If you want to take a look at a draft layout of the final output form, you need to go back to the beginning to the "Layout" tab.

Before you are able to display the form layout in a PDF like way, you need to install Adobe Lifecycle Designer in your computer. In your own PC, not in the SAP server. Without that, you will not be able to display the form here in SFP. You can download it from the SAP Marketplace and then install it. 

Then you will see in the center of your screen, a little bit of a PDF display that also contains some technical information about the fields mapping (see below).

When you move to the left pane and drill down in parts of that hierarchy, the part that you are clicking on will get highlighted in the form just beside it in the central part of your screen. 

Also, if you see the right bottom pane, you will be able to see the field "binding" (field that is assigned to) for that field too.

All of these information will help you navigate through the form for you to do your analysis on which fields you need to add or remove from your form and provide a better Functional Specification Document (FSD) with detailed information and not just screen fields like I have seen many Functional consultants doing in the past (and still today ...).

Once your Developer finishes doing the changes in the form, you will just need to update the configuration for the process to include the new form name and it will be ready to be called by the system

Finally ...

What if I need to add fields that are not part of the structures that are available already in the form ?

What if I need to add custom logics to derive those fields or read other tables from other modules (Ex. SD or MM) ? How can I do that ?

In the past, to achieve this we needed to end up doing a Z / Custom program. Take a copy of the standard program and modify it as I mentioned earlier on.

Today with Adobe forms, there is NO MORE NEED TO CREATE A CUSTOM PRINT PROGRAM. If you see someone (Abap or functional) trying to repeat those old habits from the past. STOP HIM right away !!! That person has not updated his skills to S/4 HANA. 

There is absolutely no need for a Custom print program anymore. ZERO !!!

Any custom logics, fields, calculations, Abap code can be accommodated inside of the form where there is a section for you to put your own code, Form Routines and Data Definitions. I will not tell you how to do this part exactly because I am not an Abaper, but he should go back and investigate that as it is pretty simple to do in Adobe Forms.

Once he added the custom code to the form, you will be able to obtain the expected results and no SAP code would have been modified and this form will continue to be called by standard SAP programs.

This last part is really important, as I have passed through S/4 clients in the last years and I have seen Functional consultants that still asked for a custom print program and also delivered a form by using SAPScript. That should not be the approach for S/4 HANA anymore !

The technology stills exists and is still available for you to use it if you want. But you should not use it as you will be using old technology and not benefiting from the latest innovations. (Can you still work with a Monochrome amber or green screen ? for certain things probably yes. But there are better monitors now a days. So this is the same ...).

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com