Sample Resignation letter

Today is my last day at XYZ Company and it has been my pleasure to have worked with each and every one of you.

I wanted to take this opportunity to express my thanks to all of you who have made my time here such a great experience on both a professional and personal level.

I have learned so much and will really miss working with you.

I wish each of you the best of success in your future undertakings.

I would love to keep in touch, so please feel free to contact me at xyz@abcd.com

Thanks again for all the support and guidance. Take care and God bless you.

SQL Tuning Guidelines for Oracle - Simple yet Effective!

In this article I will discuss some SQL tuning guidelines that are simple but effective. SQL is the heart of the Oracle system. You can use many different SQL statements to attain the same result. It is often the case that only one statement will be the most efficient option in a given state of affairs. The guidelines below include information about whether one form of the statement is always more efficient or whether each statement is an alternative and the efficiency will differ depending on your application.

>>Oracle processing of SQL:

Oracle processes SQL in two steps:

1. Parsing
2. Execution.

Tuning may speed up your SQL by reducing either parsing or execution or both. Tuning SQL should only be done after your code is working correctly. Beware that there is an inevitable tug-of-war between writing efficient SQL and understandable SQL.

>>Oracle SQL Tuning - Identical SQL:

SQL cannot be shared within Oracle unless it is absolutely identical. Statements must match exactly in case, white space and underlying schema objects to be shared within Oracle's memory. Oracle avoids the parsing step for each subsequent use of an identical statement.

sql> SELECT NAME FROM S_CUSTOMER WHERE ID = 212; statement to match  sql> SELECT NAME FROM s_customer WHERE ID = 212; lower case  sql> SELECT NAME FROM S_CUSTOMER WHERE ID=212; white space  sql> SELECT NAME  FROM S_CUSTOMER  WHERE ID=212; white space

>>Oracle SQL Tuning - Standard SQL:

Use SQL standards within an application. Rules like the following are easy to implement and will allow more sharing within Oracle's memory. 

- Use a single case for all SQL verbs 
- Begin all SQL verbs on a new line 
- Align the verbs right or left within the initial SQL verb 
- Separate all words with a single space

>>Oracle SQL Tuning - Bind variables:

Use bind variables. The values of bind variables need not to be the same for two statements to be considered identical. Bind variables are not substituted until a statement has been successfully parsed.

Sharable SQL	Non-sharable SQL
SELECT * FROM emp  WHERE emp_no = :B1; Bind value: 123	SELECT * FROM emp  WHERE emp_no = 123;
SELECT * FROM emp  WHERE emp_no = :B1; Bind value: 987	SELECT * FROM emp  WHERE emp_no = 987;

>>Oracle SQL Tuning - Table Aliases:

Use table aliases and a standard approach to table aliases. If two identical SQL statements differ because an identical table has two different aliases, then the SQL is different and will not be shared.

>>Oracle SQL Tuning - Prefix column names by Aliases:

Prefix all column names by their aliases when more than one table is involved in a query. This decreases the parse time and prevents future syntax errors if someone adds a column to one of the tables with the same name as a column in another table. (ORA-00918: Column Ambiguously Defined)

>>Oracle SQL Tuning - WHERE Clause:

Beware of WHERE clauses which do not use indexes at all. Even if there is an index over a column that is referenced by a WHERE clause included in this section, Oracle will ignore the index. All of WHERE clauses can be re-written to use an index while returning the same values. In other words, don't perform operations on database objects referenced in the WHERE clause.

SELECT account_name, trans_date, amount  WHERE SUBSTR (account_name,1,7) = 'CAPITAL';	SELECT account_name, trans_date, amount  WHERE account_name LIKE 'CAPITAL%';
SELECT account_name, trans_date, amount  WHERE account_name || account_type= 'AMEXA';	SELECT account_name, trans_date, amount  WHERE account_name = 'AMEX'  AND account_type = 'A';
SELECT account_name, trans_date, amount  WHERE TRUNC (trans_date) = TRUNC ( SYSDATE );	SELECT account_name, trans_date, amount  WHERE trans_date BETWEEN TRUNC ( SYSDATE ) AND TRUNC ( SYSDATE ) + .99999;
SELECT account_name, trans_date, amount  WHERE account_name = NVL ( :acc_name, account_name);	SELECT account_name, trans_date, amount  WHERE account_name LIKE NVL ( :acc_name, '%');
SELECT account_name, trans_date, amount  WHERE amount + 3000 < 5000;	SELECT account_name, trans_date, amount  WHERE amount != 0;
SELECT account_name, trans_date, amount  WHERE amount < 2000;	SELECT account_name, trans_date, amount  WHERE amount > 0;
SELECT account_name, trans_date, amount  WHERE amount NOT = 0;	SELECT account_name, trans_date, amount  FROM TRANSACTION  WHERE amount > 0;

