SAP SD implementation notes-customer master data (1)

For the implementation project, the static master data of the SD module are mainly customer master data and price master data. This article mainly records some problems and opinions about customer master data encountered during the project.

business

  • In the HANA system, the creation, modification, and viewing of customer master data and supplier master data are all used T CODE BP. All business partner data will create a unique record in the background table BUT000. In other words, if it is an external number, it must be clear whether a business partner is both a customer and a supplier.
    If you are both a customer and a supplier, should you use different codes or the same code? Generally, for the business department, the users of the purchasing department and the sales department want to separate the supplier code from the customer code, but the financial department would like to use the same external accounting entity in SAP from the perspective of checking accounts. A code. At this time, senior consultants can give suggestions based on past experience. Of course, it mainly depends on which solution the user ultimately adopts.
    Customers and suppliers use different codes.
    If different codes are used separately, that is, the same external accounting entity, such as customer A, is both a customer and a supplier. When A is a customer and a supplier, its code is in SAP It's different here. Since it is an external number, the purchasing department and the sales department need to set their own coding rules. The number segment must be within 10 digits (SAP standard), and the coding range cannot overlap. In this case, the BP grouping of customers and suppliers can be separated. (The BP group of HANA can be understood as the account group of ECC.) Generally speaking, it is not recommended to make too many BP groups. It is best for customers to have two groups, one internal number and one external number. Different BP groups give different views. The views required by HANA's standard customer grouping are: 000000 business partner regular view, FLCU01 customer view, and FLCU00 financial view.

Affiliates
In addition, for affiliated companies (companies under other molecules of the same group), there is usually sourcing relationship also exists both sales relationship for this association clients, it is best to use an external number, and by a separate BP Grouping, SAP HANA has a standard BP grouping-K400 related party merchants for this kind of related company customers. It is recommended to use the standard one directly.

Customers and suppliers use the same code.
For the same external accounting entity, both the supplier and the customer, if the same code is used, it is recommended that the customer and the supplier share a BP group, which can be referred to above. K400 was copied and created. If you don’t use the same BP group, but create a Z001 BP group for customers and a Z002 BP group for suppliers, and a business partner can only have one BP group, this will cause confusion to users. Moreover, it is troublesome to expand the supplier view to the customer in the later period, and to expand the customer view to the supplier. Using the same BP group, the BP group has views required by customers and suppliers at the same time, which is more convenient for later expansion. If the user needs to know whether the business partner is a customer or a supplier, he can find another field in the master data to store this information.

Configuration

  1. Define the account group and field selection
    path for the customer : Implementation Guide>Logistics-General>Business Partner>Customer>Control>Define the account group and field selection for the customer
  2. Define the number range
    path of customer master data : Implementation Guide>Logistics-General>Business Partner>Customer>Control>Define and Assign Customer Number Range>Define Customer Master Data Number Range
  3. Define grouping and assigning number range
    path: Implementation Guide>Cross-component Application>SAP Business Partner>Basic Settings>Numbering Range and Grouping>Defining Grouping and Assigning Number Range
  4. Instruct the BP role from customer to business partner (that is, assign a view to BP)
    Path: Implementation Guide>Cross-component application>Master data synchronization>Customer/supplier integration>Business partner settings>Customer integration settings>Define instructions for customer-to-business cooperation Partner's BP role
  5. Define the number assignment from business partners to customers (that is, assign account groups to BP groups)
    : Implementation Guide>Cross-building applications>Master data synchronization>Customer/supplier integration>Business partner settings>Customer integration settings>Integrated field assignment >Define the number assignment from business partners to customers
  6. Define the partner function
    path: Implementation Guide>Sales and Distribution>Basic Functions>Partner Determination>Set Partner Determination>Set Customer Master Data Partner Determination>Partner Function
  7. Account group-function allocation (that is, which account group can be used as which partner function)
    Path: Implementation Guide>Sales and Distribution>Basic Functions>Partner Determination>Set Partner Determination>Set Customer Master Data Partner Determination>Account Group-Function distribution
  8. Define the process
    path of partner determination : Implementation Guide>Sales and Distribution>Basic Functions>Partner Determination>Set Partner Determination>Set Customer Master Data Partner Determination>Partner Determination Process
    9. Partner Determination Process Assignment (to account group Assign partner function dermination procedure)
    Path: Implementation Guide>Sales and Distribution>Basic Functions>Partner Determination>Set Partner Determination>Set Customer Master Data Partner Determination>Partner Determination Process Assignment

