Fundamental of Data and so called Big Data

The hot topic that seems to be around every corner these days is “Big Data”.   Most publications work under the premise that everyone already understands Big Data and the value it can bring to the organization.  My experience shows that assumption is not always correct.  Many folks are unclear how to recognize “Big Data” within their particular organizations.  More importantly, folks may not understand the possible business value that can be extracted from it. Without both aspects of understanding, adoption and success of Big Data initiatives will face difficulties.  This blog addresses those two aspects by identifying:

a) Typical “Big Data” examples within organizations

b) Real-world value propositions from harvesting “Big Data”

Simple Definition and Context

Let’s start with establishing a definition and context for “Big Data” since the name alone can be misleading.  Big Data is a reference to the very large scale of data available or being created that cannot be easily handled using traditional processing, methodologies or technologies.  Big Data can relate to structured or unstructured data.  The challenges with Big Data can include how to capture it, the methods for storing it, how to understand it, how to analyze it, how to search it, or how to visualize it and correlate it to something familiar.  Data can be tagged as “Big Data” by evaluating it against the above classifications and by considering at least two factors:

1) The scale and sheer volume of the data in comparison to what is reasonably expected

2) The speed at which it is created or is expected to grow

Since there is a lot of subjectivity in defining “Big Data”, let’s list some real-world examples to solidify the understanding.

Big Data within Organizations

Using the definition above as guidance, a growing number of possible examples may belong in the “Big Data” category. For the sake of being concise, the following represent the types of “Big Data” organizations commonly encounter and the value that can be derived from them.

Call & Contact Details

Definition

Value Proposition

Organizations that offer products and services directly to consumers will have significant call center operations with several platforms to support various methods of customer interaction and engagement.  With each interaction comes information that collectively can be significant in quantity.   While organizations have used some of this data for operational support, many have struggled with maximizing the analytical value.

Re-allocation of agents across centers and queues based on predictive demand planning using diverse criteria.  Improve efficiency on agent utilization and load balancing of resources; enhance customer experience by reducing wait time and abandon rates. Analytics against voice data for accurate tagging of reasons for call, reasons for transfers, etc.  Optimizes understanding of customer satisfaction & response levels and improves call routing. Mining of call characteristics (length, number, source, type, reason) to create stronger correlations for better insight Correlations of contact metrics to recent marketing efforts to measure effectiveness and acceptance. Creating correlations between account/customer details to offers made/accepted to increase upselling & cross-selling opportunities

Transaction Details

Definition

Value Proposition

Industries including financial firms, trading firms and large retailers surmount a continuous stream of transactional detail.  This can include authorization details, trade transactions, and purchases.  Most organizations deal with this vast amount of data by limiting the amount of detail data used during analysis or applying standard practices to summarize and aggregate for business intelligence.

Fraud detection techniques using transactions well beyond individual events; longer time spans, more criteria, un-related events.  Leads to improved risk exposure management. Trending of activity across various time periods to recognize patterns of behavior.  Effective for identifying revenue opportunity or measuring strategy effectiveness. Developing correlations between transactions and customer/account details (demographics, purchase history) to improve marketing strategies. Correlations of transactions to external factors (marketing offers, news events, regional criteria) to understand behavior and measure marketing effectiveness. Analyzing transactions using broad criteria across extensive time periods to improve forecasting accuracy.

Web Clicks & Logs

Definition

Value Proposition

Analyzing details of customers with similar interests and behavioral patterns to maximize the effectiveness of offers made to individual customers.  Will improve and extend sales.Customers and prospects visiting the organization’s web sites have their own distinct behaviors and patterns.  What they click, what they click next, what peaks their current interest, what peaks the interest of other visitors at this same moment are examples of behavior patterns that are valuable to better understand.  Furthermore, each visit brings other interesting criteria such as originating source for visit, geographical tags, SEO tags, etc.   Only a handful of companies are recognizing the strategic value in this treasure chest of information.

Correlating product sales to one another to understand buying patterns, i.e., what other products are bought along with a given product.  Improve offers and up-selling opportunities. Analyzing regional considerations for customers during a given experience to optimize target marketing and ensure relevance of offers. Analyzing click and navigational patterns to improve customer experience, i.e., offer online chat or display tips to improve “stickiness” and overall experience. Correlate traffic, interest and behavior to external factors including media efforts, regional criteria to measure strategy effectiveness.

Other interesting Big Data examples you may encounter include:

Application Logs