>>Oracle SQL Tuning - Tuning the views:

Don't forget to tune views. Views are SELECT statements and can be tuned in just the same way as any other type of SELECT statement can be. All tuning applicable to any SQL statement are equally applicable to views.

>>Oracle SQL Tuning - HAVING Clause:

Avoid including a HAVING clause in SELECT statements. The HAVING clause filters selected rows only after all rows have been fetched. Using a WHERE clause helps reduce overheads in sorting, summing, etc. HAVING clauses should only be used when columns with summary operations applied to them are restricted by the clause.

Using HAVING Clause	Not Using HAVING Clause
SELECT region, AVG (loc_size)  FROM location  GROUP BY region  HAVING region != ' SYDNEY '  AND region != ' PERTH ';	SELECT region, AVG (loc_size)  FROM location  WHERE region != ' SYDNEY '  AND region != ' PERTH ';  GROUP BY region;

>>Oracle SQL Tuning - Table Lookups:

Minimize the number of table lookups (subquery blocks) in queries, particularly if your statements include subquery SELECTs or multicolumn UPDATEs.

Separate Subqueries	Combined Subqueries
SELECT emp_name  FROM emp  WHERE emp_cat = ( SELECT MAX (category)  FROM emp_categories)  AND emp_range = ( SELECT MAX (sal_range)  FROM emp_categories)  AND emp_dept = 0020;	SELECT emp_name  FROM emp  WHERE (emp_cat, sal_range)  = ( SELECT MAX (category), MAX (sal_range)  FROM emp_categories)  AND emp_dept = 0020;

>>Oracle SQL Tuning - Multiple Table Joins:

Consider the alternatives like EXISTS, IN and table joins when doing multiple table joins. None of these are consistently faster; it depends on your data. If there is a poor performer here, it's likely the IN clause. This query returns the employee names from each department in department category 'A'.

EXISTS	IN	Table Joins
SELECT emp_name  FROM emp E  WHERE EXISTS (  SELECT 'X' FROM dept  WHERE dept_no = E.dept_no  AND dept_cat = 'A');	SELECT emp_name  FROM emp E  WHERE dept_no IN  ( SELECT dept_no FROM dept  WHERE dept_no = E.dept_no  AND dept_cat = 'A');	SELECT emp_name  FROM dept D, emp E  WHERE E.dept_no = D.dept_no  AND D.dept_cat = 'A';

>>Oracle SQL Tuning - DISTINCT vs. EXISTS:

Avoid joins that require the DISTINCT qualifier on the SELECT list in queries which are used to determine information at the owner end of a one-to-many relationship. The DISTINCT operator causes Oracle to fetch all rows satisfying the table join and then sort and filter out duplicate values. EXISTS is a faster alternative, because the Oracle optimizer realizes when the subquery has been satisfied once, there is no need to proceed further and the next matching row can be fetched. 
Below query returns all department numbers and names which have at least one employee.

SELECT DISTINCT dept_no, dept_name  FROM dept D,  emp E  WHERE D.dept_no = E.dept_no;    SELECT dept_no, dept_name  FROM dept D  WHERE EXISTS (  SELECT 'X'  FROM emp E  WHERE E.dept_no = D.dept_no);

>>Oracle SQL Tuning - UNION ALL:

Consider whether a UNION ALL will be adequate in place of a UNION . The UNION clause forces all rows returned by each portion of the UNION to be sorted and merged and duplicate to be filtered before the first row is returned. A UNION ALL simply returns all rows including duplicates and does not have to perform any sort, merge or filter. If your tables include no duplicate records, or you don't care if duplicates are returned, the UNION ALL is much more efficient.

