1. Introduction. 3
2. Bank master upload – Technical walk through. 4
3. 2.1. Background. 4
4. 2.2.       Deep dive into the technical features of BIC2. 4
5. 2.2.1          Upload logic. 4
6. 2.2.2 Supported file format. 5
7. 2.2.3. ISO Country codes: 5
8. 2.2.4. ALE distribution. 5
9. 2.2.5. Padding of SWIFT with XXX: 5
10. 2.2.6. Old and new BIC2. 5
11. 2.2.7. Running in background: 5
12. 2.2.8. Locking of Bank master data. 5
13. 2.2.9. Tables impacted. 6
14. 2.2.10. Performance considerations. 6
15. 2.2.11. Reading the file from Accuity Server. 6
16. 2.2.12. Enhancements to Standard functionality. 6
17. 2.3.       Technical options for File upload. 6
18. 2.3.1.         Classic Delta upload. 6
19. 2.3.2.         Delta upload using Bic key value. 7
20. 2.3.3.         Full upload. 7
21. 2.4.       Head office Vs Branch office: 7
22. 2.5.       Unique records and skipped records. 7
23. 2.6.       Deleting records: 8
24. 2.7.       Country settings for Bank key: 8
25. 2.8.       International address. 8
26. 2.9.       Bank key derivation logic. 9
27. 2.9.1.         Countries that lack National ID: 9
28. 2.9.2.         Pictorial view of Bank key derivation logic. 10
29. Summary of limitations: 11
30. Best Practices/Recommendations: 11

Appendix – Technical differences in Bank master maintenance – Manual Vs  Automatic. 12

 

1.    Introduction

This white paper focus on Bank master maintenance process in SAP ECC, explaining the importance of maintaining clean master data, Business challenges/pain points, maintenance options and then delve deep into the technical aspects of Bank master data maintenance using Accuity GPF(Global Payment File) file and highlights the best practices to be followed.

Bank master maintenance in SAP is maintenance of Bank directory, and is represented by master data ‘Bank key’. Bank directory is a global list of Banks/Financial Institutions maintained in SAP ECC and a Financial/Banking institution is represented in SAP ECC by Bank key master. In the financial world, Banks are identified by unique Bank IDs viz., SWIFT, BIC, for exchange of electronic information among institutions.

Bank key is maintained as master data with relevant Bank IDs, Bank name and address details. Master list (Directory) of all Banks are maintained in SAP, so that this information can be used for Payment processing.

Partner (Vendor/Customer/Employee) master data, House Bank etc., are updated with Bank key information along with Bank Account details and depending on Country requirements, additional fields such as IBAN may be mandatory.

Bank information provided by Partners will be validated against the SAP Bank directory so that you avoid Payment failures due to incorrect/invalid Bank information. SWIFT, Thompson financials and Accuity are examples of the third party Organizations which provide Bank directory files with monthly updates based on subscription fee.

It is important to maintain clean Bank master data to minimize Payment failures due to incorrect Bank information and thus save on Bank charges, additional effort involved in manual re-processing of Payments etc.,

There is not enough SAP documentation available which explains the complete process and some of the features are slightly complex to understand. This White paper serve as a complete reference for anyone interested in this topic

 

Following options available for Bank directory Upload:

• BIC2 (Old Transaction BIC) – Standard Bank directory transaction to upload file provided by third Parties
• Legacy Bank data using LSMW tools
• Country specific transfer of Bank master data using BAUP transaction

 

 

2.    Bank master upload – Technical walk through

2.1. Background

