Error: The line cannot be updated or deleted because these operations are not allowed because the line has an Interface Line Context equal to ::: DOO

Issue:

Below error when trying to update Interface line with source of DOO.

Error: The line cannot be updated or deleted because these operations are not allowed because the line has an Interface Line Context equal to ::: DOO

Fix:


Go to Manage Standard Lookups -> Search lookup type "AR_FEATURES", if not found, create one with
Lookup Type: AR_FEATURES
Module: Receivables
Then create a Lookup code "AR_AUTOINV_ALLOW_DELETE_UPDATE" for it.

Try to edit this in your TEST environment, once complete above activity.

Oracle Fusion ADFDi Issue Troubleshoot

If you face any issue in Fusion ADFDi tool which is integrated with excel with fusion cloud. You can identify the issue and troubleshoot yourself by following below steps and provide the log file to oracle support for further issue debug.

1. How to download healthcheck software ?

Please download from below link

ClientHealthCheck.exe


2. How to use the tool?

1. Run ClientHealthCheck.exe
2. Review the result for each checked item
3. Click on any item that has a problem, read help text.
4. Fix some of the problems by clicking the "Fix Problems" button, otherwise follow the instructions in help text to resolve them
5. Save a report by clicking the button "Save Report As..." and choose the name and location for the report
6. Review the report opened automatically, remove any sensitive information
7. Send the report to Support while seeking further help

Source:-

MOS

Payment process request end with "Waiting for payment file Processing" status

Payment process profile end with "Waiting for payment file processing"


Steps to reproduce 

1. Submit Payment Process Request.
2. Select invoices.
3. Click Submit.
4. See that the request ends in status of "waiting for payment file processing".

When running PPR, user can choose whether to automatically create the payment file or submit create electronic/printed payment file ESS request later on manually. This is controlled by 'Create Payment Files Immediately" check box under Payments & Processing options tab of the PPR.

In this case, user ran the PPR with out checking 'Create Payment Files Immediately" check box. Hence the process stopped after creating the payments. Next step is to create a formatted payment file for these payments. To continue with processing of this PPR, customer can manually run 'Create Printed Payment Files' request by clicking on Create Printed Payment Files link in Payments dashboard.

Solution:- 

To continue with processing of the PPR, manually submit the Create Electronic/Printed Payment file using the navigation path below:

Navigation: Payments > Tasks > Create Electronic Payment File OR Create Printed Payment File


To automatically create the payment file with out this manual intervention, submit PPR with 'Create Payment Files Immediately" check box selected.

Query to get the Supplier/Vendor details from oracle E-Business Suite R12.X.X

This query will give you the vendor list by site wise in EBS R12

Pass the parameter as Vendor name or from number to number.

SELECT 
PO.SEGMENT1 VENDOR_NUMBER,
PO.VENDOR_NAME,
PO.VENDOR_NAME_ALT,
PO.VENDOR_TYPE_LOOKUP_CODE,
POS.VENDOR_SITE_CODE
,VENDOR_SITE_CODE_ALT
,POS.ADDRESS_LINE1
,POS.ADDRESS_LINE2
,POS.ADDRESS_LINE3
,POS.ADDRESS_LINE4
,POS.CITY
,POS.COUNTRY
,POS.ZIP
,POS.COUNTY
,POS.STATE
,POS.INVOICE_CURRENCY_CODE
,POS.PAYMENT_CURRENCY_CODE
,POS.PAYMENT_METHOD_LOOKUP_CODE
,POS.PAY_GROUP_LOOKUP_CODE
,HR.NAME
,INACTIVE_DATE
,GLCC.CONCATENATED_SEGMENTS LIABILITY_ACCOUNT
,GLCCP.CONCATENATED_SEGMENTS PREPAY_ACCOUNT
,POS.EMAIL_ADDRESS
FROM AP_SUPPLIERS PO,AP_SUPPLIER_SITES_ALL POS
,GL_CODE_COMBINATIONS_KFV GLCC,GL_CODE_COMBINATIONS_KFV GLCCP
, HR_OPERATING_UNITS HR
WHERE PO.VENDOR_ID=POS.VENDOR_ID
AND GLCC.CODE_COMBINATION_ID=POS.ACCTS_PAY_CODE_COMBINATION_ID
AND GLCCP.CODE_COMBINATION_ID=POS.PREPAY_CODE_COMBINATION_ID
AND HR.ORGANIZATION_ID=POS.ORG_ID
AND PO.SEGMENT1 BETWEEN NVL(:P_SUPPLIER_NUMBER_FROM,PO.SEGMENT1) AND NVL(:P_SUPPLIER_NUMBER_TO,PO.SEGMENT1)
AND PO.VENDOR_NAME=NVL(:P_VENDOR_NAME,PO.VENDOR_NAME)
ORDER BY 1;