UNION	UNION ALL
SELECT acct_num, balance_amt  FROM debit_transactions  WHERE tran_date = '31-DEC-95'  UNION  SELECT acct_num, balance_amt  FROM credit_transactions  WHERE tran_date = '31-DEC-95';	SELECT acct_num, balance_amt  FROM debit_transactions  WHERE tran_date = '31-DEC-95'  UNION ALL  SELECT acct_num, balance_amt  FROM credit_transactions  WHERE tran_date = '31-DEC-95';

>>Oracle SQL Tuning - DECODE:

Consider using DECODE to avoid having to scan the same rows repetitively or join the same table repetitively. DECODE is not necessarily faster as it depends on your data and the complexity of the resulting query. Also, using DECODE requires you to change your code when new values are allowed in the field.

SELECT COUNT (*)  FROM emp  WHERE status = 'Y'  AND emp_name LIKE 'SMITH%';

SELECT COUNT (*)  FROM emp  WHERE status = 'N'  AND emp_name LIKE 'SMITH%';  SELECT COUNT ( DECODE (status, 'Y', 'X', NULL ))Y_count,  COUNT ( DECODE (status, 'N', 'X', NULL )) N_count  FROM emp  WHERE emp_name LIKE 'SMITH%';

>>Oracle SQL Tuning - Casting:

Oracle automatically performs casting or simple column type conversions when it compares columns of different types. Depending on the type of conversion, indexes may not be used. Make sure you declare your program variables as the same type as your Oracle columns, if the type is supported in the programming language you are using.

Credit goes to the below website(s) :

http://askanantha.blogspot.com/2007/10/sql-tuning-guidelines-for-oracle-simple.html

Five Ninja Tips for Success

Be willing to fail. This also means when you do fail, learn from that experience. You’ve already made it over one of life’s hurdles – college. You will most likely enjoy many successes, but you need to know that you will also fail.

I’ve learned the most from my failures. Here is one example in my life. When I was a counselor at a sleep-away camp, I was fired because on my day off I violated a rule and brought beer onto the campgrounds. I will never forget my embarrassment and anger and the trip back with my father, who had to pick me up and take me home. In retrospect, I learned that actions have consequences, that it hurts to be fired and that my father was wonderful because he knew I was devastated and needed no further chastising. I failed, but I learned more from that experience than many of my successes.

What makes America different is that you can pick yourself up from failure and try again. Steve Jobs was fired from Apple and returned to transform the company and our lives. Many of history’s most respected figures – from George Washington and Abraham Lincoln to Henry Ford – failed countless times before they found success. Failure is part of life, so be prepared for that. Don’t be afraid of it. When it happens, don’t let it shatter you. Failure is how we learn about ourselves and about life. Think about that each time you fail.

Ask lots of questions. You will not get very far in your career – or in life – if you already know all the answers. Look for mentors. So many times I have seen young people start out thinking they can do it all on their own. Some of you might even be thinking you have to do it on your own. But you can’t, and you shouldn’t.

My very first mentors were my parents. They taught me the value of setting goals and hard work. Along the way I’ve had many more mentors, both inside and outside my industry. Their perspectives and strong examples have helped shape my approach on everything from how I run a meeting to how I structure my work-life balance.

Be passionate about learning. Just because you’ve finished college doesn’t mean you have nothing left to learn. A ninja innovator is always learning. That love of learning is the catalyst for innovation. It will help you stand out from the crowd, because you’ll have the knowledge you need to go into battle to achieve success.

Take risks. success requires doing battle, and doing battle requires taking risks. Some of the best and most innovative ideas in history have been the result of fearless leaders who took risks. Now, taking risks is not the same thing as being careless. Like World War II General George Patton said, “Take calculated risks.” Amazon CEO Jeff Bezos is a great example of a smart risk-taker. On a macro level, Bezos’ strategy for Amazon bucks public-company convention. He creates his own competition and forsakes immediate profits to invest in keeping his customers thrilled. His philosophy plays out on the micro level in services like Amazon Prime and products like the Kindle, both of which have turned out to be hugely popular and successful for Amazon.

The final ninja tip may surprise you: Don’t become a slave to your work. You will be better at your job if you have different interests outside of your job. Creativity itself is often the ability to find connections between unrelated things. You also need to take a step back, spend time with your family and loved ones, and do things you enjoy. Time spent away from work is crucial to success, because it allows you to focus on the things that matter most, and that gives you the energy you need to work hard and be successful.

