1099 Overview
Form 1099 is a form promulgated by the Internal Revenue Service and is used in the United States Income Tax System to prepare and file information return to report various type of income other than wages, salaries and tips (for which form W2 is used instead).
Each payer must complete a 1099 for each covered transaction. Three copies are made one for he payer , one for the payee and one for the IRS.
US Tax law requires business to submit a Form 1099 for every contractor paid at least $600 for service during a year. This requirement usually does not apply to corporations receiving payments.
Many business and organizations must file thousands of 1099s per year. Thus payers who file 250 or more Form 1099 reports must file all of them electronically or magnetically with the IRS. The 250 or more requirement applies separately for each type of return and separately for each type of corrected return. Even though filers may submit 249 information returns on paer, the IRS encourages files to transmit returns electronically.
If the less than 250 or more requirement is met, and paper copies are filed, the IRS also requires the payer to submit a copy of form 1096. The 1096 is a summary of information forms being sent to the IRS. You need one 1096 for each type of information form you have issued.
Payees use the information provided on the 1099 forms to help them complete their own tax returns. In order to save paper, payers can give payees one single Combined Form 1099 that lists all of their 1099 transactions for the entire year. Taxpayers are usually not required to attach Form 1099s to their own Federal income tax returns unless the Form 1099 includes a report for Federal income tax withheld by the payer from the related payments.
several versions of Form 1099 are used, depending on the nature of the income transaction:
1099-A: acquisition or Abandonment of Secured Property
1099-B: Proceeds from Broker and Barter Exchange Transactions
1099-C: Cancellation of Debt
1099-CAP: Changes in Corporate Control and Capital Structure
1099-DIV: Dividends and Distributions
1099-G: Government Payments
1099-H: Health Insurance Advance Payments
1099-INT: Interest Income
1099-LTC: Long Term Care Benefits
1099-MISC: Miscellaneous Income
1099-OID: Original Issue Discount
1099-PATR: Taxable Distributions Received From Cooperatives
1099-Q: Payment from Qualified Education Programs
1099-R: Distributions from Pensions, Annuities, Retirement Plans, IRAs, or Insurance Contracts
1099-S: Proceeds from Real Estate Transactions
1099-SA: Distributions From an HSA, Archer MSA, or Medicare Advantage MSA
1042-S: Foreign Person's U.S. Source Income
SSA-1099: Social Security Benefit Statement
SSA-1042S: Social Security Benefit Statement to Nonresident Aliens
RRB-1099: Payments by the Railroad Retirement Board
RRB-1099R: Pension and Annuity Income by the Railroad Retirement Board
RRB-1042S: Payments by the Railroad Retirement Board to Nonresident Aliens
W-2G: Certain Gambling Winnings
Each payer must complete a 1099 for each covered transaction. Three copies are made one for he payer , one for the payee and one for the IRS.
US Tax law requires business to submit a Form 1099 for every contractor paid at least $600 for service during a year. This requirement usually does not apply to corporations receiving payments.
Many business and organizations must file thousands of 1099s per year. Thus payers who file 250 or more Form 1099 reports must file all of them electronically or magnetically with the IRS. The 250 or more requirement applies separately for each type of return and separately for each type of corrected return. Even though filers may submit 249 information returns on paer, the IRS encourages files to transmit returns electronically.
If the less than 250 or more requirement is met, and paper copies are filed, the IRS also requires the payer to submit a copy of form 1096. The 1096 is a summary of information forms being sent to the IRS. You need one 1096 for each type of information form you have issued.
Payees use the information provided on the 1099 forms to help them complete their own tax returns. In order to save paper, payers can give payees one single Combined Form 1099 that lists all of their 1099 transactions for the entire year. Taxpayers are usually not required to attach Form 1099s to their own Federal income tax returns unless the Form 1099 includes a report for Federal income tax withheld by the payer from the related payments.
several versions of Form 1099 are used, depending on the nature of the income transaction:
1099-A: acquisition or Abandonment of Secured Property
1099-B: Proceeds from Broker and Barter Exchange Transactions
1099-C: Cancellation of Debt
1099-CAP: Changes in Corporate Control and Capital Structure
1099-DIV: Dividends and Distributions
1099-G: Government Payments
1099-H: Health Insurance Advance Payments
1099-INT: Interest Income
1099-LTC: Long Term Care Benefits
1099-MISC: Miscellaneous Income
1099-OID: Original Issue Discount
1099-PATR: Taxable Distributions Received From Cooperatives
1099-Q: Payment from Qualified Education Programs
1099-R: Distributions from Pensions, Annuities, Retirement Plans, IRAs, or Insurance Contracts
1099-S: Proceeds from Real Estate Transactions
1099-SA: Distributions From an HSA, Archer MSA, or Medicare Advantage MSA
1042-S: Foreign Person's U.S. Source Income
SSA-1099: Social Security Benefit Statement
SSA-1042S: Social Security Benefit Statement to Nonresident Aliens
RRB-1099: Payments by the Railroad Retirement Board
RRB-1099R: Pension and Annuity Income by the Railroad Retirement Board
RRB-1042S: Payments by the Railroad Retirement Board to Nonresident Aliens
W-2G: Certain Gambling Winnings
Wednesday, September 10, 2008
Oracle Receivables-Written Off
Oracle Receivables Writen-off
You can write off unapplied cash receipt balances. Receipt write off functionality is
Provided to account for small overpayments that you do not intend to refund or maintain as unapplied amounts or On account balance.
With this function you can choose to write off an unapplied cash receipt amount within certain limits to a specific general ledger account. The write off amount is credited to this account such as miscellaneous revenue account, and no longer reflected as an unapplied amount on the receipt or on the customer account.
Receipt write offs do not change receipt amounts nor do they affect customer balances or general ledger cash account entries. Receipt write offs can be processed for cash receipts only.
You cannot write off amounts from miscellaneous receipts.
You can write off individual unapplied receipt amounts during receipt application or later, or any time using the application window. You can also write off balances of multiple receipts in mass
using the create receipt write off option.
Receipt Write-off Setup
The following information must be set up before you can process any receipt write-offs:
Receipts write off receivable activity
Define one or more receivable activities with an activity type of Receipt Write off. Each time an unapplied receipt amount is written off, a receipt write off type receivable activity must be selected. For Receipt write off receivable activities the GL Account source must be specified as Activity GL Account. Select a valid general ledger account number as the Activity GL Account. Select valid general ledger account number as the Activity GL Account. This account will be credited for the receipt write off amount. This account may represent a miscellaneous revenue account or expense account.
Navigation Setup – Receipts – Receivable Activities.
b) Receipt Write off user approval limits
Define approval limit ranges for document type Receipt write off for all users who will be allowed to write off unapplied receipt amounts. When you write off an unapplied receipt amount, Receivable uses approval limits that have a document type of Receipt Write off. You cannot write off an unapplied receipt amount that is outside your approval limit or outside the system Maximum Write off amount. You can only write off positive amounts; therefore Receipt write off from amount limits cannot be less than zero.
Navigations
Setup/Transaction/Approval Limits
Define the system level maximum write off amount for a single receipt in your functional currency. No users can write off unapplied receipt amounts that are greater than the system maximum even if their user limits allow it.
****** Therefore the system maximum overrides user approval limits when necessary user allows it. There fore the system maximum overrides user approval limits when necessary.
Navigation: Setup>System>System Options (T) Miscellaneous
c)
How to Manually Write off Receipt Amounts
The manual receipt write off process gives you the flexibility to write off unapplied amounts when you enter and apply a receipt or later any time. You can enter multiple receipt write off lines in the Application window for a single receipt provided that the total write off amounts for the receipt does not exceed your receipt write off user approval limits or the system maximum write off user approval limit or the system maximum write off amount.
NOTE: When you write off an unapplied amount on a foreign currency receipt, Receivables uses the same exchange
rate information from the original receipt for the write-off application record. If you adjust the exchange rate of a
foreign currency receipt, Receivables reverses the write-off with the original exchange rate and then applies the new
exchange rate to a new write-off application record. Receivables completes this process only if the converted amount
does not exceed the user approval limit for receipt write-offs or the system Maximum Write-off Amount. If the converted amount exceeds either of these limits, then the write-off amount is left as an unapplied amount.
To manually write-off a receipt amount:
Navigation
Receipts- Receipts or Receipt- Batches
Enter a new cash receipt or query an existing cash receipt.
Choose application button. (You cannot process receipt write offs using the Mass apply button)
Verify that the unapplied amount for the receipt is greater than zero.
In the Apply To field, select Receipt Write-off.
In the Amount Applied field (you may have to scroll to the right to see this field), enter the unapplied amount to
be written off. (Receivables validates the value you enter is less than or equal to the unapplied amount for the
receipt, is within your user write-off approval limit, and does not exceed the system Maximum Write-off Amount.)
In the Activity field, select a Receipt Write-off type receivables activity.
Save your work. The unapplied amount on the receipt should now be reduced by the write-off amount.
How to Write off Receipt Amounts in Mass
The automatic receipt write-off process gives you the ability to write-off multiple small unapplied receipt amounts
with minimal manual intervention to individual receipt records. Unapplied amounts can be written-off based on
amount or by percentage. When you submit the Automatic Receipt Write-off request, a concurrent program creates the write-off records.
Note: Always use the Generate Report Only option to preview the receipt amounts you want to write off before
submitting the update. You can only reverse write-off receipt amounts by manually unapplying each receipt writeoff from the Applications window.
To create an automatic write-off:
Navigation
Create Receipt write off window
Control- >create receipt write off
In the Selection region, enter the currency of the receipts to write off. Receivables considers receipt amounts for
write off only if they are in the same currency as entered here. The default value is your functional currency if the user write-off approval limit has been defined for the functional currency. You can change the default value to another currency.
Enter either an unapplied amount or unapplied amount percentage, or both. Although you can enter any
amounts in these fields, Receivables will not select unapplied receipt amounts for write-off if they exceed the user
write-off approval limits or system Maximum Write-off Amount.
- If you enter an unapplied amount, Receivables selects unapplied receipt amounts that are less than or equal
to this value and that meet the other selection criteria.
- If you enter an unapplied percentage, Receivables determines the percentages of each unapplied receipt
amount by dividing the unapplied amount by the original receipt amount and then selects unapplied receipt
amounts that are a percentage smaller than or equal to the percentage entered and that meet the other
selection criteria.
- If you enter both an unapplied amount and unapplied percentage, then each unapplied receipt amount must
meet both the amount and percentage criteria. For example in figure 1, if the unapplied amount is set at
$10.00 and the unapplied percentage is set at 20%, then following would apply:
Figure 1
Selected Not Selected
$10 receipt / $1.00 unapplied (10%) $10 receipt / $5.00 unapplied (50%)
$10 receipt / $2.00 unapplied (20%) $200 receipt / $15.00 unapplied (7.5%)
$200 receipt / $5.00 unapplied (2.5%)
$200 receipt / $10.00 unapplied (5%)
Specify a receipt date range, if desired.
WARNING: When date criteria is used, the logic of this program is to select only those receipts that have receipt dates within both the receipt date range and receipt general ledger date range specified.
Specify a receipt general ledger date range, if desired.
WARNING: Please exercise caution when setting receipt general ledger date ranges. When date criteria is used,
the logic of this program is to select only those receipts that have receipt dates within both the receipt date range
and receipt general ledger date range specified.
Specify a payment method, if desired.
Specify an individual customer name, if desired.
Specify an individual customer number, if desired.
Specify an individual receipt number, if desired.
In the Parameters Region, select a Receipt Write-off receivable activity. This field is optional when submitting the
report and required when creating the write-offs.
Enter the apply date. This date is used as the apply date of the write-off application records.
Enter the GL Date. This date is used as the GL date of the write-off application records.
Enter comments, if desired. These comments are assigned to each write-off application record and can be viewed from the Applications window.
In the Options region, select one of the following options:
Generate Report Only: produces the Write-off Unapplied Receipt Balances: Pre Write-off Report, which lists the unapplied receipt amounts selected based on your criteria. Use this option to preview the write-off
results before running the option to create write-off amounts in mass.
- Create Write-off: submits the Automatic Receipt Write-off program (ARWRTCON ) that creates the write-off
application records and generates the Write-off Unapplied Receipt Balances: Write-off Report that lists the unapplied receipt amounts selected based on your criteria.
WARNING: Oracle highly recommends that you always use the Generate Report Only option first before
submitting the update. There is no supported means for reversing receipt write-offs in mass. You can only
reverse write-off receipt amounts by manually unapplying each receipt write-off from the Applications window.
Choose the Submit button.
Reversing Receipt Write-offs
Like other payment applications, receipt write-off amounts can be reversed at any time and the write-off amount will
be added to the Unapplied total for the receipt. To reverse a receipt write-off, unapply the original write-off application by unchecking the Apply check box on the Applications window for the write-off amount.
To reverse a receipt write-off:
Navigate to the Receipts window (Receipts>Receipts or Receipts>Batches).
Query the existing cash receipt.
Choose the Applications button.
Uncheck the Apply box next to the receipt write-off application line you want to reverse.
Confirm that the write-off amount is added to the Unapplied total for the receipt.
Apply the unapplied amount, if desired.
Save your work.
Viewing Receipt Write-offs
Receipt write-off amounts are displayed with other receipt application lines. You can review the applications for a
receipt by querying the receipt from the Receipts or Receipts Summary options and then selecting the Applications
button. You can also drill down to receipt application information from the Account Details option by querying the
receipt number as the Transaction number, then selecting the Activities button.
NOTE: At this time, receipt write-off amounts cannot be viewed from the Receipts form, Application Summary
tabbed region. Receipt write-off application lines are omitted from this screen.
The accounting for receipt write-off amounts is included with the accounting for the receipt.
To review receipt write-off information:
Navigation
Receipts – Receipts or Receipts – Receipts Summary.
Query the receipt to view.
If you are in the Receipts window, choose the Applications button. If you are in the Receipts Summary window,choose Open, then choose the Applications button.
View the receipt write-off line(s) and amounts.
If you want to view accounting information for receipt write-offs, close the Applications window to return to the
Receipts window.
Choose View Accounting from the Tools Menu. View the detail accounting lines for the receipt in the form of a
balanced accounting entry. The receipt write-off amounts display as credits with a line type of ‘Other Receipt
Application’ for the account that was defined for the Receipt Write-off receivable activity selected. You should also see that the write-off amount was initially included in the Unapplied line type amounts.
If you want to view the detail accounting as t-accounts, select the T Accounts button.
Accounting for Receipt Write-offs
As a cash receipt is entered, general ledger entries are created for each step in the process. Therefore, to explain the entries for a receipt write-off, you need to first understand the entries for receipts in general.
If a receipt is initially saved as unidentified (a customer is not selected), then the following entries are made:
DR Cash
CR Unidentified
However, most cash receipts are not saved before the customer is identified; therefore the following entries are
typically the initial accounting entries created for a receipt:
DR Cash
CR Unapplied
As you apply the receipt, entries are made to move the money from Unapplied to Applied (Receivable).
For example, if a $100 receipt is entered and applied in full, the following entries are made:
DR Cash 100
CR Unapplied 100
DR Unapplied 100
CR Receivable 100
When a receipt write-off is processed, the money is moved from Unapplied and put to the account defined for the
Receipt Write-off receivable activity selected.
For example, if a $100 receipt is entered and $95 is applied and $5 is written off, then the following entries are made:
DR Cash 100
CR Unapplied 100
DR Unapplied 95
CR Receivable 95
DR Unapplied 5
CR Write-off 5
If you later decide to reverse the write-off, then the following additional entries are made:
DR Write-off 5
CR Unapplied 5
Receipt Write-off Table Information
Receipt write-off amounts are stored in Oracle Receivables like other receipt application rows. Following is a description of each table that is updated when a cash receipt is entered. Only the
AR_PAYMENT_SCHEDULES_ALL
AR_RECEIVABLE_APPLICATIONS_ALL
AR_DISTIRBUTIONS_ALL
AR_CASH_RECEIPTS_ALL: One record is created per cash receipt. Receipt write-off amounts do not impact
the values in this table. However, Oracle Receivables assigns a status to each receipt based on how it is
applied. So it is important to understand how statuses are assigned and how receipt write-offs are
considered in assigning these statuses. Available statuses are: Applied (APP), Unidentified (UNID), Unapplied (UNAPP), and Reversed (REV). If the receipt is reversed (regardless of how it was applied), then the status REV is used. If any portion of the receipt is unapplied (regardless of how the rest of the receipt is applied), then the status UNAPP is used. If a customer has not yet been assigned to the receipt, then UNID is used. And if the receipt is applied in full, that includes applications to debit and credit items, as well as on
account and receipt write-off amounts, then the status APP is used. Other relevant columns for receipts include those described in Figure 2:
Figure 2
Cash_receipt_id Unique identifier of receipt (primary key)
Receipt_number Cash receipt number, not necessarily unique
Amount Amount of the payment
Currency_code Currency code assigned to the receipt
Receipt_date Date of receipt
Type CASH
Confirmed_flag Y or N
Pay_from_customer Identifier of the customer for this receipt
AR_CASH_RECEIPT_HISTORY_ALL: One record is created for each life cycle of a receipt. For example, a
typical receipt (applied or unapplied) will have one row with a status of CLEARED. If a receipt has been
reversed, then it will have two rows with statuses of: CLEARED and REVERSED. Automatic receipts can
have additional rows depending upon the confirmation levels required. So an automatic receipt could have
three rows with statuses of: APPROVED, CONFIRMED, and REMITTED. Other relevant columns for
receipts include these described in Figure 3:
Figure 3
Cash_receipt_history_id Unique identifier of the cash receipt history record
(primary key)
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Amount Receipt amount in currency assigned to the receipt
Acctd_amount Receipt amount in your functional currency
First_posted_record_flag Y – when this is the first row that has been posted
Gl_date The general ledger date used to debit the CASH
account_code_combination_id
Account_code_combination_id Code representing the CASH account that will be
debited (and possibly credited) for the row
Current_record_flag Indicates which row is the current one for the cash
receipt (Y or N)
Reversal_gl_date The general ledger date used to credit the CASH
account_code_combination_id. It also signifies that
this row of the receipt has been reversed.
Posting_control_id Receivables posting batch identifier. –3 designates
10
unposted rows, a positive number designates posted
rows.
Reversal_posting_control_id Receivables posting batch identifier for the reversal
of the row. –3 designates an unposted reversal, a
positive number designates a posted reversal.
- AR_PAYMENT_SCHEDULES_ALL: One record is created per cash receipt to reflect the overall status of the
receipt. Oracle Receivables updates this table each time activity occurs for a receipt. All cash receipts are
identified with a class of PMT. When a receipt is applied or written-off, the amount is updated to the
amount_applied column and reduces the amount_due_remaining. When a receipt is completely applied
(includes write-offs), Oracle Receivables changes the status from open (OP) to closed (CL). Unapplied, on
account, and unidentified amounts are included in the amount_due_remaining and the receipt will not close
until these amounts are applied. All receipt amounts are stored as negative numbers in this table. Additional
AR_PAYMENT_SCHEDULES_ALL records can be created for receipts when debit memo reversals or
chargebacks are created. Other relevant columns for receipts include these described in Figure 4:
Figure 4
Payment_schedule_id Unique identifier for the payment schedule row
(primary key)
Amount_due_original Amount of the payment (negative)
Amount_due_remaining Sum of unapplied, on account, and unidentified
amounts in the receipt currency or the payment
amount minus applied and receipt write-off amounts
(negative)
Acctd_amount_due_remainin
g
Amount_due_remaining in your functional currency
(negative)
Status OP for open, CL for closed. A closed receipt is one
that is fully applied.
Class PMT
Customer_id Identifier of the customer for this receipt
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Gl_date_closed The accounting date on which the schedule was
closed. The default value for open rows is ‘31-DEC-
4712’.
Amount_applied Sum of applied and receipt write-off amounts
(negative)
Trx_number Cash receipt number, not necessarily unique
Trx_date The transaction date of the row
- AR_RECEIVABLE_APPLICATIONS_ALL: One record is created for every type of transaction processed on a receipt. This table is essentially an audit trail of all accounting entries for your cash and credit memo receipt
applications. A row is written in this table for each time you select the Apply or Unapply button – regardless
of whether you manually save the changes – they are always stored here. Each row includes the amount
applied, status, accounting flexfield information, and a posting control id. Possible statuses include applied
(APP), unapplied (UNAPP), on account (ACC), unidentified (UNID), and receipt write-off (ACTIVITY). For
example, if you write-off a $1.00 unapplied amount, two rows will be created: UNAPP for -$1.00 and
ACTIVITY for $1.00.
There are two kinds of applications (CASH and CM – for credit memo applications) stored in this table and
designated by application_type. Credit memo lines applied with a receipt are stored in this table with the
other applications for the receipt. Other relevant columns for receipts include these described in
Receivable_application_id Unique identifier of the receivable application row
(primary key)
Amount_applied Total amount of the line in the receipt’s currency.
This includes line amounts, tax, freight, and finance
charges. Write-off amounts are included here as
well.
Acctd_amount_applied_from Amount_applied in your functional currency
Status APP, UNAPP, ACC, UNID, and ACTIVITY (receipt
write-offs)
Gl_date Date this application row will post to the general
ledger
Code_combination_id General ledger account number code combination id
Payment_schedule_id Identifies the cash receipt or credit memo being
applied
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Applied_customer_trx_id Identifies the transaction being paid / reversed
Applied_customer_trx_line_id Identifies the line of the transaction being paid /
reversed
Customer_trx_id Identifier of the credit memo being applied
Gl_posted_date Date this row was posted to the general ledger
Postable Y or N to indicate whether the row is postable to the
general ledger
Posting_control_id Receivables posting batch identifier. –3 designates
unposted rows, a positive number designates posted
rows.
Confirmed_flag Null or Y for confirmed receipts
AR_DISTRIBUTIONS_ALL: A record is created in this table for the general ledger distributions information
generated by the different steps in the life cycle of a cash receipt. This includes distributions based on the
rows for the receipt in the AR_CASH_RECEIPT_HISTORY_ALL and
AR_RECEIVABLE_APPLICATIONS_ALL tables. Each row includes the amounts to be debited or credited in
both the receipt and functional currency, general ledger code combination id, source table, and source type.
The source_table indicates which table the row is created from: CRH for
AR_CASH_RECEIPT_HISTORY_ALL and RA for AR_RECEIVABLE_APPLICATIONS_ALL. The
source_type reflects the type of activity, such as CASH (for the initial debit to Cash for the receipt), REC for
applied amounts, UNAPP for unapplied amounts, ACC for on account amounts, and ACTIVITY for receipt
write-off amounts. Other relevant columns for receipts include these described in Figure 6:
Figure 6
Line_id Unique identifier for each row in this table
Source_id Identifier of the row source from the foreign table. Represents
the cash_receipt_history_id from
AR_CASH_RECEIPT_HISTORY_ALL or the
receivable_application_id from
AR_RECEIVABLE_APPLICATIONS_ALL (primary key).
12
Source_table Indicates the origin of the row in the table that was used to
create this distribution line: CRH for
AR_CASH_RECEIPT_HISTORY_ALL and RA for
AR_RECEIVABLE_APPLICATIONS_ALL (primary key)
Source_type Represents the type of general ledger account for which the
distribution is created. The source_type varies based on the
source_table. For Cleared and Reversed rows in
AR_CASH_RECEIPT_HISTORY_ALL, this value is CASH.
For rows in AR_RECEIVABLE_APPLICATIONS_ALL, the
value in this table is the same as the status in that table except
for APP rows. APP status rows get a value of REC in this
table. (ACTIVITY rows are created in both tables for receipt
write-offs.) (primary key)
Code_combination_id The general ledger account the distribution is created for
Amount_dr Debit amount of the journal entry in receipt currency
Amount_cr Credit amount of the journal entry in receipt currency
Acctd_amount_dr Debit amount of the journal entry in your functional currency
Acctd_amount_cr Credit amount of the journal entry in your functional currency
13
You can write off unapplied cash receipt balances. Receipt write off functionality is
Provided to account for small overpayments that you do not intend to refund or maintain as unapplied amounts or On account balance.
With this function you can choose to write off an unapplied cash receipt amount within certain limits to a specific general ledger account. The write off amount is credited to this account such as miscellaneous revenue account, and no longer reflected as an unapplied amount on the receipt or on the customer account.
Receipt write offs do not change receipt amounts nor do they affect customer balances or general ledger cash account entries. Receipt write offs can be processed for cash receipts only.
You cannot write off amounts from miscellaneous receipts.
You can write off individual unapplied receipt amounts during receipt application or later, or any time using the application window. You can also write off balances of multiple receipts in mass
using the create receipt write off option.
Receipt Write-off Setup
The following information must be set up before you can process any receipt write-offs:
Receipts write off receivable activity
Define one or more receivable activities with an activity type of Receipt Write off. Each time an unapplied receipt amount is written off, a receipt write off type receivable activity must be selected. For Receipt write off receivable activities the GL Account source must be specified as Activity GL Account. Select a valid general ledger account number as the Activity GL Account. Select valid general ledger account number as the Activity GL Account. This account will be credited for the receipt write off amount. This account may represent a miscellaneous revenue account or expense account.
Navigation Setup – Receipts – Receivable Activities.
b) Receipt Write off user approval limits
Define approval limit ranges for document type Receipt write off for all users who will be allowed to write off unapplied receipt amounts. When you write off an unapplied receipt amount, Receivable uses approval limits that have a document type of Receipt Write off. You cannot write off an unapplied receipt amount that is outside your approval limit or outside the system Maximum Write off amount. You can only write off positive amounts; therefore Receipt write off from amount limits cannot be less than zero.
Navigations
Setup/Transaction/Approval Limits
Define the system level maximum write off amount for a single receipt in your functional currency. No users can write off unapplied receipt amounts that are greater than the system maximum even if their user limits allow it.
****** Therefore the system maximum overrides user approval limits when necessary user allows it. There fore the system maximum overrides user approval limits when necessary.
Navigation: Setup>System>System Options (T) Miscellaneous
c)
How to Manually Write off Receipt Amounts
The manual receipt write off process gives you the flexibility to write off unapplied amounts when you enter and apply a receipt or later any time. You can enter multiple receipt write off lines in the Application window for a single receipt provided that the total write off amounts for the receipt does not exceed your receipt write off user approval limits or the system maximum write off user approval limit or the system maximum write off amount.
NOTE: When you write off an unapplied amount on a foreign currency receipt, Receivables uses the same exchange
rate information from the original receipt for the write-off application record. If you adjust the exchange rate of a
foreign currency receipt, Receivables reverses the write-off with the original exchange rate and then applies the new
exchange rate to a new write-off application record. Receivables completes this process only if the converted amount
does not exceed the user approval limit for receipt write-offs or the system Maximum Write-off Amount. If the converted amount exceeds either of these limits, then the write-off amount is left as an unapplied amount.
To manually write-off a receipt amount:
Navigation
Receipts- Receipts or Receipt- Batches
Enter a new cash receipt or query an existing cash receipt.
Choose application button. (You cannot process receipt write offs using the Mass apply button)
Verify that the unapplied amount for the receipt is greater than zero.
In the Apply To field, select Receipt Write-off.
In the Amount Applied field (you may have to scroll to the right to see this field), enter the unapplied amount to
be written off. (Receivables validates the value you enter is less than or equal to the unapplied amount for the
receipt, is within your user write-off approval limit, and does not exceed the system Maximum Write-off Amount.)
In the Activity field, select a Receipt Write-off type receivables activity.
Save your work. The unapplied amount on the receipt should now be reduced by the write-off amount.
How to Write off Receipt Amounts in Mass
The automatic receipt write-off process gives you the ability to write-off multiple small unapplied receipt amounts
with minimal manual intervention to individual receipt records. Unapplied amounts can be written-off based on
amount or by percentage. When you submit the Automatic Receipt Write-off request, a concurrent program creates the write-off records.
Note: Always use the Generate Report Only option to preview the receipt amounts you want to write off before
submitting the update. You can only reverse write-off receipt amounts by manually unapplying each receipt writeoff from the Applications window.
To create an automatic write-off:
Navigation
Create Receipt write off window
Control- >create receipt write off
In the Selection region, enter the currency of the receipts to write off. Receivables considers receipt amounts for
write off only if they are in the same currency as entered here. The default value is your functional currency if the user write-off approval limit has been defined for the functional currency. You can change the default value to another currency.
Enter either an unapplied amount or unapplied amount percentage, or both. Although you can enter any
amounts in these fields, Receivables will not select unapplied receipt amounts for write-off if they exceed the user
write-off approval limits or system Maximum Write-off Amount.
- If you enter an unapplied amount, Receivables selects unapplied receipt amounts that are less than or equal
to this value and that meet the other selection criteria.
- If you enter an unapplied percentage, Receivables determines the percentages of each unapplied receipt
amount by dividing the unapplied amount by the original receipt amount and then selects unapplied receipt
amounts that are a percentage smaller than or equal to the percentage entered and that meet the other
selection criteria.
- If you enter both an unapplied amount and unapplied percentage, then each unapplied receipt amount must
meet both the amount and percentage criteria. For example in figure 1, if the unapplied amount is set at
$10.00 and the unapplied percentage is set at 20%, then following would apply:
Figure 1
Selected Not Selected
$10 receipt / $1.00 unapplied (10%) $10 receipt / $5.00 unapplied (50%)
$10 receipt / $2.00 unapplied (20%) $200 receipt / $15.00 unapplied (7.5%)
$200 receipt / $5.00 unapplied (2.5%)
$200 receipt / $10.00 unapplied (5%)
Specify a receipt date range, if desired.
WARNING: When date criteria is used, the logic of this program is to select only those receipts that have receipt dates within both the receipt date range and receipt general ledger date range specified.
Specify a receipt general ledger date range, if desired.
WARNING: Please exercise caution when setting receipt general ledger date ranges. When date criteria is used,
the logic of this program is to select only those receipts that have receipt dates within both the receipt date range
and receipt general ledger date range specified.
Specify a payment method, if desired.
Specify an individual customer name, if desired.
Specify an individual customer number, if desired.
Specify an individual receipt number, if desired.
In the Parameters Region, select a Receipt Write-off receivable activity. This field is optional when submitting the
report and required when creating the write-offs.
Enter the apply date. This date is used as the apply date of the write-off application records.
Enter the GL Date. This date is used as the GL date of the write-off application records.
Enter comments, if desired. These comments are assigned to each write-off application record and can be viewed from the Applications window.
In the Options region, select one of the following options:
Generate Report Only: produces the Write-off Unapplied Receipt Balances: Pre Write-off Report, which lists the unapplied receipt amounts selected based on your criteria. Use this option to preview the write-off
results before running the option to create write-off amounts in mass.
- Create Write-off: submits the Automatic Receipt Write-off program (ARWRTCON ) that creates the write-off
application records and generates the Write-off Unapplied Receipt Balances: Write-off Report that lists the unapplied receipt amounts selected based on your criteria.
WARNING: Oracle highly recommends that you always use the Generate Report Only option first before
submitting the update. There is no supported means for reversing receipt write-offs in mass. You can only
reverse write-off receipt amounts by manually unapplying each receipt write-off from the Applications window.
Choose the Submit button.
Reversing Receipt Write-offs
Like other payment applications, receipt write-off amounts can be reversed at any time and the write-off amount will
be added to the Unapplied total for the receipt. To reverse a receipt write-off, unapply the original write-off application by unchecking the Apply check box on the Applications window for the write-off amount.
To reverse a receipt write-off:
Navigate to the Receipts window (Receipts>Receipts or Receipts>Batches).
Query the existing cash receipt.
Choose the Applications button.
Uncheck the Apply box next to the receipt write-off application line you want to reverse.
Confirm that the write-off amount is added to the Unapplied total for the receipt.
Apply the unapplied amount, if desired.
Save your work.
Viewing Receipt Write-offs
Receipt write-off amounts are displayed with other receipt application lines. You can review the applications for a
receipt by querying the receipt from the Receipts or Receipts Summary options and then selecting the Applications
button. You can also drill down to receipt application information from the Account Details option by querying the
receipt number as the Transaction number, then selecting the Activities button.
NOTE: At this time, receipt write-off amounts cannot be viewed from the Receipts form, Application Summary
tabbed region. Receipt write-off application lines are omitted from this screen.
The accounting for receipt write-off amounts is included with the accounting for the receipt.
To review receipt write-off information:
Navigation
Receipts – Receipts or Receipts – Receipts Summary.
Query the receipt to view.
If you are in the Receipts window, choose the Applications button. If you are in the Receipts Summary window,choose Open, then choose the Applications button.
View the receipt write-off line(s) and amounts.
If you want to view accounting information for receipt write-offs, close the Applications window to return to the
Receipts window.
Choose View Accounting from the Tools Menu. View the detail accounting lines for the receipt in the form of a
balanced accounting entry. The receipt write-off amounts display as credits with a line type of ‘Other Receipt
Application’ for the account that was defined for the Receipt Write-off receivable activity selected. You should also see that the write-off amount was initially included in the Unapplied line type amounts.
If you want to view the detail accounting as t-accounts, select the T Accounts button.
Accounting for Receipt Write-offs
As a cash receipt is entered, general ledger entries are created for each step in the process. Therefore, to explain the entries for a receipt write-off, you need to first understand the entries for receipts in general.
If a receipt is initially saved as unidentified (a customer is not selected), then the following entries are made:
DR Cash
CR Unidentified
However, most cash receipts are not saved before the customer is identified; therefore the following entries are
typically the initial accounting entries created for a receipt:
DR Cash
CR Unapplied
As you apply the receipt, entries are made to move the money from Unapplied to Applied (Receivable).
For example, if a $100 receipt is entered and applied in full, the following entries are made:
DR Cash 100
CR Unapplied 100
DR Unapplied 100
CR Receivable 100
When a receipt write-off is processed, the money is moved from Unapplied and put to the account defined for the
Receipt Write-off receivable activity selected.
For example, if a $100 receipt is entered and $95 is applied and $5 is written off, then the following entries are made:
DR Cash 100
CR Unapplied 100
DR Unapplied 95
CR Receivable 95
DR Unapplied 5
CR Write-off 5
If you later decide to reverse the write-off, then the following additional entries are made:
DR Write-off 5
CR Unapplied 5
Receipt Write-off Table Information
Receipt write-off amounts are stored in Oracle Receivables like other receipt application rows. Following is a description of each table that is updated when a cash receipt is entered. Only the
AR_PAYMENT_SCHEDULES_ALL
AR_RECEIVABLE_APPLICATIONS_ALL
AR_DISTIRBUTIONS_ALL
AR_CASH_RECEIPTS_ALL: One record is created per cash receipt. Receipt write-off amounts do not impact
the values in this table. However, Oracle Receivables assigns a status to each receipt based on how it is
applied. So it is important to understand how statuses are assigned and how receipt write-offs are
considered in assigning these statuses. Available statuses are: Applied (APP), Unidentified (UNID), Unapplied (UNAPP), and Reversed (REV). If the receipt is reversed (regardless of how it was applied), then the status REV is used. If any portion of the receipt is unapplied (regardless of how the rest of the receipt is applied), then the status UNAPP is used. If a customer has not yet been assigned to the receipt, then UNID is used. And if the receipt is applied in full, that includes applications to debit and credit items, as well as on
account and receipt write-off amounts, then the status APP is used. Other relevant columns for receipts include those described in Figure 2:
Figure 2
Cash_receipt_id Unique identifier of receipt (primary key)
Receipt_number Cash receipt number, not necessarily unique
Amount Amount of the payment
Currency_code Currency code assigned to the receipt
Receipt_date Date of receipt
Type CASH
Confirmed_flag Y or N
Pay_from_customer Identifier of the customer for this receipt
AR_CASH_RECEIPT_HISTORY_ALL: One record is created for each life cycle of a receipt. For example, a
typical receipt (applied or unapplied) will have one row with a status of CLEARED. If a receipt has been
reversed, then it will have two rows with statuses of: CLEARED and REVERSED. Automatic receipts can
have additional rows depending upon the confirmation levels required. So an automatic receipt could have
three rows with statuses of: APPROVED, CONFIRMED, and REMITTED. Other relevant columns for
receipts include these described in Figure 3:
Figure 3
Cash_receipt_history_id Unique identifier of the cash receipt history record
(primary key)
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Amount Receipt amount in currency assigned to the receipt
Acctd_amount Receipt amount in your functional currency
First_posted_record_flag Y – when this is the first row that has been posted
Gl_date The general ledger date used to debit the CASH
account_code_combination_id
Account_code_combination_id Code representing the CASH account that will be
debited (and possibly credited) for the row
Current_record_flag Indicates which row is the current one for the cash
receipt (Y or N)
Reversal_gl_date The general ledger date used to credit the CASH
account_code_combination_id. It also signifies that
this row of the receipt has been reversed.
Posting_control_id Receivables posting batch identifier. –3 designates
10
unposted rows, a positive number designates posted
rows.
Reversal_posting_control_id Receivables posting batch identifier for the reversal
of the row. –3 designates an unposted reversal, a
positive number designates a posted reversal.
- AR_PAYMENT_SCHEDULES_ALL: One record is created per cash receipt to reflect the overall status of the
receipt. Oracle Receivables updates this table each time activity occurs for a receipt. All cash receipts are
identified with a class of PMT. When a receipt is applied or written-off, the amount is updated to the
amount_applied column and reduces the amount_due_remaining. When a receipt is completely applied
(includes write-offs), Oracle Receivables changes the status from open (OP) to closed (CL). Unapplied, on
account, and unidentified amounts are included in the amount_due_remaining and the receipt will not close
until these amounts are applied. All receipt amounts are stored as negative numbers in this table. Additional
AR_PAYMENT_SCHEDULES_ALL records can be created for receipts when debit memo reversals or
chargebacks are created. Other relevant columns for receipts include these described in Figure 4:
Figure 4
Payment_schedule_id Unique identifier for the payment schedule row
(primary key)
Amount_due_original Amount of the payment (negative)
Amount_due_remaining Sum of unapplied, on account, and unidentified
amounts in the receipt currency or the payment
amount minus applied and receipt write-off amounts
(negative)
Acctd_amount_due_remainin
g
Amount_due_remaining in your functional currency
(negative)
Status OP for open, CL for closed. A closed receipt is one
that is fully applied.
Class PMT
Customer_id Identifier of the customer for this receipt
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Gl_date_closed The accounting date on which the schedule was
closed. The default value for open rows is ‘31-DEC-
4712’.
Amount_applied Sum of applied and receipt write-off amounts
(negative)
Trx_number Cash receipt number, not necessarily unique
Trx_date The transaction date of the row
- AR_RECEIVABLE_APPLICATIONS_ALL: One record is created for every type of transaction processed on a receipt. This table is essentially an audit trail of all accounting entries for your cash and credit memo receipt
applications. A row is written in this table for each time you select the Apply or Unapply button – regardless
of whether you manually save the changes – they are always stored here. Each row includes the amount
applied, status, accounting flexfield information, and a posting control id. Possible statuses include applied
(APP), unapplied (UNAPP), on account (ACC), unidentified (UNID), and receipt write-off (ACTIVITY). For
example, if you write-off a $1.00 unapplied amount, two rows will be created: UNAPP for -$1.00 and
ACTIVITY for $1.00.
There are two kinds of applications (CASH and CM – for credit memo applications) stored in this table and
designated by application_type. Credit memo lines applied with a receipt are stored in this table with the
other applications for the receipt. Other relevant columns for receipts include these described in
Receivable_application_id Unique identifier of the receivable application row
(primary key)
Amount_applied Total amount of the line in the receipt’s currency.
This includes line amounts, tax, freight, and finance
charges. Write-off amounts are included here as
well.
Acctd_amount_applied_from Amount_applied in your functional currency
Status APP, UNAPP, ACC, UNID, and ACTIVITY (receipt
write-offs)
Gl_date Date this application row will post to the general
ledger
Code_combination_id General ledger account number code combination id
Payment_schedule_id Identifies the cash receipt or credit memo being
applied
Cash_receipt_id Unique identifier of receipt, although multiple rows
can have the same cash_receipt_id
Applied_customer_trx_id Identifies the transaction being paid / reversed
Applied_customer_trx_line_id Identifies the line of the transaction being paid /
reversed
Customer_trx_id Identifier of the credit memo being applied
Gl_posted_date Date this row was posted to the general ledger
Postable Y or N to indicate whether the row is postable to the
general ledger
Posting_control_id Receivables posting batch identifier. –3 designates
unposted rows, a positive number designates posted
rows.
Confirmed_flag Null or Y for confirmed receipts
AR_DISTRIBUTIONS_ALL: A record is created in this table for the general ledger distributions information
generated by the different steps in the life cycle of a cash receipt. This includes distributions based on the
rows for the receipt in the AR_CASH_RECEIPT_HISTORY_ALL and
AR_RECEIVABLE_APPLICATIONS_ALL tables. Each row includes the amounts to be debited or credited in
both the receipt and functional currency, general ledger code combination id, source table, and source type.
The source_table indicates which table the row is created from: CRH for
AR_CASH_RECEIPT_HISTORY_ALL and RA for AR_RECEIVABLE_APPLICATIONS_ALL. The
source_type reflects the type of activity, such as CASH (for the initial debit to Cash for the receipt), REC for
applied amounts, UNAPP for unapplied amounts, ACC for on account amounts, and ACTIVITY for receipt
write-off amounts. Other relevant columns for receipts include these described in Figure 6:
Figure 6
Line_id Unique identifier for each row in this table
Source_id Identifier of the row source from the foreign table. Represents
the cash_receipt_history_id from
AR_CASH_RECEIPT_HISTORY_ALL or the
receivable_application_id from
AR_RECEIVABLE_APPLICATIONS_ALL (primary key).
12
Source_table Indicates the origin of the row in the table that was used to
create this distribution line: CRH for
AR_CASH_RECEIPT_HISTORY_ALL and RA for
AR_RECEIVABLE_APPLICATIONS_ALL (primary key)
Source_type Represents the type of general ledger account for which the
distribution is created. The source_type varies based on the
source_table. For Cleared and Reversed rows in
AR_CASH_RECEIPT_HISTORY_ALL, this value is CASH.
For rows in AR_RECEIVABLE_APPLICATIONS_ALL, the
value in this table is the same as the status in that table except
for APP rows. APP status rows get a value of REC in this
table. (ACTIVITY rows are created in both tables for receipt
write-offs.) (primary key)
Code_combination_id The general ledger account the distribution is created for
Amount_dr Debit amount of the journal entry in receipt currency
Amount_cr Credit amount of the journal entry in receipt currency
Acctd_amount_dr Debit amount of the journal entry in your functional currency
Acctd_amount_cr Credit amount of the journal entry in your functional currency
13
Thursday, August 21, 2008
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 revaluation journals with adjustments to the defined unrealized gain/loss account. The Revaluation program generates adjustments in the Functional Currency. If you have a Reporting Set of Books you must run revaluation 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.
You get to the Revalue balances form by following navigation path
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 revaluation journals with adjustments to the defined unrealized gain/loss account. The Revaluation program generates adjustments in the Functional Currency. If you have a Reporting Set of Books you must run revaluation 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.
You get to the Revalue balances form by following navigation path
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 Receivables
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
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.
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
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
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.
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
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 nundane 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 unix 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 nundane 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 unix based systems letting developers choose their preferred development platform.
Wednesday, August 20, 2008
11i and 12 i -Changes
11i and 12i
In 11i the field 'bank_account_id' acts as a relation key between the AP_CHECKS_ALL and AP_BANK_ACCOUNTS_ALL tables.
In 12 i the same field is no longer is used in 'AP_CHECKS_ALL' table.
In 12 i where 'CE_BANK_ACCT_USE_ID' is acts as a 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 processes across ledger.
Centralized rules engines for tax, accounting and Intercomapny.
Centralized trading partners i.e Suppliers, Banks, First Party legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.
In 11i the field 'bank_account_id' acts as a relation key between the AP_CHECKS_ALL and AP_BANK_ACCOUNTS_ALL tables.
In 12 i the same field is no longer is used in 'AP_CHECKS_ALL' table.
In 12 i where 'CE_BANK_ACCT_USE_ID' is acts as a 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 processes across ledger.
Centralized rules engines for tax, accounting and Intercomapny.
Centralized trading partners i.e Suppliers, Banks, First Party legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.
Tuesday, August 19, 2008
Oracle AIM 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.
Application Implementation Method is a proven approach for all the activities required to implement oracle applications. 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 StrategyB
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 StrategyMD.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 strategyTE.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
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
Application Implementation Method is a proven approach for all the activities required to implement oracle applications. 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 StrategyB
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 StrategyMD.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 strategyTE.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
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
Subscribe to: Posts (Atom)
Blog Archive
Posts
No comments:
Post a Comment