Informational, warning, error, monitoring and event messages are continuously produced by software systems, hardware devices and application platforms.  Proactively recognizing potential issues from the patterns can help improve the quality of service and reliability that the IT groups need to ensure.  Furthermore, it can be an element of a good risk mitigation strategy if the services and platforms are a critical part of your business.  This content is often overlooked for the value it possesses.

Social Media

Tweets, Facebook and Google+ posts, blogs & responses have quickly become acceptable means of social interaction between people.  The sheer number of people using these channels creates a “Big Data” problem.  The data and growth is exceptionally large to deal with. The content is text-based and needs to be evaluated in context to derive at the right interpretation. Furthermore the relevance of the content (eliminating noise) is difficult to decipher.  The jury is still in deliberation over the ROI for harvesting this information.  Nonetheless, it’s difficult to ignore.

GPS Trace Records

Equipment, products and personnel are increasingly fitted with GPS technologies that can track every move from point A to point B.  The ability to proactively analyze this movement can lead to supply chain efficiencies, human capital effectiveness, bottom-line cost reduction, fraud mitigation and allow for overall control and continuous visibility.

Technology & Instrument Output

Needless to say, there are countless unique examples within industries.  Utility and communication companies produce incredible amounts of usage details that can be used to manage demand and optimize performance.  Genomics and scientific organizations are deploying technologies producing ever granular bits of potentially important information.

Documents & Other Unstructured Data

Virtually every organization produces an immense amount of unstructured data, or in other words information that does not easily conform to a defined data model.    This can include internal documentation, publications, correspondences, health records, audio recordings, etc.  Not only is this a content management problem but it also requires unique analytical techniques to harvest value from the content.  Increase the scale of it and it now becomes a Big Data challenge.  Businesses can use this data for ensuring compliance, managing risk and achieving more complete records.

Many more organizations will have “Big Data” challenges over the coming years. Some of this can be attributed to their individual growth as a company but much of it is the result of technology advances and outside factors.   It is safe to conclude that all organizations with Big Data will need to take some action to do something valuable with it, at least to remain competitive.

In future blogs I will talk in more specifics about individual approaches, technologies and business application around Big Data.  In the meantime, please feel free to comment below or reach out to me to talk about “Big Data” challenges you are facing.

So why do successful IT implementations fail to achieve desired results?

So why do successful IT implementations fail to achieve desired results?

Answer in almost all cases is lack of user adoption.  I know we have heard it before but humans in general are creatures of habit.  Once we are comfortable with a method – no matter how cumbersome it is – we like to stick with it. We build our comfort zone around it and resist any effort to change it.  Your IT team can implement the nirvana system that solves all problems, but it will never gain the desired results if end-users don’t buy into it.  The IT team needs to be both sales and marketing to get it. In reality, most IT projects focus heavily on the “technical” and completely miss the “human factor”.  Oh, and the sales and marketing process doesn’t start at your launch party. Your end users need to be sold on the change before the project is even started.  So put on your marketing and sales hat and get started.

Keep these 5 things in mind before you launch your next IT project:

1. Business Requirements: Business requirements come from business users, not IT. Sounds obvious but not always practiced. Usually the project team in all sincerity tries to address business problems without consulting the business users, involving them too late in the process, way after the technology/tool selection occurs. For a successful implementation, it is important that the users whose pain you are working to resolve are involved in defining the scope of the project.

2. The right tool for the job: A lot of time, the tool or technology is selected before the problem is completely defined.  This is a recipe for disaster. You should not base your business needs around a tool’s capabilities. It should be chosen in response to your business needs. Sometimes- this will lead to a combination of various tools and technologies to get to the right solution.

3. Focus Groups: Once you have good understanding of business requirements and have decided on the technology, don’t try to solve everything at once. A phased approach is best to get buy in. Start with a small  group of end users and walk them through the complete life cycle of the project. Get this group comfortable with the solution and you will now have end-user champions that will serve as an extended team to help promote within the organization.

4. Training and Rollout: Before you open the system for end users, make sure that you have proper training materials and a training schedule in place. Proper training is a must for successful end-user adoption. As I said earlier, people resist abrupt change. Make sure that your new implementation eases into their daily routine. End users will then realize the true value of the system and the problem it solves. Change will gradually occur.

5. BICC: Last but not least, is the implementation of proper processes and procedures. You should think about developing a BICC (Business Intelligence Competency Center). A BICC is comprised of members from both IT and business users. The days of IT producing data and end-users consuming it are gone.  Now with fourth generation reporting tools like Oracle’s OBIEE, your data consumers are self enabled to access the information themselves when needed. This behooves us to make sure that the information that is being accessed is accurate and readily available. The BICC ensures that the right personnel are involved in the development, distribution and consumption of information in your organization.