Each of you can make a difference. You can make something happen. You will be our next innovators, our next leaders. Whatever career path you choose, keep these five tips in mind. Don’t be afraid to fail; look for mentors; keep on learning; take calculated risks; and make time to get away so you can always come back refreshed. 

11 Tips for Deploying ERP Applications

http://www.cio.com/article/733423/11_Tips_for_Deploying_ERP_Applications?page=3&taxonomyId=3000

Oracle Apps Concurrent program Output as Email

Using the below Unix SH file we can send the Concurrent program Output as Email.Please pass the request id of the Concurrent program and email address.

-------------------------------------------------------------------------------------

#!/bin/ksh
#################################
# Parameters
# 1 = echo "Start of the Program"
#################################
# File Name #
##############
REQUEST_ID=`echo $*awk '{print $9}' sed 's/"//g'`
REQUEST_ID=`eval "echo $REQUEST_ID"`
echo "Request Id= " ${REQUEST_ID}
###################
# Enail #
###################
mail_add=`echo $* awk '{print $10}' tr -d "`
echo "mail id : ${mail_add}"
req_file='${req_id}.out'
###################
# Data Directory #
###################
cd $APPLCSF/$APPLOUT
uuencode ${REQUEST_ID} ${REQUEST_ID} mailx -v -s"XXX Banks Accounts&PO expense Creation Out File" "$mail_add"

Oracle Employee Signing/Approval Limits

There is no API and other Method To Enter Signing Limits Metalink Note (171837.1)
The only option is direct insert in base table. :)

INSERT INTO ap_web_signing_limits_all
(document_type,
employee_id,
cost_center,
signing_limit,
last_update_date,
last_updated_by,
last_update_login,
creation_date,
created_by,
org_id
)
VALUES ('APEXP',
123,
r1.cost_centre,
l_sup_amt,
SYSDATE,
gl_user_id,
gl_login_id,
SYSDATE,
gl_user_id,
201
);

R12 Payment Process Request - Functional and Technical Information

Payment Process Requests
Overview
Under Funds disbursement page, users can submit Payment Process Requests (PPR) to generate payments. There is an option to submit a single Payment Process Request or schedule Payment Process Requests.
There are four steps in the processing of a PPR.
a) Document selection
b) Build Payments
c) Format Payments
d) Confirm Payments
Document selection and Confirm Payments are handled by Payables (AP) code while Build Payments and Format payments are handled by Payments (IBY) code.
Submitting a Single Payment Process Request
Mandatory Fields - Payment process request name, pay through date
Under Payment Attributes tab – Payment Date, Payment Exchange rate type.
Payment Process Profile and Disbursement bank account are optional fields.
Under Processing tab, options are available to stop the process after document selection / payment and also how to create Payment Instruction.
Under Validation Failure Results tab, choose option that best suits the business needs regarding how to handle validation failure on document(s) or payment(s).
Click on Submit to submit the Payment process request.
Document Selection – Payables
Code: AP_AUTOSELECT_PKG
When a Payment Process request is submitted, a record is created in AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name which is the same as the payment process request name.
Payment Profile and Internal Bank Account from which payments have to be made do not have to be specified during invoice selection. User who submits the PPR does not need know this information. These values can be provided by at a later stage by a Payments Manager or Administrator.
Selection:
Invoices are then selected based on due date, discount date, paygroup and other criteria provided by the user while submitting the PPR. The selection process is handled by the calling product
The table AP_SELECTED_INVOICES_ALL is populated with selected invoices.
AP_UNSELECTED_INVOICES_ALL is populated with unselected invoices.
Locking:
After selecting the documents, the invoices are locked to prevent other check runs from selecting the same invoices.
AP_PAYMENT_SCHEDULES_ALL.checkrun_id is populated on the selected documents.
Review:
If the Payment Process Request has been setup to ‘Stop Process for Review After Scheduled Payment Selection’, the process stops for user review. The status of the PPR is set to Invoices Pending Review.
If the ‘Stop Process for Review After Scheduled Payment Selection’ was not enabled, at the end of invoice selection, build program is submitted automatically.
If no invoices met the selection criteria and no payment schedules selected for payment, the PPR is cancelled automatically and the status of the PPR is set to “Cancelled - No Invoices Selected”
If user review required, after the user reviews the selected payment schedules and clicks on Submit, AP calls the IBYBUILD program.
Valid Statuses and actions
At the end of this step, the valid statuses are
a) Invoices Pending Review or
b) Cancelled - No Invoices Selected or
c) Other statuses from missing information such as Missing Exchange rates
If PPR status is Cancelled-No Invoices Selected, there are no valid actions available.
For others, the actions available are
a) Terminate the PPR or
b) Modify / proceed to submit the PPR and start the build process.
Build Payments - Payments
Code: IBY_DISBURSE_SUBMIT_PUB_PKG
Build Payments creates record in IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code = checkrun_name.
Primary Key: PAYMENT_SEVICE_REQUEST_ID
Key Columns:
CALL_AP_PAY_SERVICE_REQ_CODE -> PPR name
CALLING_APP_ID
PAYMENT_SERVICE_REQUEST_STATUS
INTERNAL_BANK_ACCOUNT_ID
MAXIMUM_PAYMENT_AMOUNT
MINIMUM_PAYMENT_AMOUNT
DOCUMENT_REJECTION_LEVEL_CODE
PAYMENT_REJECTION_LEVEL_CODE
REQUIRE_PROP_PMTS_REVIEW_FLAG
CREATE_PMT_INSTRUCTIONS_FLAG
Note: The displayed status of the PPR is generated by ibyvutlb.pls
There is a get_psr_status function that derives the display sttaus of the PPR on the dashboard.
Some of the values for PAYMENT_SERVICE_REQUEST_STATUS in the table are
PAYMENT_SERVICE_REQUEST_STATUS
------------------------------
DOCUMENTS_VALIDATED
INFORMATION_REQUIRED
INSERTED
PAYMENTS_CREATED
PENDING_REVIEW
TERMINATED
VALIDATION_FAILED
The build program populates the IBY_DOCS_PAYABLE_ALL table with the payments. Link to the payment service request table is through PAYMENT_SERVICE_REQUEST_ID.
Key Columns:
Payment_service_request_id
Calling_app_doc_ref_number -> invoice_number
Document_payable_id
Document_status
Payment_currency_code
Payment_amount
Document_amount
Exclusive_payment_flag
Payment_method_code
Payment_id
Formatting_payment_id
Ext_payee_id
Payee_party_id
Payment_profile_id
Internal_bank_account_id
Calling_app_doc_unique_ref2 -> invoice_id
Calling_app_doc_unique_ref3 -> payment number