PRC: Interface Invoices to Receivables Ends with Rejection 'Accounting flexfield could not be validated

Issue:

PRC: Interface Invoices to Receivables Ends with Rejection 'Accounting flexfield could not be validated

Resolution:-

1.  First you will need to figure out what account the system is trying to build. 
2.  Using the Project Billing Super User responsibility, Setup | Auto Accounting | Assign Rules => Query on function 'Revenue and Invoice Accounts'
3.  Put your cursor in the function 'Unbilled Retention Account' and go through each rule which will help you build the account, i.e., segment 0 is 'Company Rule' with a constant of 01, segment 1 is 'Cost Center Rule' with a constant of 000 and segment 2 is the 'Account Number Rule' with a constant of 1233.  Thus the account we are building is 01.000.1233.
4.  Using the General Ledger Super User responsibility navigate
5.  Setup | Accounts | Code Combinations => enter the account code combination generated in PA, i.e., 01-000-1233.
6.  Verify the 'Enable' box is checked.  If not, please enable. 
7.  Re-run the PRC:  Interface Invoices to Receivables process.


NOTE:  PRC: Interface Invoices to Receivables will end with rejection 'Accounting flexfield could not be validated' if current date is not in between code combination start date and code combination end date.
Validation for code combination while interfacing invoice does not depend on invoice date but Sys date.

If any cross validation or Security rules applied any one of the segment also this issue will occur.

Error Message: ORA-04061: existing state of has been invalidated

Issue:
Error Message: ORA-04061: existing state of has been invalidated ORA-04061: existing state of has been invalidated ORA-04061: existing state of package "APPS.GL_WF_JE_APPROVAL_PKG" has been invalidated ORA-04065: not executed, altered or dropped package "APPS.GL_WF_JE_APPROVAL_PKG" ORA-06508: PL/SQL: could not find program unit being called: "APPS.GL_WF_JE_APPROVAL_PKG


Resolution:

Please follow the below process to fix the issue .

Step - 1

Shutdown the concurrent manager

Step-2 

Recompile GL_WF_JE_NOTIFICATION_PKG

Step-3

E.g.

sqlplus apps/apps

SQL>alter package GL_WF_JE_NOTIFICATION_PKG complie;

SQL>alter package GL_WF_JE_NOTIFICATION_PKG compile body;

Step-4

Restart the concurrent manager

Step-5

Run the Journal apporval process 

"ADFI-05566 Unable to retrieve values for the last binding "OrgIdlist", or for one or more of its dependent lists"

Error

"ADFI-05566 Unable to retrieve values for the last binding "OrgIdlist", or for one or more of its dependent lists"

Details of the error:

The remote server returned an error: (500) Internal Server Error.

~~~~~~~~~~
WebException: The remote server returned an error: (500) Internal Server Error.
Source: System

Solution:

Set the DEFAULT_ORG_ID profile for the user to one of the accessible Business Units

Go to Setup and Maintenance
Search for the task "Manage Administrator Profile Values"
Go to Task
Search for Profile option code "DEFAULT_ORG_ID"
Click on + icon on last table
Set the profile level as User
Set the user name in User Name
Set the Business Unite name in Profile Value and save and close

If you are using Internet Explorer Version 10 which is not certified with Fusion Applications as of April 2014, you will need to do the step above AND:

Open Excel
File > Options > Trust Center
click Trust Center Settings button
Select Protected View in left panel
Un-check the first two check boxes.
Click OK (twice) to close the dialogs.
Close Excel.

If you would like to keep Protected View, use the following workaround:
When prompted if you would like to save or open excel. Choose save. And then later open excel file from saved location.

Also check:

Open Excel and > Excel Options > Trust Center.
> Trust Center Settings.
> Macro Settings.
> Select the Trust access to the VBA project object model check box.
> Click OK to close the Excel Options dialog box.

"Enter a value less than or equal to 8 characters for the account (CE-660079)."

Error:

error while uploading the bank account using spreadsheet.

"Enter a value less than or equal to 8 characters for the account (CE-660079)."

Solution:

Search with: Manage Cash Management Profile Options 

Please set country specified profile option at site level.

CE_DISABLE_BANK_VAL profile option to Yes at site or user level who trying to modify bank account.

You can provide at most one receivables account for a transaction (invoice, debit memo, or credit memo)

Issue:

You can provide at most one receivables account for a transaction (invoice, debit memo, or credit memo)

Solution:

This issue happen due to missing grouping Rules Setup - you expect the interface data to create multiple transactions but instead records are being grouped into one. Since there are multiple REC rows in the data this causes the error to be raised since a transaction can only have one REC row.

1. Verify the grouping rule associated to the Transaction Batch Source you are using

a. Search "Manage Transaction Sources" from Setup & Maintance Screen
Query for Batch Source Name = RA_INTERFACE_LINES_ALL.BATCH_SOURCE_NAME and check in AutoInvoice Options tab the value in Grouping Rule

2. Check your Grouping Rules setup

a. "Manage AutoInvoice Grouping Rules" from Setup & Maintance Screen

b. Ensure that you have defined a grouping rule setup for each type of transaction: Invoice, Credit Memo, Debit memo

Fusion Cloud customer upload error codes

Error Codes on Bank Interface Table (RA_CUSTOMER_BANKS_INT_ALL)

S1 - The customer reference specified is invalid
S2 - The address reference specified is invalid
S3 - The address reference specified is not valid for this customer
S7 - An active BILL_TO site must be defined for this customer and address
V2 - The bank account specified must be of type 'EXTERNAL'
W1 - BANK_NAME is mandatory when the bank account is not defined
W2 - BANK_BRANCH_NAME is mandatory when the bank account is not defined
W3 - BANK_ACCOUNT_CURRENCY_CODE is mandatory when account not defined
W4 - BANK_ACCOUNT_CURRENCY_CODE is not defined in FND_CURRENCIES
b7 - BANK_ACCOUNT_NUM is mandatory when the bank account is not defined
V3 - This customer bank is already active between the dates specified
V4 - Customer site bank account already active between these dates
V5 - This customer already has a primary bank account for the dates specified
V6 - Customer site has a primary bank account for the dates specified
V7 - Customer bank is already defined to be active for this date range
V8 - Duplicate primary customer banks defined within the interface table
W6 - Duplicate bank number in interface table
W5 - Bank number already existing.
f8 - Bank number and Branch number already exist.
W8 - Duplicate bank name & branch in interface table
W0 - Bank name & branch already existing
S6 - bank end date should be greater than start date
W7 - Bank primary flag specified is invalid .
B9 or w7 - territory code for bank is not defined in fnd_territories
w6 - bank home country is mandatory
Z1 - Bank Creation Failed
Z2 - Bank Branch or bank account creation failed.


Error Codes on Payment method Interface table (RA_CUST_PAY_METHOD_INT_ALL)


S1 - The customer reference specified is invalid
S2 - The address reference specified is invalid
S3 - The address reference specified is not valid for this customer
S7 - An active BILL_TO site must be defined for this customer and address
S4 - payment method name provided is not valid.
S6 - Start date should be less than end date.
T1 - Start date and end dates is invalid for the specified receipt method in account level.
W7 - primary_flag for the receipt method should be either Y/N or blank
T2 - Start date and end dates is invalid for the specified receipt method in site level.
T3 - Start date and end dates is invalid for the specified receipt method


Error Codes on Profiles interface table (RA_CUSTOMER_PROFILES_INT_ALL)

Z0 - if currency code is not specified, then interest rate ,maximum interest charge,minimum dunning amount,minimum dunning invoice amount, minimum fc balance amount,
minimum fc invoice amount, min statement amount,overall credit limit and transaction credit limit are not expected to be defined.