Of course, there are many more factors involved in making sure the implementation of an IT project is successful, but following the above mentioned best practices will ensure that your IT project will result in a successfully utilized business solution.  Stay tuned for more on this topic!

Art of BI RD

Eliciting and creating requirements for an OBIEE project is a very important step in creating a successful, pervasive OBIEE system in an organization.

Throughout the requirements elicitation and creation process, you need to keep in mind that all requirements must be testable.  The only way to verify if a requirement has been met is to successfully test it, and therefore, all requirements must be specific and detailed enough to allow for a QA person to verify it.

A huge and essential component of OBIEE projects is the reports being delivered in one form or another – and therefore, another set of characteristics to keep in mind are that the reports and their form of delivery need to be: accurate, relevant, timely, and actionable.

Typically an OBIEE project involves significant effort, and can take several months to complete, but visible progress can be made in a shorter time.  Requirements may need to be prioritized to handle the most critical ones first (a phase 1 for example), and postpone some for later in the project – a phase 2 for example.  However, it should not take months to see some results, because OBIEE is a great platform for an agile methodology – allowing the project to show some results early and ongoing, as the project becomes more and more completed.

To elicit requirements, there are a number of methods that can be used.  You will need to choose the most appropriate method based on the particular scenario – who is the user, what area does the requirements cover, etc.  Some of the methods used can include: interviews, observation, reviewing existing reports (from a previous system for example); soliciting information from colleagues in other companies; and developing/showing report concepts and getting feedback; brainstorming – from strategic goals and reporting needs to tactical/operational.  However, you should try to learn as much as possible about the business, processes and people beforehand; and always try to be a good listener.

Requirements for an OBIEE project can be grouped into the following groups of questions:

What information does the business users need to see? 

This is often driven by the company’s strategic goals. The data needs to be in aid of answering business questions that users will need to aid their decision making in order to realize operational and tactical goals that support the strategic goals.

The information could be enterprise wide, departmental, or specific subject matter.

The reporting requirements could also be classified as strategic, tactical, or operational.  The strategic requirements are usually enterprise wide, while the tactical and operational requirements are usually relevant to a departmental, group or individual role.  Strategic requirements can at times be monitored and tracked via Key Performance Indicators (KPIs) which can be developed and presented in OBIEE.  Operational requirements at times will need Agents or iBots that trigger some action based on an event.  And tactical requirements are usually satisfied using reports that display valuable metrics about the business operations.

What are your business objectives and what metrics will help you to monitor progress toward those objectives?  What information do you wish you had to do your job better?

Where will the data be sourced from?  In other words, what are the source systems?

The answer to this question could include Data warehouses or data marts, ERP systems, Line of Business systems (LOBs), Flat files, External sources, OLTP, OLAP, etc.

The data sources need to be defined in the OBIEE BI Repository (RPD) via Connection Pools, and the metadata for the relevant tables imported.  OBIEE data sources can be relational (OLTP), multi-dimensional (OLAP) or files (Excel, XML, ADF).  The OLAP data sources supported by OBIEE are Oracle Essbase, Oracle OLAP, Microsoft SQL Server Analysis Services, and SAP BW.

However, for better performance, it is best if the data sources are multi-dimensional – either star-schema relational or OLAP.

What data is required from those systems?  And what data needs to be calculated or derived?

Analysis needs to be done to determine what subset of data (if not all) is needed from each of the source systems. What measures, dimensions, hierarchies, and attributes are required? What lookup tables are required?

And it’s always a good idea to ask “Why?”  Why is this data needed?  How will it be used?

This involves reports, and it is important to keep in mind that all report/reporting data need to be accurate, relevant, timely, and actionable.

What data that is not in the source system but can be derived? Calculations, Associations, mappings, etc – these derived items can be created in the OBIEE repository BMM layer, and exposed to users as necessary.

What granularity of data is needed?  Summary, Detail, both

What time range (including the time granularity) of data is needed?  Historical, Current, Real-time, Day, Month, Quarter, Year

What KPI’s are required to track the state of the business?

What data needs to be filtered out/in from each data source tables in the various scenarios?

What are some of the frequently used filter criteria?  à this could drive some of the repository variables created in OBIEE

What are some frequently used values for analysis?  à this could drive dashboard prompts in OBIEE

Will the business users need to perform data mining or need the results of data mining?

How frequently does the data need to be updated?

If the data is not directly connected to the source, then how often should the data be updated – real-time, hourly, daily, weekly, monthly, on-demand, etc?