a) Internal Bank Account/Payment Process Profile Assignment:
Code: IBY_ASSIGN_PUB
If the payment process request has the internal bank account and payment profile assigned to it, the same is assigned to all the documents in the PPR.
If a default internal bank account and PPP were not provided when submitting the PPR, Oracle Payments attempts to default the values. If it cannot find a default value for all the documents, the PPR is set to INFORMATION REQUIRED status. The display status of the PPR is “Information Required - Pending Action”
User should complete the missing information and Run Payment Process to continue.
b) Document Validation
Code: IBY_VALIDATIONSETS_PUB
During this step, Oracle Payments validates all the documents using Payment Method based validations and then payment format based validations..
b.1 - If all the documents pass validation, all the documents are set to a status of VALIDATED and the request status is set to ‘Documents Validated’.
b.2 – If there are any validation failures, Oracle Payments uses the system option used while submitting the PPR to determine the next action.
The DOCUMENT_REJECTION_LEVEL_CODE of the PPR can have the following values which determine how the document processing will continue when there is a validation failure
REQUEST - Reject all documents in this PPR
DOCUMENT - Reject only the document in error
PAYEE - Reject all the documents related to the supplier
NONE - Stop the request for review
b.2.1 – REQUEST
The status of the payment process request is updated to ‘Failed Document Validation’. Oracle Payments calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request.
b.2.2 – DOCUMENT
Oracle Payments rejects all documents that failed validation. Oracle Payments then calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. The rest of the documents are set to VALIDATED status and the ppr is set to ‘Documents Validated’ status.
b.2.3 – PAYEE
Oracle Payments rejects all documents for the supplier that had one or more documents that failed validation. Oracle Payments calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. The rest of the documents are set to VALIDATED status and the ppr is set to ‘Documents Validated’ status.
c) Create Payments
Code: IBY_PAYGROUP_PUB
The validated documents are then grouped into proposed payments based on the grouping rules, both user defined and hard coded.
Example: If exclusive_payment_flag = Y on a document, its paid on a separate payment.
It then numbers the payments (internal identifier not the check numbering) and validates the created payments.
Records are inserted into IBY_PAYMENTS_ALL that holds the payment information for the selected documents.
The build program then updates the IBY_DOCS_PAYABLE_ALL table with the payment_id and formatting_payment_id values that corresponding to the payment that pays the document.
IBY_PAYMENTS_ALL links through payment_service_request_id.
Key Columns:
Payment_service_request_id
Payment_id
Payment_method_code
Payment_status
Payments_complete_flag
Payment_amount,
Dicount_amount_taken
Internal_bank_Account_id
Ext_payee_id
Payment_instruction_id
Payment_profile_id
Void_date
The PAYMENT_REJECTION_LEVEL_CODE can have the following values which determine how the payment processing will continue when there is a validation failure
REQUEST – Reject all payments in the request
PAYMENT – Reject only those payments in error
NONE – Stop the request for review
Request – Entire PPR is rejected. Oracle Payments raises a business event that calls AP to release the documents. The status of the payment process request and proposed payments is updated to ‘REJECTED’.
Payment – Payments that failed validation are rejected and AP releases the documents that belong to the payment that failed validation. The other payments are accepted. The accepted payments get a status of ‘CREATED’.
None – Payments that failed Validation are set to ‘Failed Validation’ and allows for user intervention. Status of the PPR is set to ‘PENDING REVIEW’
If in the PPR setup, ‘Stop Process for Review After Creation of Proposed Payments’ is enabled, the PPR status is set to ‘Pending Proposed Payment Review’. This status prevents further processing until user takes action. If this option to stop for review is not enabled, the status of the PPR is set to ‘Payments Created’. In this status, payment instruction can be created for the PPR.
Format Payments - Payments
Code: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB
When a PPR is submitted, there are two options
The CREATE_PMT_INSTRUCTIONS_FLAG can be a Y or N
Y – Payment Instruction will be automatically created after payments are created.
N – Application waits for standard request submission for Payment Instruction.
IBY_PAYMENT_INSTRUCTIONS_ALL stores the payment instruction information.
If the PPR is setup to automatically submit instruction, the payment_service_request_id will be populated in iby_payment_instructions_all because the instruction will be specific to the PPR In this case, the instruction can be linked to the PPR using PAYMENT_SERVICE_REQUEST_ID
If the PPR processing is setup for the user to submit the instruction as a standard request, then when the instruction is submitted, then the instruction is linked to the PPR through the payments selected by the instruction.
The link in this case will be through iby_payments_all.payment_instruction_id

