Ansicht
Dokumentation
BAPI_STUDENT_ADDRESS_CHANGE - Method: Change Student Address
Vendor Master (General Section) ABAP Short ReferenceThis documentation is copyright by SAP AG.
Functionality
With this BAPI you can change the relevant address for the business partner in question.
The system checks that the business partner and the address exist, and then checks the new data for consistency and Customizing settings. Any errors that occur are logged and issued in the RETURN table. If any of the checks run across errors, the address changes are not carried out.
Depending on the business partner category of the business partner you have entered, either the address of a person or that of an organization is changed.
This module differs from the standard change BAPIs in that you are not only able to change existing
entries, but you can also delete or add telephone numbers and fax numbers, and so on, that are appended to an address as attributes.
Use reference structure bars (check bars) to select entries that you want to change.
If the appropriate settings have been made in the system, a duplicate check is carried out when an address is changed. If a record that is to be created is recognized as already existing in the system, the addresses that are similar to this record are returned in the table ADDRESSDUPLICATES.
If the tool used for the duplicate check offers the possibility, the probability in percent of the current record being a duplicate is returned in the table ADDRESSDUPLICATES.
In order to maintain international address versions, use the tables BAPIADVERSORG, BAPIADVERSORG_X and BAPIADVERSPERS or BAPIADVERSPERS_X. You can maintain international address versions for organizations and groups with the tables BAPIADVERSORG and BAPIADVERSORG_X. You maintain international address versions for persons with the tables BAPIADVERSPERS and BAPIADVERSPERS_X.
At present you only extend existing addresses by adding address versions. Address versions are inserted (I), changed (U) or deleted (D) using the change indicator (BAPIADVERSORG_X-UPDATEFLAG or BAPIADVERSPERS_X-UPDATEFLAG).
Time Dependency
The following applies to the temporal validity of address usages: there is only one standard address at any time during the entire validity of the addresses. This address usage is created automatically if necessary. As long as there is one valid address, only a new address can become the standard address instead of the current standard address. By adding an address usage in table ADDRESSUSAGE, the new address can be made the standard address.
It is possible to remove a standard address if there is one other address usage that is available to be the new standard address. This automatically becomes the new standard address.
There can also be other address usages. If there is more than one address for an address usage, you can use the indicator ADDRESSUSAGE-STANDARDADDRESSUSAGE to determine the standard address within this usage.
The fields ADDRESSTYPE and USAGEVALIDTO (corresponding to the key of the table BUT021_FS) form the key of an address usage. Therefore, when you change an address usage, the field VALIDTOREADFORCHANGE must be stated in order to identify the usage to be changed. (If the valid-to date should be changed, USAGEVALIDTO must be used for the new validity end.)
The fields USAGEVALIDFROM and STANDARDADDRESSUSAGE are, on the other hand, attributes of the usage.
If an address exists in an address usage in different validity periods, then the usage to be changed must be specified in more detail by entering the field ADDRESSUSAGE-USAGEVALIDTO. The other key fields of this transaction are the address number and ADDRESSUSAGE-ADDRESSTYPE. This means that there is a change to a usage if the flag STANDARDADDRESSUSAGE or USAGEVALIDFROM should be changed. In this case the UPDATEFLAG must be set to 'U' in table ADDRESSUSAGE_X.
Example
Partner 1 has the following addresses:
| Address(GUID) | Valid from | Valid to |
|---|---|---|
| 11 | 01.01.2000 | 31.12.9999 |
| 12 | 01.01.2000 | 31.12.9999 |
| 13 | 01.01.2000 | 31.12.2004 |
Application examples for changes to the address usages:
- You want to make the address with the address(GUID) 13 into the standard address from the 01.01. 2003 to the 31.12.2003.
| Before the change: | ||||
|---|---|---|---|---|
| Address usage | Valid from | Valid to | Address(GUID) | Standard flag |
| Standard address | 01.01.2000 | 31.12. 2004 | 11 | |
| Standard address | 01.01.2005 | 31.12.2010 | 12 | |
| Standard address | 01.01.2011 | 31.12.9999 | 11 | |
| Correspondence address | 01.01.2001 | 31.12.2004 | 13 | Standard |
- ADDRESSGUID,,,,,,,,= 13
- ADDRESSUSAGE-ADDRESSTYPE,, = 'XXDEFAULT'.
- ADDRESSUSAGE-USAGEVALIDFROM,,= '20030101'.
- ADDRESSUSAGE-USAGEVALIDTO ,,= '20031231'.
- ADDRESSUSAGE_X-UPDATEFLAG = 'I'.
| Result: | ||||
|---|---|---|---|---|
| Address usage | Valid from | Valid to | Address(GUID) | Standard flag |
| Standard address | 01.01.2000 | 31.12.2002 | 11 | |
| Standard address | 01.01.2003 | 31.12.2003 | 13 | |
| Standard address | 01.01.2004 | 31.12.2004 | 11 | |
| Standard address | 01.01.2005 | 31.12.2010 | 12 | |
| Standard address | 01.01.2011 | 31.12.9999 | 11 | |
| Correspondence address | 01.01.2001 | 31.12.2004 | 13 | Standard |
The validity of the standard address with the GUID 11 is automatically adapted.
- There are two possibilities if you want to extend the validity of the address with the GUID12 as the standard address till 2015.
- The following procedure is possible, since the current usages are adapted when a standard address is created:
- ADDRESSGUID,,,,,,,,= 12.
- ADDRESSUSAGE-ADDRESSTYPE ,,= 'XXDEFAULT'.
- ADDRESSUSAGE-USAGEVALIDFROM ,,= '20050101'.
- ADDRESSUSAGE-USAGEVALIDTO ,,= '20151231'.
- ADDRESSUSAGE_X-UPDATEFLAG = 'I'.
- Or changing the valid to date":
- ADDRESSGUID,,,,,,,, ,,= 12 .
- ADDRESSUSAGE-ADDRESSTYPE ,,,,= 'XXDEFAULT'.
- ADDRESSUSAGE-VALIDTOREADFORCHANGE = '20101231'.
- ADDRESSUSAGE-USAGEVALIDTO ,,,,= '20151231'.
- ADDRESSUSAGE-USAGEVALIDTO = 'X'.
- ADDRESSUSAGE_X-UPDATEFLAG = 'U'.
| Result: | ||||
|---|---|---|---|---|
| Address usage | Valid from | Valid to | Address(GUID) | Standard flag |
| Standard address | 01.01.2000 | 31.12. 2002 | 11 | |
| Standard address | 01.01.2003 | 31.12.2003 | 13 | |
| Standard address | 01.01.2004 | 31.12.2004 | 11 | |
| Standard address | 01.01.2005 | 31.12.2015 | 12 | |
| Standard address | 01.01.2016 | 31.12.9999 | 11 | |
| Correspondence address | 01.01.2001 | 31.12.2004 | 13 | Standard |
- You want to limit the usage of address (GUID) 11 as the standard address untill the end of 2000. Since there are several addresses that could be the new standard address from 01.01.2001 (either address (GUID) 12 or 13, because both addresses are valid at that time), this is not possible as a deletion/change (UPDATEFLAG = 'D' / UPDATEFLAG = 'U'), but again only as an insert of the new address usage (see previous examples). The validity of the address (GUID) 11 is then automatically limited.
- You want to a delete the address (GUID) 13 as the correspondence address. However the value '0001' corresponds to the address usage "correspondence address" (see table TB009).
- ADDRESSGUID ,,,,,,,,,,,,= 13.
- ADDRESSUSAGE-ADDRESSTYPE ,,,,,,= '0001'.
- ADDRESSUSAGE-VALIDTOREADFORCHANGE ,,= '20041231'.
- ADDRESSUSAGE_X-UPDATEFLAG ,,,,,,= 'D'.
- The standard address (address type XXDEFAULT) can also be influenced with the field ADDRESSDATA_X-STANDARDADDRESS. This field is obsolete. It may not be used in conjunction with the table ADDRESSUSAGE.
Example
Notes
If you do not state an address GUID when you call this module, the system assumes that you want to change the standard address of this business partner.
If you want to delete a telephone number in the table of existing telephone numbers for a certain address, for example, the UPDATEFLAG field in the reference structure bar of the corresponding line must contain a "D". If you want to add an entry, this field has to contain an "I". When a reference structure bar is flagged with "I", you must also provide corresponding data for insertion. All new line-type entries that you want to add, including the related reference structure bars, must be placed after all the entries you want to change (U) and delete (D).
With change data, the key fields must always be filled with data, and will be considered as far as possible.
It is thus of no importance, for example, whether all remarks for a telephone number are listed as change
data before the remarks for the fax number, or vice-versa, unless you completely omit the sequence numbers
for communication addresses or remarks, or only state them in part. In this case, the sequence of data plays a major role.
The following fields are regarded as being key fields:
| Structure | Fields |
|---|---|
| BAPIAD1VL | ADDR_VERS, FROM_DATE |
| BAPIAD_REM | ADDR_VERS, LANGU |
| BAPIADTEL | CONSNUMBER |
| ... | ... |
| BAPIADPAG | CONSNUMBER |
| BAPICOMREM | COMM_TYPE, CONSNUMBER, LANGU |
It is possible to transfer blank sequence numbers for communication addresses and remarks. In this case, the sequence in which the data was transferred counts. For example, if you want to delete the telephone number that is in second position in the list of existing telephone numbers whose sequence numbers are sorted in ascending order, with this function module you firstly have to transfer a dummy telephone number line with the update flag (U), without marking fields for updating, and then you have to transfer a telephone number line with the deletion flag (D).
You should be aware that the communication addresses stored in the database are not usually sorted according to sequence numbers. You therefore first have to determine the sequence of the communication addresses sorted according to sequence numbers. You are advised not to follow the above procedure, as it is very easy to make mistakes when assigning data. It is much safer to enter the sequence numbers as the key.
You should assign your own sequence numbers with communication addresses that you want to create (I), and with the related addresses, so that the assignment of the communication address to a remark is clear. You only have to make sure that the sequence numbers are not yet in use in the database, unless you explicitly want to assign a remark to an existing communication address. If you omit the number assignment, the system assumes that all remarks to be inserted belong to the communication addresses to be added, and not to existing communication addresses. (This would only make sense if you want to add a remark in a different language to the one in which a communication address was created).
Assignment takes place exclusively by way of the sequence of the data transferred. The first German language remark entered for a telephone number, that has been flagged for creation (I), is assigned to the first telephone number you have said you want to add. The third English language remark on a fax number with the insertion flag (I) is assigned to the third fax number you have said you want to add.
In this case, it is not possible to add a remark to a communication address that already exists. Here you always require the correct sequence number.
If the sequence numbers are filled in the case of one category of communication addresses and their remarks, but not with another category, this has no effect on the overall functionality. All communication types are processed separately. In other words, if complete sequence numbers are stated with a communication type, they are considered, even if the sequence numbers with another communication type are missing in full or part. In the latter two cases, the sequence of data to be processed is used.
You can state the sequence numbers with the communication addresses you want to insert (I), and omit them with the communication addresses you want to update (U) and delete (D), and vice-versa. Separate processing then takes place per case (sequence numbers or sequence of data). Only communication addresses that you want to update or delete have to be transferred together, whereby the sequence numbers have to be complete or not exist at all. To be on the safe side you should always state complete sequence numbers with all data.
Data that you want to change should be read in advance (for example, with FM BAPI_ADDRESSORG_GETDETAIL), in case communication data should also be changed, so that you know the sequence numbers of the communication data.
Temporal Validity of Communication Data
The communication data for an address (e.g. table BAPIADTEL ...) can be restricted with regard to time. A date with the format YYYMMDD can be entered aligned to the left in the fields VALID_FROM and VALID_TO. The exact time is not taken into account. The communication data is valid only as long as the address is valid. If necessary, the date fields are adapted without an error message.
Further information
Parameters
ACCEPT_ERRORADDRESSDATA
ADDRESSDATA_X
ADDRESSDUPLICATES
ADDRESSGUID
ADDRESSUSAGE
ADDRESSUSAGE_X
BAPIADFAX
BAPIADFAX_X
BAPIADPAG
BAPIADPAG_X
BAPIADPRT
BAPIADPRT_X
BAPIADRFC
BAPIADRFC_X
BAPIADRML
BAPIADRML_X
BAPIADSMTP
BAPIADSMT_X
BAPIADSSF
BAPIADSSF_X
BAPIADTEL
BAPIADTEL_X
BAPIADTLX
BAPIADTLX_X
BAPIADTTX
BAPIADTTX_X
BAPIADURI
BAPIADURI_X
BAPIADUSE
BAPIADUSE_X
BAPIADVERSPERS
BAPIADVERSPERS_X
BAPIADX400
BAPIADX40_X
BAPIAD_REM
BAPIAD_RE_X
BAPICOMREM
BAPICOMRE_X
DUPLICATE_MESSAGE_TYPE
OBJECTID
PLANVERSION
RETURN
Exceptions
Function Group
HRPIQ00STUDENTBAPIVendor Master (General Section) Addresses (Business Address Services)
This documentation is copyright by SAP AG.
Length: 23134 Date: 20240523 Time: 174435 sap01-206 ( 300 ms )