b1 - if transaction credit limit is a positive value , overall credit limit is Mandatory and should be greater than transaction credit limit
if transaction credit limit -1 or NULL , overall credit limit should be -1 or NULL.
b2 - transaction credit limit should be less than overall credit limit
K4 - late charge type specified is not valid
K5 - late charge calculation trx specified is not valid
K6 - When late charge calculation trx is specified to be AVG_DAILY_BALANCE, cons inv flag should be Y.
K7 - When late charge calculation trx is specified to be AVG_DAILY_BALANCE, Null is expected in late charge type,interest period days,interest calculation period,
hold charged invoices flag columns .
K8 - interest calculation period specified is not valid
K9 - multiple interest rates flag should be either Y/N or blank .
K10 - hold charged invoices flag should be either Y/N or blank .
K11 - late charge term id specified is not valid
K12 - late charge type cannot be ADJ when late charge term id is defined.
K13 - credit items flag should be either Y/N or blank .
K14 - disputed transactions flag should be either Y/N or blank .
K15 - exchange rate type specified is not valid
K16 - min fc invoice overdue type specified is not valid
K17 - min fc balance overdue type specified is not valid
K18 - Interest type specified is not valid
K19 - if interest type is FIXED_RATE then interest rate column is mandatory and interest fixed amount and interest schedule id should be null
if interest type is FIXED_AMOUNT then interest fixed amount column is mandatory and interest rate and interest schedule id should be null .
if interest type is CHARGES_SCHEDULE then interest schedule id is mandatory and interest fixed amount and interest rate should be null .
K20 - Penalty type specified is not valid
K21 - if penalty type is FIXED_RATE then penalty rate is mandatory and penalty fixed amount and penalty schedule id should be null .
if penalty type is FIXED_AMOUNT then penalty fixed amount is mandatory and penalty rate and penalty schedule id should be null .
if penalty type is CHARGES_SCHEDULE then penalty schedule id is mandatory and penalty fixed amount and penalty rate should be null .
K22 - interest fixed amount cannot be negative
K23 - penalty fixed amount cannot be negative
K24 - min interest charge cannot be negative
K26 - penalty rate specified cannot be less than 0 or greater than 100
K27 - min fc invoice percent specified cannot be less than 0 or greater than 100
K28 - min fc balance percent specified cannot be less than 0 or greater than 100
K29 - interest schedule id specified is invalid
K30 - penalty schedule id specified is invalid
K31 - match by autoupdate flag should be either Y/N or blank
K32 - preferred contact method specified is invalid
K33 - exception rule name specified is invalid
K34 - automatch rule name specified is invalid
K45 - CONS_BILL_LEVEL must be null when CONS_INV_FLAG is N or null.
w2 - credit classification value specified is not valid
a2 - tax printing option value specified is not valid
X6 - Currency Code specified is not valid
X5 - grouping rule name specified is not valid.
y5 - autocash hierarchy name adr specified is not valid.
N0 - autocash hierarchy name specified is not valid.
N9 - percent collectable cannot be less than 0 or greater than 100
N8 - account status specified is not valid
N7 or b6 - statement cycle name specified is not valid
b8 - auto rec incl disputed flag should be either Y/N or blank
N5 - override terms should be either Y/N or blank
b4 - payment grace days cannot be a negative value.
N4 or b5 - standard term name specified is not valid
y4 - lockbox matching option specified is not valid
N3 - risk code specified is not valid
N2 - credit rating specified is not valid
N1 - credit hold specified is not valid
X4 - charge on finance charge flag should be either Y/N or blank
Z6 - when discount terms is Y then discount grace days should be a positive number
Z7 - when discount terms is N then discount grace days can only be -1 or NULL
Z5 - when discount terms is NULL then discount grace days can only be -1 or NULL
M6 - discount terms should be either Y/N or blank
M5 - tolerance should be between -100 and +100
M4 - credit checking should be either Y/N or blank
b4 or M3 - collector name specified is not valid
B7 - You should provide a valid profile class name or atleast one seeded profile class should exist in the system
f4 - clearing days should be a positive value.
O7 - if interest charges is Y then a positive value for interest period days is expected.
L1 - Collector name cannot be null provided customer profile class name is not null
L2 - tolerance cannot be null provided customer profile class name is not null
L3 - discount terms cannot be null provided customer profile class name is not null
L4 - dunning letters cannot be null provided customer profile class name is not null
04 - credit checking cannot be null provided customer profile class name is not null
L5 - interest charges cannot be null provided customer profile class name is not null
L6 - statements cannot be null provided customer profile class name is not null
L7 - credit balance statements cannot be null provided customer profile class name is not null
X1 - auto rec incl disputed flag cannot be null provided customer profile class name is not null
X0 - override terms cannot be null provided customer profile class name is not null
M7 - dunning letters should be either Y/N or blank
L9 - When dunning letters are enabled , dunning letter set name Cannot be null
Z8 - When dunning letters are disabled , dunning letter set name is not supposed to have a value.
Z9 - dunning letter set name should be null when dunning_letters column is NULL.
M0 - credit balance statements should be either Y/N or blank
M8 - interest charges should be either Y/N or blank
M1 - interest period days is mandatory when interest charges is Y
O5 - charge on finance charge flag should be either N or NULL when interest charges is N
O6 - interest period days should be NULL when interest charges is N
Z3 - charge on finance charge flag Must be blank when interest charges is not specified
Z4 - interest period days Must be blank when interest charges is not specified
M9 - statements should be either Y/N or blank
O1 - statement cycle name Cannot be null when statements is Y
X7 - credit balance statements Cannot be null when statements is Y
X8 - credit balance statements should be N when statements is N
X9 - statement cycle name Should be Null when statements are specified to be N
Z1 - credit balance statements should be left blank when statements are not specified
Z2 - statement cycle name should be left blank when statements are not specified
J8 - insert Update flag should be either I or U
a4 - account/site profile exists cannot do the insert
a3 - account/site profile doesn't exist to update
S1 - invalid account/site specified for profile insert
a7 - two profiles cannot be of same currency code.
a8 - two profiles cannot be of same name.

