AddressOrg

No description is available

Available Methods

• Change : BAPI to change organization addresses [ BAPI_ADDRESSORG_CHANGE ]
  
• GetDetail : BAPI to read organization addresses [ BAPI_ADDRESSORG_GETDETAIL ]
  
• SaveReplica : BAPI for inbound distribution of organizational addresses [ BAPI_ADDRESSORG_SAVEREPLICA ]
  

Change

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.

Example

* Change an organization address:

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 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.

GetDetail

The address data of the organization address for the specified object type and key is returned.
The address number used in the current system is also returned.

Example

* Read an organization address:

Notes

The sequence of the communication data and comments in the tables is the serial numbers of the data in the specified system.
The organization address number 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.

SaveReplica

The organization address is determined from the specified object typeand key, and overwritten by the specified current address and communication data. This module is usually called by the ALE functionmodule IDOC_INPUT_ADRMAS.

Example

* Replicate an organization address: copy the current status in the

An ALE IDOC is created and distributed in AB1 by the module ALE_ADDRESSORG_SAVEREPLICA after the function moduleMASTERIDOC_CREATE_REQ_ADRMAS has been called.
When the IDOC arrives in AB2, it is read by the moduleIDOC_INPUT_ADRMAS, and its data are passed to the module BAPI_ADDRESSORG_SAVEREPLICA. The object type OBJ_TYPE, the object key
OBJ_ID, the object key extension OBJ_ID_EXT, and the context CONTEXT are the same as in the source system.
For example, values are assigned as follows in the (main) customer address:
Object type: 'KNA1'
Object key: <customer number>
(extension empty): ' '

context: '0001'

The module call is as follows:

DATA: bapiad1vl  like bapiad1vl occurs 0,

The data for address number ADDRNUMBER has now been updated in AB2.

Note

Error messages are in the return structure RETURN.
The valid organization address number for the target system is returned
in the ADDRESS_NUMBER parameter.

The result is returned in the communication data transfer structuresBAPIADTEL, BAPIADFAX, ... , BAPIADPAG and their comment transferstructure 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 telephonenumber. 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 errorflag 'ERRORFLAG' is set to 'X' and the serial number 'CONSNUMBER' to '000' in its row in the BAPIAD* structure.