Who needs to see what data?  And who needs access to what functionality?

This is in essence a security question.  What are the various groups/roles that need access to data, and what data should each group/role have access to?

Can the reporting system be integrated with the company’s existing LDAP? This is typically the case for most modern reporting systems including OBIEE which integrates with popular LDAP systems including Active Directory.

Does row-level security need to be implemented?  OBIEE allows for row-level security.

Can all users use all features of the reporting platform?  Or will only specific users be granted access to specific functionality?

What dashboards and reports will each group of users be able to see?

How will the information be shared with business users?  What modes of information delivery need to be used?

Will reports be shared?  email, saved to a directory, web dashboard, file (pdf, word, excel, html)?

Do users need to be proactively notified of events? – for example, a user or group needs to be notified if stock levels fall below a threshold.

The answers to this question will drive the Agents/iBots that need to be created.

Will the reports be run on a predefined schedule or based on some predefined condition?  Or will they be run on-demand?  This will also drive Agents/iBots and Conditions.

Do users need to download information?  This will drive the ‘report links’ that are placed on the dashboard pages.

Do report results need to be preserved or can/should they be overwritten?

Will users be allowed to create their own analyses or perform adhoc analysis? And if yes, how will that activity be monitored and supported?

What visualization features are required for each report or set of data?  Dashboards, Scorecards, Charts, graphs, tables, pivots, gauges, icons, colors, fonts, etc.

Will the users need to be able to drill from summary to detail reports?  Rollup from detail to summary?

Will the users be able to interact with the data?  Prompts, View Selectors, Column Selectors, etc

What are some of the system level requirements?

What level of system performance is required?

Dashboard and report creation tools

Does the reporting system need to be able to access/connect to multiple data sources at a time?  OBIEE allows for multiple data sources connected at the same time.
Does the reporting system need to be able to access/connect to relational, multi-dimensional, and file data sources?

Does the reporting system need data mining capabilities?

Does the system need to support drill-down, rollup functionality?

What are the critical usage times for the system?  In other words, what are times when the system must be available? For example, during the month-end close process or during the holiday sales season.  This will drive when changes can be made to the system.

What are the highest usage times for the system?  What hardware do we need to support that usage?

How will changes be handled? In other words, what is the change control process?

It is very important that all the relevant players are included in the requirements process – business leaders and business users, SMEs, technical staff, database administrators, OBIEE Developers (report developers, rpd developers), OBIEE architect, ETL developers, ETL architect.  Before development officially starts, it is important to get all relevant sign-offs on the requirements.  This will ensure that everyone is on the same page, and that the business users are getting what they need.

R12: Master Troubleshooting Guide for vendor Payment for Oracle Payables

1. What is a Payment Process Request (PPR), and How Are PPRs Created and Managed?

What is a PPR?

Ans) In R12, a Payment Process Request, or "PPR", is a payment batch. ThePayment Batch entry form used in R11i has been replaced in R12 by a new module called the Payments Manager module (IBY), which offers a number of new features related to payment batch processing.

How is a new PPR submitted?

Ans) Using the Submit a Single Request link on the Payments ManagerDashboard (or the button on theSearch PPRs window), users are taken to a PPR entry form made up of a header and several tabbed regions. Users can enter search criteria for the invoices they want to pay, and parameters surrounding the payment process itself using the fields on the tabbed regions.

Modifying Payment Process Requests

You can modify the batch of invoices that the system selected for you, and the proposed payments generated by the system, using "review" windows along the course of the PPR process. These review "stops" are optional. When creating a new PPR, you can set parameters on the Processing tab that will cause the PPR process to stop after: 1) the system initially selects the invoices to be paid by the batch, and/or 2) after the PPR process has compiled the "proposed payments". This gives you an opportunity to review (and if necessary, modify) the invoices and "proposed" payments before they are turned into formatted Payment Instructions.

Terminating Payment Instructions

You can terminate a set of Payment Instructions at any time prior to marking the payments "Complete" - even if they have been printed - by using the Terminateicon on the Payment Instructions tab on the Payments Manager Dashboard. When this action is taken, Oracle Payments sets the status of the payment instruction to "Terminated", and informs the source product of the terminated documents payable. Then for each payment in the payment instruction, Oracle Payments sets the status to "Canceled". The source product unlocks the documents and resets their status so they are ready for future selection.

Stopping & Voiding Completed Payments

You can record a "Stop Payment" action or a "Void" action on one or more completed payments using thePayments tab on the Payments ManagerDashboard.