Development

  • The development of customer master data mainly includes: batch guide program, interface, report.
    If customer master data is imported from an external system, the interface will be involved. It is recommended that the interface fields, batch guide fields and report fields are consistent, so that users can understand , It is also relatively easy to develop.
    interface
  • When the receiving interface
    talks about the interface field with the peripheral system, the following matters need to be paid attention to:

    1. For customer master data transferred from external systems, generally three actions need to be distinguished: create, modify, and delete. Therefore, when discussing interface fields with peripheral systems, you need to specify a field to distinguish between creation, modification, or deletion? Of course, SAP's customer master data is generally not physically deleted, but marked as frozen.

      1. For the modification action, it is necessary to confirm with the peripheral system whether there are any SAP fields that cannot be modified/cannot be modified at will, but there are fields that may be modified in the peripheral system, such as BP grouping. My project encountered this situation. The business divided the customers into 2 categories, so we also built 2 BP groups based on these 2 types of customers, but later in the process of communicating with the peripheral system, we found that the user can modify the customer category in the peripheral system , But the customer category of SAP HANA cannot be easily modified. Therefore, later we changed the two BP groups of the customer to leave only one, and used the field BPKIND to distinguish the customer category (normal view-control-business partner type, as shown in the figure below).

      SAP SD implementation notes-customer master data (1)

      1. Need to pay attention to whether the customer number of the peripheral system is within 10 digits. The business partner code of the SAP system has a maximum of 10 digits. If it exceeds 10 digits, there are two solutions.
        Solution 1: It is best for users to modify the original customer code rules of the peripheral system to adapt to the new SAP system, and recode the old customers with more than 10 customers-although it is troublesome to organize the data in the early stage, it is easy in the later stage. This solution is worthwhile in the long run. It can make the data of the entire group as unified as possible and facilitate unified planning. Recommended option one.
        Solution 2: If the user does not agree to modify the original customer number rule, then the customer number of the peripheral system can be stored in the field BUT000-BPEXT (regular view-identification-external business partner number, as shown in the figure below), and then SAP Generate an internal number within 10 digits. However, in this way, if the peripheral system modifies customer data, SAP needs to find the corresponding SAP customer number through the external business partner number, and then modify it. If the business order is also placed in the peripheral system, when the sales order is transferred to SAP, the partner also needs to be converted. Option two is the next choice.
        SAP SD implementation notes-customer master data (1)

      2. Whether the peripheral system maintains multiple bank accounts for a customer. If the peripheral system maintains multiple bank accounts for a customer, assuming a maximum of 3, correspondingly, the interface field should be a few more.
      3. Agree with the peripheral system on the interface field length/format/whether it is required/default value, etc. Length, such as the length of the address, the length of the customer number, etc.; the format, such as the date format, is best to use a pure number format such as 20201001, and try to avoid non-pure number formats such as 2020-10-01 or 2020/10/01; Required check, also called completeness check. Some field values ​​are mandatory for SAP, and the peripheral system must pass the value, such as country and region. If the peripheral system can fill in the field, it can be left blank. It is better to request the modification of the peripheral system so that the user must maintain the field in the peripheral system, or the two parties agree on a virtual default value, such as a street field. If the user does not maintain address information in the peripheral system, the peripheral system will pass in the default value 999999 to SAP, etc.; default value, some fields are required by SAP, but the peripheral system may not maintain the information corresponding to the field, it is best to let the peripheral system transmit the default value according to certain rules, and it is best not to directly specify in the SAP interface The default value, which is conducive to later business development. For example, to control the subject field, SAP customer master data needs to fill in this field, but generally speaking, the peripheral system does not have this field information, then we can tell the peripheral system to transmit according to specific rules Some default value.
      4. The processing logic agreed with the peripheral system, is it synchronous or asynchronous? Synchronization can be understood as after the peripheral system sends information to SAP, it needs to wait to receive the success or failure information returned after SAP processing. If SAP returns E (failure), the peripheral system needs to process or resend it; asynchronously, the peripheral system sends the information to SAP without waiting for the information returned by SAP.
      5. To be continued.
  • The FS of the receiving interface is written
    in this part of the FS function specification. I provide the interface field template as an example.
    The following are the fields contained in the log table ZTSD001_CMD. The log table contains all interface service fields. The fields marked with yellow are newly added fields outside the interface.
    SAP SD implementation notes-customer master data (1)
    SAP SD implementation notes-customer master data (1)
    SAP SD implementation notes-customer master data (1)
    SAP SD implementation notes-customer master data (1)
    SAP SD implementation notes-customer master data (1)
    SAP SD implementation notes-customer master data (1)

    对于这种主数据接收程序,程序处理逻辑可参考如下:
  • Step 1: Perform integrity check on interface fields. If the verification fails, an error message is returned to the peripheral system. Do not save information to the log table.
  • Step 2: Perform field logical verification on the interface field, mainly for length, value/value range, and format. If the verification fails, an error message is returned to the peripheral system. Do not save information to the log table.
  • Step 3: If the verification is successful, record the field information to the log table ZTSD001_CMD, and proceed to the next step.
  • Step 4: Assign values ​​to some fields in the log table according to certain logic.
  • Step 5: Create\modify\freeze the corresponding customer master data according to the log table.
  • Step 6: If the creation\modification\freeze is successful, the customer number that was created successfully will be returned. If the creation fails, an error message is returned.
    Of course, in addition to the interface processing logic, there is usually a reprocessing program for the interface. The reprocessing program needs to read the data of the message type E (Eerror) in the log table and process it again. If you need to re-process, you need to inform the development, the logic is roughly the same as the interface program, and it needs to be able to process in the background.

