The Rollback Depreciation API FA_DEPRN_ROLLBACK_PUB.DO_ROLLBACK was introduced with Release 12. In prior releases, FADRB - Rollback Depreciation program was available in order to rollback the depreciation calculation after it was run for a book without closing the period. In Release 12, this program is no longer available because a new feature was introduced - automatic depreciation rollback. With this new feature, after running depreciation for a book without closing the period, if additional transactions are needed on particular assets (adjustment, retirement etc.), the user can update those assets with whatever transaction is needed. For those particular assets, the depreciation data is automatically rolled back and the transactions can be performed on them. After this, the user can run depreciation again to depreciate these particular assets. *Note that the rollback is also completed for asset description changes per Note 1463816.1. Instead of entering additional transactions, in case it is not needed, you can manually rollback depreciation for an asset by running the Rollback Depreciation API which restores the asset to its state prior to running depreciation. This may be useful for the purpose of testing some setup behavior. You can find details about this API in Oracle Assets Users' Guide Release 12. A sample script is provided below. The ASSET_HDR_REC_TYPE asset structure contains unique identification information for a given asset, such as the asset ID and book type code. Both variables are required when running the API. Steps 1) Run depreciation without closing the period 2) Run the Rollback Depreciation API procedure FA_DEPRN_ROLLBACK_PUB.DO_ROLLBACK for an asset/book Code (SQL): SET serveroutput ON DECLARE l_asset_hdr_rec fa_api_types.asset_hdr_rec_type; l_return_status VARCHAR2(1); l_mesg_count NUMBER; l_mesg varchar2(4000); BEGIN dbms_output.enable(1000000); FA_SRVR_MSG.Init_Server_Message; -- asset header info l_asset_hdr_rec.asset_id := &asset_id; l_asset_hdr_rec.book_type_code := '&book'; --call the api FA_DEPRN_ROLLBACK_PUB.do_rollback (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, px_asset_hdr_rec => l_asset_hdr_rec); --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'); END IF; END; / 3) If the script returns SUCCESS, issue a commit. Code (SQL): COMMIT; The asset is restored to its state prior to running depreciation. Depending on the status before the rollback, the API takes appropriate action: Rows are deleted from FA_DEPRN_SUMMARY and FA_DEPRN_DETAIL for this asset /book and period_counter. If the Create Accounting program was not run yet or only in Draft mode, i.e., the depreciation event was not processed, the event is simply deleted. If Create Accounting was run in Final mode, then the Depreciation event was Processed (XLA_EVENTS.EVENT_STATUS_CODE=P ) and Rollback generates a ROLLBACK_DEPRECIATION event in order to reverse the prior depreciation event. When Transfer to GL is run, a Depreciation Journal entry will be sent to GL to reverse the prior entry. Depreciation Override is not an API, as such direct entry of the data to the fa_deprn_override table is not a triggering event for Depreciation Rollback. And when periodic depreciation already exists on any assets with new POST rows in the fa_deprn_override table, those overrides will not be processed since only assets without depreciation for the open period are picked up by the next Depreciation Run process. The workaround is to do a two step process for inserting data into fa_deprn_override: 1) For each asset you wish to do the insert for, check if a current period row exists in fa_deprn_summary and if it does, submit the Depreciation Rollback API to rollback open period depreciation. Then: 2) Insert the row into the fa_deprn_override table. This way, the Override will be processed by the subsequent Depreciation run. An API has been requested via Enhancement Request Bug 9022136. Information on how to call the Depreciation Rollback API can be found in How To Run Depreciation Rollback API In Release 12? (Doc ID 578422.1).