PPR Templates

To make entry of a new single PPR faster and easier, you can create a PPR"Template" with the search criteria and parameters that you typically use on your PPRs. Then when creating a new PPR, simply enter the name of the template in the header, and the pre-defined settings on the template are automatically copied to the fields on the header of your new PPR for you! You can accept the defaulted values, or edit them for the new PPR.

Scheduling PPRs using PPR Templates

You can use the name of a PPR Template as the Request Name on theSchedule Payment Process Requestform in the Payments Manager module, allowing users to schedule PPRs to run automatically on a periodic basis, such as once/multiple times a day, once/multiple times a week, once/multiple times a month, etc. The scheduling parameters are generally the same as for scheduling Oracle Reports or other processes.

Required Setups

To maximize all the features available in creating Payment Process Requests (and to minimize the possibility of issues), you will want to become familiar with both the required and recommended setups that are necessary before running your first PPR. Some setups in the Payments module (IBY) are common to both theFunds Capture (receipts) and the Funds Disbursement (payments) roles that the module provides. They include:

aAccess control

APIs

servlets

transmission

security

Configurable setups include:

Payment Methods

Bank Instruction Codes

Delivery Channel Codes

Payment Reason Codes

Payment Process Profiles ("PPPs")

Disbursement System Options

Payment Formats

XML Publisher Payment Templates

Internal Banks, Branches, and Bank Accounts

Suppliers

External Bank Account

• "Skipped" and "Spoiled" Check Numbers
• Skipped Check Numbers: If you use pre-numbered paper check stock when running a Payment Process Request ("PPR") in R12, you may have experienced a common issue faced by most Payment Administrators -- skipped checks during the printing process (most often when the batch was printed using a laser printer). That is, one or more unused checks get "stuck" to the check above it in the feeder bin, and slip through the printing process unprinted. When that happens, the check numbers that were actually printed and the check numbers that appear on the related payment reports are no longer in-sync with one another. It's important that the system is informed of these "skipped" check numbers as soon as possible so your reports will reflect appropriate check numbers, and the Last Issued Document Numberfield on the Define/Update Payment Documents window for the associated Bank Account is properly updated as well. Use the Skipped Payment Documents region on the Record Print Status window to manually enter the skipped check numbers before you confirm the PPR.Spoiled Check Numbers: Another common issue that Payment Administrators often face is the dreaded "spoiled" check during a printing process. A "spoiled" check is when your printer "eats up" (physically destroys) a payment document as it goes through the printing process -- usually causing the printer to stop until you remove the mangled document, and re-start the printer. "Spoiled" checks can actually be defined as ANY unuseable paper payment documents (checks) that have become unuseable for ANY reason (for instance, perhaps one of your boxes of unused checks was destroyed due to a flood or fire). So printer jams aren't the only cause for "spoiled" checks -- but they are the most common. It's important that the system is informed of these "spoiled" check numbers as soon as possible, so your reports will reflect appropriate check numbers, and the Last Issued Document Number field on theDefine/Update Payment Documents is properly updated as well. Spoiled checks can be marked as "spoiled" in Oracle by either: 1) reprinting a replacement check for the supplier/creditor in the same PPR before confirming the PPR, or 2) manually marking the check number as "spoiled" on the Spoiled Payment Documents region of the Record Print Statuswindow, and then paying the supplier/creditor on a later PPR or Quick Payment.
• 2. How does the PPR Process work? Once the user has entered their desired parameters on the header of the PPR, and clicks on theSubmit button, the PPR process follows the following four (4) program steps:
  DOCUMENT SELECTION ("AUTOSELECT")
  (Code: AP_AUTOSELECT_PKG): The Selection process is handled by Payables (AP), the calling product.
  When a PPR is submitted, a record is created in AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name, which is the same as the PPR Name.

Selection: Invoices are then selected based on Due Date, Discount Date, Pay Group, and other criteria provided by the user while completing the PPR header.

The table AP_SELECTED_INVOICES_ALL is populated with selected invoices.

The table AP_UNSELECTED_INVOICES_ALL is populated with the invoices that were not selected.

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 (invoices).

Review:If the PPR has been setup to Stop Process for Review After Schedule Payment Selection (option available on the header of the PPR), the process stops for user review after the initial selection of payables documents has been completed. The status of the PPR is set to "Invoices Pending Review". After the user reviews and/or modifies the selected documents, and clicks on the Submitbutton, AP calls the IBYBUILD program.

If the Stop Process for Review After Schedule Payment Selectionparameter was not enabled, then at the end of invoice selection, the Build program is submitted automatically.

