Functionality The organization address is determined from the specified object type and object key, and updated with the specified address and communication data, if required. This module differs from a standard change BAPI in that not only can existing entries be changed, but address attribute telephone numbers, fax numbers, etc. can also be deleted or inserted. Reference structures (checkboxes) are used to select entries to be changed. Example * Change an organization address: * Change, delete and add a telephone number DATA: objtype LIKE bapi4001_1-objtype, obj_id LIKE bapi4001_1-objkey, obj_id_ext LIKE bapi4001_1-extension, context LIKE bapi4001_1-context, address_number LIKE adrc-addrnumber, bapiadtel LIKE bapiadtel OCCURS 0 WITH HEADER LINE, bapiadtel_x LIKE bapiadtelx OCCURS 0 WITH HEADER LINE, return LIKE bapiret2 OCCURS 0. * Assign the following object type and object key to a main customer * address objtype = 'KNA1'. obj_id = . obj_id_ext = ' '. context = '0001'. * Get existing data by calling, e.g. FM 'BAPI_ADDRESSORG_GETDETAIL' ... * Enter the reference structure data * The telephone number with serial number '002' is to be deleted and * the one with serial number '003' updated CLEAR: bapiadtel, bapiadtel_x. bapiadtel-consnumber = '002'. bapiadtel_x-updateflag = 'D'. APPEND: bapiadtel, bapiadtel_x. "Delete entry CLEAR: bapiadtel, bapiadtel_x. bapiadtel-consnumber = '003'. bapiadtel-extension = '77733'. bapiadtel_x-extension = 'X'. bapiadtel_x-updateflag = 'U' APPEND: bapiadtel, bapiadtel_x. "Update entry CLEAR: bapiadtel, bapiadtel_x. bapiadtel-telephone = '06227'. bapiadtel-extension = '11111'. bapiadtel_x-updateflag = 'I'. APPEND: bapiadtel, bapiadtel_x. "Insert new entry * call change module CALL FUNCTION 'BAPI_ADDRESSORG_CHANGE' EXPORTING obj_type = objtype obj_id = obj_id obj_id_ext = obj_id_ext context = context IMPORTING address_number = address_number TABLES bapiadtel = bapiadtel bapiadtel_x = bapiadtel_x return = return. * Errors and warnings are in the RETURN table. If successful, the * organization address and its communication data are now updated * in the system. * The adress number is in the ADDRESS_NUMBER field. Notes To delete, e.g. a telephone number in the table of existing telephone numbers for an address, the 'UPDATEFLAG' field in the associated reference structure line must contain 'D'. To create an entry, this field must contain 'I' and the data to be inserted must be passed. All new lines to be inserted (I) and their reference structures must be after all entries to be changed (U) and deleted (D). Change data key fields must always be filled, and are taken into account as far as possible. It is not significant whether, e.g. all telephone number comments are followed by fax number comments as change data, or vice versa; only the sequence among entries with the same key is significant, unless you pass only some or no communication address or comment serial numbers, in which case the data sequence is significant . The key fields are: Structure | Fields --------------------------------- BAPIAD1VL | ADDR_VERS, FROM_DATE BAPIAD_REM | ADDR_VERS, LANGU BAPIADTEL | CONSNUMBER ... | ... BAPIADPAG | CONSNUMBER BAPICOMREM | COMM_TYPE, LANGU You can pass the communication address and comment serial numbers empty, in which case the sequence of the data passed is significant, for example if you want to delete the telephone number in the second position in the in ascending order of serial numbers sorted existing telephone numbers, in the database, you must pass a dummy telephone number with update flag (U) in the first position, without selecting fields to update, and a telephone number with delete flag (D) in the second position. The communication addresses in the database are usually not sorted by serial numbers, so you must first determine the sequence of the communication addresses sorted by serial numbers. This procedure is not advisable because it is easy to make data sequence errors. Specifying serial numbers as key is safer. You should assign your own serial numbers for communication addresses and their comments to be inserted (I), so that the communication address - comment assignment is clear. Ensure that the serial numbers are not already used in the database, unless you want to assign a comment explicitly to an existing communication address. If you assign no numbers, it is assumed that all comments to be inserted belong to the communication addresses to be inserted, and they are assigned by the sequence of the data passed. (This would be appropriate if a comment in another language than the creation language is to assigned to a communication address.) Then the first telephone number comment in German flagged for insertion (I) is assigned to the first telephone number to be inserted. The third fax number comment in English to be inserted (I) is assigned to the third fax number to be inserted specified. In this case you cannot assign a comment to an existing communication address. You need a serial number to do this. If one type of communication address and its comments has serial numbers and another does not, this does not affect the overall functionality. All communication types are processed separately, i.e. if all addresses of a communication type have serial numbers, they are used, even if there are no serial numbers for all or some addresses of another communication type. The addresses of such communication types are processed in the order of their data. You can specify serial numbers for communication addresses to be inserted (I) and omit them for communication addresses to be updated (U) and deleted (D), and vice versa. They are processed separately using serial numbers or the data sequence as appropriate. Communication addresses to be updated (U) or delete (D) must both be passed either completely with or completely without serial numbers. You are on the safe side if you always pass a serial number. You must first read the data to be changed (e.g. using FM BAPI_ADDRESSORG_GETDETAIL), if communication data are also to be changed, to get the communication data serial numbers. The address number of the organization address for the object type and key is returned in the export parameter ADDRESS_NUMBER. Processing warnings and errors are in the table RETURN. To be able to use this function module, the System needs to know how it should determine the assignment between the BOR objects to be processed and the references to the stored addresses. For this purpose, table TSADOBJ for the BOR object type must contain the names of the application tables and fields in which the address references are stored. In addition, the name of the callback function module, with which this address reference can be read, must be noted in table TSADRV. If the relevant table entries do not exist in TSADOBJ and TSADRV, the function module returns an error message in the error table RETURN, and the address of the BOR object cannot be processed further. This function contains no COMMIT command. This is required by the BAPI programming guidelines from Release 4.0. See OSS note 131838. The result is returned in the communication data transfer structures BAPIADTEL, BAPIADFAX, ... , BAPIADPAG and their comment transfer structure BAPICOMREM, if no exception error ('E') occurred in the BAPI processing. So if a communication address has been processed, BAPIAD* contains the data as they are in the database, or would be after the next COMMIT. For example the field 'TEL_NO' is filled with a complete telephone number. More importantly, the communication address serial numbers used are also returned. This is particularly useful for new communication addresses. If a communication address or comment could not be processed, the error flag 'ERRORFLAG' is set to 'X' and the serial number 'CONSNUMBER' to '000' in its row in the BAPIAD* structure. To maintain address communication data with this BAPI: after you have created, changed or deleted communication data one number must be flagged as the standard number (STD_NO = 'X'). Assign a serial number (CONSNUMBER) to each communication address. This preserves the assignment between communication addresses and any comments which you may maintain, possibly in several languages. You can choose these numbers when creating, but they may be changed when saving, if for example they already exist. Use the serial numbers which are saved in the database to change or delete communication addresses.