• In this section, Bank master file upload using Accuity file upload is discussed.
• Accuity is a third party vendor who provides GPF (Global Payment File) for Bank master upload in XML and ASCII format. Main difference between these two formats is that delta Text file has even unchanged records, which makes the Delta file bigger than the Full file! From a processing point of ASCII file is better than XML file. Given full file size, it is almost not possible to upload XML file unless special processing resources are allocated for the upload. We have chosen Text file for the full load and XML format for the delta file.
• They provide Custom ABAP Program for upload using XML format, which offers some features which are not available in standard SAP BIC2 Program like Bank key filter on Selection etc.,
• They also have Custom ABAP Utility program which splits the file. This is useful especially if you want to upload huge XML full files.
• SAP Notes 1769640 needs to be implemented to enable Accuity functionality of BIC2 (drop down will have ‘Accuity Bankmaster’). This Note #2041677 was released based on our discussion with SAP team and is to update Primary key value onto the BICKY field (BNKA-BICKY). If you have Head office, Branch office scenario, updating this field helps in identifying the specific record for update. For instance, Branch details will not overwrite Head office, where both have same SWIFT/Bank number. However, if we have to use this feature, we need to select ‘Use Bicky’ check box on the selection which also activates ‘Delta upload using BICKY’ rather the Classic Delta upload. We had concern activating this check box, as this overwrites the SWIFT/Bank number details as well. SAP was reluctant to fix this as they continue to maintain that it was the intended functionality and not a bug. Expected behavior should be where SWIFT/Bank number details to be updated, mark existing record for ‘deletion’ and insert a new record.
• Typical File fizes: Full XML/Text file – 750 to 800 MB, Delta XML – 2 to 10 MB and Delta Text file – bigger than the Full file, since this file also has Unchanged records.

2.2. Deep dive into the technical features of BIC2

2.2.1 Upload logic

• Bank record is created if it has a flag ‘M’ or ‘A’ in the input file and does not exist in BNKA table.
• On the other hand, a Bank record will be modified if it has a flag ‘M’ or ‘A’ in the input file, but already exists in BNKA Table.
• The Bank change will not happen, if there are no relevant field level changes to Bank master record.
• Also note that, a Bank record can also become re-activated if it is flagged as ‘A’ or ‘M’ but already has a deletion flag set in BNKA-LOVEM. This will remove the deletion flag in BNKA Table. (how to handle such scenarios post go-live)
• Records will be marked for deletion, if it has flag ‘Marked for Deletion’ in the input file and ‘Deletion flag’ is checked on the Selection screen
• A Bank master also be set for ‘Deletion’, even if it is not marked for deletion in the input file. This will happen in case of full file upload, where records which are not present in the input file are all set with deletion indicator.
• Text files (ASCII)
• XML files (Preferred)
• Fixed length Text file and XML file formats are supported. However, local language supplement is only available in XML format.

2.2.2 Supported file format

2.2.3. ISO Country codes:

• BIC2 assumes one to one relationship between ISO Country code and SAP Country code. If more than one Country code exists for a given ISO code, first record will be considered and rest will be ignored.
• If SAP Country code and ISO code does not match, such records will be ignored and shown in the output as Error records
• Depending the ALE model maintained in the System, ALE can be triggered in a Distributed environment
• SWIFT code is either 8 character or 11 character length
• Where SWIFT is 8 character length, ‘XXX’ is padded at the end to make it 11 character length
• With this option, ‘XXX’ will not ignored and stored as is from the file
• Old BIC2 program does not support Delta upload functionality. Using new BIC2, old BIC2 logic can be invoked by using Selection screen option.
• Since this Program is designed for GUI_UPLOAD cannot accept files from Presentation Server in the background
• However, you can use the Application server option to run in background

2.2.4. ALE distribution

2.2.5. Padding of SWIFT with XXX:

2.2.6. Old and new BIC2

2.2.7. Running in background:

2.2.8. Locking of Bank master data

During the update, it is essential to lock Bank master data for any parallel updates

2.2.9. Tables impacted

• BNKA
• CDPOS/CDHDR/CDCLS
• SMLG (Log table)

2.2.10. Performance considerations

