Customer Master - BDC load , Tax jurisdiction challenges

Customer Master upload – BDC, Tax jurisdiction challenges .

Preface:

Loading customer master often calls for many technical challenges in making the appropriate design that will cover the  tradeoff between the following factors

• Speed of load process .
• Maintaining the Data integrity with in SAP like a standard screen flow would do field by field, screen by screen.
• Maintaining Data Integrity between systems  based on the Architecture etc .
• Dialog constraints like tax jurisdiction pop ups when a 3 rd party apps like Vertex determines the list

It is a known fact that SAP provides standard options like recording, BAPIs, ALEs . Often these comes with limitations with the  nature of the data we are trying to load them .For examples BAPI are excellent but what if there are fields that we need to load in which is not a part of the given BAPI structures .  We would end up in trying multiple approaches to cover all data .

Options are :

• LSMW- recording
• LSMW - Direct input programs
• LSMW - BAPI
• LSMW - ALE messages
• Custom coded program which one or many of the following to update 
  • FM – SD_CUSTOMER_MAINTAIN_ALL
  • BAPIs,
  • BDCs ( Session Vs Call Transaction )

If the fields are limited that comes under the purview of one of standard options, it is wise to go thru .Standard approaches apparently goes thru a inbuilt strong validations mechanisms which will ensure the data integrity is maintained.

Problem Case :

In my case , the client requirements was to build one load program which will do the following :

• Run in a Data Pre validation mode – Meaning to run various checks in the input ( normalized template )
• Create mode  (XD01 ) – to create customer master and update the classification and characteristics
• Change mode ( XD02 )  - to update a few fields from 3pl systems in to the customer master

Technical Challenges:

• The key challenges that I faced in designing is the tax jurisdiction pop up  ,that may or may not pop up based on the parameters like Zipcode, city and region . The list was the outcome of the Vertex tax evaluations that uses RFCs communications to get the values
• These values and pop up are only for US customers , NOT for any other
• We don’t want to run in the foreground , because of huge volume and pain of monitoring , It would be a painful if we are trying multiple iterations during the build phase . I intented to run them in Background what ever my design was

Final Design / Load Execution

• After evaluating all the options above , I concluded to build a custom program  that will run a BDC code for XD01 and XD02
• Create a recording with a pop up scenario and get the code plugged in to your code , let say BDC1
• Create a recording with-out a popup scenario (one value so no pop up )  Let say BDC2.

In your program evaluate predetermine by using the

Function module RFC_DETERMINE_JURISDICTION.

if the value returned is one record then call BDC2 else call BDC1 .( in my case the default pick is the first item in the F4 list )

• Generate a ALV output to list the errors and status messages that u get from the BDC
• Execution :
  • Split the input file in to
    • Records that requires tax jurisdiction evaluation(set 1)
    • Records that don’t (set 2)
    • Run set1 in E mode (background) , Weird ,but works ..
    • Run Set2 in N mode (background).

If u mix them both and try to run in any of the modes , either of them fails ,

for example , if u pick a record in set 1 and load them in “ N” mode , it errors “ No tax jurisdiction can be found “. If u run the same record in E mode, it successfully load them , Weird right ? ,but it works and it save a huge hassle of foreground load .

Notes to Remember:

• The default partners will NOT be created when u do XD01 recording. So u need to have a following load on XD02 by just clicking the Sales area details button and click save in your recording .
• Always use Mode “E” for records that needs Tax jurisdiction.