This appendix covers the following topics:
You can use this API if you have a custom interface that makes it difficult to use with the existing interfaces in Oracle Assets. The Unit Adjustment API uses the FA_UNIT_ADJ_PUB.DO_UNIT_ADJUSTMENT() procedure. You can use this API if you have a custom interface that makes it difficult to use with the existing interfaces in Oracle Assets.
The Unit Adjustment API provides the following functionality:
The Unit Adjustment API automatically adjusts assets in all the tax books that are associated with the corporate book where the unit adjustment transaction originated.
If you have set up alternate ledger currency , when you add or modify assets using an Oracle Assets API, the API copies the transactions to the reporting currencies automatically. Invoice rounding issues are avoided by using the API to drive the alternate ledger currency accounting for both the ledger and reporting currencies.
Related Topics
Unit Adjustment API Description
Sample Script: Using the Unit Adjustment API
All transaction APIs use a basic shared framework to simplify the understanding of how the APIs work and to minimize redundancy in coding. In Unit Adjustment API, the common structures used include the following:
TRANS_REC_TYPE
ASSET_HDR_REC_TYPE
ASSET_DIST_TBL_TYPE (table of ASSET_DIST_REC_TYPE)
See Common Structures for description of shared framework and definition of structures listed above.
You must call the FA_UNIT_ADJ_PUB.DO_UNIT_ADJUSTMENT () API to perform adjustment transactions. The following table provides the arguments, types, value, and descriptions of the elements in the FA_UNIT_ADJ_PUB.DO_UNIT_ADJUSTMENT procedure.
Each argument has a prefix of P, X, or PX. These prefixes mean the following:
P - indicates an In argument
X - indicates an Out argument
PX - indicates an argument that is both In and Out
Argument | Type | Value | Description |
---|---|---|---|
P_API_VERSION | NUMBER | Internal use only | Version of the API in use. |
P_INIT_MSG_LIST | VARCHAR2 | FND_API.G_TRUE - Initialize the message stack. FND_API.G_FALSE - Do not initialize the message stack (Default). |
Determines whether the messages stack should be initialized and cleared. |
P_COMMIT | VARCHAR2 | FND_API.G_TRUE - Commit automatically. FND_API.G_FALSE - Do not commit automatically (Default) |
Commits the transaction. |
P_VALIDATION_LEVEL | NUMBER | FND_API.G_VALID_ LEVEL_NONE - Low level validation for a transaction. FND_API.G_VALID_ LEVEL_FULL - High level validation for a transaction (Default). |
Asset validation by the API. |
P_CALLING_FN | VARCHAR2 | Function calling the API | |
X_RETURN_STATUS | VARCHAR2 | FND_API.G_RET_STS_ SUCCESS - Indicates a successful transaction. FND_API.G_RET_STS_ ERROR - Indicates a failed transaction. FND_API.G_RET_STS_ UNEXP_ERROR - Indicates an unexpected error. |
Determines if the API is successful. |
X_MSG_COUNT | NUMBER | Number of messages on the message stack. | |
X_MSG_DATA | FA_API_TYPES.MSG_REC_TYPE | The part of the API that stores messages to be passed to the user. | |
PX_TRANS_REC | FA_API_TYPES. TRANS_REC_TYPE | Describes the transaction taking place. | |
PX_ASSET_HDR_REC | FA_API_TYPES. ASSET_HDR_REC_ TYPE | Unique identifiers for the assets. | |
PX_ASSET_DIST_TBL | FA_API_TYPES. ASSET_DIST_TBL_ TYPE | Distribution information of the asset. |
The TRANS_REC_TYPE transaction structure contains information about the transaction, such as the transaction header ID and the transaction type code. The following table shows type and value information for each argument.
Argument | Required / Optional | Type | Value |
---|---|---|---|
TRANSACTION_DATE_ ENTERED | Optional | DATE | Populate if you are doing previous period unit adjustment, else do nothing or set it to null. Defaults to current period. |
TRANSACTION_NAME | Optional | VARCHAR2(20) | Enter comments for this transaction. |
DESC_FLEX | Optional | DESC_FLEX_REC | Enter descriptive flexfield information. |
WHO_INFO | Optional | STANDARD_WHO_REC_TYPE | Defaults to the following values: LAST_UPDATE_DATE - SYSDATE LAST_UPDATED_BY - FND_GLOBAL.USER_ID CREATED_BY - FND_GLOBAL.USER_ID LAST_UPDATE_LOGIN - FND_GLOBAL.LOGIN_ID |
CALLING_INTERFACE | Optional | VARCHAR2(30) | Enter the interface name that calls the API. Defaults to CUSTOM. |
TRANSACTION_ HEADER_ID | Optional | NUMBER(15) |
The ASSET_HDR_REC_TYPE asset structure contains unique identification information for a given asset, such as the asset ID and book type code. The following table shows type and value information for each argument.
Argument | Required / Optional | Type | Value |
---|---|---|---|
ASSET_ID | Required | NUMBER(15) | Asset ID. |
BOOK_TYPE_CODE | Required | VARCHAR2(15) | Book type code. |
The ASSET_DIST_REC_TYPE asset structure contains information that represents a single source or destination distribution line. All the ASSET_DIST_REC_TYPE records comprising a single unit adjustment transaction are contained in the ASSET_DIST_TBL table. At least one source line and at least one destination line are required for each unit adjustment transaction. The following table shows type and value information for each argument.
Argument | Required / Optional | Type | Value |
---|---|---|---|
DISTRIBUTION_ID | NUMBER(15) | Unique distribution identification number. | |
TRANSACTION_UNITS | NUMBER | Number of units involved in the transaction. | |
ASSIGNED_TO | NUMBER(15) | Employee identification number. | |
EXPENSE_CCID | NUMBER(15) | Depreciation expense account identification number. | |
LOCATION_CCID | NUMBER(15) | Location flexfield identification number. |
The asset has one unit with one distribution line. You now want to adjust to a total of two units, and assign the new unit to a new distribution line. To accomplish this, you need to populate the distribution lines as illustrated in the table below:
Argument | Row 1 |
---|---|
DISTRIBUTION_ID | |
TRANSACTION_UNITS | 1 |
ASSIGNED_TO | 20 |
EXPENSE_CCID | 1234 |
LOCATION_CCID | 7777 |
The table above shows one new unit being created with new distribution information. Also, DISTRIBUTION_ID, ASSIGNED_TO, EXPENSE_CCID, and LOCATION_ID should all have valid IDs.
The asset has a total of two units and two distribution lines, one unit in each distribution line. For this example, you want to increase total units to four, by adding one unit to each existing line. To accomplish this, you need to populate the distribution lines as illustrated in the table below:
Argument | Row 1 | Row 2 |
---|---|---|
DISTRIBUTION_ID | 1111 | 2222 |
TRANSACTION_UNITS | 1 | 1 |
ASSIGNED_TO | ||
EXPENSE_CCID | ||
LOCATION_CCID |
The table above shows one unit being added to distribution #1111 and one unit to distribution #2222.
The following example shows how to call public Unit Adjustment API for unit adjustment transaction. This example increases total units from two to four, and distributes the two new units to existing distributions.
set serveroutput on; declare l_trans_rec fa_api_types.trans_rec_type; l_asset_hdr_rec fa_api_types.asset_hdr_rec_type; l_asset_dist_tbl fa_api_types.asset_dist_tbl_type; l_return_status VARCHAR2(1); l_mesg_count number; l_mesg varchar2(512); begin dbms_output.enable(1000000); fa_srvr_msg.init_server_message; -- fill in asset information l_asset_hdr_rec.asset_id := &asset_id -- fill in distribution data for existing distribution lines -- affected by this unit adj txn. Note: You need to fill in -- only affected distribution lines. -- -- For source distribution, you must fill in either existing -- distribution id or 2 columns(expense_ccid,location_ccid) or -- 3-tuple columns(assigned_to,expense_ccid, and location_ccid) -- depending on the makeup of the particular distribution -- of the asset. -- -- NOTE: you can add to existing, subtract from existing, -- add new, or a combination of these -- Option 1 - Impacts to existing distributions l_asset_dist_tbl(1).transaction_units := &trx_units -- Option 1a - known dist id l_asset_dist_tbl(1).distribution_id := &existing_dist_id -- or -- Option 1b - Existing distribution - known dist attributes l_asset_dist_tbl(1).assigned_to := &existing_assigned_to l_asset_dist_tbl(1).expense_ccid := &existing_epense_ccid l_asset_dist_tbl(1).location_ccid := &existing_location_id -- and/or -- Option 2 - Completely new Distributions -- fill in dist info for one or more destination distribution (start with 2..(3,4,..)) l_asset_dist_tbl(2).transaction_units := &trx_units2 l_asset_dist_tbl(2).assigned_to := &new_assigned_to l_asset_dist_tbl(2).expense_ccid := &new_expense_ccid l_asset_dist_tbl(2).location_ccid := &new_location_id FA_UNIT_ADJ_PUB.do_unit_adjustment( -- std parameters p_api_version => 1.0, p_init_msg_list => FND_API.G_FALSE, p_commit => FND_API.G_FALSE, p_validation_level => FND_API.G_VALID_LEVEL_FULL, p_calling_fn => NULL, x_return_status => l_return_status, x_msg_count => l_mesg_count, x_msg_data => l_mesg, -- api parameters px_trans_rec => l_trans_rec, px_asset_hdr_rec => l_asset_hdr_rec, px_asset_dist_tbl => l_asset_dist_tbl); --dump messages l_mesg_count := fnd_msg_pub.count_msg; if l_mesg_count > 0 then l_mesg := chr(10) || substr(fnd_msg_pub.get (fnd_msg_pub.G_FIRST, fnd_api.G_FALSE), 1, 250); dbms_output.put_line(l_mesg); for i in 1..(l_mesg_count - 1) loop l_mesg := substr(fnd_msg_pub.get (fnd_msg_pub.G_NEXT, fnd_api.G_FALSE), 1, 250); dbms_output.put_line(l_mesg); end loop; fnd_msg_pub.delete_msg(); end if; if (l_return_status <> FND_API.G_RET_STS_SUCCESS) then dbms_output.put_line('FAILURE'); else dbms_output.put_line('SUCCESS'); dbms_output.put_line('THID' || to_char(l_trans_rec.transaction_header_id)); end if; end; /