Unable to see direct SQL option under subject area in fusion BI

Issue:

Unable to see fusion Direct SQL option under subject area in fusion BI after upgrade R11 to R12

Solution:

1. Login to Fusion Application and choose the "Security Console" option

2. Under the Roles Tab, click on Create Role button and fill out the form as seen in the screen shot

3. Click next till you get to the "Role Hierarchy" and then click on the Plus sign (+) to add the seeded BI Administrator Role

4. Search for the BI Administrator Role and then click on "Add Role Membership"

5. Click Next and then Submit the request

6. To assign the newly created "Custom BI Administrator Role" to a user, you need to query up the Role and click "Edit Role"

7. Click Next or jump to "Users" and then click on "Add User"

8. Search for the user and then click on "Add User to Role" button

9. Then click on Next and then "Save and Close"

10. Now run the "Retrieve Latest LDAP Changes" ESS Job.


The user should now have the BI Administrator Role. Please allow up to 20 minutes for the change to take effect.

Oracle receivables Late charge report ended with "no data found"

Issue:

Oracle receivables Late charge report ended with "no data found"

Solution:

1. Go into the responsibility: Receivables.

2. Navigate to Customers -> Customer profiles

Query back the profile used on your customers

Click on the 'Late Charge Profile'

Check the 'Late Charge Type'

select 'Adjustment'

Ensure you update all customers when prompted.

If you have already done the above set up and still no invoices are picked up, please check the below.

Please select 'Charge Schedule Per Invoice' instead of 'Charge Schedule Per Tier'.In 'Charge Schedule Per Invoice' the 'Schedule Type' can be defined as 'Percentage' as well as 'Amount' Type.The set up for 'Charge schedule Per Invoice' is same as 'Charge Schedule per Tier' where we can define our own slabs.

Whereas In 'Charge Schedule Per Tier' the 'Schedule Type' can be defined only as 'Amount'.

Oracle receivables Late charge report ended with null output (not generating output)

Issue:

Late charge report not generating output

Solution:

Set the profile to Yes at the site level.

Profile Name: "AR: Use Statement, Dunning, and Late Charges"

Responsibility: System Administrator

Navigation: Profile > System

Query Profile : AR: Use Statement, Dunning, and Late Charges

Set the profile option to "Yes" at the site level.

How to Setup Oracle Payable Withholding Tax (AWT) in R12

Oracle Account Payable – Withholding Tax Setup & Flow - R12


1. Create Special Calendar for AWT