Key Columns in IBY_PAYMENT_INSTRUCTIONS_ALL
Payment_instruction_id
Payment_profile_id
Payment_instruction_status
Payments_complete_code
Payment_count
Print_instruction_immed_flag
Transmit_instr_immed_flag
Internal_bank_account_id
Payment_document_id
Payment_date
Payment_reason_code
Payment_currency_code
Format:
The following processing occurs during the format step.
a) Number the payments – Check Numbering
b) Create XML Extract message
c) Pass the extract to XML publisher
d) Oracle XML Publisher (BI publisher) applies the format template
e) BI publisher formats and stores the output
f) Oracle Payments then updates the status of the Payment Instruction and the Payments. If successful, the status of Payments and Instruction is ‘Formatted’.
Print Checks:
a) Users can load stationery into the printer and print checks at this stage.
b) Determine if the checks printed ok. If not reprint
Confirm Payments - Payables
Code: AP_PMT_CALLOUT_PKG
Record Print Status of the checks to confirm the payments. Oracle Payments calls ap_pmt_callout_pkg.payment_completed to confirm the payments.
This does the following:
a) Assigns sequence/values – Document sequencing.
b) Creates data in AP_CHECKS_ALL with appropriate data from IBY tables.
Checkrun_name = ppr name and checkrun_id = checkrun_id from IBY table.
c) Data inserted into AP_INVOICE_PAYMENTS_ALL for the corresponding checks.
d) AP_PAYMENT_SCHEDULES_ALL for the invoices are updated to indicate the payment details and status.
e) The documents paid in this PPR are released by setting the checkrun_id on the payment schedules to null.
f) AP_INVOICES_ALL is udpated to show payment status
g) Data is deleted from the AP_SELECTED_INVOICES_ALL
h) Data is deleted from AP_UNSELECTED_INVOICES_ALL