If no invoices met the selection criteria, the PPR is canceled automatically and the status of the PPR is set to "Canceled - No Invoices Selected".

BUILD PAYMENTS

(Code: IBY_DISBURSE_SUBMIT_PUB_PKG): The Build Payments process is handled by Oracle Payments (IBY).

The Build Payments program first creates a record in IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code = checkrun_name.

The Build Payments program goes on to populate the IBY_DOCS_PAYABLE_ALL table with the proposed payments.

The link to the payment service request table is through the PAYMENT_SERVICE_REQUEST_ID.

Internal Bank Account / Payment Process Profile Assignment(Code: IBY_ASSIGN_PUB): If the PPR has a default internal bank account and Payment Process Profile (PPP) assigned to it on the header of the PPR, the values are assigned to all of the selected documents in the PPR.

If a default internal bank account and PPP were not provided by the user on the header of the PPR, Oracle Payments attempts to default the values. If it cannot find a default value for all of the selected documents, the PPR status is set to "INFORMATION REQUIRED". The user display shows it as "Information Required - Pending Action". The user will need to use the Information Required window to provide the missing internal bank account(s) and PPP(s) for each selected document.

Document Validation (Code: IBY_VALIDATIONSETS_PUB): During this step, Oracle Payments validates all the documents (selected invoices & memos) using Pre-Defined and User-Defined Validations assigned to Payment Methods assigned to the selected documents. Afterward, the program validates all the documents again, using the Pre-Defined and User-Defined Validations assigned to Payment Formats associated with the PPPs specified on the PPR.

If all the documents pass validation, all the documents are set to a status of VALIDATED in the tables and the request status is displayed as "Documents Validated".

If there any document validation failures, Oracle Payments uses the parameter setting for "Documents" on the Validation Failure Results tab on the PPR header (the DOCUMENT_REJECTION_LEVEL_CODE) to determine the next action.

• 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 PPR for review

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. It then numbers the proposed payments with an internal identifier (not "the" check number) and validates the payments.

Records are inserted into IBY_PAYMENTS_ALL that holds the payment information for the selected documents (invoices). The Build Payments program then updates the IBY_DOCS_PAYABLE_ALL table with the payment_id and formatting_payment_id values of the payment associated with each document.

If there any payment validation failures, Oracle Payments uses the parameter setting for "Payments" on the Validation Failure Results tab on the PPR header (the PAYMENT_REJECTION_LEVEL_CODE) to determine the next action.

• 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 PPR for review

If the PPR setup Stop Process for Review After Creation of Proposed Payments is enabled on the Process tab of the PPR header, the displayed PPR status is set to "Pending Proposed Payment Review". This status prevents further processing until user takes action.

If this option to stop for a review is not enabled, the displayed status of the PPR is set to "Payments Created". In this status, payment instructions can be created for the PPR.

FORMAT PAYMENTS

(Codes: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB): The Format Payments process is handled by Oracle Payments (IBY).
When a PPR is submitted, the program checks the setting for the Create Payment Instructions parameter on the Process tab of the PPR header to determine if the associated payment instruction(s) (PI) should be created automatically after the payments are created (the CREATE_PMT_INSTRUCTIONS_FLAG = Y), or if the program is to wait for a manual kick-off of the Format Payment Instructions program through the Standard Request Submission form (SRS) (the CREATE_PMT_INSTRUCTIONS_FLAG = N).

If the PPR is set up to automatically submit instruction(s), 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(s) can be linked to the PPR using PAYMENT_SERVICE_REQUEST_ID.

If the PPR is set up for the user to submit the instruction program manually on the SRS form, then when the instruction(s) is submitted, the instruction(s) is linked to the PPR through the payments selected by the instruction(s). The link in this case will be through the payment_instruction_id in IBY_PAYMENTS_ALL.

In addition, the following processing occurs during the Format Payments step (see The Extract and Format Operation Flow section in Note 1348102.1 "R12: Master Troubleshooting Guide for Oracle Payables Payment Formats & associated XML Publisher Templates"):

Number the payments (paper checks and possibly, electronic payments)

Create XML extracted message

Pass the extract to Oracle XML Publisher (also known as "BI Publisher")

XML Publisher applies the formatted template to the payments

XML Publisher formats and stores the output

Oracle Payments then updates the status of the Payment Instruction(s) and the PPR. If successful, the displayed status of the PPR is "Formatted", and the status of the Payment Instruction(s) will be "Formatted" for electronic payments and "Formatted - Ready for Printing" for check payments

Print checks:

Users can load stationery into the printer and print checks at this stage by clicking on the Take Action icon for the related Payment Instruction on the Search PPRs window.

Determine if the checks printed OK, and if so, click on the Take Action icon again to be taken to the "Record Print Status" window, and click on the Record Print Status button. If there were problems with the printing process (paper jams, skipped checks, etc.) -- especially if you are using pre-numbered check stock -- use the Reprint button to reprint the batch and record any spoiled (ruined) and/or skipped check numbers.

Transmit electronic payments:

Electronic payments can be transmitted at this point.

CONFIRM PAYMENTS

(Code: AP_PMT_CALLOUT_PKG): The Selection process is handled by Payables (AP).

In order to confirm the printing of paper checks, the user needs to use the Record Print Status window to confirm which pre-numbered paper stock printed OK, and which (if any) were skipped or were damaged beyond repair ("spoiled").

Oracle Payments calls ap_pmt_callout_pkg.payment_completed to confirm the payments. During this step, the program does the following:

Assigns sequence values for Document Sequencing (Vouchering).

Creates data in the AP_CHECKS_ALL table with the appropriate data from the IBY tables.

Inserts data into the AP_INVOICE_PAYMENTS_ALL table for the corresponding checks.

The documents (invoices) are updated in the AP_PAYMENT_SCHEDULES_ALL table to indicate in the Invoices Workbench the payment details and status.

The documents not paid in this PPR are released by setting the checkrun_id on the Payment Schedules to NULL.

The AP_INVOICES_ALL table is updated to show the payment status in the Invoices Workbench for those documents that were paid by the PPR.

Data for this PPR is deleted from the AP_SELECTED_INVOICES_ALL table.

Data for this PPR is deleted from the AP_UNSELECTED_INVOICES_ALL table.

"Completing" Electronic Payments: Electronic payments are not "confirmed" in the same way that paper documents are handled. The system will automatically mark electronic payments as "completed" based on the setting you chose for the "Completion Point" field on the header of the associated Payment Process Profile (PPP):

"Built" = the payments will be marked as "complete" when the Build process completes

"Payment Instruction is Created" = the payments will be marked as "complete" when the PI is created

Payment Instruction is Formatted" = the payments will be marked as "complete" when the PI has successfully completed the Formatting process

"Payment Instruction is Transmitted" = the payments will be marked as "complete" when they are transmitted"

3. PPR Reports: There are several reports related to PPR processing

Payment Process Request Status Report: The Payment Process Request Status Report is a report that you can run that displays proposed payment information. You can request the report to run automatically after proposed payments have been created and validated or run the report by standard report submission. The report provides parameters, such as the Payment Process Request name/identifier and runs if the Payment Process Request status is "Payments Created".

Payment Instruction Register: Once a payment instruction has been formatted, payments within that payment instruction can be reviewed in report format. The Payment Instruction Register can be run at any time after payment instruction creation. The report lists the various statuses of payments within the payment instructions, such as Formatted or Transmitted.

Separate Remittance Advice:The Separate Remittance Advice is a report sent to a payee that lists the documents payable paid as part of each payment. You can specify the format for the remittance advice document and the delivery method.

Positive Pay: A positive pay file is a security measure in the form of a document that the deploying company sends to its payment system or bank to inform it of payments made by check. When you print checks, then you can electronically transmit a list of payments to the bank or payment system that indicates the checks you printed, so the bank or payment system knows what checks to pay. This list prevents the payment system or bank from paying fraudulent checks, since such checks are not listed on the positive pay file.

R12 Oracle Payments offers two versions of the Positive Pay report:

the Positive Pay File program, and

the Positive Pay File with Additional Parameters program.These programs replace the R11i report called the Positive Pay Report.

5. Alternatives to using Payment Process Requests

Creating PPRs is the only method of creating payments in the Oracle Payments module (IBY), but you can still create single payments using thePayments Workbench form in Oracle Payables (AP). There are three types of single payments that you can create using the AP Payments Workbench form:

Quick Payment = a single computer-generated payment to be generated and printed or transmitted using Oracle

Manual Payment = a single payment already generated outside of Oracle (such as bank wires, hand-written checks, etc.)

Refund = a single payment to a supplier, usually to repay one or more overpayments received in Oracle Receivables, or to refund a credit account balance in Oracle Payables.

Remember that the Payments Workbench is limited to creating only single payments, and requires that the user manually select the desired invoices and/or memos to pay.
Payment Process Requests (PPRs), on the other hand, are by far the most popular and heavily used payment programs for Oracle users because the Oracle Payments disbursement engine enables you to greatly simplify your procedures for managing complex payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations, and bank accounts.