2. CIS Calendar Profile Option

3. Define Withholding Supplier (Tax Authority)

4. Create Withholding Code

5. Define Withholding Group

6. Configure Payable Options

7. Enable Withholding Tax applicability in the vendors

8. Perform AWT Transactions/Transaction flow

1. Create Special Calendar for WHT

Create Monthly Special Calendar

(N) Setup>Calendar>Special Calendar

2. Profile option for CIS calendar

Attach your SPL calendar in site level profile option

(N)System Admin>System Profile

3. Define withholding supplier (Tax Authority)

Create Tax Authority supplier to create withholding invoices

(N)Supplier > Entry

Select the supplier type as “Tax Authority”

4. Create withholding code

Create withholding tax code with attaching the tax authority, SPL calendar and withholding tax percentage.

(N) Setup>Tax>withholding>Code

5. Define withholding Group

Create withholding group and attach the withholding code to it.

(N) Setup>Tax>withholding>Group

6. Configure Payables Option

Setup payables option for withholding tax,

(N) Setup>Options>Payables Options

7. Enable withholding tax applicability in the vendors

Allow withholding tax in the supplier and supplier site level for withholding tax applicability

(N)Supplier > Entry

8. Perform withholding tax Transactions

Create AP invoice for withholding tax supplier to test your configuration.

Invoice deducted the withholding tax

Query the “Tax Authority” to find the withholding tax invoice

End the Process...

What are all obligation status values available in PSRM v2.5

The below are obligation status values are available by default in PSRM system:-

05 Incomplete - This status does not have any meaning in PSRM. It is an inherited status that is not used.

10 Pending Start - Obligations are typically created in this status however, the status itself does not have meaning in PSRM. The recommendation is to include an Obligation Creation algorithm to transition the obligation to Active.

20 Active - Obligations are in this state if they do not have an end date. Most obligations in PSRM have a start and end date covering the revenue period so obligations typically do not remain in this status but rather transition to Pending Stopped right away. Obligations that do not have an end date remain active, however the end date must be populated for the obligation to transition through the subsequent states.

30 Pending Stop - Obligations transition to this status when the end date is populated however the state doesn't have any meaning in PSRM. The recommendation is to include an Obligation Stop Initiation algorithm to automatically transition the obligation to Stopped.

40 Stopped - This state represents Obligations whose end date is populated and are waiting for the balance to be paid off so that it can be closed. (Note that algorithms can check that other conditions are met - like a valid tax form has been filed - before allowing an obligation to be closed.)

50 Reactivated - This state is used for obligations that were closed but where additional FTs were posted, causing it to reopen.

60 Closed - This state is used for obligations that were valid and where all the appropriate financial liabilities were posted and the obligation no longer has a balance. (As already mentioned, algorithms can check that other conditions are met before allowing an obligation to be closed.)

70 Canceled - This state is used to "logically delete" obligations that were created in error.


To summarize, in general most obligations will be created in Pending Start but immediately transition through Active > Pending Stop > Stopped right away assuming that the start and end date are populated at creation time and that the appropriate algorithms are plugged in to Obligation Creation and Obligation Stop Initiation as described above.


Obligations will typically be instantiated in one of the following the states:

> Stopped / Reactivated (Current outstanding obligations will be in one of these states)

> Closed

> Canceled


Most system logic that is checking for a 'current' obligation checks for obligations where the status is not Closed or Canceled.

How the GL Account Mapped in PSRM Financial Transaction

Accounting entries for financial transactions,

- Bill

- Payment

- Adjustment


Bill:- If a bill segment has a financial effect, the distribution code to debit comes from the distribution code on the obligation type; the distribution codes to credit come from the calculation lines used to calculate the bill segment. Calculation rules define the distribution codes to be used when creating bill calculation lines.

Payment:- Payment segments always have a financial effect; the distribution code to debit comes from the bank account on the tender source of the tender control of the tender, the distribution code to credit comes from the obligation type.

Note: The information in this topic refers to bills created using calculation rule based functionality. For details of the source of FTs for rate-based bills

How the adjustments affect the general ledger (GL) :-


• For many adjustments there is a single accounting entry generated:

• One side of the accounting entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment. For example, if you are adjusting the payoff balance on a normal obligation, the A/R account is constructed from the distribution code on the obligation's obligation type.

