Skip Headers

Oracle Receivables Reference Guide
Release 12.1
Part Number E13512-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Adjustment API User Notes

Overview

This document outlines the use of the Adjustment API. This API allows users to create, approve, update, and reverse adjustments for invoices using simple calls to PL/SQL functions.

The Adjustment API is not intended to replace the existing Adjustment form, Adjustment Approval form, or the batch Auto-Adjust program.

Note: The Adjustment API requires the following receivable activity setup: the GL Account Source must be Activity.

You can access the API in two ways:

API Usage

To create, modify, approve, or reverse adjustments, use the following routines:

The Adjustment API has a defaulting mechanism for input parameters. This lets you create, approve, update, and reverse adjustments while passing a minimal number of API parameters.

Note: You can pass an adjustment account and override the default account (derived from the adjustment's receivable activity), provided that:

The following table shows standard API parameters that are common to all routines in the Adjustment API:

Parameter Type Data-type Required Default Value Description
p_api_version IN NUMBER Yes   Used to compare version numbers of incoming calls to its current version number.
p_init_msg_list IN VARCHAR2   FND_API.G_FALSE Allows API callers to request that the API does initialization of the message list on their behalf.
p_commit IN VARCHAR2   FND_API.G_FALSE Used by API callers to ask the API to commit on their behalf.
p_validation_level IN NUMBER   FND_API.G_VALID_LEVEL_FULL Not currently for use by the user. Allow this parameter to default.
p_return_status OUT VARCHAR2     Represents the API overall return status. For possible values, see Error Handling.
p_msg_count OUT NUMBER     Number of messages in the API message list
p_msg_data OUT VARCHAR2     This is the message in encoded format if p_msg_count=1

Ar_Adjust_pub.Create_Adjustment

Use this routine to create adjustments to invoices. The API returns the Out parameter p_new_adjust_id, which represents the newly-created adjustment ID. The following is a breakdown of parameters for this routine, divided according to parameter type:

Input Parameters

Standard API parameters: 4

Create Adjustment parameters: 6 required parameters (might vary depending on the adjustment type)

Output Parameters

Standard API parameters: 3

Create Adjustment parameters: 2

Since the Create Adjustment API allows users to pass the adjustment record type to the procedure, it is not recommended that users enter values for unnecessary fields. These fields could be populated for internal use only.

Parameter Descriptions

The following table lists parameters that pertain specifically to the Create Adjustment routine:

Parameter Type Data-type Required Default Value Description
p_adj_rec.type IN VARCHAR2 Yes   The type of adjustment to be created. Possible Values: 'INVOICE', 'LINE', 'TAX', 'FREIGHT', 'CHARGES', 'FINCHRG'
p_adj_rec.payment_schedule_id IN NUMBER Yes   Payment Schedule id of the transaction for which the transaction is to be created.
p_adj_rec.amount IN NUMBER Yes/No   If the adjustment type is any other value than 'INVOICE' then this is a required field. The amount indicates the amount to be adjusted.
p_adj_rec.customer_trx_line_id IN NUMBER Yes/No   If the adjustment type is 'LINE' then the customer_trx_line_id indicates the line to be adjusted. For all the other adjustment types the value is not required.
p_adj_rec.receivables_trx_id IN NUMBER Yes   The id of the activity name (from ar_receivables_trx) should be passed.
p_adj_rec.code_combination_id IN NUMBER No   The code combination id is not required. If the value is not passed, then the default is the code combination id specified in the receivables_trx_id record. If the value passed is not the same as the code_combination_id and the AR: Override Adjustment Activity Account Option profile option is set to No, then this would error out.
p_adj_rec.apply_date IN DATE Yes   The apply date should be equal to or greater than the transaction date.
p_adj_rec.gl_date IN DATE Yes   The gl date should be equal to or greater than the transaction gl date, and the date should be from the open/future period.
p_adj_rec.reason_code IN VARCHAR2 No   The reason code should a valid reason code in ar_lookups with lookup_type = 'ADJUST_REASON'.
p_adj_rec.comments IN VARCHAR2 No   The user can enter comments, up to 2000 bytes, for creating the adjustments which could be useful for the user, for future reference.
p_adj_rec.associated_cash_receipt_id IN NUMBER No   The associated cash receipt id is the id of a valid cash receipt, and is to be associated with the adjustment.
p_adj_rec.ussgl_transaction_code IN VARCHAR2 No   The USSGL transaction code should be a valid USSGL transaction code in gl_ussgl_transaction_codes.
p_adj_rec.created_from IN VARCHAR2 Yes   Some value that indicates to the user that it was created through the Adjustment API. Eg. 'ADJ-API'
p_adj_rec.attribute_category, p_adj_rec.attribute1 - p_adj_rec.attribute15 IN VARCHAR2 No   This attribute_category and the attribute1 through attribute15 can be entered if the user want to enter the details of the descriptive flexfield for the adjustment.
p_adj_rec.adjustment_id IN   No. Entered values will be overwritten.    
p_adj_rec.acctd_amount IN   No. Entered values will be overwritten.    
p_adj_rec.gl_posted_date IN   No. Entered values will be overwritten.    
p_adj_rec.set_of_books_id IN   No. Entered values will be overwritten.    
p_adj_rec.adjustment_type IN   No. Entered values will be overwritten.    
p_adj_rec.status IN   No. Entered values will be overwritten.    
p_adj_rec.line_adjusted IN   No. Entered values will be overwritten.    
p_adj_rec.freight_adjusted IN   No. Entered values will be overwritten.    
p_adj_rec.tax_adjusted IN   No. Entered values will be overwritten.    
p_adj_rec.receivables_chages_adjusted IN   No. Entered values will be overwritten.    
p_adj_rec.batch_id IN   No. Entered values will be overwritten.    
p_adj_rec.customer_trx_id IN   No. Entered values will be overwritten.    
p_adj_rec.subsequent_trx_id IN   No. Entered values will be overwritten.    
p_adj_rec.chargeback_customer_trx_id IN   No. Entered values will be overwritten.    
p_adj_rec.distribution_set_id IN   No. Entered values will be overwritten.    
p_adj_rec.associated_application_id IN   No. Entered values will be overwritten.    
p_adj_rec.automatically_generated IN   No. Entered values will be overwritten.    
p_adj_rec.postable IN   No. Entered values will be overwritten.    
p_adj_rec.approved_by IN   No. Entered values will be overwritten.    
p_adj_rec.adjustment_number IN   No. Entered values will be overwritten.    
p_adj_rec.doc_sequence_value IN   No. Entered values will be overwritten.    
p_adj_rec.doc_sequence_id IN   No. Entered values will be overwritten.    
p_adj_rec.posting_control_id IN   No. Entered values will be overwritten.    
p_adj_rec.last_updated_by IN   No. Entered values will be overwritten.    
p_adj_rec.last_updated_date IN   No. Entered values will be overwritten.    
p_adj_rec.last_updated_login IN   No. Entered values will be overwritten.    
p_adj_rec.created_by IN   No. Entered values will be overwritten.    
p_adj_rec.creation_date IN   No. Entered values will be overwritten.    
p_adj_rec.program_application_id IN   No. Entered values will be overwritten.    
p_adj_rec.program_id IN   No. Entered values will be overwritten.    
p_adj_rec.program_update_date IN   No. Entered values will be overwritten.    
p_adj_rec.request_id IN   No.    
p_chk_approval_limits IN VARCHAR2 No. FND_API.G_TRUE This value can be set to 'F' if the adjusted amount should not be validated against the users approval limit.
p_move_deferred_tax IN VARCHAR2 No. Y This parameter is only used for BR.
p_check_amount IN VARCHAR2 No. FND_API.G_TRUE This value should never be set to 'F'. It is used for some internal logic.
p_new_adjust_number OUT ar_adjustment.adjustment_number%type     If the adjustment is created successfully, then this parameter will contain the value of the new adjustment number.
p_new_adjust_id OUT ar_adjustment.adjustment_id%type     If the adjustment is created successfully, then this parameter will contain the value of the new adjustment id.
p_called_from IN VARCHAR2 No NULL This flag is only used for BR.

Note: If the user passes values for any parameter not reported in the table above, then those values will be ignored and will not show up in the record.

Default values for API parameters derive from the following:

Depending on the user's particular business needs, the minimum number of parameters required to create an adjustment may vary.

Validation of the parameters passed

All the parameters that are passed to the API are validated, and if any of the required fields are missing or invalid, then the API returns an error message. A list of possible error messages appears in Messages.

Example

The following is the simplest test case for creating an adjustment.

Objective:

To create an adjustment, passing the minimum number of parameters.

Entered parameters:

p_adj_rec.type = 'INVOICE',

p_adj_rec.payment_schedule_id = 22222,

p_adj_rec.receivables_trx = 15,

p_adj_rec.apply_date = to_date('12-FEB-00', 'DD-MON-RR'),

p_adj_rec.gl_date = to_date('12-FEB-00', 'DD-MON-RR'),

p_adj_rec.created_from = 'ADJ-API'

Call to the API:

AR_ADJUST_PUB.Create_Adjustment(
     p_api_name          =>   'AR_ADJUST_PUB', 
     p_api_version       =>   1.0,
     p_msg_count         =>   msg_count ,
     p_msg_data          =>   msg_data, 
     p_return_status     =>   return_status,
     p_adj_rec           =>   adj_rec,
     p_new_adjust_number =>   new_adj_num,
     p_new_adjust_id     =>   new_adj_id ); 

Result:

Creates an adjustment, passing two standard required parameters and six adjustment record related parameters.

Ar_Adjust_pub.Approve_Adjustment

Use this routine to approve an adjustment. The following is a breakdown of parameters for this routine, divided according to parameter type:

Input Parameters

Standard API parameters: 4

Approve Adjustment parameters: 1 required parameter

Output Parameters

Standard API parameters: 3

Parameter Descriptions

Although the Approve Adjustments API allows users to pass the adjustment record type to the procedure, all the values are overwritten by the values in the existing adjustment record except for the status and gl_date.

The following table shows parameters that pertain specifically to the Approve Adjustment routine.

Note: If required parameters are not passed in a call to this API, then the call will fail. If values are not required, then the values for those fields will be copied from the existing values of the adjustment.

Parameter Type Data-type Required Default Value Description
p_old_adjust_id IN NUMBER Yes   The id of the adjustment that needs to be approved.
p_adj_rec.type IN VARCHAR2 No    
p_adj_rec.payment_schedule_id IN NUMBER No    
p_adj_rec.amount IN NUMBER No    
p_adj_rec.customer_trx_line_id IN NUMBER No    
p_adj_rec.receivables_trx_id IN NUMBER No    
p_adj_rec.code_combination_id IN NUMBER No    
p_adj_rec.apply_date IN DATE No    
p_adj_rec.gl_date IN DATE No GL date of adjustment The GL date should be entered if it is going to be different from the one in the old adjustment.
p_adj_rec.reason_code IN VARCHAR2 No    
p_adj_rec.comments IN VARCHAR2 No    
p_adj_rec.associated_cash_receipt_id IN NUMBER No    
p_adj_rec.ussgl_transaction_code IN VARCHAR2 No    
p_adj_rec.created_from IN VARCHAR2 No    
p_adj_rec.attribute_category, p_adj_rec.attribute1 - p_adj_rec.attribute15 IN VARCHAR2 No    
p_adj_rec.adjustment_id IN   No    
p_adj_rec.acctd_amount IN   No    
p_adj_rec.gl_posted_date IN   No    
p_adj_rec.set_of_books_id IN   No    
p_adj_rec.adjustment_type IN   No    
p_adj_rec.status IN   No 'A' if the status is null. Possible Value: 'A' which indicates Approval
p_adj_rec.line_adjusted IN   No    
p_adj_rec.freight_adjusted IN   No    
p_adj_rec.tax_adjusted IN   No    
p_adj_rec.receivables_chages_adjusted IN   No    
p_adj_rec.batch_id IN   No    
p_adj_rec.customer_trx_id IN   No    
p_adj_rec.subsequent_trx_id IN   No    
p_adj_rec.chargeback_customer_trx_id IN   No    
p_adj_rec.distribution_set_id IN   No    
p_adj_rec.associated_application_id IN   No    
p_adj_rec.automatically_generated IN   No    
p_adj_rec.postable IN   No    
p_adj_rec.approved_by IN   No    
p_adj_rec.adjustment_nu,mber IN   No    
p_adj_rec.doc_sequence_value IN   No    
p_adj_rec.doc_sequence_id IN   No    
p_adj_rec.posting_control_id IN   No    
p_adj_rec.last_updated_by IN   No    
p_adj_rec.last_updated_date IN   No    
p_adj_rec.last_updated_login IN   No    
p_adj_rec.created_by IN   No    
p_adj_rec.creation_date IN   No    
p_adj_rec.program_application_id IN   No    
p_adj_rec.program_id IN   No    
p_adj_rec.program_update_date IN   No    
p_adj_rec.request_id IN   No    
p_chk_approval_limits IN VARCHAR2 No FND_API.G_TRUE This value can be set to 'F' if the adjusted amount should not be validated against the users approval limit.
p_move_deferred_tax IN VARCHAR2 No Y This flag is used only for Bills Receivable.

Validation of the parameters passed

All the parameters that are passed to the API are validated, and if any required fields areNo missing or invalid, then the API returns an error message. A list of possible error messages appears in Messages.

Example

The following is the simplest test case for approving an adjustment.

Objective:

To approve an adjustment, passing the minimum number of parameters.

Entered parameters:

adjustment_id = 88888;

Call to the API:

AR_ADJUST_PUB.Approve_Adjustment(
     p_api_name           =>   'AR_ADJUST_PUB', 
     p_api_version        =>   1.0,
     p_msg_count          =>   msg_count ,
     p_msg_data           =>   msg_data, 
     p_return_status      =>   return_status,
     p_old_adjust_id      =>   adjustment_id ); 

Result:

Approves an adjustment, passing 2 standard required parameters and 1 adjustment record parameter.

Ar_Adjust_pub.Modify_Adjustment

Use this routine to update an adjustment. The attributes that can be modified are comments, gl date, and status. If the status of the adjustment is already 'A' (i.e. the adjustment has already been approved), then you cannot update the adjustment. The following is a breakdown of parameters for this routine, divided according to parameter type:

Input Parameters

Standard API parameters: 4

Modify Adjustment parameters: 1 required parameter

Output Parameters

Standard API parameters: 3

Parameter Descriptions

Although the Modify Adjustments API allows users to pass the adjustment record type to the procedure, all the values are overwritten by the existing adjustment record except for the status, comments, and gl_date.

The following table shows parameters that pertain specifically to the Modify Adjustments routine.

Note: If required parameters are not passed in a call to this API, then the call will fail. If values are not required, then the values for those fields will be copied from the existing values of the adjustment.

Parameter Type Data-type Required Default Value Description
p_old_adjust_id IN NUMBER Yes   The id of the adjustment that needs to be modified.
P_adj_rec.type IN VARCHAR2 No    
p_adj_rec.payment_schedule_id IN NUMBER No    
p_adj_rec.amount IN NUMBER No    
p_adj_rec.customer_trx_line_id IN NUMBER No    
p_adj_rec.receivables_trx_id IN NUMBER No    
p_adj_rec.code_combination_id IN NUMBER No    
p_adj_rec.apply_date IN DATE No    
p_adj_rec.gl_date IN DATE No GL date of adjustment The GL date should be entered if the user wishes to modify the existing gl date of the adjustment.
P_adj_rec.reason_code IN VARCHAR2 No    
p_adj_rec.comments IN VARCHAR2 No   The comments should be entered if the user wishes to modify the existing comments of the adjustment.
P_adj_rec.associated_cash_receipt_id IN NUMBER No    
p_adj_rec.ussgl_transaction_code IN VARCHAR2 No    
p_adj_rec.created_from IN VARCHAR2 No    
p_adj_rec.attribute_category, p_adj_rec.attribute1 - p_adj_rec.attribute15 IN VARCHAR2 No    
p_adj_rec.adjustment_id IN   No    
p_adj_rec.acctd_amount IN   No    
p_adj_rec.gl_posted_date IN   No    
p_adj_rec.set_of_books_id IN   No    
p_adj_rec.adjustment_type IN   No    
p_adj_rec.status IN   No   The status should be entered if the user wishes to change the existing status of the adjustment. Possible Value: 'A', 'R', 'M', 'W'.
p_adj_rec.line_adjusted IN   No    
p_adj_rec.freight_adjusted IN   No    
p_adj_rec.tax_adjusted IN   No    
p_adj_rec.receivables_chages_adjusted IN   No    
p_adj_rec.batch_id IN   No    
p_adj_rec.customer_trx_id IN   No    
p_adj_rec.subsequent_trx_id IN   No    
p_adj_rec.chargeback_customer_trx_id IN   No    
p_adj_rec.distribution_set_id IN   No    
p_adj_rec.associated_application_id IN   No    
p_adj_rec.automatically_generated IN   No    
p_adj_rec.postable IN   No    
p_adj_rec.approved_by IN   No    
p_adj_rec.adjustment_nu,mber IN   No    
p_adj_rec.doc_sequence_value IN   No    
p_adj_rec.doc_sequence_id IN   No    
p_adj_rec.posting_control_id IN   No    
p_adj_rec.last_updated_by IN   No    
p_adj_rec.last_updated_date IN   No    
p_adj_rec.last_updated_login IN   No    
p_adj_rec.created_by IN   No    
p_adj_rec.creation_date IN   No    
p_adj_rec.program_application_id IN   No    
p_adj_rec.program_id IN   No    
p_adj_rec.program_update_date IN   No    
p_adj_rec.request_id IN   No    
p_chk_approval_limits IN VARCHAR2 No FND_API.G_TRUE This value can be set to 'F' if the adjusted amount should not be validated against the users approval limit.
p_move_deferred_tax IN VARCHAR2 No Y This flag is only used for Y.

Validations of the parameters passed

All the parameters that are passed to the API are validated, and if any of the required fields are missing or invalid, then the API returns an error message. A list of possible error messages appears in Messages.

Example

The following is the simplest test case for updating an adjustment.

Objective:

To update an adjustment, passing the minimum number of parameters. For this example, assume the user wants to update comments.

Entered parameters:

old_adjustment_id = 88888

adj_rec.comments = 'This is the new comment'

Call to the API:

AR_ADJUST_PUB.Create_Adjustment(
     p_api_name           =>   'AR_ADJUST_PUB', 
     p_api_version        =>   1.0,
     p_msg_count          =>   msg_count ,
     p_msg_data           =>   msg_data, 
     p_return_status      =>   return_status,
     p_adj_rec            =>   adj_rec,
     p_old_adjust_id      =>   old_adjustment_id );

Result:

Updates an adjustment, passing two standard required parameters and one adjustment record parameter. Users should also pass values for other parameters that the user wishes to update in the adjustment record.

Ar_Adjust_pub.Reverse_Adjustment

Use this routine to reverse an adjustment. The following is a breakdown of parameters for this routine, divided according to parameter type:

Input Parameters

Standard API parameters: 4

Reverse Adjustment parameters: 1 required parameter

Output Parameters

Standard API parameters: 3

Reverse Adjustment parameters: 1

Parameter Descriptions

The following table shows parameters that pertain specifically to the Reverse Adjustment routine:

Parameter Type Data-type Required Default Value Description
p_old_adjust_id IN NUMBER Yes   The id of the adjustment that needs to be modified.
p_comments IN VARCHAR2 No   The user can specify any comments that should appear in the reverse adjustment.
p_reversal_gl_date IN DATE No Old adjustments gl date The user can enter a gl date if he wishes it to be different from the old adjustments gl date.
p_reversal_date IN DATE No Old adjustments date The user can enter a date if he wishes it to be different from the old adjustments date.
p_new_adj_id OUT NUMBER      
p_chk_approval_limits IN VARCHAR2 No FND_API.G_TRUE This value can be set to 'F' if the adjusted amount should not be validated against the users approval limit.
p_move_deferred_tax IN VARCHAR2 No Y This flag is used only for Bills Receivable.
p_called_from IN VARCHAR2 No NULL This flag is used only for Bills Receivable.

Validation of the parameters passed

All the parameters that are passed to the API are validated, and if any of the required fields are missing or invalid, then the API returns an error message. A list of possible error messages appears in Messages.

Example

The following is the simplest test case for reversing an adjustment.

Objective:

To reverse an adjustment, passing the minimum number of parameters.

Entered parameters:

old_adjustment_id = 88888

Call to the API:

AR_ADJUST_PUB.Reverse_Adjustment(
     p_api_name           =>   'AR_ADJUST_PUB', 
     p_api_version        =>   1.0,
     p_msg_count          =>   msg_count ,
     p_msg_data           =>   msg_data, 
     p_return_status      =>   return_status,
     p_old_adjust_id      =>   old_adjustment_id 
     p_new_adj_id         =>   new_adjustment_id);

Result:

Reverses an adjustment, passing two standard required parameters and one adjustment record parameter.

Ar_Adjust_pub.Create_Linelevel_Adjustment

Use this routine to create adjustments to invoices at line level. This routine uses some parameters that are specific to this routine, and all the Standard API and other input and output parameters used by the Create_Adjustment routine described in Ar_Adjust_pub.Create_Adjustment.

Parameter Descriptions

The following table lists parameters that pertain specifically to the Create_Linelevel_Adjustment routine:

Parameter Type Data-type Required Default Value Description
p_llca_adj_trx_lines_tbl.customer_trx_line_id IN NUMBER Yes   Customer_trx_line_id indicates the line to be adjusted.
p_llca_adj_trx_lines_tbl.receivable_trx_id IN NUMBER Yes   The ID of the activity name (from ar_receivables_trx) should be passed.
p_llca_adj_trx_lines_tbl.line_amount IN NUMBER Yes   The amount indicates the amount to be adjusted (Including Tax amount).
p_llca_adj_create_tbl_type.adjustme_number OUT NUMBER     If the adjustment is created successfully, then this parameter contains the value of the new adjustment number.
p_llca_adj_create_tbl_type.adjustment_id OUT NUMBER     If the adjustment is created successfully, then this parameter contains the value of the new adjustment_id.
p_llca_adj_create_tbl_type.customer_trx_line_id OUT NUMBER     If the adjustment is created successfully, then this parameter contains the value of the corresponding customer trx_line_id.

Note: You should populate the line level details on p_llca_adj_trx_lines_tbl for particular transactions, so that the system creates an adjustment for each line on p_llca_adj_trx_lines_tbl . You can retrieve the created adjustment details by using p_llca_adj_create_tbl_type as an out parameter.

The adjustment amount, receivable_trx_id, customer_trx_line_id are not required at the Header Level. The routine ignores these parameters and gives precedence to the p_llca_adj_trx_lines_tbl input parameters.

Validation of the parameters passed

All the parameters that are passed to the API are validated, and if any of the required fields are missing or invalid, then the API returns an error message. A list of possible error messages appears in Messages.

The API populates all error messages in the global temporary table ar_llca_adj_trx_errors_gt. Programs calling the API can then get the messages from this table and process them by issuing them, loading them into a database table, or writing them to a log file.

You need to check if a record exist in error table. If no records exist for a customer_trx_id and customer_trx_line_id, only then adjustment are created for a line against the transaction.

Example

The following is the simplest test case for creating an adjustment at the line level.

Objective:

To create an adjustment at line level, passing the minimum number of parameters.

Entered parameters:

p_adj_rec.type = 'LINE',

p_adj_rec.payment_schedule_id = 220175,,

p_adj_rec.receivables_trx = 684090,

p_adj_rec.apply_date = to_date('10-FEB-2008', 'DD-MON-YYYY'),

p_adj_rec.gl_date = to_date('10-FEB-2008', 'DD-MON-YYYY'),

p_adj_rec.created_from = 'ADJ-API'

p_llca_adj_trx_lines_tbl(1).customer_trx_line_id := 1228207;

p_llca_adj_trx_lines_tbl(1).line_amount := -10;

p_llca_adj_trx_lines_tbl(1).receivables_trx_id := 1280;

p_llca_adj_trx_lines_tbl(2).customer_trx_line_id := 1228208;

p_llca_adj_trx_lines_tbl(2).line_amount := -20;

p_llca_adj_trx_lines_tbl(2).receivables_trx_id := 3095;

Call to the API:

AR_ADJUST_PUB.Create_Linelevel_Adjustment(
     p_api_name                  =>   'AR_ADJUST_PUB', 
     p_api_version               =>   1.0,
     p_msg_count                 =>   msg_count ,
     p_msg_data                  =>   msg_data, 
     p_return_status             =>   return_status,
     p_adj_rec                   =>   adj_rec,
     p_llca_adj_trx_lines_tbl    =>   p_llca_adj_trx_lines_tbl,
     p_move_deferred_tax         =>	  'Y'
     p_llca_adj_create_tbl_type  =>   p_llca_adj_create_tbl_type,
     p_called_from               =>   p_adj_rec.created_from,
		 p_old_adjust_id            =>   NULL);	

Note: The p_move_deferred_tax => 'Y' flag is used only for bills receivables.

Result:

Creates an adjustment for each line; and the output parameter p_llca_adj_create_tbl_type contains the adjustment information as described below:

p_llca_adj_create_tbl_type.customer_trx_line_id(1) = 1228207

p_llca_adj_create_tbl_type.adjustment_number(1) = 6032

p_llca_adj_create_tbl_type.adjustment_id(1) = 22012

p_llca_adj_create_tbl_type.customer_trx_line_id(2)= 1228208

p_llca_adj_create_tbl_type.adjustment_number(2) = 6033

p_llca_adj_create_tbl_type.adjustment_id(2) = 22013

Messages

The following table describes the possible messages returned by the Adjustment API.

Message Number Message Name Message Description Additional Comments
42963 AR_AAPI_ADJ_AMOUNT_ZERO No Adjustment amount passed.  
42964 AR_AAPI_ADR_ZERO_INV Cannot adjust, because the amount due in the Payment Schedule is zero, and the type specified is INVOICE.  
42965 AR_AAPI_APPLYDATE_LT_TRXDATE The Apply date &APPLY_DATE is earlier than the transaction date &TRX_DATE.  
42966 AR_AAPI_DOC_SEQ_NOT_REQD The specified document sequence: &DOCUMENT_SEQ is not required as the Unique Sequence Number profile option does not allow it.  
42967 AR_AAPI_GLDATE_INVALID_PERIOD The GL date: &GL_DATE is not in an open or future enterable period.  
42968 AR_AAPI_GLDATE_LT_APPLYDATE The GL date &GL_DATE is earlier than the apply date &APPLY_DATE.  
42969 AR_AAPI_GLDATE_LT_TRXGLDATE The Adjustment GL date &GL_DATE is earlier than the transaction GL date &TRX_GL_DATE.  
42970 AR_AAPI_INVALID_ADJ_ID Invalid adjustment ID: &ADJUSTMENT_ID specified.  
42971 AR_AAPI_INVALID_CCID Invalid code combination ID: &CCID  
42972 AR_AAPI_INVALID_CREATE_STATUS Invalid status: &STATUS passed during creation of Adjustment  
42973 AR_AAPI_INVALID_DESC_FLEX Invalid Descriptive Flexfield has been provided.  
42974 AR_AAPI_INVALID_PAYSCHD Invalid Payment Schedule ID: &PAYMENT_SCHEDULE_ID  
42975 AR_AAPI_INVALID_RCVABLE_TRX_ID Invalid receivables trx ID: &RECEIVABLES_TRX_ID  
42976 AR_AAPI_INVALID_REASON_CODE The reason code &REASON_CODE is invalid.  
42977 AR_AAPI_INVALID_RECEIPT_ID Invalid Associated Cash Receipt ID &ASSOCIATED_CASH_RECEIPT_ID has been specified.  
42978 AR_AAPI_INVALID_TRX_CLASS Adjustment not allowed for transactions of class: &CLASS  
42979 AR_AAPI_INVALID_TYPE Invalid type of adjustment: &TYPE  
42980 AR_AAPI_INVALID_USSGL_CODE Invalid USSGL Transaction Code &USSGL_CODE has been specified  
42981 AR_AAPI_LINE_ID_FOR_NONLINE Customer trx line ID: &CUSTOMER_TRX_LINE_ID passed for type = &TYPE  
42982 AR_AAPI_NO_APPLY_DATE Apply date has not been specified  
42983 AR_AAPI_NO_APPROVAL_CODES No valid approval codes exists for Adjustments in the Lookup table  
42984 AR_AAPI_NO_CCID No valid code combinations exist for Adjustment  
42985 AR_AAPI_NO_CCID_FOR_ACTIVITY No code combination id exists for receivables trx ID: &RECEIVABLES_TRX_ID and no code combination has been specified  
42986 AR_AAPI_NO_CHANGE_OR_REVERSE No changes allowed for Adjustment with &STATUS status  
42987 AR_AAPI_NO_CREATED_FROM No values specified for the Created From attribute of the adjustment  
42988 AR_AAPI_NO_CUSTOMER_ID No customer ID exists for payment schedule ID: &PAYMENT_SCHEDULE_ID  
42989 AR_AAPI_NO_CUSTOMER_TRX_ID No customer trx id exists for payment schedule ID: &PAYMENT_SCHEDULE_ID  
42990 AR_AAPI_NO_CUSTOMER_TRX_LINEID Invalid customer trx line id: &CUSTOMER_TRX_LINE_ID passed for customer trx id: &CUSTOMER_TRX_ID  
42991 AR_AAPI_NO_GL_DATE GL date has not been specified  
42992 AR_AAPI_NO_OPEN_FUTURE_PERIOD No valid open or future enterable GL periods exist for the ledger ID &SET_OF_BOOKS_ID  
42993 AR_AAPI_NO_REASON_CODES No valid reason codes exist for Adjustments in the Lookup table  
42994 AR_AAPI_NO_RECEIVABLES_TRX No valid receivables activity exists for Adjustments  
42995 AR_AAPI_NO_TYPE_CODES No valid type codes exists for Adjustments in the Lookup table  
42996 AR_AAPI_NO_USSGL_CODES No valid USSGL Codes exist for Adjustment  
42997 AR_AAPI_OVERRIDE_CCID_DISALLOW Override Activity profile option does not allow to override the Code Combination ID provided in the Receivables Activity  
42998 AR_AAPI_USSGL_CODE_DISALLOW USSGL code is not allowed as the USSGL profile option does not allow it  
4667279 AR_LL_ADJ_INSTALL_NOT_ALLOWED You cannot create a line-level adjustment for a transaction with installments  
4667280 AR_LL_ADJ_LEGACY_NOT_ALLOWED You cannot create a line-level adjustment for a transaction with activity. This is applicable to invoices and debit memos created in Release 11i and having prior activity on them.
4667283 AR_ADJ_API_CUST_LINE_ID_IG The line-level customer transaction line ID takes precedence over header-level customer transaction line ID. If you passed the customer_trx_line_id in p_adj_rec and it is also passed for the line in the PLSQL table (used to pass line level adjustment data), this warning message is displayed.
4667282 AR_ADJ_API_AMOUNT_IG The line-level amount takes precedence over the header-level amount. If you passed the line_amount in p_adj_rec and it is also passed for the line in the PLSQL table (used to pass line level adjustment data), this warning message is displayed.
4667284 AR_ADJ_API_RECV_TRX_ID_IG The line-level Receivables transaction ID takes precedence over the header-level Receivables transaction ID If you passed the receivables_trx_id in p_adj_rec and it is also passed for the line in the PLSQL table (used to pass line level adjustment data), this warning message is displayed.
4667285 AR_ADJ_API_TYPE_DISALLOW Receivables allows a line-level adjustment only for the line adjustment type  
4667281 AR_LL_ADJ_MODIFY_NOT_ALLOWED You cannot modify an adjustment created at the line level Use the reverse adjustment routine as stated in the earlier section of the documentation.