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:
With standard PL/SQL servers-side routine calls.
Through Forms to have a procedure as its underlying base table.
To create, modify, approve, or reverse adjustments, use the following routines:
Ar_Adjust_pub.Create_Adjustment: Use this routine to create an adjustment for an invoice.
Ar_Adjust_pub.Create_Linelevel_Adjustment: Use this routine to create an adjustment for an invoice/debit memo at line level.
Line level adjustments result in distributions being created only for the invoice line being adjusted. Such distributions are not prorated across all invoice lines but are applicable only to the specified invoice line using the remaining balances of the invoice line.
This routine creates the adjustment at the line level, and maintains the line level balances of the transactions.
This routine is restricted to do line level adjustment for adjustment type – LINE. The tax amount is prorated based on the receivable activity tax code source passed for the line adjustment.
Tax, freight and charges adjustments can only be done at the header level of the invoice. Use the standard Create_Adjustment API to create tax, freight and charges adjustments applicable to the invoice header.
You cannot modify the line level adjustment using modify routine in the API. However, you can use the Reverse_Adjustment routine to reverse an existing adjustment by passing the applicable adjustment identifier.
Receivables does not support line level adjustment functionality for invoices with installments. You can make adjustments against an invoice with multiple installments only at the invoice header level.
You cannot create line level adjustments against Invoices or debit memos that were created prior to Release 12 and have activity against them.
Ar_Adjust_pub.Modify_Adjustment: Use this routine to modify an adjustment's status, comments, and reason code.
Note: If the existing status of the adjustment is A or R, then it cannot be modified.
Ar_Adjust_pub.Approve_Adjustment: Use this routine to approve an adjustment.
Ar_Adjust_pub.Reverse_Adjustment: Use this routine to reverse an adjustment at either header or line level.
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 GL account source on the adjustment's receivable activity is Activity and the tax code source is None.
The AR: Override Adjustment Activity Account Option profile option is set to Yes.
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 |
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:
Standard API parameters: 4
Create Adjustment parameters: 6 required parameters (might vary depending on the adjustment type)
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.
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 such as ''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_charges_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:
Values of the other parameters in the API call
Values set in the ar_system_parameters table entered through the System Options form
Relevant profile option values
Depending on the user's particular business needs, the minimum number of parameters required to create an adjustment may vary.
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 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.
Use this routine to approve an adjustment. The following is a breakdown of parameters for this routine, divided according to parameter type:
Standard API parameters: 4
Approve Adjustment parameters: 1 required parameter
Standard API parameters: 3
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_number | 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. |
All the parameters that are passed to the API are validated, and if any required fields are missing or invalid, then the API returns an error message. A list of possible error messages appears in Messages.
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.
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' (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:
Standard API parameters: 4
Modify Adjustment parameters: 1 required parameter
Standard API parameters: 3
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_number | 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. |
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 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.
Use this routine to reverse an adjustment. The following is a breakdown of parameters for this routine, divided according to parameter type:
Standard API parameters: 4
Reverse Adjustment parameters: 1 required parameter
Standard API parameters: 3
Reverse Adjustment parameters: 1
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. |
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 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.
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.
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.
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.
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
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. |