• The other side of the accounting entry is taken from the distribution code on the adjustment's adjustment type.

• For transfer adjustments (i.e., adjustments used to transfer moneys between two obligations), there are two accounting entries generated - one for the "from" side and one for the "to" side. Each adjustment carries its own set of balanced GL accounting details.

• For each adjustment, one side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment

• The other sides of both accounting entries have the same GL account. This account should be the intermediate clearing GL account that is to be used for the transfer. The source of this clearing GL account is the distribution code on the adjustment type used to transfer the funds.

• For generated adjustments, the accounting entry may include several GL details:

• One side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment.

• The other side of the entry depends on configuration on the adjustment financial transaction algorithm. If it is configured to use the Calculation Lines as the source, the distribution codes are taken from the calculation lines. If it is configured to use the adjustment type as the distribution code source, the other side of the accounting entry is taken from the distribution code on the adjustment type.

PSRM basic accounting Entries:-

The table explained the basic PSRM accounting entries

Financial Transaction Example screen for Payment event:- 

Ways to submit batch processes in PSRM/ETPM

There are a number of ways of submitting batch processes within the Oracle Utilities Application Framework. The various ways reflect the different uses for the product at a site. The figure below summarizes the various submission methods:






• It is possible to submit the batch process in a basic interactive mode where the batch object executed in a single JVM. This mode is known as THIN mode and is primarily designed for developers to test their code in isolation from the rest of the system. The mode is not efficient enough to be recommended for any activity other than developer testing. Refer to Interactive Submission section for details on how to use this method.

• The product browser user interface allows the registration and execution of batch processes within the JVM used online. This mode allows part of the resources of online be devoted to registering and executing of batch processes. This method is primarily designed for use for testing purposes. Refer to the Online Submission section for details on how to use this method.

• Typically at a site, a batch scheduling tool is used to schedule and manage all of the background tasks required at a site. This can include running product batch processes and any related maintenance process such as transferring interface files to and from other systems, backup and other maintenance activities. This method is designed for production use and has a number of variations to support flexible scheduling options. Refer to the External Scheduler Submission section for details on how to use this method.

Tax Forms Common Lifecycle Statuses - Public Sector Revenue Management (PSRM)

Common Lifecycle of Tax Forms 

The base product supplies a parent business object for tax forms that defines the following lifecycle:

Pending
 
 The tax form is created in an initial state where processing rules are not yet executed. This allows the form to be saved as work-in-progress.

Validated
    A validation step verifies the information on the tax form. Validation form rules specific for the form type are executed to check the validity of the form data. Any issues detected at this step usually causes form processing to stop.

Suspended
    A tax form goes into this state when the validation step detects errors on the form that a user may be able to investigate and resolve. Exceptions are stored in the system so that a user can resolve the issues accordingly. The form needs to be re-validated after the issues are resolved.

Waiting for Information
    A tax form goes into this state when the validation step detects missing information, thus preventing the system from further proceeding with form processing. Exceptions are stored in the system so that a user can track the issues accordingly. In addition, this state usually triggers correspondence to the taxpayer, requesting for the missing information. The form is usually re-validated after the missing information is received.

Ready for Posting
    When a tax form passes validation, it transitions to Ready for Posting. From here a user may choose to make further changes by re-editing the form. Or the form can transition to Posted.
    Note: For implementations that use form control functionality, the tax form is only progressed to Posted by linking it to a form control that gets approved. Refer to The Big Picture of Form Control for more information.

Re-edited
    When a user is creating or correcting a form and it passes validation, there may still be a need to review and correct the data further. A form in the Ready for Posting state may be updated by transitioning it to Re-edited. The form needs to be re-validated once it is re-edited.

Posted
    When a tax form passes validation, it can be posted in the system. The posting of a form typically causes other data in the system to be added or updated. For example, adjustments are created for the assessments. Taxpayer data may also get updated based on newer information from the form. Posting form rules specific to the form type are responsible for the posting logic.

Adjusted
    A posted tax form can be adjusted for any of the following common reasons:

        Correcting data capture errors or data entry errors

        Line item adjustments initiated by the taxpayer

        Adjustments initiated from an audit

    When a tax form is adjusted, the financial effect of the existing tax form is canceled and new financial transactions are created for the updated line items. Note that the effects of adjusting a form are controlled by form rules.