Batch Payment STATUSES In R12

PPR Process STATUSES and What They Mean

As a Payment Process Request transitions through the different stages of processing, the PPR will display a "Status" to let you know where in the process the PPR has progressed to, and what's going on with it.

The list below is not a comprehensive list of EVERY possible Status that may appear on a PPR (or on its associated Payment Instruction file(s)), but it does include the statuses most commonly encountered:

NEW:
This status indicates that the PPR has been successfully submitted for processing, and the AutoSelect program is digesting the criteria provided by the user on the header of the PPR in preparation of the automatic selection the invoices and memos related to that criteria.

SELECTING INVOICES:
This status indicates that the AutoSelect program is selecting the eligible invoices/memos for the payment batch based on Due Date, Discount Date, Pay Group, and other criteria provided by the user on the header of the PPR.

CANCELLED - NO INVOICES SELECTED:
If no invoices or memos met the selection criteria provided by the user on the header of the PPR, the PPR is automatically terminated and the status changes to this status.

"MISSING..." STATUSES: 
Other statuses may appear at this point in the process if the user failed to included required information on the PPR header, such as "Missing Exchange Rates", etc.

INVOICES SELECTED:
After selecting the documents (invoices/memos), they are locked to prevent other checkruns from selecting the same documents.

INVOICES PENDING REVIEW:
This status will only appear if you selected the Stop Process for Review After Scheduled Payment Selection option on the Processing tab of the PPR header. This status means that the PPR process has stopped, and is waiting for you to review the invoices and memos that were selected for payment (and make any changes to the batch, as needed). Click on the Take Actionicon to be taken to the Review Selected Scheduled Payments window.

CALCULATING SPECIAL AMOUNTS:
This status will only appear if you selected the Calculate Payment Withholding and Interest During the Scheduled Payment Selection option on the Processing tab of the PPR header. This status means that interest and withholding tax are being calculated and applied, as necessary, to the invoices and memos selected for this payment batch.

ASSEMBLING/ASSEMBLED PAYMENTS:
An "interim" status, it appears after the calculation for interest and withholding has been completed, and the Build Payments program is starting. It may appear again later after the user provides any required bank account and PPP information for the invoices/memos ("documents") selected.

INFORMATION REQUIRED - PENDING ACTION:
This status appears if you did not provide a default Internal (Disbursement) Bank Account and/or PPP on the header of the PPR. In that case, you need to click on the Take Action icon to be taken to a form where you can decide which internal bank account and PPP should be used for each invoice and memo selected for payment.

PENDING PROPOSED PAYMENT REVIEW:
This status will only appear if you selected the Stop Process for Review After Creation of Proposed Paymentsoption on the Processing tab of the PPR header. In this case, the system is waiting for you to review (and modify, if needed) the proposed payments for this batch. Click on the Take Action icon to be taken to the Review Proposed Payments window.

FORMATTING:
This status indicates that the proposed payments have been turned into payment instruction files. At this point, you will want to click on the Show link to view the new associated payment instruction file(s). Each payment instruction file with have their own PI Reference Number. If you have both electronic and paper ("check") payments involved in this payment batch, you will see a payment instruction file for each type of payment method.

PAYMENT INSTRUCTION STATUSES:
An "electronic" type of payment instruction file will usually be marked asFORMATTED at this stage, which means the PI has been created, (and based on your setups) may also have been transmitted, and even marked as "Complete".

A "check" type of payment instruction file will (based on your setups) usually be marked as FORMATTED - READY FOR PRINTING, which means the payment instruction file was created, and is waiting to be sent to your printer. Click on the Take Action icon to send the file to the printer.

Afterward, the Status will change to SUBMITTED FOR PRINTING. Click on the Take Action icon again to "confirm" the payments (Record Print Status). This is also where the user will have an opportunity to "Reprint" the payment instruction file, if there were problems during the first printing process. Once the payment instruction file has been printed, an internal Payment Reference Number is assigned to the payment, along with a Paper Document(Check)Number.

Once the user clicks on the Record Print Status button (and confirms it), the payment instruction file's Status changes again, this time to PRINTED.

CONFIRMED PAYMENT:
Once the payment instructions have been transmitted/printed and confirmed, the Status of the PPR changes to this status to indicate a successfully completed payment batch (PPR).

TERMINATED:
If the user terminates a PPR anytime prior to confirmation of the payments (using the Terminate icon), the status will change to "Terminated", and the PPR is permanently closed.