We we need or want to cancel an invoice, Oracle Payables allows us to cancel only unpaid invoices. In addition these invoices cannot be on postable holds, have applied prepayments, or have been matched to a permanently closed PO. If invoices are prepayments, we cannot cancel the prepayments if they are applied to the invoices. If the invoices are placed on postable hold, these invoices must be released from the holds prior to being cancelled. If we cancel an invoice, we will no longer be able to make changes to it. To cancel invoice distributions, we must reverse them. When Oracle Payables cancels an invoice, it sets the invoice amount and all its scheduled payments to zero. It also reverses the invoice distributions of the invoice and any PO matches.It also submits invoice approval, and if there are no postable holds, the invoice will be cancelled.
To cancel an invoice, we use the invoice Workbench. Enter the selection criteria and click on the Find button to locate the invoice you want to cancel. From the invoices form, select the action button. The invoice actions form will appear. To cancel invoice, check the Cancel Invoices checkbox and click on OK. The invoice will be cancelled if there are no postable holds.
Maintaining Invoice and Credit Memo Transactions
In oracle Receivables transaction can be reviewed an updated after creation regardless of whether the transaction was created manually or imported using ‘Auto Invoice’.There are exceptions to this and some system options and profile options have to be set.
If the Allow change to printed transactions system option is ‘Yes’ you can update most of the transaction information, even if the transaction has been printed. However if there is activity against the transaction, you will not be able to make changes to many of the transaction attributes. Activity includes actions such as payments, credit memos, adjustments and including transactions on a consolidated billing invoice.
After your transactions have posted to your General Ledger, you can still update most of information. Receivables maintains a complete audit trail of all the posted changes you make to your accounting entries.
Receivable does not maintain an audit trail when you change a transaction that has not been posted.
Also what can be changed depends on various attribute settings on the transaction. In addition to updating transactions, you may find the need to delete or void a transaction. Again, there are circumstances under which deleting or voiding a transaction can be accomplished.
Transaction Field Reference
When reviewing the tables, you will notice the tables indicate the field reference in down the left side of the table with the conditions going across the rows. Within the rows is the indication as to whether this field reference can be updated or not any exceptions that must be considered. By using these tables you will resolve many of your own issues as to why a user cannot update particular field on an invoice or credit memo.
When reviewing the update table you will note there are two sections, header and line levels.
Once you save the transaction, you cannot update the transaction number.
Additionally here are some profile options and system options that effect maintaining transactions.
System options can be set as follows
Setup/System/System Options/Trans and Customers Tab
Set allow change to printed transactions to Yes
Profile Options can be set as follows
Using the system administrator responsibility
Profile/System
Profile/System
Site level
Query in the field for the profile of choice. Some profile options that affect maintaining transactions are
AR: Update Due
AR: Change Customer on Transaction
Allow update existing sales credits
Sequential Numbering – Make the options is not null at all levels, has to contain a value at least one level.
Delete or Void Transactions
Deleting or voiding transactions can be accomplished depending on how your administrator has setup function security on you Oracle Receivables.
If the allow change to Printed Transactions system options is set to Yes and transactions have no activity against them, then the transaction have no activity against them, then the transactions can be removed by one of the following methods:
By delete record from the edit menu. This will delete invoice and any lines.
Invoice with rules cannot be deleted but you can create a credit memo and apply it to the invoice. The credit memo will create a credit entry offsetting the invoice debit entry.
Void the invoice by changing the invoice type in the Transaction window to a type with the Open Receivables and Post to GL options set to No. This will delete the payment schedule and cancel the distributions by removing the GL Date.
Delete the payment schedule by choosing incomplete button in Transaction window. This makes the invoice inaccessible for payment or crediting.
Maintaining Transactions Navigation
Navigate to the Transactions or the Transactions summary window:
Transactions/Transactions
Query the Transaction.
Change the transaction type to ‘void’ transaction type
Save
Transaction Table Information
Invoice : When an invoice is created the Header information is written to the RA_CUSTOMER_TRX_ALL table. Changes to any of the header information such as the customer invoice line information is written to RA_CUSTOMER_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL and RA_CUST_TRX_LINE_SALEREPS_ALL.
RA_CUST_TRX_LINES_ALL holds line details, what and how much is being invoices a nd what tax is applicable.
RA_CUST_TRX_LINES_GL_DIST_ALL stores information that need to be posted across General Ledger. a
AR_PAYMENT_SCHEDULES_ALL keeps running totals of the Invoice amounts for line,tax and freight. Record both the original amounts and the amounts remaining.
RA_CUST_TRX_LINE_SALEREPS_ALL stores who get credited for the sale represented by the invoice.
Credit Memo
Credit memos are stored in the same tables as the invoices. RA_CUSTOMER_TRX_ALL hold the credit memo header information similar to that of the invoice credit memo line information is t stored in RA_CUST_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_LINES ALL holds credit memo line detail information.
AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied
If the Allow change to printed transactions system option is ‘Yes’ you can update most of the transaction information, even if the transaction has been printed. However if there is activity against the transaction, you will not be able to make changes to many of the transaction attributes. Activity includes actions such as payments, credit memos, adjustments and including transactions on a consolidated billing invoice.
After your transactions have posted to your General Ledger, you can still update most of information. Receivables maintains a complete audit trail of all the posted changes you make to your accounting entries.
Receivable does not maintain an audit trail when you change a transaction that has not been posted.
Also what can be changed depends on various attribute settings on the transaction. In addition to updating transactions, you may find the need to delete or void a transaction. Again, there are circumstances under which deleting or voiding a transaction can be accomplished.
Transaction Field Reference
When reviewing the tables, you will notice the tables indicate the field reference in down the left side of the table with the conditions going across the rows. Within the rows is the indication as to whether this field reference can be updated or not any exceptions that must be considered. By using these tables you will resolve many of your own issues as to why a user cannot update particular field on an invoice or credit memo.
When reviewing the update table you will note there are two sections, header and line levels.
Once you save the transaction, you cannot update the transaction number.
Additionally here are some profile options and system options that effect maintaining transactions.
System options can be set as follows
Setup/System/System Options/Trans and Customers Tab
Set allow change to printed transactions to Yes
Profile Options can be set as follows
Using the system administrator responsibility
Profile/System
Profile/System
Site level
Query in the field for the profile of choice. Some profile options that affect maintaining transactions are
AR: Update Due
AR: Change Customer on Transaction
Allow update existing sales credits
Sequential Numbering – Make the options is not null at all levels, has to contain a value at least one level.
Delete or Void Transactions
Deleting or voiding transactions can be accomplished depending on how your administrator has setup function security on you Oracle Receivables.
If the allow change to Printed Transactions system options is set to Yes and transactions have no activity against them, then the transaction have no activity against them, then the transactions can be removed by one of the following methods:
By delete record from the edit menu. This will delete invoice and any lines.
Invoice with rules cannot be deleted but you can create a credit memo and apply it to the invoice. The credit memo will create a credit entry offsetting the invoice debit entry.
Void the invoice by changing the invoice type in the Transaction window to a type with the Open Receivables and Post to GL options set to No. This will delete the payment schedule and cancel the distributions by removing the GL Date.
Delete the payment schedule by choosing incomplete button in Transaction window. This makes the invoice inaccessible for payment or crediting.
Maintaining Transactions Navigation
Navigate to the Transactions or the Transactions summary window:
Transactions/Transactions
Query the Transaction.
Change the transaction type to ‘void’ transaction type
Save
Transaction Table Information
Invoice : When an invoice is created the Header information is written to the RA_CUSTOMER_TRX_ALL table. Changes to any of the header information such as the customer invoice line information is written to RA_CUSTOMER_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL and RA_CUST_TRX_LINE_SALEREPS_ALL.
RA_CUST_TRX_LINES_ALL holds line details, what and how much is being invoices a nd what tax is applicable.
RA_CUST_TRX_LINES_GL_DIST_ALL stores information that need to be posted across General Ledger. a
AR_PAYMENT_SCHEDULES_ALL keeps running totals of the Invoice amounts for line,tax and freight. Record both the original amounts and the amounts remaining.
RA_CUST_TRX_LINE_SALEREPS_ALL stores who get credited for the sale represented by the invoice.
Credit Memo
Credit memos are stored in the same tables as the invoices. RA_CUSTOMER_TRX_ALL hold the credit memo header information similar to that of the invoice credit memo line information is t stored in RA_CUST_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_LINES ALL holds credit memo line detail information.
AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied
Match Approval Level (Matching of Invoices with Purchase Orders)
If we use Oracle Payables with Oracle Purchasing or another integrated purchasing product, we can perform online matching of invoices and original purchase orders or purchase order receipts. Matching ensures that we only pay for the goods and services you ordered and that our suppliers do not over bill us. If we are billed for an item over the amount and quantity invoice tolerances that we define in the Invoice Tolerances window in Payables then Invoice validation applies holds to the invoice and prevents payment until we release the holds.
For 3 Way matching to work, we must set a value for Quantity received in the Invoice Tolerances window , and the item needs to be set to receipt required.
2 - Way- When we match to purchase order or receipt, Invoice validation performs these control checks.
1. Quantity Billed <= Quantity Ordered.
2. Invoice Price <=Pruchase Order Price.
3 Way-
1. Quantity Billed <= Quantity Ordered.
2. Invoice Price <=Pruchase Order Price.
3. Quantity Billed <= Quantity Received.
4 Way-
1. Quantity Billed <= Quantity Ordered.
2. Invoice Price <=Pruchase Order Price.
3. Quantity Billed <= Quantity Received.
4.Quantity Billed <=Quantity Accepted.
For 3 Way matching to work, we must set a value for Quantity received in the Invoice Tolerances window , and the item needs to be set to receipt required.
2 - Way- When we match to purchase order or receipt, Invoice validation performs these control checks.
1. Quantity Billed <= Quantity Ordered.
2. Invoice Price <=Pruchase Order Price.
3 Way-
1. Quantity Billed <= Quantity Ordered.
2. Invoice Price <=Pruchase Order Price.
3. Quantity Billed <= Quantity Received.
4 Way-
1. Quantity Billed <= Quantity Ordered.
2. Invoice Price <=Pruchase Order Price.
3. Quantity Billed <= Quantity Received.
4.Quantity Billed <=Quantity Accepted.
Incorporation Custom Programs
Incorporation Custom Program
Oracle Applications comes seeded with many concurrent reports and programs. However, we will most likely need to extend Oracle Applications by creating custom reports for any Oracle Applications installation. Oracle Suggests we create our custom application before incorporating custom programs.
Identifying an Executable to Oracle Applications
To incorporate a custom program, we must first create an executable, which is the operating system file for the concurrent program. For Oracle Report, for example the executable file is the .RDF executable file. To define executable, we follow the navigation path Concurrent/Program/Executable
First, enter the required fields, including the executable name, the executable short name, and the application. The executable name is the user name that associates the executable to a concurrent program. The application determines the top directory/base path for the operating system file. For example, if we select Oracle General Ledger as the application, the program file will be found in the GL_TOP directory. We can also enter an optional description. Next select an execution method, which determines what type of program we are registering and what subdirectory name sql and SQL*Loader or C executables will be in the subdirectory name bin.
Once we have entered the execution method, enter the required execution filename, which is the operating system filename. If the execution method is Immediate or Spawned, enter the subroutine name in the Subroutine name field. If the execution method is Request Set Stage function, click on the stage function parameters button to enter parameters.
Valid Execution Methods
Host- Operating System File
Immediate- Concurrent manager program library subroutine.
Oracle Reports- Oracle Reports reports
PL/SQL Stored Procedure- Database stored procedure
Request Set Stage Function -Database stored function that calculates the completion statues of request set stages.
Spawned - C or Pro C program
SQL *Loader - SQL *Loader control file.
SQL Plus - SQL *Plus or PL/SQL Program files.
Define Concurrent Program
Once we have defined the executable, we can now define a concurrent program. Follow the navigation path Concurrent/Program/Define First, enter the concurrent program name, which will appear to the user in the Submit Request and the view my Request forms. Check the enabled checkbox to enable the concurrent program. Next enter a unique short name and the application name. The application name identifies the location of the output and log files as well as which Oracle Database user ID to use at execution time. Enter an optional description.
In the Executable region, select the defined executable. If the execution method is Oracle Reports and the report is in bitmapped mode, we must enter VERSION=2.0b in the option field. We can also pass ORIENTATION and PAGESIGE parameters to bitmapped reports, and assign a priority to the concurrent program. If no priority is defined, the priority will be based on the profile option Concurrent/Profile Value.
In the Request region, we can assign a request type to the concurrent program, if we wish, we can also identify whether the concurrent program can be user in SRS, whether disabled values are allowed as parameters, whether the concurrent program must be run alone, whether a trace should be enabled for the concurrent program, whether the concurrent program should restart after system failure, and whether the concurrent program is NLS (National Language Support) compliant.
In the Output region, select valid format type HGML, PostScript, PDF, Text. Then decide whether we want to save and or print the output file. We can also enter the minimum column and row length, for the output file. We can also enter the minimum column and row length for the output file. If we enter minimum column and row length, some print styles may be eliminated. Key in the print style for the program. If we check the style required checkbox, the print style will be locked for the concurrent program and application users will not be able to override it. We can also limit the concurrent program to print to a dedicated printer.
Click on the Incompatibilities button to identify concurrent programs that should not be running along with this particular program. To enter incompatible programs, enter the application and program name. Next, identify whether the scope of incompatibility is a set, or just the individual program alone. One common usage of incompatible programs is to make a program incompatible with itself.
Specifying Concurrent Program Parameter Information
Click on the parameters button to specify parameters for the concurrent programs. For each parameter, enter a sequence number, a parameter name, a description, and whether we want to enable the parameter.
In the validation region, enter a value set govern valid values of the parameters, we also enter a default type and default value . Default types can be Constant, Current Date, Current Time, Profile , SQL Statement, of Segment. A default value may be defined for a default type of Constant, Profile, SQL Statement, of Segments. For Constant , the default value will be the literal value entered in the default value field. For profile , enter the profile option name in the default value field; at execution time, the default value of the parameter will be set to the value of the profile option. For SQL statement enter a SQL statement in the Default Value field. For segments, the default value will be the segment name.
We can determine whether the parameter is required, and we can decide whether we want to enable security for the parameter. If we wish we can enter Low and High or Pair as the range. If we enter low in one parameter, we must enter High for another parameter;otherwise, when the application user submits the program it will produce an error. The low and the high ranges are used to govern two parameters that identify a range. For example the low can be a start date and the high can be an end date. Oracle Applications ensure that the end date is after the start date. For pair we must identify two parameters as a pair and again, Oracle Applications will make sure that both parameters identified as Pair are entered.
Check the display checkbox if we want parameters to be displayed. At last enter the display size, the description size, the concatenated description size, and the prompt. If the concurrent program is of execution method Oracle Reports, we will need to enter a token equal to the parameter name defined in Oracle Reports.
Once we have defined concurrent program and its incompatible programs and parameters, we may click on the copy to button to copy the concurrent program definition to create new program.
Oracle Applications comes seeded with many concurrent reports and programs. However, we will most likely need to extend Oracle Applications by creating custom reports for any Oracle Applications installation. Oracle Suggests we create our custom application before incorporating custom programs.
Identifying an Executable to Oracle Applications
To incorporate a custom program, we must first create an executable, which is the operating system file for the concurrent program. For Oracle Report, for example the executable file is the .RDF executable file. To define executable, we follow the navigation path Concurrent/Program/Executable
First, enter the required fields, including the executable name, the executable short name, and the application. The executable name is the user name that associates the executable to a concurrent program. The application determines the top directory/base path for the operating system file. For example, if we select Oracle General Ledger as the application, the program file will be found in the GL_TOP directory. We can also enter an optional description. Next select an execution method, which determines what type of program we are registering and what subdirectory name sql and SQL*Loader or C executables will be in the subdirectory name bin.
Once we have entered the execution method, enter the required execution filename, which is the operating system filename. If the execution method is Immediate or Spawned, enter the subroutine name in the Subroutine name field. If the execution method is Request Set Stage function, click on the stage function parameters button to enter parameters.
Valid Execution Methods
Host- Operating System File
Immediate- Concurrent manager program library subroutine.
Oracle Reports- Oracle Reports reports
PL/SQL Stored Procedure- Database stored procedure
Request Set Stage Function -Database stored function that calculates the completion statues of request set stages.
Spawned - C or Pro C program
SQL *Loader - SQL *Loader control file.
SQL Plus - SQL *Plus or PL/SQL Program files.
Define Concurrent Program
Once we have defined the executable, we can now define a concurrent program. Follow the navigation path Concurrent/Program/Define First, enter the concurrent program name, which will appear to the user in the Submit Request and the view my Request forms. Check the enabled checkbox to enable the concurrent program. Next enter a unique short name and the application name. The application name identifies the location of the output and log files as well as which Oracle Database user ID to use at execution time. Enter an optional description.
In the Executable region, select the defined executable. If the execution method is Oracle Reports and the report is in bitmapped mode, we must enter VERSION=2.0b in the option field. We can also pass ORIENTATION and PAGESIGE parameters to bitmapped reports, and assign a priority to the concurrent program. If no priority is defined, the priority will be based on the profile option Concurrent/Profile Value.
In the Request region, we can assign a request type to the concurrent program, if we wish, we can also identify whether the concurrent program can be user in SRS, whether disabled values are allowed as parameters, whether the concurrent program must be run alone, whether a trace should be enabled for the concurrent program, whether the concurrent program should restart after system failure, and whether the concurrent program is NLS (National Language Support) compliant.
In the Output region, select valid format type HGML, PostScript, PDF, Text. Then decide whether we want to save and or print the output file. We can also enter the minimum column and row length, for the output file. We can also enter the minimum column and row length for the output file. If we enter minimum column and row length, some print styles may be eliminated. Key in the print style for the program. If we check the style required checkbox, the print style will be locked for the concurrent program and application users will not be able to override it. We can also limit the concurrent program to print to a dedicated printer.
Click on the Incompatibilities button to identify concurrent programs that should not be running along with this particular program. To enter incompatible programs, enter the application and program name. Next, identify whether the scope of incompatibility is a set, or just the individual program alone. One common usage of incompatible programs is to make a program incompatible with itself.
Specifying Concurrent Program Parameter Information
Click on the parameters button to specify parameters for the concurrent programs. For each parameter, enter a sequence number, a parameter name, a description, and whether we want to enable the parameter.
In the validation region, enter a value set govern valid values of the parameters, we also enter a default type and default value . Default types can be Constant, Current Date, Current Time, Profile , SQL Statement, of Segment. A default value may be defined for a default type of Constant, Profile, SQL Statement, of Segments. For Constant , the default value will be the literal value entered in the default value field. For profile , enter the profile option name in the default value field; at execution time, the default value of the parameter will be set to the value of the profile option. For SQL statement enter a SQL statement in the Default Value field. For segments, the default value will be the segment name.
We can determine whether the parameter is required, and we can decide whether we want to enable security for the parameter. If we wish we can enter Low and High or Pair as the range. If we enter low in one parameter, we must enter High for another parameter;otherwise, when the application user submits the program it will produce an error. The low and the high ranges are used to govern two parameters that identify a range. For example the low can be a start date and the high can be an end date. Oracle Applications ensure that the end date is after the start date. For pair we must identify two parameters as a pair and again, Oracle Applications will make sure that both parameters identified as Pair are entered.
Check the display checkbox if we want parameters to be displayed. At last enter the display size, the description size, the concatenated description size, and the prompt. If the concurrent program is of execution method Oracle Reports, we will need to enter a token equal to the parameter name defined in Oracle Reports.
Once we have defined concurrent program and its incompatible programs and parameters, we may click on the copy to button to copy the concurrent program definition to create new program.
Ways to Audit Oracle Applicaitons
There are two auditing types in Oracle Applications
Users
Database Changes
Users-We can audit users at four different levels. The level is determined by the prole option Sing-On, Audit Level,. The four levels are
None - No Auditing
User- Audit the sign on application user name, time and the terminal.
Responsibility- Audit the sign on application user name, time, the terminal, the responsibilities chosen, and the time used for each responsibility.
Form-Audit the sign on application user name, time the terminal, the responsibilities chosen, the time used for each responsibility, the forms the user utilizes, and the time used for each form.
If we set the sign-on, Audit level option to a level other than None, we can then monitor users online using the Monitor Users form. Follow the navigation path
Security/User /Monitor.
Database Changes
We can set up audit trails to track changes users make in the Oracle database. To enable the audit trail, we must
Define audit Installations
Define audit groups
Define audit tables
Run the audit trail update tables request
Define Audit Installations- During installation, we must enable audit trails for an Oracle database user ID. Follow the navigation path Security/Audit trial / Install. Select the Oracle User name for which we want to enable audit trails and check the Audit enabled on checkbox.
Define Audit Groups-Next, we must define audit groups to identify what tables we wish to audit. For custom tables to appear in the List of Values we select form, we must first register them. To define audit groups, follow the navigation path Security/AuditTrail/Groups. On the Audit Groups form, select the application name and enter the audit group name. The combination must be unique across the entire Oracle Applications. Again, the application name is for information purposes only and will not restrict any table to be audited. The group state displays the state of the audit group. Valid audit group states are Enable Requested, Disable-Interrupt Audit, Disable-prepare for Archive, Disable Purge table and enabled.
When we first create and audit group, the state is Enable Requested; after we run the audit trail update tables request, the state becomes enabled. To disable auditing, we have three choices. We can disable audit by changing the state to disable-Interrupt Audit. This allows we to interrupt auditing and write one final row into the shadow table whenever the row is being modified(this is slow disable). Or, we can change the state to Disable-Prepare for Archive. This allows we to copy the existing values for all audited rows to the shadow table immediately and disable auditing right away. We usually use this disable option to perform an achieve and enable auditing again. Before we enable auditing again, we must manually purge the shadow table. We can also change the state to Disable -Purge table to purge the shadow table and disable auditing immediately. We can also enter an optional description for our audit group.
Next, enter the audit tables to be included in our audit group. Select the user table name. The system table name, and the application , and the description will be automatically filled in. For our online exercise, create an audit group called New_Audit group and select a few GL tables such as GL_BALANCES and GL_CODE_COMBINATIONS.
Define Audit Tables- Next select the columns to be audited for each audited table. Once the columns are selected, they cannot be deleted. Columns can be selected from a list of values, where the primary keys column will have the primary key checkbox checked. All of the primary keys will be automatically audited. We can add the columns using the Define Audit tables form. To define audit tables, we can follow the navigation path Security/AuditTrail/Tables.
Run the Audit Trail Update Tables Request-The audit trail update tables request generates database triggers and shadow tables for our audit groups. Whenever we change the audit groups or audit tables definitions, we must rerun this request. Run this request through SRS and the audit trail will be enabled.
Users
Database Changes
Users-We can audit users at four different levels. The level is determined by the prole option Sing-On, Audit Level,. The four levels are
None - No Auditing
User- Audit the sign on application user name, time and the terminal.
Responsibility- Audit the sign on application user name, time, the terminal, the responsibilities chosen, and the time used for each responsibility.
Form-Audit the sign on application user name, time the terminal, the responsibilities chosen, the time used for each responsibility, the forms the user utilizes, and the time used for each form.
If we set the sign-on, Audit level option to a level other than None, we can then monitor users online using the Monitor Users form. Follow the navigation path
Security/User /Monitor.
Database Changes
We can set up audit trails to track changes users make in the Oracle database. To enable the audit trail, we must
Define audit Installations
Define audit groups
Define audit tables
Run the audit trail update tables request
Define Audit Installations- During installation, we must enable audit trails for an Oracle database user ID. Follow the navigation path Security/Audit trial / Install. Select the Oracle User name for which we want to enable audit trails and check the Audit enabled on checkbox.
Define Audit Groups-Next, we must define audit groups to identify what tables we wish to audit. For custom tables to appear in the List of Values we select form, we must first register them. To define audit groups, follow the navigation path Security/AuditTrail/Groups. On the Audit Groups form, select the application name and enter the audit group name. The combination must be unique across the entire Oracle Applications. Again, the application name is for information purposes only and will not restrict any table to be audited. The group state displays the state of the audit group. Valid audit group states are Enable Requested, Disable-Interrupt Audit, Disable-prepare for Archive, Disable Purge table and enabled.
When we first create and audit group, the state is Enable Requested; after we run the audit trail update tables request, the state becomes enabled. To disable auditing, we have three choices. We can disable audit by changing the state to disable-Interrupt Audit. This allows we to interrupt auditing and write one final row into the shadow table whenever the row is being modified(this is slow disable). Or, we can change the state to Disable-Prepare for Archive. This allows we to copy the existing values for all audited rows to the shadow table immediately and disable auditing right away. We usually use this disable option to perform an achieve and enable auditing again. Before we enable auditing again, we must manually purge the shadow table. We can also change the state to Disable -Purge table to purge the shadow table and disable auditing immediately. We can also enter an optional description for our audit group.
Next, enter the audit tables to be included in our audit group. Select the user table name. The system table name, and the application , and the description will be automatically filled in. For our online exercise, create an audit group called New_Audit group and select a few GL tables such as GL_BALANCES and GL_CODE_COMBINATIONS.
Define Audit Tables- Next select the columns to be audited for each audited table. Once the columns are selected, they cannot be deleted. Columns can be selected from a list of values, where the primary keys column will have the primary key checkbox checked. All of the primary keys will be automatically audited. We can add the columns using the Define Audit tables form. To define audit tables, we can follow the navigation path Security/AuditTrail/Tables.
Run the Audit Trail Update Tables Request-The audit trail update tables request generates database triggers and shadow tables for our audit groups. Whenever we change the audit groups or audit tables definitions, we must rerun this request. Run this request through SRS and the audit trail will be enabled.
Importing Journal Entries
Importing Journal
We can import journal entries from subledger such as Oracle Receivables and Oracle Payables, Loans etc. Importing journal entries is a function performed by the Journal Import Program.
Most Oracle Financials subledgers post their accounting journals into an interface table called GL_INTERFACE. The Journal Import program reads the records in this interface table and processes them into GL's production tables, creating journal entries with batches, Journals and Journal lines. There are two exceptions to this ;
Oracle Assets posts its accounting journals directly into GL's production tables bypassing the interface tables.
Oracle Purchasing Encumbrance journals also post directly into GL's production tables bypassing the interface tables.
The other subledgers all go through the interface table, and they generally provide an option to run the Journal Import program automatically after posting the accounting entries to Oracle General Ledger. If Journal Import is not set to run automatically after the subledger transfer, we must run Journal Import manually. We can do this by navigation path
Journals/Import/Run
This will call up the import journal form, in this form we start by selecting the journal source we want to import. One easy way to do this is to execute the Edit/List of Values menu command, which will produce a list of valid journal sources. We can select a source and then click on the OK button to have it placed into the Source column in the Import Journals form.
Some Journal sources, such as Oracle Receivables, send journals to Oracle GL in groups. When importing Journals from such sources, we must select the group id.(Group IDs are assigned automatically by subledger and are used to subdivide ther interface journals into separate batches. Different subledgers have different rules in deriving group IDs some subledgers do not even use a group, and just send the journals as a single large batch). The import journals from include checkboxes offering two different run options:
Post Errors to Suspense-Causes the Journal Import program to balance journals by posting the difference between debit and credit amounts to a suspense account. We can only select the post errors to suspense option if suspense accounting is allowed at the set of books level. Suspense accounts can defined at the Set of Books level or overridden by the Journal source and Journal Category combinations. If post Errors to Suspense is not enabled the Journal Import will reject any unbalanced journals.
Create Summary Journals- the Journal import program to add journal lines together (summarize them ) by accounting combination, currency, and accounting period. The detailed journal lines are retained in our journal source if it has been configured to keep import journal references. Selecting the Create Summary Journal option disable to import of descriptive flexfield information.
Correcting Journals
If the Journal Import Program report import errors, we can correct data in the interface table and rerun journal import. This will require one of two different approaches, depending on where the erroneous data came from :
If the problem data cam from Oracle Subledgers, we must fix the problem in two places: their source and the interface table. This is because Oracle Subledgers wil not retransfer journals to the interface table. So after we fix the source and essential step because the problem is likely to occur again next accounting period if the subledger is not fixed we must still correct data in the interface table and rerun journal import.
If the problem is related to how Oracle GL is set up for instance a segment value being disabled or an accounting period not opened you can simply fix the GL setup and rerun Journal import.
If we do need to correct records in the interface table directly , we can do so by following the navigation path
Journals/Import/Correct
This causes two forms to appear: the Correct Journal Import data form is in the background, while the find Journal Import Data form opens in the foreground. Using the find journal import data window, we can specify a wide variety of search criteria; the desired status (the error code error or corrected), Journal source application, transaction category , accounting date range, journal type (actual, budget, encumbrance), currency, and group IDs range.
Once we have specified the Journal Import data we wish to find, we are returned to the Correct Journal Import Data Form. The bottom portion of this form is capable of displaying five different sets, or regions of data : batches/Journals, accounts journal lines, descriptive flexfields, and references. We select the region we want by choosing it from a drop down list. Select appropriate region from list, correct the problem save.
Deleting Journals- We can delete journals using the delete/journal/import data form , which is available via the navigation path journals /import/delete. We can specify the journal source application, the concurrent request that corresponds to a journal import run, or a group ID.
************IMP**********
This procedure must be used with extreme caution: remember that Oracle Sub ledgers Will no re transfer. We should use this step only if the data is from a source that be required, such as a data conversion or another interface that can regenerate and reinterface the accounting entries.
We can import journal entries from subledger such as Oracle Receivables and Oracle Payables, Loans etc. Importing journal entries is a function performed by the Journal Import Program.
Most Oracle Financials subledgers post their accounting journals into an interface table called GL_INTERFACE. The Journal Import program reads the records in this interface table and processes them into GL's production tables, creating journal entries with batches, Journals and Journal lines. There are two exceptions to this ;
Oracle Assets posts its accounting journals directly into GL's production tables bypassing the interface tables.
Oracle Purchasing Encumbrance journals also post directly into GL's production tables bypassing the interface tables.
The other subledgers all go through the interface table, and they generally provide an option to run the Journal Import program automatically after posting the accounting entries to Oracle General Ledger. If Journal Import is not set to run automatically after the subledger transfer, we must run Journal Import manually. We can do this by navigation path
Journals/Import/Run
This will call up the import journal form, in this form we start by selecting the journal source we want to import. One easy way to do this is to execute the Edit/List of Values menu command, which will produce a list of valid journal sources. We can select a source and then click on the OK button to have it placed into the Source column in the Import Journals form.
Some Journal sources, such as Oracle Receivables, send journals to Oracle GL in groups. When importing Journals from such sources, we must select the group id.(Group IDs are assigned automatically by subledger and are used to subdivide ther interface journals into separate batches. Different subledgers have different rules in deriving group IDs some subledgers do not even use a group, and just send the journals as a single large batch). The import journals from include checkboxes offering two different run options:
Post Errors to Suspense-Causes the Journal Import program to balance journals by posting the difference between debit and credit amounts to a suspense account. We can only select the post errors to suspense option if suspense accounting is allowed at the set of books level. Suspense accounts can defined at the Set of Books level or overridden by the Journal source and Journal Category combinations. If post Errors to Suspense is not enabled the Journal Import will reject any unbalanced journals.
Create Summary Journals- the Journal import program to add journal lines together (summarize them ) by accounting combination, currency, and accounting period. The detailed journal lines are retained in our journal source if it has been configured to keep import journal references. Selecting the Create Summary Journal option disable to import of descriptive flexfield information.
Correcting Journals
If the Journal Import Program report import errors, we can correct data in the interface table and rerun journal import. This will require one of two different approaches, depending on where the erroneous data came from :
If the problem data cam from Oracle Subledgers, we must fix the problem in two places: their source and the interface table. This is because Oracle Subledgers wil not retransfer journals to the interface table. So after we fix the source and essential step because the problem is likely to occur again next accounting period if the subledger is not fixed we must still correct data in the interface table and rerun journal import.
If the problem is related to how Oracle GL is set up for instance a segment value being disabled or an accounting period not opened you can simply fix the GL setup and rerun Journal import.
If we do need to correct records in the interface table directly , we can do so by following the navigation path
Journals/Import/Correct
This causes two forms to appear: the Correct Journal Import data form is in the background, while the find Journal Import Data form opens in the foreground. Using the find journal import data window, we can specify a wide variety of search criteria; the desired status (the error code error or corrected), Journal source application, transaction category , accounting date range, journal type (actual, budget, encumbrance), currency, and group IDs range.
Once we have specified the Journal Import data we wish to find, we are returned to the Correct Journal Import Data Form. The bottom portion of this form is capable of displaying five different sets, or regions of data : batches/Journals, accounts journal lines, descriptive flexfields, and references. We select the region we want by choosing it from a drop down list. Select appropriate region from list, correct the problem save.
Deleting Journals- We can delete journals using the delete/journal/import data form , which is available via the navigation path journals /import/delete. We can specify the journal source application, the concurrent request that corresponds to a journal import run, or a group ID.
************IMP**********
This procedure must be used with extreme caution: remember that Oracle Sub ledgers Will no re transfer. We should use this step only if the data is from a source that be required, such as a data conversion or another interface that can regenerate and reinterface the accounting entries.
Defining Request Sets
We can define request sets to run multiple concurrent programs and reports at once. There are two types of request sets : Private and Public. Private Request sets are created by application users that are not logged on as system administrators. These users may include any programs from their responsibility's request security group in their private request set. The application user who creates the request set will become its owner. The private request set will always be available to the owner from the SRS form, regardless of whether the private request set is within the request security group. The only exception is when we use the Submit Request form customized with restrictions. This customized Submit Request form will not include any private request sets.
System administrators can create public request sets that include any concurrent programs and reports, and that assign any application user as the owner, or choose to have no owner. System administrators can also update any request set, regardless of who the owner is. Only the system administrator can update a request set that has no assigned owner. Otherwise, both the system administrator and the owner can update the request set. System administrator and the owner can update the request set. System administrators can also define request set incompatibilities.
Request sets can be assigned to request groups, just like concurrent programs and reports. When a request set's assigned to a request group, the request set's concurrent programs and reports are automatically assigned to the request group. In the request set contains concurrent programs and reports that do not exist entire request set, and not the individual program. In addition, the application user cannot edit the request set unless they are the owner of the request set, or are connected with the System Administrator responsibility.
As a system administrator we define request sets using the navigation path
Requests/Set (If connected to responsibility other than the system administrator , we would use navigation path Other/Request/Set)When creating a new request set, we can use the Request Set wizard or simply enter the request set name and code and the application module. Again, the request set name, the request set code, and both the application modules must be unique across Oracle Applications. We can also enter the description, and if we are a system administrator, we can assign an application user as the owner. If we are creating a request set, and we are not a system administrator, we will become the owner. Next we can enter an active date range to limit when the request set is valid. Then we can choose whether we want to print all of the concurrent programs and reports in the request set together (or have each one print as it completes). Finally choose whether to allow incompatibility between other concurrent programs/reports and the request set.
A request set is composed of one or more stage, and each stage is composed of one or more requests. Stages give we the ability to run groups of requests sequentially. All requests within the stage must be completed before the next stage starts. If we do not need the capability to run groups of requests sequentially, we can define only one stage for the request set. To define a request we must first define its stages. Creating a request set that consists of two stages i.e programs and reports. For each stage we must enter a display sequence, a stage name and optionally a stage description. Also required are a stage code and a function/application. The display sequence determines the order of the stages, and the stage code is used to identify the stage internally. We must also define a function to be used for evaluating the completion status of the stage. Oracle Applications comes seeded with the standard evaluation function. Last choose whether we want this stage outcome to define the request set outcome, and whether we allow incompatibility. If we have multiple stages that can impact the outcome of the request set, then the completion status of the last stage that completes will become the completion status of the entire request set.
Click on the Requests button to enter the concurrent reports and programs we want to include for the particular stage. Unless we are a system adminstrator, the concurrent reports and or programs we may select from are limited to those in our responsibility's request security group. For each program we include , we must enter a sequence number and the program name. We can uncheck the allow stage function to use this programs result checkbox if we do not want the status of specific program to be included in calculation of the status of the satage. We can also specify print options to decide how man copies to print the print style , the printer and whether we want to save the output files.
Click on the parameters button to see and update parameters fo each request. All of the parameters related to the request will be displayed, and the sequence fieldshows the order of the parameters. We can choose whether to dsplay or allow the user to modify the parameters, and we can enter a shared parameter in the applicable field. If we enter the same shared parameter lable for multiple parameters within the request set, then at run time the user only needs to enter the value for the first occurrence of the shared parameter, and the rest of the occurances within the entire request set will default to this value. Thus, we avoid typing in the same parameter multiple times. On the request parameters form, we can also specify a default type and default value for each parameter. These values will be applied when a user submits the request. The valid default types are as follows
Constant -Use a constant value (literal)as the default value.
Current Date-The current system date will be used as default. The format of the date depends on the length of the parameter. The length of 9 will have the current date in the DD-MON-YY format while the length of 11 will have the current date in the DD-MON-YYYY format.
Current Time- The current system time will be used as default.
Field -Use the field name as default value; the value of the field will be used when submitting request.
Profile-Enter the profile option name as the default value;at the time of submitting the request the value of the specified profile option will be used.
SQL Statement-Enter the sql statement as the default value; at the time of submitting the request the sql statement wil be executed.
Segment-Enter the prior segment name as the default value; at the time of submitting the request, the current segment will use the prior segment value.
Once the stages, requests and parameters have been defined, we must link the stages to let the system know how to proceed when each stage is completed either successfully , with a warning, or in error. In our exercise, form the Request Set form, click on the Link stages button. Link the success and warning completion of the programs stage to the reports stage. Click on Done when finished.
System administrators can create public request sets that include any concurrent programs and reports, and that assign any application user as the owner, or choose to have no owner. System administrators can also update any request set, regardless of who the owner is. Only the system administrator can update a request set that has no assigned owner. Otherwise, both the system administrator and the owner can update the request set. System administrator and the owner can update the request set. System administrators can also define request set incompatibilities.
Request sets can be assigned to request groups, just like concurrent programs and reports. When a request set's assigned to a request group, the request set's concurrent programs and reports are automatically assigned to the request group. In the request set contains concurrent programs and reports that do not exist entire request set, and not the individual program. In addition, the application user cannot edit the request set unless they are the owner of the request set, or are connected with the System Administrator responsibility.
As a system administrator we define request sets using the navigation path
Requests/Set (If connected to responsibility other than the system administrator , we would use navigation path Other/Request/Set)When creating a new request set, we can use the Request Set wizard or simply enter the request set name and code and the application module. Again, the request set name, the request set code, and both the application modules must be unique across Oracle Applications. We can also enter the description, and if we are a system administrator, we can assign an application user as the owner. If we are creating a request set, and we are not a system administrator, we will become the owner. Next we can enter an active date range to limit when the request set is valid. Then we can choose whether we want to print all of the concurrent programs and reports in the request set together (or have each one print as it completes). Finally choose whether to allow incompatibility between other concurrent programs/reports and the request set.
A request set is composed of one or more stage, and each stage is composed of one or more requests. Stages give we the ability to run groups of requests sequentially. All requests within the stage must be completed before the next stage starts. If we do not need the capability to run groups of requests sequentially, we can define only one stage for the request set. To define a request we must first define its stages. Creating a request set that consists of two stages i.e programs and reports. For each stage we must enter a display sequence, a stage name and optionally a stage description. Also required are a stage code and a function/application. The display sequence determines the order of the stages, and the stage code is used to identify the stage internally. We must also define a function to be used for evaluating the completion status of the stage. Oracle Applications comes seeded with the standard evaluation function. Last choose whether we want this stage outcome to define the request set outcome, and whether we allow incompatibility. If we have multiple stages that can impact the outcome of the request set, then the completion status of the last stage that completes will become the completion status of the entire request set.
Click on the Requests button to enter the concurrent reports and programs we want to include for the particular stage. Unless we are a system adminstrator, the concurrent reports and or programs we may select from are limited to those in our responsibility's request security group. For each program we include , we must enter a sequence number and the program name. We can uncheck the allow stage function to use this programs result checkbox if we do not want the status of specific program to be included in calculation of the status of the satage. We can also specify print options to decide how man copies to print the print style , the printer and whether we want to save the output files.
Click on the parameters button to see and update parameters fo each request. All of the parameters related to the request will be displayed, and the sequence fieldshows the order of the parameters. We can choose whether to dsplay or allow the user to modify the parameters, and we can enter a shared parameter in the applicable field. If we enter the same shared parameter lable for multiple parameters within the request set, then at run time the user only needs to enter the value for the first occurrence of the shared parameter, and the rest of the occurances within the entire request set will default to this value. Thus, we avoid typing in the same parameter multiple times. On the request parameters form, we can also specify a default type and default value for each parameter. These values will be applied when a user submits the request. The valid default types are as follows
Constant -Use a constant value (literal)as the default value.
Current Date-The current system date will be used as default. The format of the date depends on the length of the parameter. The length of 9 will have the current date in the DD-MON-YY format while the length of 11 will have the current date in the DD-MON-YYYY format.
Current Time- The current system time will be used as default.
Field -Use the field name as default value; the value of the field will be used when submitting request.
Profile-Enter the profile option name as the default value;at the time of submitting the request the value of the specified profile option will be used.
SQL Statement-Enter the sql statement as the default value; at the time of submitting the request the sql statement wil be executed.
Segment-Enter the prior segment name as the default value; at the time of submitting the request, the current segment will use the prior segment value.
Once the stages, requests and parameters have been defined, we must link the stages to let the system know how to proceed when each stage is completed either successfully , with a warning, or in error. In our exercise, form the Request Set form, click on the Link stages button. Link the success and warning completion of the programs stage to the reports stage. Click on Done when finished.
Defining Request Groups
We should recall that request security group are used to restrict and group the concurrent reports and programs that we can run. To create a request security group, you attach a request group to a responsibility. (We can also use the request groups to customize the SRS processing or reports, which we will learn about in the next section.) In this section, we will explore defining request groups. We define request groups through the navigation path
Security/Responsibility/Request
This will take you to the Request groups form.
To create a request group, we would first enter the group (request group name)and the application. We may include requests from any application in our request group, regardless of the application attached to our request group. The application name is for informational purpose only. The group and application are both required, and must be unique across Oracle Applications. Next, we can optionally assign a code to the request group. This code is used for a custom SRS form so that only programs or reports in this request group could be processed by the custom SRS form. The code together with the application module also must be unique. As a last step , we can enter an optional description.
Enter requests that are included in the request groups by selecting the type and the request name. The type can be Application, program, Set or stage function. Application means include all concurrent programs and reports within the application. Program and Set mean a particular concurrent request or a particular request set. Function means a particular concurrent request set stage function. Query up the GL concurrent program Group to see the definition of the request group you utilized for our responsibility.
Security/Responsibility/Request
This will take you to the Request groups form.
To create a request group, we would first enter the group (request group name)and the application. We may include requests from any application in our request group, regardless of the application attached to our request group. The application name is for informational purpose only. The group and application are both required, and must be unique across Oracle Applications. Next, we can optionally assign a code to the request group. This code is used for a custom SRS form so that only programs or reports in this request group could be processed by the custom SRS form. The code together with the application module also must be unique. As a last step , we can enter an optional description.
Enter requests that are included in the request groups by selecting the type and the request name. The type can be Application, program, Set or stage function. Application means include all concurrent programs and reports within the application. Program and Set mean a particular concurrent request or a particular request set. Function means a particular concurrent request set stage function. Query up the GL concurrent program Group to see the definition of the request group you utilized for our responsibility.
Submitting Requests Through SRS
The Standard Request Submission (SRS) window provides all users with a standard way to submit concurrent requests (i.e reports or programs). We can access the Submit a New Request form through the navigation path
Requests/Run
This standard form gives you the option to submit a request or a request set. (Request sets will be defined later in this section.) An application user can only submit single requests or request sets within the request security group associated with the logged on responsibility or through menu functions that were specifically programmed to run a report.
First we will be asked whether we want to run a single request or a request set. Select single request for now, and the Submit Request Form will open. We can identify the request either by typing a valid name in the Request Name field or by using the Edit /List of Values menu command and selecting the name from the list that appears. If we choose a concurrent program or report that requires parameters, we will be presented with a dialog box requesting values for those parameters.
Once we have returned to the Submit Request Form, you have the option of defining a submission schedule and variety of completion options.
To see the scheduling parameters, click on the Schedule button. When the Schedule form opens, click on the Apply a Saved Schedule button to apply a previously saved schedule. If we are not applying a saved schedule, we can specify our own schedule stating that the job should be run as soon as possible , once, periodically, or on specific days. Each of these choices causes appropriate fields to appear on the form. Once we have specified the parameters for the schedule, we can save it for reuse by checking the save this schedule for use again later checkbox. Click on the OK button to apply the schedule information to your submission request.
Once we have returned to the Submit Request form, we may click on the Completion Options button to specify actions we want the system to take after the request has been completed. These options include notifying one or more people through Workflow, and printing one or more copies of the output. Click on the OK button after we define the completion options we want, and then click on the Submit Request button to submit the program or report for processing.
Once we have entered all of the schedule information, parameters and completion options, we may wish to run this extract same request again in the future. To do so, click on the Copy a Prior Request button. We will see a list of all of our requests submitted since the last time the system administrator ran the Purge Concurrent Request and/or Manager data program. We may modify any of the parameters, schedule info, or completion options before submitting the request.
Requests/Run
This standard form gives you the option to submit a request or a request set. (Request sets will be defined later in this section.) An application user can only submit single requests or request sets within the request security group associated with the logged on responsibility or through menu functions that were specifically programmed to run a report.
First we will be asked whether we want to run a single request or a request set. Select single request for now, and the Submit Request Form will open. We can identify the request either by typing a valid name in the Request Name field or by using the Edit /List of Values menu command and selecting the name from the list that appears. If we choose a concurrent program or report that requires parameters, we will be presented with a dialog box requesting values for those parameters.
Once we have returned to the Submit Request Form, you have the option of defining a submission schedule and variety of completion options.
To see the scheduling parameters, click on the Schedule button. When the Schedule form opens, click on the Apply a Saved Schedule button to apply a previously saved schedule. If we are not applying a saved schedule, we can specify our own schedule stating that the job should be run as soon as possible , once, periodically, or on specific days. Each of these choices causes appropriate fields to appear on the form. Once we have specified the parameters for the schedule, we can save it for reuse by checking the save this schedule for use again later checkbox. Click on the OK button to apply the schedule information to your submission request.
Once we have returned to the Submit Request form, we may click on the Completion Options button to specify actions we want the system to take after the request has been completed. These options include notifying one or more people through Workflow, and printing one or more copies of the output. Click on the OK button after we define the completion options we want, and then click on the Submit Request button to submit the program or report for processing.
Once we have entered all of the schedule information, parameters and completion options, we may wish to run this extract same request again in the future. To do so, click on the Copy a Prior Request button. We will see a list of all of our requests submitted since the last time the system administrator ran the Purge Concurrent Request and/or Manager data program. We may modify any of the parameters, schedule info, or completion options before submitting the request.
Customizing Application Privileges
Application privileges, which govern which aspect of the application can be accessed can be defined to restrict or allow access at many different levels. There are several kinds of application privileges:
Set of Books
Data Groups
Forms
Functions
Securing attributes
Reports/Programs
Set of Books- This governs which Set of Books is associated with the application user. The application user can only see data within the associated Set of Books.
Data Groups- A data group maps each Oracle Application module to a database ID. This determines which Oracle database user ID connects to the database when using a certain application module. The Oracle database user ID determines which database tables and other database objects the user can access through Oracle Applications forms, reports, or concurrent programs.
Forms- Forms are the forms/windows that the application user can access. The list of forms that can be accessed by an application user is determined by the configuration of the menu attached to the responsibility the user is connected to. A given user will see a different menu (and can access different forms) each time they connect to a different responsibility.
Functions- Function security governs what functionality can be performed from a given responsibility. There are two kinds of functions: form functions and subfunctions. Form Functions are functions that will call a form; subfunctions are those within a form, usually associated with a button. Application users restricted from performing certain functions on a form will still be able to navigate to the form, but will not be able to navigate to the section of the form representing a restricted form function, or to see the buttons or graphics on a form that are associated with a restricted subfunctions.
Securing Attributes- Securing attributes governs what set of data values an application user can access through the self service Web Applications.
Reports/Programs- The list of available reports and programs varies, depending on the responsibility the user is connected to. A request group is defined as a list of reports and programs. A request group can then be attached to a responsibility, and this controls the programs and reports that can be accessed by users of that responsibility.
Set of Books
Data Groups
Forms
Functions
Securing attributes
Reports/Programs
Set of Books- This governs which Set of Books is associated with the application user. The application user can only see data within the associated Set of Books.
Data Groups- A data group maps each Oracle Application module to a database ID. This determines which Oracle database user ID connects to the database when using a certain application module. The Oracle database user ID determines which database tables and other database objects the user can access through Oracle Applications forms, reports, or concurrent programs.
Forms- Forms are the forms/windows that the application user can access. The list of forms that can be accessed by an application user is determined by the configuration of the menu attached to the responsibility the user is connected to. A given user will see a different menu (and can access different forms) each time they connect to a different responsibility.
Functions- Function security governs what functionality can be performed from a given responsibility. There are two kinds of functions: form functions and subfunctions. Form Functions are functions that will call a form; subfunctions are those within a form, usually associated with a button. Application users restricted from performing certain functions on a form will still be able to navigate to the form, but will not be able to navigate to the section of the form representing a restricted form function, or to see the buttons or graphics on a form that are associated with a restricted subfunctions.
Securing Attributes- Securing attributes governs what set of data values an application user can access through the self service Web Applications.
Reports/Programs- The list of available reports and programs varies, depending on the responsibility the user is connected to. A request group is defined as a list of reports and programs. A request group can then be attached to a responsibility, and this controls the programs and reports that can be accessed by users of that responsibility.
Setting Up Depreciation
To setup depreciation, we must define the following characteristics
Depreciation methods
Prorate/Retirement conventions
Bonus Rules
Depreciation Ceilings
Investment Tax Credits
Depreciation Methods
By following the navigation path Setup/Depreciation/Methods, we can select from four different depreciation methods. They are as follows:
Calculated- is a straight line method. It calculates an assets annual depreciation rate by spreading its recoverable cost evenly across its useful life. The calculation basis has to be cost. We can elect to depreciate the asset in the year it retires. We can also select assets useful life.
Table Depreciation- Method determines the depreciation rate based on a user or system defined table. The calculation basis can be cost or NBV. We can also enter the number of prorate periods per year this depreciation method uses. Clicking on the Rate button allows you to enter annual depreciation rates. Since assets must be fully depreciated when they are retired, for the Cost calculation basis, all annual rates must add up to exactly 1. For the NBV calculation basis, the annual rate for the asset's last year has to be 1, and the rates prior to the last year must be between o and 1.
Production- Is used for units of production depreciation, in which the depreciation rate is based on consumption. We cannot modify any parameter for this depreciation method, and no life needs to be defined.
Flat-Uses a flat rate as the depreciation rate. The calculation basis can be cost or NBV. We can elect to depreciate the asset in the year the asset retires, and we can specify whether to exclude salvage value if the cost basis is NBV. No life needs to be defined for this depreciation method.
Prorate Retirement Conventions
The prorate convention is used to determine how much depreciation to take in the first year of assets life, while the retirement convention is only used when an asset is retired before it is fully reserved. In this case, the retirement convention is used to determine how much depreciation to take in the last year of the asset's life. For depreciation methods other than straight line, you can enable the Depreciate when placed in service option to force use of the date placed in service instead of the prorate date. Common prorate convention include:
Following month starts depreciating in the period following the asset's date placed in service for example
From DATE TO Date Prorate Date
01-JAN-2005 31-JAN-2005 01-FEB-2005
01-FEB-2005 28-FEB-2005 01-MAR-2005
Half year starts depreciating at the beginning of the fiscal year or at the half year point of the fiscal year, depending on whether the asset is placed in service in the first half of the fiscal year or the second half of the fiscal year for example:
From Date TO Date Prorate Date
01-JAN-2005 31-JUN-2005 01-JAN-2005
01-JUL-2005 31-DEC-2005 01-JUL-2005
Mid Month applies when an asset is placed in service after mid month; take the half month depreciation in the period the asset's is placed in service, and half month depreciation in the month the asset is retired. Otherwise,take a full month in the period the asset is placed in service and nothing in the month the asset is retired. For Example
From Date TO Date Prorate Date
01-JAN-2005 15-JAN-2005 01-JAN-2005
16-JAN-2005 31-JAN-2005 16-JAN-2005
Mid quarter is similar to mid month, but instead of month, use the quarter as the date range. For example
From Date TO Date Prorate Date
01-JAN-2005 15-FEB-2005 01-JAN-2005
16-FEB-2005 31-MAR-2005 16-FEB-2005
Bonus Rules
For the flat depreciation method, we can create a bonus rate for each year, or range of years, of the asset's life.
Depreciation Ceilings
There are three types of depreciation ceilings:
A Cost Ceiling Sets the maximum value we can use as recoverable cost in depreciation.
An expense ceiling sets the maximum value we can take as a depreciation or an expense ceiling for assets in the tax book-but not both. For luxury automobiles in the United States, we must set an expense depreciation ceiling.
An Investment Tax credit ceiling sets the maximum amount that can be used to not surprisingly calculate an investment tax credit.
Investment Tax Credits
In order for investment tax credits (ITC) to work, we must also setup the ITC rates and ITC recapture rates. ITC rates define the amount of ITC for an asset, while ITC recapture rates define the amount of ITC that needs to be recaptured if the asset retires before its useful life is complete.
Depreciation methods
Prorate/Retirement conventions
Bonus Rules
Depreciation Ceilings
Investment Tax Credits
Depreciation Methods
By following the navigation path Setup/Depreciation/Methods, we can select from four different depreciation methods. They are as follows:
Calculated- is a straight line method. It calculates an assets annual depreciation rate by spreading its recoverable cost evenly across its useful life. The calculation basis has to be cost. We can elect to depreciate the asset in the year it retires. We can also select assets useful life.
Table Depreciation- Method determines the depreciation rate based on a user or system defined table. The calculation basis can be cost or NBV. We can also enter the number of prorate periods per year this depreciation method uses. Clicking on the Rate button allows you to enter annual depreciation rates. Since assets must be fully depreciated when they are retired, for the Cost calculation basis, all annual rates must add up to exactly 1. For the NBV calculation basis, the annual rate for the asset's last year has to be 1, and the rates prior to the last year must be between o and 1.
Production- Is used for units of production depreciation, in which the depreciation rate is based on consumption. We cannot modify any parameter for this depreciation method, and no life needs to be defined.
Flat-Uses a flat rate as the depreciation rate. The calculation basis can be cost or NBV. We can elect to depreciate the asset in the year the asset retires, and we can specify whether to exclude salvage value if the cost basis is NBV. No life needs to be defined for this depreciation method.
Prorate Retirement Conventions
The prorate convention is used to determine how much depreciation to take in the first year of assets life, while the retirement convention is only used when an asset is retired before it is fully reserved. In this case, the retirement convention is used to determine how much depreciation to take in the last year of the asset's life. For depreciation methods other than straight line, you can enable the Depreciate when placed in service option to force use of the date placed in service instead of the prorate date. Common prorate convention include:
Following month starts depreciating in the period following the asset's date placed in service for example
From DATE TO Date Prorate Date
01-JAN-2005 31-JAN-2005 01-FEB-2005
01-FEB-2005 28-FEB-2005 01-MAR-2005
Half year starts depreciating at the beginning of the fiscal year or at the half year point of the fiscal year, depending on whether the asset is placed in service in the first half of the fiscal year or the second half of the fiscal year for example:
From Date TO Date Prorate Date
01-JAN-2005 31-JUN-2005 01-JAN-2005
01-JUL-2005 31-DEC-2005 01-JUL-2005
Mid Month applies when an asset is placed in service after mid month; take the half month depreciation in the period the asset's is placed in service, and half month depreciation in the month the asset is retired. Otherwise,take a full month in the period the asset is placed in service and nothing in the month the asset is retired. For Example
From Date TO Date Prorate Date
01-JAN-2005 15-JAN-2005 01-JAN-2005
16-JAN-2005 31-JAN-2005 16-JAN-2005
Mid quarter is similar to mid month, but instead of month, use the quarter as the date range. For example
From Date TO Date Prorate Date
01-JAN-2005 15-FEB-2005 01-JAN-2005
16-FEB-2005 31-MAR-2005 16-FEB-2005
Bonus Rules
For the flat depreciation method, we can create a bonus rate for each year, or range of years, of the asset's life.
Depreciation Ceilings
There are three types of depreciation ceilings:
A Cost Ceiling Sets the maximum value we can use as recoverable cost in depreciation.
An expense ceiling sets the maximum value we can take as a depreciation or an expense ceiling for assets in the tax book-but not both. For luxury automobiles in the United States, we must set an expense depreciation ceiling.
An Investment Tax credit ceiling sets the maximum amount that can be used to not surprisingly calculate an investment tax credit.
Investment Tax Credits
In order for investment tax credits (ITC) to work, we must also setup the ITC rates and ITC recapture rates. ITC rates define the amount of ITC for an asset, while ITC recapture rates define the amount of ITC that needs to be recaptured if the asset retires before its useful life is complete.
Creating Summary Accounts
Summary accounts store balances of multiple accounts. To define how balances roll up into a summary account, you must set up summary templates. Summary templates can be defined by regular flexfield values, parent values, and rollup groups.
Defining Parent Segment Values
Parent Segment Values (also called parent values ) are values that reference other segment values typically knows as child segment values(also called child values). You can set up parent values for any segment values together, and they are utilized in reporting and/or assigned to rollup groups. Child values can be defined in ranges or individually.
Using the Chart of Accounts you defined earlier,you are going to add a parent value called ASSETS to include balances from the Cash and Receivables asset accounts you created earlier. You define parent values in the same from you define you segment values. Find your accounting flexfield structure and the account segment. To do this enter accounting flexfield structure and the segment name corresponding to the account segment in the find window, then click on the find button. You will see the values that are valid for the account segment. Go to the values(accounts) region, add a new record, and enter the value ASSETS and a description. Navigate to the Hierarchy, Qualifiers alternative region and check the Parent Checkbox to make this parent value.
Next define child values for the ASSETS parent value. Save first then click on the Define Child Ranges button to enter the child values. Enter child values for the Cash Account and the Receivables account, and in the include column select Child Values Only.
Defining Rollup Groups
Rollup groups are one level higher then parent values. Use rollup groups in summary account templates. Assign parent values to roolup groups. In order to use parent values in summary account templates, we must first assign the parent values to the rollup groups.
We can define rollup groups via the navigation path
Setup/Financials/Key/Groups
we will be presented with a find key Flexfield segment window, enter the name of you accounting flexfield structure in the structure field and then click on the Find Button. Go to the Rollup groups region and enter you rollup group names and description. Create a Rollup group called ASSETS now so you can assign the parent values we defined in the define segment values form.
Assigning Rollup Groups
Rollup groups are assigned to parent values in the Segment values from Navigaiton
Setup/Financials/Flexfields/Validation/Values
in this form the group field is in the Hierarchy, Qualifiers group, just to the right of the parent checkbox.
Defining Summary Accounts
Now you can create summary accounts. Summary accounts will be described in detail in a later chapter, but an overview is provided here. After following the navigation path
Setup/Accounts/Summary, we enter a name, a template and a description for the summary account template. We must also enter the earliest period for which Oracle General Ledger should generate summarized balances.
Summary accounts are generated based on the defined summary account templates. To setup summary account templates, we define a template option for each segment of the Chart of Accounts options include
D
T
Rollup groups
D- D Means to create a summar account for each segment value of the segment. The system will not allow to setup a summary account template with all D's because doing so would cause each segment to expand to include every possible segment value.
T- T means to create one summar account that summarizes all segment values. T must be a defined parent value with the entire segments possible values as child values. No rollup group must be assinged to T. When using this option,the Detailed Posting Allowed and Detailed Budgeting Allowed parameters are set to NO. You do not need to set up a summary account with Ts in every segment because doing so would create one account that totals the system and this account combination would always have a balance 0.
Rollup Groups- A rollup group is used to create one summary account for each parent values assigned to it. For instance assume you have three companies. five departments, then accounts, and Rollup Group R1 in the account segment with two parent values. A summary account template of D-T-D will create 3*1*10=30 summary accounts. A summary account template of D-T-R1 will create 3*1*2=6 summary accounts.
Maintain Summary Accounts
We do not need to maintain summary accounts If you only add child values to parent values. The new child values will automatically be included when the Maintain Summary Templates program is executed. The maintain summary templates program can be invoked manually; it is also called automatically by the posting program. We may want to run the maintain summary templates program prior to posting if we add a lot of child values for performing reasons. However , if we add parent values to rollup groups and the rollup groups are used in summary accounting templates, you will need to delete the related summary accounts and re create them. Adding or deleting summary accounts will initiate the Add/Delete Summary accounts program automatically.
Defining Parent Segment Values
Parent Segment Values (also called parent values ) are values that reference other segment values typically knows as child segment values(also called child values). You can set up parent values for any segment values together, and they are utilized in reporting and/or assigned to rollup groups. Child values can be defined in ranges or individually.
Using the Chart of Accounts you defined earlier,you are going to add a parent value called ASSETS to include balances from the Cash and Receivables asset accounts you created earlier. You define parent values in the same from you define you segment values. Find your accounting flexfield structure and the account segment. To do this enter accounting flexfield structure and the segment name corresponding to the account segment in the find window, then click on the find button. You will see the values that are valid for the account segment. Go to the values(accounts) region, add a new record, and enter the value ASSETS and a description. Navigate to the Hierarchy, Qualifiers alternative region and check the Parent Checkbox to make this parent value.
Next define child values for the ASSETS parent value. Save first then click on the Define Child Ranges button to enter the child values. Enter child values for the Cash Account and the Receivables account, and in the include column select Child Values Only.
Defining Rollup Groups
Rollup groups are one level higher then parent values. Use rollup groups in summary account templates. Assign parent values to roolup groups. In order to use parent values in summary account templates, we must first assign the parent values to the rollup groups.
We can define rollup groups via the navigation path
Setup/Financials/Key/Groups
we will be presented with a find key Flexfield segment window, enter the name of you accounting flexfield structure in the structure field and then click on the Find Button. Go to the Rollup groups region and enter you rollup group names and description. Create a Rollup group called ASSETS now so you can assign the parent values we defined in the define segment values form.
Assigning Rollup Groups
Rollup groups are assigned to parent values in the Segment values from Navigaiton
Setup/Financials/Flexfields/Validation/Values
in this form the group field is in the Hierarchy, Qualifiers group, just to the right of the parent checkbox.
Defining Summary Accounts
Now you can create summary accounts. Summary accounts will be described in detail in a later chapter, but an overview is provided here. After following the navigation path
Setup/Accounts/Summary, we enter a name, a template and a description for the summary account template. We must also enter the earliest period for which Oracle General Ledger should generate summarized balances.
Summary accounts are generated based on the defined summary account templates. To setup summary account templates, we define a template option for each segment of the Chart of Accounts options include
D
T
Rollup groups
D- D Means to create a summar account for each segment value of the segment. The system will not allow to setup a summary account template with all D's because doing so would cause each segment to expand to include every possible segment value.
T- T means to create one summar account that summarizes all segment values. T must be a defined parent value with the entire segments possible values as child values. No rollup group must be assinged to T. When using this option,the Detailed Posting Allowed and Detailed Budgeting Allowed parameters are set to NO. You do not need to set up a summary account with Ts in every segment because doing so would create one account that totals the system and this account combination would always have a balance 0.
Rollup Groups- A rollup group is used to create one summary account for each parent values assigned to it. For instance assume you have three companies. five departments, then accounts, and Rollup Group R1 in the account segment with two parent values. A summary account template of D-T-D will create 3*1*10=30 summary accounts. A summary account template of D-T-R1 will create 3*1*2=6 summary accounts.
Maintain Summary Accounts
We do not need to maintain summary accounts If you only add child values to parent values. The new child values will automatically be included when the Maintain Summary Templates program is executed. The maintain summary templates program can be invoked manually; it is also called automatically by the posting program. We may want to run the maintain summary templates program prior to posting if we add a lot of child values for performing reasons. However , if we add parent values to rollup groups and the rollup groups are used in summary accounting templates, you will need to delete the related summary accounts and re create them. Adding or deleting summary accounts will initiate the Add/Delete Summary accounts program automatically.
Some Typical Profile Option Modifications
GL Set of Books Name - Points the application user or more commonly, the responsibility to a particular set of books.
OE: Set of Books- Points the responsibility or more commonly the application to a particular set of books for order entry.
Concurrent: Active Request limit- Limits the number of requests that can be run simultaneously.
Concurrent Report Access Level- Can be set to user or responsibility to determine whether to allow users within the same responsibility to share the output files. User means no sharing.
Concurrent: Report Copies-Sets the number of copies that should be printed to the printer. This be set to zero during development so as not to waste paper.
Currency: Negative Format- Allows you to set the default format for negative currency amounts.
Default Currency- Allows you to set the default country to be used through Oracle Applications.
Flexfields:AutoSkip-Allows you to skip to the next segment of the flexfield whenever you enter enough characters to identify a unique value.
MO: Operating Unit- Sets the operating unit to which the user or more commonly the responsibility-points.
Site Name- Identifies the site name for the Oracle Applications Site.
OE: Item Validation Organization- Specifies the inventory organization used to validate order entry.
PO:MFG Organization ID- Specifies the inventory organization used as manufacturing inventory organization in Oracle Purchasing.
HR:Business Group- Specifies the associated business group.
Budgetary Control Group- Specifies the budgetary control group used in budgetary control.
MRC: Reporting Set of Books - Specifies the associated Reporting set of books for MRC responsibilities.
Utilities:SQL Trace- Allows you to generate SQL trace files from Oracle Applications.
OE: Set of Books- Points the responsibility or more commonly the application to a particular set of books for order entry.
Concurrent: Active Request limit- Limits the number of requests that can be run simultaneously.
Concurrent Report Access Level- Can be set to user or responsibility to determine whether to allow users within the same responsibility to share the output files. User means no sharing.
Concurrent: Report Copies-Sets the number of copies that should be printed to the printer. This be set to zero during development so as not to waste paper.
Currency: Negative Format- Allows you to set the default format for negative currency amounts.
Default Currency- Allows you to set the default country to be used through Oracle Applications.
Flexfields:AutoSkip-Allows you to skip to the next segment of the flexfield whenever you enter enough characters to identify a unique value.
MO: Operating Unit- Sets the operating unit to which the user or more commonly the responsibility-points.
Site Name- Identifies the site name for the Oracle Applications Site.
OE: Item Validation Organization- Specifies the inventory organization used to validate order entry.
PO:MFG Organization ID- Specifies the inventory organization used as manufacturing inventory organization in Oracle Purchasing.
HR:Business Group- Specifies the associated business group.
Budgetary Control Group- Specifies the budgetary control group used in budgetary control.
MRC: Reporting Set of Books - Specifies the associated Reporting set of books for MRC responsibilities.
Utilities:SQL Trace- Allows you to generate SQL trace files from Oracle Applications.
Oracle 11i Account Receivabls(AR)Key Reports
AR Application provides more than 100 Reports to assist with accounting , collections, execution, printing documents, listings, tax reporting, and miscellaneous activities.
Accounting Reports- These Reports assist with recording the history of transactions, balancing the AR Subledger internally, and recording entries into the General Ledger.
Accounting Reports in AR
Adjustment Apporval- Use this report to see information about transacitons adjustments.
Adjustment Register- Review approved adjustments with this report. This is one of the reports used to balance the system.
Aging By Account Report- This is variation of the aging reports to show open items in summary or detail by accounting flexfield value. This is one of the reports used to balance the system.
Applied Receipts Register-This report shows all activity of receipt. This is one of the reports used to balance the system.
Automatic Receipt Batch Managment- This report is used to review the status of Automatic Receipt Batches.
Automatic Receipt Awaiting Confirmation-This report lists automatic receipts that have been formatted and have been assigned a payment method with a receipt class with Require confirmaiton.
Bad Debt Provision Report- This report can calculate a bad debt exposure from the percent collectable value in the customer profile class.
Billing and Receipt History- Use this report to see detailed list of transaction for the date range.
Billing History Report- This report shows a summary of transaction in an account.
Commitment Balance Report- This is a summary listing of information about commitments.
Invoice Exception Report- This report shows transaction where open Receivables is equal to NO. These transactions do not appear on an aging report but are on the transaction register.
Invoices Posted to Suspence Report- This is listing of invoices where the revenue account is a suspence account.
Journal Entries Report- Use this report to reconcile the AR subledger to the General Ledger.
Journal With GL Detail Report- Use this report to show journal entries for specific transacitons in AR.
Miscellaneus Transaction Report- List miscellaneous receipts activity with this report.
Receipts Register- This is a listing receipts for a date range.
Receipts Journal Report- This reports lists the details of the receipts that have been included in a journal entry.
Sales Jounal by Customer Report- This report lists all transactions by customer.
Sales Journal by GL Account- This report is similar to the transaction register by GL account. Use this report when you balance the AR aging to the General Ledger.
Transaction Reconciliation Report- This is a report to show GL journal entry lines created from specific AR transactions.
Transaction Register- This register to verify that possible items are included in the sales journal. This is one of the key reports used to balance the system.
Unapplied Receipts Register- This report lists the details of on account and unapplied receipts.
Unposted Items Report- This report to see items not posted to General Ledger for a date range.
Accounting Reports- These Reports assist with recording the history of transactions, balancing the AR Subledger internally, and recording entries into the General Ledger.
Accounting Reports in AR
Adjustment Apporval- Use this report to see information about transacitons adjustments.
Adjustment Register- Review approved adjustments with this report. This is one of the reports used to balance the system.
Aging By Account Report- This is variation of the aging reports to show open items in summary or detail by accounting flexfield value. This is one of the reports used to balance the system.
Applied Receipts Register-This report shows all activity of receipt. This is one of the reports used to balance the system.
Automatic Receipt Batch Managment- This report is used to review the status of Automatic Receipt Batches.
Automatic Receipt Awaiting Confirmation-This report lists automatic receipts that have been formatted and have been assigned a payment method with a receipt class with Require confirmaiton.
Bad Debt Provision Report- This report can calculate a bad debt exposure from the percent collectable value in the customer profile class.
Billing and Receipt History- Use this report to see detailed list of transaction for the date range.
Billing History Report- This report shows a summary of transaction in an account.
Commitment Balance Report- This is a summary listing of information about commitments.
Invoice Exception Report- This report shows transaction where open Receivables is equal to NO. These transactions do not appear on an aging report but are on the transaction register.
Invoices Posted to Suspence Report- This is listing of invoices where the revenue account is a suspence account.
Journal Entries Report- Use this report to reconcile the AR subledger to the General Ledger.
Journal With GL Detail Report- Use this report to show journal entries for specific transacitons in AR.
Miscellaneus Transaction Report- List miscellaneous receipts activity with this report.
Receipts Register- This is a listing receipts for a date range.
Receipts Journal Report- This reports lists the details of the receipts that have been included in a journal entry.
Sales Jounal by Customer Report- This report lists all transactions by customer.
Sales Journal by GL Account- This report is similar to the transaction register by GL account. Use this report when you balance the AR aging to the General Ledger.
Transaction Reconciliation Report- This is a report to show GL journal entry lines created from specific AR transactions.
Transaction Register- This register to verify that possible items are included in the sales journal. This is one of the key reports used to balance the system.
Unapplied Receipts Register- This report lists the details of on account and unapplied receipts.
Unposted Items Report- This report to see items not posted to General Ledger for a date range.
Oracle Applications 11i Shortcut Keys
Shortcut Keys
F4- Exit
F5- Clear Field
F6- Clear Record
F7-Clear Block
F8-Clear Form
F11- Query Enter
F12- Count Query
Ctrl + S - Save
Ctrl + L - List of Values
Ctrl + F11- Query Run
Ctrl + E - Edit
Ctrl + Up - Delete Record
Ctrl + Down Insert Record
Ctrl + P - Print
Ctrl + U - Update Record
Ctrl+B- Block Menu
Ctrl+K - Display List of Keys
Shift+F5- Duplicate Field
Shift+F6- Duplicate Record
Shift+F8 - Next set of Records.
Shift+Page - Down Next Block
Shift+Tab- Previous Field
Shift+Page Up - Previous Block
Shift+Ctrl+E - Display Error
Page Down Scroll Down - Its Works same as Shift +F8
Page Up - Scroll Up
Oracle Apps Interview Questions
Q) What is the difference between Financial and Payables Options in Account Payables?
Ans) Financial Option works for purchasing, AP and FA modules, where as payable option works for payables only.
Q) What is Pay on receipt?
Ans)This is a feature in AP to PO Cycle. We have to enable this option to generate invoices automatically when you receive the goods.
Q) What is Hold ? Explain types of Holds?
Ans) Hold is to prevent invoices from payment.
There are 3 types of Holds
1) Invoice Hod- You can manually apply one or more holds on invoice name by using the invoice hold tab on invoice workbench.
2) Schedule Payment Hold - You can hold payment on invoices by placing holds on one or more schedule payment.
3) Supplier Hold - In supplier site you can put holds
a) Hold all invoices b) Hold unmatched invoices c) Invoice amount limit- If invoice amount exceeds the limit specified.
Q)What is the difference between debit memo and Credit memo in Oracle Payables.
Ans) In Oracle Payables the functionality of the debit memo and credit memo is same. Since both are reduces the supplier balances.
Only difference is debit memo generates customer and sends to the supplier where as credit memo sends supplier to customer.
Q) What is the difference between a direct loan and extended repayment schedule loan(ERS)?
Ans) A direct loan is direct payment to customer handled through a check being sent from account payable. The resulting bills from this loan create new invoice in Account Receivable(AR).
Eg- Customer A requests a $10000 loan from you. You create the direct loan in Oracle Loans and send the customer checks for $10000 through Account Payable. The instalments to pay the loan will be created as invoices in Account receivables when they are due.
Extended Repayment Schedule(ERS) Loan
An ERS loan is covering an existing invoice in Accounts Receivable to a loan. No funding is required for this type of loan.
Eg- Customer B has an outstanding invoice in AR for $5000. They inform you that they will have trouble making payment on this invoice so you agree to convert it to a loan and charge them interest over a period of time. When creating loan in Oracle Loans, you select the Extended Repayment Schedule type and this will allow you to select any invoice from AR.
Once the loan is created, the adjustment API will adjust the original invoice in AR down to $O. The loan will then be billed out in installments according to your loan setup. So the original $5000 will be billed out in several invoices overtime in AR and be charged interest.
Ans) Financial Option works for purchasing, AP and FA modules, where as payable option works for payables only.
Q) What is Pay on receipt?
Ans)This is a feature in AP to PO Cycle. We have to enable this option to generate invoices automatically when you receive the goods.
Q) What is Hold ? Explain types of Holds?
Ans) Hold is to prevent invoices from payment.
There are 3 types of Holds
1) Invoice Hod- You can manually apply one or more holds on invoice name by using the invoice hold tab on invoice workbench.
2) Schedule Payment Hold - You can hold payment on invoices by placing holds on one or more schedule payment.
3) Supplier Hold - In supplier site you can put holds
a) Hold all invoices b) Hold unmatched invoices c) Invoice amount limit- If invoice amount exceeds the limit specified.
Q)What is the difference between debit memo and Credit memo in Oracle Payables.
Ans) In Oracle Payables the functionality of the debit memo and credit memo is same. Since both are reduces the supplier balances.
Only difference is debit memo generates customer and sends to the supplier where as credit memo sends supplier to customer.
Q) What is the difference between a direct loan and extended repayment schedule loan(ERS)?
Ans) A direct loan is direct payment to customer handled through a check being sent from account payable. The resulting bills from this loan create new invoice in Account Receivable(AR).
Eg- Customer A requests a $10000 loan from you. You create the direct loan in Oracle Loans and send the customer checks for $10000 through Account Payable. The instalments to pay the loan will be created as invoices in Account receivables when they are due.
Extended Repayment Schedule(ERS) Loan
An ERS loan is covering an existing invoice in Accounts Receivable to a loan. No funding is required for this type of loan.
Eg- Customer B has an outstanding invoice in AR for $5000. They inform you that they will have trouble making payment on this invoice so you agree to convert it to a loan and charge them interest over a period of time. When creating loan in Oracle Loans, you select the Extended Repayment Schedule type and this will allow you to select any invoice from AR.
Once the loan is created, the adjustment API will adjust the original invoice in AR down to $O. The loan will then be billed out in installments according to your loan setup. So the original $5000 will be billed out in several invoices overtime in AR and be charged interest.
Multiple Currencies
Revaluing Foreign Currency Balances
Asset and Liability accounts that are entered in foreign currencies must be revalued every period in accordance with FAS52(Financial Accounting Standards). The Revaluation program adjusts the value of the balance sheet accounts based on current period exchange rates. It then generates revalulaiton journals with adjustments to the defined unrelized gain/loss account. The revaluaiton program genrates adjustements in the Functional Currency. If you have a Reporting Set of Books you must run revalution once for each Primary and Reporting Set of Books. The Revaluation generates a revaluation batch containing a separate journal for each foreign currency. The Revaluation batch automatically has its reversal period set to the next accounting period. When you run revaluation for the next accounting period, you must reverse and post the last accounting periods revaluation batch first.
Navgation - Currency -> Revaluation
Translating Foreign Currency Balances The Translation process translates actual and budget account balances to another currency in accordance FAS52. The translation program uses three different exchange rates: period-average, period end, and historical. The translation program translates asset and liability accounts using the period end exchange rate, ownership/stockholder equity accounts using the historical exchange rate, and revenue and expenses accounts using period average exchange rate. The period average exchange rate is the average rate of all daily rates across the entire accounting period.
The profile option GL: Owners equity transaction rule effects how ownership stockholders equity account balances are translated. If the profile option is set to PTD, the net activity accounts of the accounting period are translated, then added to the corresponding prior period balances. If the profile set to YTD the balances, not the activities are translated and the translated amounts are the YTD Balances. There is no need to add the balances to previous balances.
Navigation
Currency-> Translation
Multiple Reporting Currencies
Multiple Reporting Currencies allows you to maintain accounting transactions in more than one functional currency. MRC is set up by creating one or more Reporting Set of Books.
MRC need if Your company is located a member state of EMU and would like to report financial data, including transaction level data, in both your functional currency and the Euro.
You must regularly report financial data including transaction level data in more than one currency because your company is multinational.
MRC Works for following modules
Assets, CashManagment, Cost Management , General Ledger, Payables, Projects, Purchasing, Receivables.
MRC works differently depdning on whether you enter the transaction inn Oracle Subledger or Oracle GL. When you enter transaction in subledgers the accounting transactions are translated into the Reporting set of books as you enter the transaction. When you transfer to Oracle GL, you must transfer to both the primary set of books and the reporting set of books you should post the transferred subledgers accounting transactions to the primary set of books as well as to all reporting set of books.
When you enter transactions in GL, the journal entries entered in the Primary Set of Books are not translated immediately into any reporting Set of Books, when the Journal entries are posted In the Primary Set of Books it will transferred to reporting Set of Books. In the reporting Set of Books you can post, revalue , translate and consolidate.
Asset and Liability accounts that are entered in foreign currencies must be revalued every period in accordance with FAS52(Financial Accounting Standards). The Revaluation program adjusts the value of the balance sheet accounts based on current period exchange rates. It then generates revalulaiton journals with adjustments to the defined unrelized gain/loss account. The revaluaiton program genrates adjustements in the Functional Currency. If you have a Reporting Set of Books you must run revalution once for each Primary and Reporting Set of Books. The Revaluation generates a revaluation batch containing a separate journal for each foreign currency. The Revaluation batch automatically has its reversal period set to the next accounting period. When you run revaluation for the next accounting period, you must reverse and post the last accounting periods revaluation batch first.
Navgation - Currency -> Revaluation
Translating Foreign Currency Balances The Translation process translates actual and budget account balances to another currency in accordance FAS52. The translation program uses three different exchange rates: period-average, period end, and historical. The translation program translates asset and liability accounts using the period end exchange rate, ownership/stockholder equity accounts using the historical exchange rate, and revenue and expenses accounts using period average exchange rate. The period average exchange rate is the average rate of all daily rates across the entire accounting period.
The profile option GL: Owners equity transaction rule effects how ownership stockholders equity account balances are translated. If the profile option is set to PTD, the net activity accounts of the accounting period are translated, then added to the corresponding prior period balances. If the profile set to YTD the balances, not the activities are translated and the translated amounts are the YTD Balances. There is no need to add the balances to previous balances.
Navigation
Currency-> Translation
Multiple Reporting Currencies
Multiple Reporting Currencies allows you to maintain accounting transactions in more than one functional currency. MRC is set up by creating one or more Reporting Set of Books.
MRC need if Your company is located a member state of EMU and would like to report financial data, including transaction level data, in both your functional currency and the Euro.
You must regularly report financial data including transaction level data in more than one currency because your company is multinational.
MRC Works for following modules
Assets, CashManagment, Cost Management , General Ledger, Payables, Projects, Purchasing, Receivables.
MRC works differently depdning on whether you enter the transaction inn Oracle Subledger or Oracle GL. When you enter transaction in subledgers the accounting transactions are translated into the Reporting set of books as you enter the transaction. When you transfer to Oracle GL, you must transfer to both the primary set of books and the reporting set of books you should post the transferred subledgers accounting transactions to the primary set of books as well as to all reporting set of books.
When you enter transactions in GL, the journal entries entered in the Primary Set of Books are not translated immediately into any reporting Set of Books, when the Journal entries are posted In the Primary Set of Books it will transferred to reporting Set of Books. In the reporting Set of Books you can post, revalue , translate and consolidate.
Oracle A.I.M. Methodology
Oracle A.I.M Methodology encompasses a project management methodology with documentation templates that support the life cycle of an implementation. The life cycle methodology and documentation templates allows A.I.M to be very useful tool for managing implementation projects sucessfully. This is a depiction of A.I.M methodology life cycle. Applicaiton Implementation method is a proven approach for all the activities required to implement oracle applicaitons. There are eleven processes of implementation.
1 )Buisness process archtechture-BP This phase outlines - Existing Business Practices,Catalog change practices,Future practices
BP.010 Define Business and Process Strategy
B P.020 Catalog and Analyze Potential Changes
BP.030 Determine Data Gathering Requirements
BP.040 Develop Current Process Model
BP.050 Review Leading Practices
BP.060 Develop High-Level Process Vision
BP.070 Develop High-Level Process Design
BP.080 Develop Future Process Model
BP.090 Document Business Procedure
2) Business Requirement Definition [RD] - This phase explains about the initial baseline questionnarie and gathering of requirements.
RD010 Identify current financial and operating structure
RD.020 Conduct Current Business Baseline
RD.030 Establish Process and Mapping Summary
RD.040 Gather Business Volumes and Metrics
RD.050 Gather Business Requirements
RD.060 Determine Audit and Control Requirements
RD.070 Identify Business Availability Requirements
RD.080 Identify Reporting and Information Access Requirements
3). Business Requirement Mapping [BR] - In this phase the requirements of business are matched with the standard functionality of the oracle applications. BR.010 Analyze High-Level Gaps
BR.020 Prepare mapping environment
BR.030 Map Business requirements
BR.040 Map Business Data
BR.050 Conduct Integration Fit Analysis
BR.060 Create Information Model
BR.070 Create Reporting Fit Analysis
BR.080 Test Business Solutions
BR.090 Confirm Integrated Business Solutions
BR.100 Define Applications Setup
BR.110 Define security Profiles
4) Application and Technical Architecture [TA] - This outlines the infrastructure requirements to implement oracle applications.
TA.010 Define Architecture Requirements and Strategy
TA.020 Identify Current Technical Architecture
TA.030 Develop Preliminary Conceptual Architecture
TA.040 Define Application Architecture
TA.050 Define System Availability Strategy
TA.060 Define Reporting and Information Access Strategy
TA.070 Revise Conceptual Architecture
TA.080 Define Application Security Architecture
TA.090 Define Application and Database Server Architecture
TA.100 Define and Propose Architecture Subsystems
TA.110 Define System Capacity Plan
TA.120 Define Platform and Network Architecture
TA.130 Define Application Deployment Plan
TA.140 Assess Performance Risks
TA.150 Define System Management Procedures
5) Build and Module Design [MD] - This phase emphasizes the development of new functionality (customization) required by the client. It mainly details how to design the required forms, database and reports.
MD.010 Define Application Extension Strategy
MD.020 Define and estimate application extensions
MD.030 Define design standards
MD.040 Define Build Standards
MD.050 Create Application extensions functional design
MD.060 Design Database extensions
MD.070 Create Application extensions technical design
MD.080 Review functional and Technical designs
MD.090 Prepare Development environment
MD.100 Create Database extensions
MD.110 Create Application extension modules
MD.120 Create Installation routines
6)Data Conversion [CV] - Data Conversion is the process of converting or transferring the data from legacy system to oracle applications. Ex. Transferring customer records from the legacy to the Customer Master.
CV.010 Define data conversion requirements and strategy
CV.020 Define Conversion standards
CV.030 Prepare conversion environment
CV.040 Perform conversion data mapping
CV.050 Define manual conversion procedures
CV.060 Design conversion programs
CV.070 Prepare conversion test plans
CV.080 Develop conversion programs
CV.090 Perform conversion unit tests
CV.100 Perform conversion business objects
CV.110 Perform conversion validation tests
CV.120 Install conversion programs
CV.130 Convert and verify data
7. Documentation [DO] - Documentation prepared per module that includes user guides and implementation manuals.
DO.010 Define documentation requirements and strategy
DO.020 Define Documentation standards and procedures
DO.030 Prepare glossary
DO.040 Prepare documentation environment
DO.050 Produce documentation prototypes and templates
DO.060 Publish user reference manual
DO.070 Publish user guide
DO.080 Publish technical reference manual
DO.090 Publish system management guide
8). Business System Testing [TE] - A process of validating the setup’s and functionality by QA(functional consultant) to certify status.
TE.010 Define testing requirements and strategy
TE.020 Develop unit test script
TE.030 Develop link test script
TE.040 Develop system test script
TE.050 Develop systems integration test script
TE.060 Prepare testing environments
TE.070 Perform unit test TE.080 Perform link test
TE.090 perform installation test
TE.100 Prepare key users for testing
TE.110 Perform system test
TE.120 Perform systems integration test
TE.130 Perform Acceptance test
9). Performance Testing [PT] - Performance testing is the evaluation of transactions saving time, transaction retrieval times, workflow background process, database performance, etc PT.010 - Define Performance Testing Strategy
PT.020 - Identify Performance Test Scenarios
PT.030 - Identify Performance Test Transaction
PT.040 - Create Performance Test Scripts
PT.050 - Design Performance Test Transaction Programs
PT.060 - Design Performance Test Data
PT.070 - Design Test Database Load Programs
PT.080 - Create Performance Test TransactionPrograms
PT.090 - Create Test Database Load Programs
PT.100 - Construct Performance Test Database
PT.110 - Prepare Performance Test Environment
PT.120 - Execute Performance Test
10). Adoption and Learning [AP] - This phase explains the removal of the legacy system and oracle application roll out enterprise wide.
AP.010 - Define Executive Project Strategy
AP.020 - Conduct Initial Project Team Orientation
AP.030 - Develop Project Team Learning Plan
AP.040 - Prepare Project Team Learning Environment
AP.050 - Conduct Project Team Learning Events
AP.060 - Develop Business Unit Managers’Readiness Plan
AP.070 - Develop Project Readiness Roadmap
AP.080 - Develop and Execute CommunicationCampaign
AP.090 - Develop Managers’ Readiness Plan
AP.100 - Identify Business Process Impact onOrganization
AP.110 - Align Human Performance SupportSystems
AP.120 - Align Information Technology Groups
AP.130 - Conduct User Learning Needs Analysis
AP.140 - Develop User Learning Plan
AP.150 - Develop User Learningware
AP.160 - Prepare User Learning Environment
AP.170 - Conduct User Learning Events
AP.180 - Conduct Effectiveness Assessment
11). Production Migration [PM] - The process of “decommissioning” of legacy system and the usage(adoption) of oracle application system.
PM.010 - Define Transition Strategy
PM.020 - Design Production Support Infrastructure
PM.030 - Develop Transition and Contingency Plan
PM.040 - Prepare Production Environment
PM.050 - Set Up Applications
PM.060 - Implement Production Support Infrastructure
PM.070 - Verify Production Readiness
PM.080 - Begin Production
PM.090 - Measure System Performance
PM.100 - Maintain System
PM.110 - Refine Production System
PM.120 - Decommission Former Systems
PM.130 - Propose Future Business Direction
PM.140 - Propose Future Technical Direction
1 )Buisness process archtechture-BP This phase outlines - Existing Business Practices,Catalog change practices,Future practices
BP.010 Define Business and Process Strategy
B P.020 Catalog and Analyze Potential Changes
BP.030 Determine Data Gathering Requirements
BP.040 Develop Current Process Model
BP.050 Review Leading Practices
BP.060 Develop High-Level Process Vision
BP.070 Develop High-Level Process Design
BP.080 Develop Future Process Model
BP.090 Document Business Procedure
2) Business Requirement Definition [RD] - This phase explains about the initial baseline questionnarie and gathering of requirements.
RD010 Identify current financial and operating structure
RD.020 Conduct Current Business Baseline
RD.030 Establish Process and Mapping Summary
RD.040 Gather Business Volumes and Metrics
RD.050 Gather Business Requirements
RD.060 Determine Audit and Control Requirements
RD.070 Identify Business Availability Requirements
RD.080 Identify Reporting and Information Access Requirements
3). Business Requirement Mapping [BR] - In this phase the requirements of business are matched with the standard functionality of the oracle applications. BR.010 Analyze High-Level Gaps
BR.020 Prepare mapping environment
BR.030 Map Business requirements
BR.040 Map Business Data
BR.050 Conduct Integration Fit Analysis
BR.060 Create Information Model
BR.070 Create Reporting Fit Analysis
BR.080 Test Business Solutions
BR.090 Confirm Integrated Business Solutions
BR.100 Define Applications Setup
BR.110 Define security Profiles
4) Application and Technical Architecture [TA] - This outlines the infrastructure requirements to implement oracle applications.
TA.010 Define Architecture Requirements and Strategy
TA.020 Identify Current Technical Architecture
TA.030 Develop Preliminary Conceptual Architecture
TA.040 Define Application Architecture
TA.050 Define System Availability Strategy
TA.060 Define Reporting and Information Access Strategy
TA.070 Revise Conceptual Architecture
TA.080 Define Application Security Architecture
TA.090 Define Application and Database Server Architecture
TA.100 Define and Propose Architecture Subsystems
TA.110 Define System Capacity Plan
TA.120 Define Platform and Network Architecture
TA.130 Define Application Deployment Plan
TA.140 Assess Performance Risks
TA.150 Define System Management Procedures
5) Build and Module Design [MD] - This phase emphasizes the development of new functionality (customization) required by the client. It mainly details how to design the required forms, database and reports.
MD.010 Define Application Extension Strategy
MD.020 Define and estimate application extensions
MD.030 Define design standards
MD.040 Define Build Standards
MD.050 Create Application extensions functional design
MD.060 Design Database extensions
MD.070 Create Application extensions technical design
MD.080 Review functional and Technical designs
MD.090 Prepare Development environment
MD.100 Create Database extensions
MD.110 Create Application extension modules
MD.120 Create Installation routines
6)Data Conversion [CV] - Data Conversion is the process of converting or transferring the data from legacy system to oracle applications. Ex. Transferring customer records from the legacy to the Customer Master.
CV.010 Define data conversion requirements and strategy
CV.020 Define Conversion standards
CV.030 Prepare conversion environment
CV.040 Perform conversion data mapping
CV.050 Define manual conversion procedures
CV.060 Design conversion programs
CV.070 Prepare conversion test plans
CV.080 Develop conversion programs
CV.090 Perform conversion unit tests
CV.100 Perform conversion business objects
CV.110 Perform conversion validation tests
CV.120 Install conversion programs
CV.130 Convert and verify data
7. Documentation [DO] - Documentation prepared per module that includes user guides and implementation manuals.
DO.010 Define documentation requirements and strategy
DO.020 Define Documentation standards and procedures
DO.030 Prepare glossary
DO.040 Prepare documentation environment
DO.050 Produce documentation prototypes and templates
DO.060 Publish user reference manual
DO.070 Publish user guide
DO.080 Publish technical reference manual
DO.090 Publish system management guide
8). Business System Testing [TE] - A process of validating the setup’s and functionality by QA(functional consultant) to certify status.
TE.010 Define testing requirements and strategy
TE.020 Develop unit test script
TE.030 Develop link test script
TE.040 Develop system test script
TE.050 Develop systems integration test script
TE.060 Prepare testing environments
TE.070 Perform unit test TE.080 Perform link test
TE.090 perform installation test
TE.100 Prepare key users for testing
TE.110 Perform system test
TE.120 Perform systems integration test
TE.130 Perform Acceptance test
9). Performance Testing [PT] - Performance testing is the evaluation of transactions saving time, transaction retrieval times, workflow background process, database performance, etc PT.010 - Define Performance Testing Strategy
PT.020 - Identify Performance Test Scenarios
PT.030 - Identify Performance Test Transaction
PT.040 - Create Performance Test Scripts
PT.050 - Design Performance Test Transaction Programs
PT.060 - Design Performance Test Data
PT.070 - Design Test Database Load Programs
PT.080 - Create Performance Test TransactionPrograms
PT.090 - Create Test Database Load Programs
PT.100 - Construct Performance Test Database
PT.110 - Prepare Performance Test Environment
PT.120 - Execute Performance Test
10). Adoption and Learning [AP] - This phase explains the removal of the legacy system and oracle application roll out enterprise wide.
AP.010 - Define Executive Project Strategy
AP.020 - Conduct Initial Project Team Orientation
AP.030 - Develop Project Team Learning Plan
AP.040 - Prepare Project Team Learning Environment
AP.050 - Conduct Project Team Learning Events
AP.060 - Develop Business Unit Managers’Readiness Plan
AP.070 - Develop Project Readiness Roadmap
AP.080 - Develop and Execute CommunicationCampaign
AP.090 - Develop Managers’ Readiness Plan
AP.100 - Identify Business Process Impact onOrganization
AP.110 - Align Human Performance SupportSystems
AP.120 - Align Information Technology Groups
AP.130 - Conduct User Learning Needs Analysis
AP.140 - Develop User Learning Plan
AP.150 - Develop User Learningware
AP.160 - Prepare User Learning Environment
AP.170 - Conduct User Learning Events
AP.180 - Conduct Effectiveness Assessment
11). Production Migration [PM] - The process of “decommissioning” of legacy system and the usage(adoption) of oracle application system.
PM.010 - Define Transition Strategy
PM.020 - Design Production Support Infrastructure
PM.030 - Develop Transition and Contingency Plan
PM.040 - Prepare Production Environment
PM.050 - Set Up Applications
PM.060 - Implement Production Support Infrastructure
PM.070 - Verify Production Readiness
PM.080 - Begin Production
PM.090 - Measure System Performance
PM.100 - Maintain System
PM.110 - Refine Production System
PM.120 - Decommission Former Systems
PM.130 - Propose Future Business Direction
PM.140 - Propose Future Technical Direction
Oracle Payments
Payments can be made to suppliers by any of the following
Automated Checks
Quick Check
Manual Payments
Wire Transfers
EDI
Electronic Funds Transfers(EFT)
Automated Checks- Automatic checks are computer generated to pay a supplier for one or more invoices. Automatic checks use the payment terms and due date to select invoices for a payment batch. Payment batch Steps
1) Invoice Selection
2) Payment Build
3) Modification
4)Format and Print
5) Confirmation
1) Selection for Payment - The following are steps to follow for selecting for payment.
Selection criteria in the payment batches window. Payable selects all approved invoices that match your invoice selection criteria.
Enter Unique batch name.
Enter or change the default bank account.
Select a payment document.
Enter or change the payment date.
Optionally choose a paygroup
Verify the pay-through date.
Payables selects all invoices due for payment based on the proceding entered criteria. Payables selects invoices with a discount or due date on or before the pay through date.
2) Payment Build - When Payables builds payments it determines which invoices will be paid with each payment document. Payables automatically builds payments when you initiate invoice selection. Payables also automatically builds payments after you modify a payment batch.
If you want to review and modify the invoices selected in the payment batch before you format payments.
3) Modifying The Selection- After selecting invoices and building payments, you have the opportunity to review and modify the payment batch. You can prevent payment of a particular invoice, modify the payment amount of an invoice, or add an invoice that payables did not originally select. After you complete your modifications, you can review your changes on a new Preliminary Payment Register.
4) Formatting Payments- When Payables formats payments, it creates an output file that is used to print the checks, or if you are making electronic payments without the EDI Gateway, you can deliver the output file to your bank for processing. The output file is stored in the Payables output directory.
5) Confirming Payments- Confirming is the final step in processing a payment batch. This step updates the payment history of invoices paid and associates payment document number with the invoices and invoice payments.
Resetting a Payment Batch
Troubleshooting begins with identifying the current status status of your payment batch so that you can determine the best course of action. You can review the payment batch status in the payment batch window.
Most payment batch problems are due to a printer malfunction during check printing, causing skipped or spoiled checks. If you have printer problem during check printing you still confirm the results using the Confirm payment batch window.
To record a partial payment batch and restart check printing record the checks as either setup, skipped or printed and then choose restart payment batch.
To record a partial payment batch and cancel the remainder, record the checks as either setup,skipped, spoiled or printed and then choose cancel remainder.
Automated Checks
Quick Check
Manual Payments
Wire Transfers
EDI
Electronic Funds Transfers(EFT)
Automated Checks- Automatic checks are computer generated to pay a supplier for one or more invoices. Automatic checks use the payment terms and due date to select invoices for a payment batch. Payment batch Steps
1) Invoice Selection
2) Payment Build
3) Modification
4)Format and Print
5) Confirmation
1) Selection for Payment - The following are steps to follow for selecting for payment.
Selection criteria in the payment batches window. Payable selects all approved invoices that match your invoice selection criteria.
Enter Unique batch name.
Enter or change the default bank account.
Select a payment document.
Enter or change the payment date.
Optionally choose a paygroup
Verify the pay-through date.
Payables selects all invoices due for payment based on the proceding entered criteria. Payables selects invoices with a discount or due date on or before the pay through date.
2) Payment Build - When Payables builds payments it determines which invoices will be paid with each payment document. Payables automatically builds payments when you initiate invoice selection. Payables also automatically builds payments after you modify a payment batch.
If you want to review and modify the invoices selected in the payment batch before you format payments.
3) Modifying The Selection- After selecting invoices and building payments, you have the opportunity to review and modify the payment batch. You can prevent payment of a particular invoice, modify the payment amount of an invoice, or add an invoice that payables did not originally select. After you complete your modifications, you can review your changes on a new Preliminary Payment Register.
4) Formatting Payments- When Payables formats payments, it creates an output file that is used to print the checks, or if you are making electronic payments without the EDI Gateway, you can deliver the output file to your bank for processing. The output file is stored in the Payables output directory.
5) Confirming Payments- Confirming is the final step in processing a payment batch. This step updates the payment history of invoices paid and associates payment document number with the invoices and invoice payments.
Resetting a Payment Batch
Troubleshooting begins with identifying the current status status of your payment batch so that you can determine the best course of action. You can review the payment batch status in the payment batch window.
Most payment batch problems are due to a printer malfunction during check printing, causing skipped or spoiled checks. If you have printer problem during check printing you still confirm the results using the Confirm payment batch window.
To record a partial payment batch and restart check printing record the checks as either setup, skipped or printed and then choose restart payment batch.
To record a partial payment batch and cancel the remainder, record the checks as either setup,skipped, spoiled or printed and then choose cancel remainder.
ORACLE FUSION MIDDLEWARE
JDeveloper
Oracle JDeveloper is an integrated development environment (IDE) for building service oriented applications using the latest industry standards for JAVA, XML, Web Services and SQL.
Oracle J Developer supports the complete development life cycle with integrated features for modeling, coding, debugging, testing, profiling, tuning and deploying applications.JDeveloper visual and declarative development approach and innovative Oracle Application Development Framework (Oracle ADF) work together to simplify application development and reduce coding tasks, offering unparalleled productivity and a choice of technology stacks.
Although JDeveloper is mainly a Java Development tool it offers extensive support for development in related languages and environments as well. In addition to the Java capabilities ,JDeveloper enables XML based application development with features such as the XML Schema Modeler, XML code insight and visual editing, and XSLT debugging. Oracle JDeveloper also provides a full development and modeling environment for building database objects and stores procedures.
Applications developed with JDeveloper work with any data source and can be deployed on any J2EE compatible application server.
Oracle JDeveloper a 100% Java based tool is a cross platform IDE that runs on windows Linux, MAC and various based systems letting developers choose their preferred development platform.
Oracle JDeveloper is an integrated development environment (IDE) for building service oriented applications using the latest industry standards for JAVA, XML, Web Services and SQL.
Oracle J Developer supports the complete development life cycle with integrated features for modeling, coding, debugging, testing, profiling, tuning and deploying applications.JDeveloper visual and declarative development approach and innovative Oracle Application Development Framework (Oracle ADF) work together to simplify application development and reduce coding tasks, offering unparalleled productivity and a choice of technology stacks.
Although JDeveloper is mainly a Java Development tool it offers extensive support for development in related languages and environments as well. In addition to the Java capabilities ,JDeveloper enables XML based application development with features such as the XML Schema Modeler, XML code insight and visual editing, and XSLT debugging. Oracle JDeveloper also provides a full development and modeling environment for building database objects and stores procedures.
Applications developed with JDeveloper work with any data source and can be deployed on any J2EE compatible application server.
Oracle JDeveloper a 100% Java based tool is a cross platform IDE that runs on windows Linux, MAC and various based systems letting developers choose their preferred development platform.
Invoices
Before payments can be made to suppliers, the suppliers invoice must be entered. Invoices can be manually entered or entered through Payables Open Interface. If Invoices are entered manually they can be entered individually or as part of batch.
You can use batches in the following ways:
You can enter invoice defaults at the bath level that override both system and supplier site defaults for all invoices in the batch.
You can maximize accuracy by tracking variances between the control invoice count and total and the actual invoice count and total resulting from the invoices entered in your batch.
You can easily locate a batch online and review the name of the person who created the batch and the date it was created.
Payables supports eight different types of invoices.
Standard- This is typical invoice from supplier.
Credit Memo- This invoice represents a credit for goods or services.
Debit Memo- This is used to notify a suuplier of a credit you recorded.
Expense Report- This is an internally generated invoice to record business related expesnse incurred by employee.
PO default- When you match the invoice to specific PO Number, information is defaulted from the PO.
Quickmatch- This is used when you want to automatically match all PO Shipment lines to an invoice.
Mixed- This invoice type can be combination of matched to a PO or another invoice.
Prepayment- This invoice is used for advace payments. This can be entered for suppliers or employees.
You can use batches in the following ways:
You can enter invoice defaults at the bath level that override both system and supplier site defaults for all invoices in the batch.
You can maximize accuracy by tracking variances between the control invoice count and total and the actual invoice count and total resulting from the invoices entered in your batch.
You can easily locate a batch online and review the name of the person who created the batch and the date it was created.
Payables supports eight different types of invoices.
Standard- This is typical invoice from supplier.
Credit Memo- This invoice represents a credit for goods or services.
Debit Memo- This is used to notify a suuplier of a credit you recorded.
Expense Report- This is an internally generated invoice to record business related expesnse incurred by employee.
PO default- When you match the invoice to specific PO Number, information is defaulted from the PO.
Quickmatch- This is used when you want to automatically match all PO Shipment lines to an invoice.
Mixed- This invoice type can be combination of matched to a PO or another invoice.
Prepayment- This invoice is used for advace payments. This can be entered for suppliers or employees.
Encumbrance Types
Encumbrance is funds reserving against budget. When budgetary control is enabled in the set of books, GL automatically creates encumbrance entries for purchasing and payables.
Encubrances can also be created in GL by manual entry of Journals, MassAllocation, or jounal import. If you do not want to use automatic encumbrances, Budgetary Control need not be enabled in a set of books unless Budgetary controls are defined and implemented.
Encumbrances Types
GL has two predefined encumbrance types: Commitment and Obligation. The former implies that the funds have been reserved or committed for the transaction -for example a requisition. The later implies that a liability has been incurred and budgeted funds are permanently reduced ( for example a purchase).
Encubrances can also be created in GL by manual entry of Journals, MassAllocation, or jounal import. If you do not want to use automatic encumbrances, Budgetary Control need not be enabled in a set of books unless Budgetary controls are defined and implemented.
Encumbrances Types
GL has two predefined encumbrance types: Commitment and Obligation. The former implies that the funds have been reserved or committed for the transaction -for example a requisition. The later implies that a liability has been incurred and budgeted funds are permanently reduced ( for example a purchase).
Currency Processing
Transactions can be entered in either the functional currency(from a set of books) or in a foreign currency. GL automatically converts the amounts in foreign currency journals to functional currency equivalents using daily exchange rates. GL also saves maintains both of the amounts for all transactions.
GL provides three standard reports showing foreign currency exchange rates:
Daily Conversion Rates Listing. Lists daily rates for specific currency and accounting period.
Historical Rates Listing. Lists defined historical transaction rates and amounts.
Periodic Rates Listing. Lists defined exchange rates for any accounting period, including the period average and period end translation rates and revaluation rates.
GL provides three standard reports showing foreign currency exchange rates:
Daily Conversion Rates Listing. Lists daily rates for specific currency and accounting period.
Historical Rates Listing. Lists defined historical transaction rates and amounts.
Periodic Rates Listing. Lists defined exchange rates for any accounting period, including the period average and period end translation rates and revaluation rates.
Recurring Journals
With the Recurring Journal entries function of GL, Journal entries can be created using fixed amounts and or accounts. Multiple journals can be created with the same or similar information.
The following types of recurring journals can be created in GL:
Skelton Journals : Here you enter accounts only. This creates journals without amounts, which are entered using the Enter Journals window.
Standard Journals: Here the amounts and accounts are entered as constants, and journals are created with same account and amount informaiton. Use the enter Journals window to modify specific journals.
Formula Journals: Here the amounts vary based on the formula defined. Each generation uses the specified account balances to calculate the journal line amounts. Use the Enter Journlas window to modify specific journals.
The following types of recurring journals can be created in GL:
Skelton Journals : Here you enter accounts only. This creates journals without amounts, which are entered using the Enter Journals window.
Standard Journals: Here the amounts and accounts are entered as constants, and journals are created with same account and amount informaiton. Use the enter Journals window to modify specific journals.
Formula Journals: Here the amounts vary based on the formula defined. Each generation uses the specified account balances to calculate the journal line amounts. Use the Enter Journlas window to modify specific journals.
bank_account_id in Release 12i (CE_BANK_ACCOUNT_USE_ID)
In 11i the field 'bank_account_id' acts as a relation key between the AP_CHECKS_ALL and AP_BANK_ACCOUNTS_ALL tables.
In 12i the same field is no longer is used in AP_CHECKS_ALL table.
In 12i where 'CE_BANK_ACCOUNT_USE_ID is acts as relation between 'CE_BANK_ACCT_USES_ALL' and 'AP_CHECKS_ALL'
In 12i the same field is no longer is used in AP_CHECKS_ALL table.
In 12i where 'CE_BANK_ACCOUNT_USE_ID is acts as relation between 'CE_BANK_ACCT_USES_ALL' and 'AP_CHECKS_ALL'
Highlights of Release 12i
A Single responsibility to access and transact on multiple organizations.
A Single Ledger to manage multiple currencies.
Ledger Sets to Manage accounting process across ledger.
Centralized trading partners i.e Supplier , Banks , First Party Legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.
A Single Ledger to manage multiple currencies.
Ledger Sets to Manage accounting process across ledger.
Centralized trading partners i.e Supplier , Banks , First Party Legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.
Open Periods in the AP Calendar
Payables periods are different from General Ledger periods. For example, you can close the March period in AP before you close the March period in General Ledger.
Payables provides for invoice entry,payment entry, and payment voiding in open accounting periods. You can enter invoices in Future accounting periods, but you cannot post any invoices in Future accounting periods until the status is changed to open. The period statues available in payables are Never Opened , Open , Closed and Permanently Closed.
When you update a period status to Closed, Payables automatically checks whether you have any unposted transactions in their period. If you have any unposted transactions in a period you are trying to close, Payables prevents you from closing the period and automatically submits the Unposted Invoice Sweep report. You can use this report to view all your unposted transactions for the period. You can submit the Unposted Invoice Sweep program if you want to move all unposted transactions from one period to another. Then close your period.
Payables provides for invoice entry,payment entry, and payment voiding in open accounting periods. You can enter invoices in Future accounting periods, but you cannot post any invoices in Future accounting periods until the status is changed to open. The period statues available in payables are Never Opened , Open , Closed and Permanently Closed.
When you update a period status to Closed, Payables automatically checks whether you have any unposted transactions in their period. If you have any unposted transactions in a period you are trying to close, Payables prevents you from closing the period and automatically submits the Unposted Invoice Sweep report. You can use this report to view all your unposted transactions for the period. You can submit the Unposted Invoice Sweep program if you want to move all unposted transactions from one period to another. Then close your period.
AP Periods and Period Types
Oracle Payables provides you with the period types of Month , Quarter and Year. You can setup additional types if needed. Use these types when you define the Payables. The periods define the number of periods in the calender year.
The possible period statuses follow:
Never Opened : First Status of a New Period. Must be changed to Future or Open for transactions.
Future : Invoice entry allowed.
Open: All transactions allowed.
Closed: Transactions not allowed. Can be reopened.
Permanently Closed : Cannot be reopened.
The possible period statuses follow:
Never Opened : First Status of a New Period. Must be changed to Future or Open for transactions.
Future : Invoice entry allowed.
Open: All transactions allowed.
Closed: Transactions not allowed. Can be reopened.
Permanently Closed : Cannot be reopened.
Following are some Important GL Standard reports with a brief description of their purpose:
Account Analysis Report: Lists the accumulated balances of range of accounts and all journal lines that affect that range . Details listed for each journal line include source, batch name and description.
Account Analysis with Payable Detail Report: This report is same as the Account Analysis Report and the details listed for each journal line additionally include vendor name and invoice number.
Budget Trial balance Report: Lists the GL account budget balances and activity for a specific currency.
Detail Trial Balance Report: Lists the GL account balances and activity for GL accounts in detail.
Encumbrance Trial Balance Report: Lists the encumbrance balances and activity for GL accounts in detail.
Expanded Trial Balance Report: Lists the beginning, ending and net balances as well as period activity for a set of accounts.
Foreign Account Analysis Report: Lists the accumulated foreign balances of range of accounts and all journal lines that affect that range. Details listed for each journal line include source, batch name, and description.
Foreign Account Analysis Report with Payables Detail: This report is the same as the Foreign Account Analysis Report and the details listed for each journal line additionally include vendor name and invoice number.
Foreign Currency Detail Trial Balance Report: Lists the GL account balances and activity entered in a foreign currency in detail.
Foreign Currency Summary Trial Balance Report: Lists the GL balances and activity in a foreign currency.
General Ledger Report: Lists beginning and ending account balances and all journal lines affecting each account balance in functional currency. Details listed for each journal line include source and category.
Summary1 Trial Balance Report: Lists the GL account balances and activity for each segment value.
Summary2 Trial Balance Report: Lists the GL account balances and activity for a combination of account segment values and secondary segment values.
Translation Trial Balance Report: Lists the translated account balances and period activity for a specific foreign currency.
Subscribe to:
Posts (Atom)
Posts