The following is a detailed analysis of each step:
1) Perform integrity check on interface fields.
After the peripheral system pushes the customer information to SAP, SAP will perform field integrity verification: The fifth column of Table 1 marks the fields that need to be integrity-checked in all interface fields. After checking all "required" fields, as long as there is a value in the "required" field that is not provided by the peripheral system in the interface, the error message "E" will be returned for this push (INFO=E, MESSAGE=Error) , Return Error: incomplete data for the error field. Then exit the interface. Only when all the "required" fields in Table 1 have values, can we proceed to the next logical verification.

2) Logical integrity check: After
passing the integrity check, proceed to field logical check. Column 6 and 7 in Table 1 indicate the logical verification interface fields and their verification content. As long as there is a field that fails the logical verification, an error message of "E" is returned for this push, and the corresponding error message for the error field is returned, and then the interface is exited. Only the logical verification is successful before proceeding to the next step. The corresponding error information is listed as follows:
a. Length: The transmission value of all fields cannot exceed the set length (hereinafter referred to as "extra-long", but the field of "extra-long truncation" is only truncated without error), if this item is checked If it fails, it returns "error: character length" for this field, and returns an error message for this field (INFO=E, MESSAGE=Error);
b. Value/range: some fields can only transmit the value in the value range (hereinafter referred to as " Table value"), some fields can only transmit one of several specific values ​​(hereinafter referred to as "fixed value"). If the item fails to be checked because of this, "error: value range" will be returned for this field, and an error will be returned for this field Message (INFO=E, MESSAGE=Error);
c. Check: perform integrity check or uniqueness check based on certain premises. If the item check fails, then "error: check" is returned for this field, and it is returned for this field Error message (INFO=E, MESSAGE=Error);
if the length and value/range of the two checks fail on the same field, the content of the error message will be combined (separated by "/") to give a unified feedback, such as " Error: Length/Value Range", an error message (INFO=E, MESSAGE=Error) is returned for this field.

3) If both steps 1 and 2 are successfully verified, the field information is stored in the log table ZTSD001_CMD.
4) Create a function ZSDIF001 (Customer Master Data Interface), which is used to process the related business of the interface, and at the same time it is used for reprocessing calls;

5) Operate the data after the inspection has passed and landed (the reprocessing mechanism is also applicable).

6) SAP needs to assign values ​​to some fields in the log table according to certain logic. For specific assignment rules, please see the red part in the last column of Table 1.
7) Create\modify\freeze the corresponding customer master data according to the log table.
If XBLCK=1, create customer master data; if XBLCK=2, modify customer master data; if XBLCK=3, freeze customer master data.
A. Create customer master data:
If BU_GROUP=Z005, when creating customer master data, the customer code will be the internal number given by the system instead of the customer number provided by the peripheral system. BU_GROUP=Z001, use the customer number passed from the peripheral system.
Call FUNCTION CVI_EI_INBOUND_MAIN to create customer master data.
If the creation is successful, assign "S" to the transmission status field of the log table, and add follow-up information after the message field is cleared: "Customer" + customer code + "created successfully".
If the creation fails, assign "E" to the transmission status field of the log table, and add the follow-up: "Customer creation failed" + system error message code after the message field is cleared. Perform a reprocessing.
The message of successful or failed creation is then returned to the peripheral system.
B. Modify customer master data:
If BU_GROUP=Z005, you need to find the customer number of the customer in SAP, and then modify the master data of the customer number, you need to find BUT000-BPEXT=ZTSD001_CMD- in the SAP table BUT000 first In BPEXT, the value of BUT000- PARTNER is the SAP customer number that needs to be modified.
If the BP group is other, the customer number is directly taken from the KUNNR passed in by the interface.
If the customer has been frozen before, the freeze needs to be released, that is, KNA1- AUFSD="".
Call BAPI/Function to create customer master data.
If the modification is successful, assign "S" to the transmission status field of the log table, and add follow-up information after the message field is cleared: "Customer" + Customer Code + "Modification Successful".
If the modification fails, assign "E" to the transmission status field of the log table, and add the follow-up after the message field is cleared: "Customer modification failed" + system error message code. Perform a reprocessing.
The success or failure message is then returned to the peripheral system.

C. Freeze customer master data:
If BU_GROUP=Z005, you need to find the customer number of the customer in SAP, and then freeze the customer. When BUT000-BPEXT=ZTSD001_CMD-BPEXT needs to be searched in SAP table BUT000 first, the value of BUT000- PARTNER is the SAP customer number that needs to be frozen.
To freeze the customer is about to T code: The following fields in BP are marked with "01", that is, KNA1- AUFSD="01".
The freeze success or failure message is then returned to the peripheral system.

8) Output data The
output data is mainly the customer number of the peripheral system and the customer number generated by the corresponding SAP system. At the same time, the SAP system will feed back the results generated to the peripheral system through the interface. The specific feedback fields are as follows:
SAP SD implementation notes-customer master data (1)

Download link of FS template for this interface:
Customer master data is transferred to interface FS writing template

Follow-up notes on the customer master data sending interface, batch guide program, etc. are left for the next article.

Guess you like

Origin blog.51cto.com/9027965/2544521