• Uploading the Full file requires lot of System resources and takes longer run time
• Full file in XML format requires lot of processing time and invariably uploading job gets canceled due to memory issues and in this case, option would be to use Text format based file to upload
• If you have to distribute to Other Systems, it makes better case not to activate ALE distribution in BIC2 selection, as it would take longer run time and better replicate as offline process and not at the same time of Bank master upload
• Accuity makes the Full and Delta files available by a specified each month
• Either files can be read manually or through some middle layer
• FTP pull method
• Accuity provides the files in compressed format. Either use the middle layer to un-compress the files or build a SAP utility to un-compress the files
• Implicit enhancement are available to embed some Custom logic into Standard SAP includes
• One Use case is to embed Custom logic not to update existing records. For instance, we have used logic to identify existing records and exclude such records for any updates and show the Output log accordingly

2.2.11. Reading the file from Accuity Server

2.2.12. Enhancements to Standard functionality

2.3. Technical options for File upload

2.3.1.      Classic Delta upload

• In this option, apart from Bank Country & Bank Key, SWIFT & Bank number fields are matched for any updates required
• Deletion indicator is set in the BNKA Table, if the file has ‘Deletion indicator’ and ‘Deletion indicator’ is checked on the Selection screen
• Following fields will be updated during a modification:
  • § Name of the Bank
  • § Street
  • § City
  • § Branch
  • § Deletion indicator

BIC record key

• Please note that ‘User’ will not be updated in BNKA Table, so you would not know who and when the update/modification is done to a particular record. However, change log Tables (CHHDR/CDPOS) have these information (these details can be reviewed in FI02/FI03 transaction)

2.3.2.      Delta upload using Bic key value

• In this option, BICKY will be used to match records for updates along with Bank key & Bank country
• There is no check for duplicate values for BICKY field during update/Insert to BNKA Table
• Used for Branch Vs Head office updates
• Run the risk of overwriting SWIFT/Bank number values with this approach, as there is no duplicate check on BNKA-BICKY field
• For Accuity file uploads, implement SAP note 2041677 to update ‘KEY_VALUE’ into BNKA-BICKY field
• There is also an option to use ‘BICKY’ as Bank key
• This is the complete file with the idea of full refresh and intended for the first time upload into the System
• Matching records are identified by matching Bank key and Bank country for any updates/modifications
• Run the risk of overwriting SWIFT/Bank number values
• All existing records will be set to deletion flag, provided you select ‘Deletion indicator’ on the Selection screen

2.3.3.      Full upload

2.4. Head office Vs Branch office:

• It is possible that Branch office has same National ID as that of Head office. There is no option to store Head office & Branch office relation in BNKA
• Branch name in BANK is a free text and as such cannot be establish relationship
• To prevent Head office details getting overwritten by Branch, additional identifier
  (BNKA-BICKY) can be used by implementing Note # (refer to section on Background)
• BIC2 as such does not have any logic to use preference indicator from the input file

2.5. Unique records and skipped records

• Unique records are identified based on Bank key and Bank Country combination from the Country. Please note that Bank key as such is not part of the input file, but this is derived by BIC2 logic based on the Country Bank type settings (T005-BNKEY). If the Bank type is ‘1’ (Bank number), National ID/Bank number is used as Bank key and if the Bank type is ‘4’ (Externally assigned), then based on Selection screen input for ‘Bank key for Type 4’, Bank key will be determined
• Based on this logic, records with missing information (no SWIFT/NAT ID), duplicate records and other invalid records will be ignore for further processing
• Unique records are shown separately in the Output log
• Total of Records Created + Modified + Unchanged + Deleted = Total Unique Records. However, for full upload this equation will not hold good, as Marked for Deletion records are those which are not present in the Full upload file
• Output log does not provide the list of ignored/skipped records

2.6. Deleting records:

Deletion indicator has to be set on Selection to mark for deletion. It is not sufficient that the input file has ‘Deletion’ indicator

2.7. Country settings for Bank key:

• Country with Bank key type as ‘1’ has Bank number as Bank key, which means, uses ‘Bank number’ or ‘National ID’ as Bank key. However, where there is no Bank number then no Bank master will be created.
• Where Bank key type is set as ‘4’, we can derive Bank key either from Bank number or BIC/SWIFT. We also have options to use the other value, if preferred value is not available in the input file or we can create two Bank masters using both of these Values as Bank key
• Length of Bank key/Bank number influence the length
• Some Countries require Bank information to be sent in local language for local payments. This means that apart from English version, local version address also to be maintained for the Bank master record
• International version of the address will be stored in the Address Table (ADRC)
• Standard BIC2 does not support upload of both default address and International address for a given record
• Enhancement or a work around solution is required to upload Bank address in local language
• Enhancement also required to pick the right address, say depending on the type of Payments (Local/International)

2.8. International address

2.9. Bank key derivation logic

• Bank key derivation is important, when upload using standard Upload Program as the Country specific settings comes to play here, whereas when you create a Bank master manually, these Controls are not relevant
• If you are implementing this process in a live SAP environment, you have to make sure that you are not breaking any of the existing Payment process
• BIC2 provides some implicit enhancement options to add some Custom logic. For instance, you add logic not to update any of the existing records
• For IBAN mandatory Countries, it is important to use ‘Bank number’ as Bank key
• If you have to use any Custom derivation logic for Type 4 Countries, you can develop a separate Program for those Countries
• Please note that if you are subscribing to Accuity files, for some of the Countries (refer to Accuity documentation) Accuity does not provide National Codes. Please do your due diligence to make sure that you plan how to take care of these scenarios.
• For Countries which does not have National IDs and use SWIFT/BIC for domestic Payments, Bank key can be created by using ‘SWIFT/BIC’ key
• There are defined list of countries for which National ID is not available
• For these Countries, the Country settings (OY18/T005 Table) setting should be set to ‘4’, (externally assigned). Otherwise, Bank master cannot be created

2.9.1.      Countries that lack National ID:

2.9.2.      Pictorial view of Bank key derivation logic

3.     Summary of limitations:

• International version cannot be updated to ADRC along with default address for a given Bank master
• No detailed output log to reconcile skipped/ignored records from the file
• No list of skipped records in the output log. This could be useful instance, you want to create Bank master for some skipped records using a different Bank key Derivation rule (for Bank key type = 1 records)
• There is no duplicate check on BNKA-BICKY field, which will be used for identifying records for modifications/updates in case of Delta upload using BICKY
• No warning for the Bank key masters which are in use (in House Bank, Vendor master etc.,) before marking them for deletion
• No warning for Bank keys which get truncated
• SLG1 Application log is not active
• Full upload will set all existing Banks with ‘Deletion indicator’. Even House Banks which are created as Bank keys also will be marked for deletion
• There is no option to filter based on specific Bank keys on the Selection screen
• When a record is modified, corresponding User and modified date are not updated in BNKA Table. However, change log is captured by CDHDR/CDPOS

4.     Best Practices/Recommendations:

• Use ‘Delta’ upload method even for ‘Full load’, so that you don’t overwrite some key fields like “SWIFT”, “Bank number” etc.,
• First preference is for Bank number/National ID. Where no ‘National ID’ use SWIFT/BIC as Bank key
• Make sure that, where you want to use Bank key value other than, ‘Bank number’, Country Bank key setting is set to ‘4’
• Use Country specific logic for uploading Bank master data. For instance, In some countries, Bank National ID is a mandatory requirement for Payment processing, so you can define ‘Derivation rules’ in such a way that Bank master is not created unless National Id is available in the input file
• Make sure to test end to end Payment process, before moving to Production, as there could be differences in the way Bank master fields are updated in the as-is and how Accuity upload updates the Bank master fields
• Make sure to run the upload program when Payment related processing is not happening. Preferably, during week-ends
• Accuity Fixed length Text (ASCII) delta file has ‘Unchanged’ records as well, which makes the Delta file size bigger than the ‘Full file’. This makes XML format file a clear winner, as the difference in File between these formats is significant
• Try the ‘Test run’ before the Update run for the Full load

Appendix – Technical differences in Bank master maintenance – Manual Vs  Automatic