The organization address is determined from the specified object type and object key, and updated with the specified address andcommunication data, if required.
This module differs from a standard change BAPI in that not only canexisting 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.
* 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
objtype = 'KNA1'.
obj_id = <customer number>.
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'
obj_type = objtype
obj_id = obj_id
obj_id_ext = obj_id_ext
context = context
address_number = address_number
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.
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 intoaccount as far as possible. It is not significant whether, e.g. alltelephone number comments are followed by fax number comments as changedata, 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 issignificant .
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 secondposition in the in ascending order of serial numbers sorted existingtelephone numbers, in the database, you must pass a dummy telephone
number with update flag (U) in the first position, without selectingfields to update, and a telephone number with delete flag (D) in the second position.
The communication addresses in the database are usually not sorted byserial 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 addressesand their comments to be inserted (I), so that the communication
address - comment assignment is clear. Ensure that the serial numbersare not already used in the database, unless you want to assign acomment explicitly to an existing communication address. If you assignno numbers, it is assumed that all comments to be inserted belong to
the communication addresses to be inserted, and they are assigned bythe sequence of the data passed. (This would be appropriate if acomment in another language than the creation language is to assignedto a communication address.) Then the first telephone number comment in
German flagged for insertion (I) is assigned to the first telephonenumber to be inserted. The third fax number comment in English to beinserted (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 overallfunctionality. 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 ofanother 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 beinserted (I) and omit them for communication addresses to be updated
(U) and deleted (D), and vice versa. They are processed separatelyusing serial numbers or the data sequence as appropriate. Communicationaddresses 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 FMBAPI_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 associate the BOR object types to be used to their addresses.
The table TSADOBJ must contain the BOR object type application tables
and address reference fields. The address reference read callback function module must be in table TSADRV.
If TSADOBJ and TSADRV do not contain these entries, the function moduleputs a message in the error table RETURN, and the BOR object address cannot be processed.
This function contains no COMMIT command as required by the BAPI programming guidelines from Release 4.0.
See OSS note 131838.
The result is returned in the communication data transfer structuresBAPIADTEL, 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 thedata 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 usedare also returned. This is particularly useful for new communication addresses.
If a communication address or comment could not be processed, the errorflag '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.