Transferred
    A tax form can be transferred to a different taxpayer/obligation if it previously posted to the incorrect taxpayer/obligation.

    When a tax form is transferred, the current tax form transitions to Transferred and a new tax form is created, allowing a user to indicate the correct taxpayer / obligation. The financial effect of the existing tax form is removed from the current obligation using form rules. The new form goes through the same lifecycle of validation and posting and new financial transactions are created for the 'transfer to' obligation via the new form's posting rules.

Reversed
    Some exceptional cases may require that the financial effect of a tax form be canceled, without necessarily creating new financial transactions. A tax form reversal is a way of voiding a tax form that has already posted.

Canceled
    Forms that are not yet posted may be canceled if a user determines that the form was created incorrectly.

The base package provides a tax form business object C1-ParentTaxForm that has the lifecycle described above. Specific form business objects created using form generation are child forms for a common parent form BO so that the lifecycle is consistent for all forms. The base parent BO may be used or an implementation may create a custom business object. Refer to the business object meta-data for more details on the lifecycle, including the allowed transitions and the algorithms provided.

APP-SQLAP-10000: ORA-01403: no data found occurred in with parameters (Terms id = Seqiemce num =1)

Issue:

Unable to validate invoice where the item line has a withholding tax group due to:

APP-SQLAP-10000: ORA-01403: no data found occurred in
with parameters (Term id = Sequence num = 1) while performing the following operation: &DEBUG_INFO the following error occurs.

Solution:-

This error is caused because when the invoice is validated the system tries to create the automatic withholding invoice yet there is no Payment Term associated with the Supplier (Tax Authority) site. Since the invoice could not be created without this, the validation fails.

1. Navigate to Supplier form
Payables > Suppliers > Entry

2. Query the Supplier/Tax Authority linked to the withholding group on the problematic invoice
Click Update
Select the Key Payment Setup tab

3. Scroll to the Payment terms section and add a Payment Term to the Tax Authority for that Vendor Site.

4. Retest the issue

Check the opening and closing balances in the control totals

Issue: 

Check the opening and closing balances in the control totals.

Solution:


The Bank Statement Import program checks if the Control end balance matches:
(Control begin balance) + (Control cr amount) - (Control dr amount)

If not, it shows the warning, "Check the opening and closing balances in the control totals."

Here's the steps to address the warning:

Case 1:
Bank statement file does not provide the opening and closing balances and these optional fields are not populated.
So CONTROL_TOTAL_DR and CONTROL_TOTAL_CR are populated but not the begin and end balance.

Workaround:
Either null out the CONTROL TOTAL DR and CONTROL TOTAL CR, or populate begin and end balance for the Bank Statement Import Parameters.

Case 2:
CONTROL_BEGIN_BALANCE and CONTROL_END_BALANCE is populated but not CONTROL_TOTAL_DR and CONTROL_TOTAL_CR

The issue can occurr when there is a missing transaction code setup.

1 - With the Bank Statement in the Interface tables , navigate to the Bank Statement Interface form.

2 - Check the Bank Transaction Codes assigned to the Bank Statement Lines.

3 - Ensure Bank Transaction Codes identified on the Bank Statement are correctly setup in the system prior to importing the bank statement.

Please check the information from bank statement loader TDD:
-----------------------------------------------------------
After you load SWIFT940 bank statement files into the open interface tables,
you may need to define new bank transaction codes in Cash Management.
SWIFT940 transaction codes represent the type of transaction. For example,
TRF represents transfers. SWIFT940 transaction codes do not, however, contain
information about the debit or credit nature of the transaction. Instead,
the Debit/Credit Mark field is used to differentiate debit and credit
entries, where D means debit and C means credit. When the Bank Statement
Loader program populates the TRX_CODE column in the Bank Statement Lines
Interface table, it appends the Debit/Credit Mark to the transaction code to
form a new code. For example, debit transfers are identified as TRFD and
credit transfers as TRFC. You must set up these new transaction codes before
you can import the bank statement information.


4 - Once this is checked and corrected ( if required ), make a change to the Bank Statement in the Interface form and save.

5 - Now, try to import the Bank Statement.