KentW Limited

Back to R12 – Upgrade Overview

Placeholder for XML Publisher

Multiple Organizations Access Control (MOAC) security give the possibility of querying or seeing transactions of one or more Operating Units (OU) without changing responsibility.

In 11i we were securing transactions by Operating Unit (OU) only and we would have to choose a corresponding responsibility to see the transactions:

• OU1 – Receivables Manager
• OU2 – Receivables Manager
• OU3 – Receivables Manager

In R12 it is now possible to have a shared services responsibility like:

• ALL – Receivables Manager

This new kind of security is based on Security Profiles which is a hierarchy of operating units.

So best practice in R12 is now to secure all responsibilities by Security Profile rather than by Operating Unit.

11i non-MOAC setup:

So a global shared service responsibility was not possible in 11i so some companies had very long lists of responsibilities.

Also note in R11i site level setting takes precedence at lower levels so the responsibility level setting in this case is not needed – only if the OU had been different.

R12 MOAC setup:

Assuming we have a hierarchy like this where OU and security profiles have same names:

> Vision Global
>> Vision US
>>> Vision Operations (OU)
>>> Vision Services (OU)
>> Vision Europe (OU)

We do not need to have a security profile for all branches in the hierarchy above but it is best practice to do so.

So in R12 GL Set of Books Name is gone and you leave MO: Operating Unit empty and leave it to the Security Profile.

Note: MO: Default Operating Unit is not required and can be left empty however I have had several bugs in R12.1.1 and R12.1.2 related to missing default operating unit in IEX so try leaving it empty first and if you get problems put a default value in this and try again.

So Oracle has created MOAC but forgot a few details here and there.

Mixed R11i/R12 MOAC setup:

Some modules in R12 does not yet fully support MOAC so a mixed setup may be needed.

Luckily Oracle changed the MO profile settings inheritance so the site level setting does NOT override at responsibility level as in R11i – well at least this setup worked in R12.1.1.

Using the setup above you will get a site level default OU of “Vision Operations” however at responsibility level the security profile takes precedence so Receivables (Global) will be able to see all OU’s within “Vision Global”. In 11i you would have been locked down to “Vision Operations”.

Technical

11i – View Based Security

11i used views to secure transactions in individual schemas:

APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL

With where clause using CLIENT_INFO set from the responsibility context.

In PL/SQL programs you would set:

• fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id);

and:

• dbms_application_info.set_client_info(var_organization_id);

R12 – VPD Based Security

R12 uses the Virtual Private Database (VPD) technology for MOAC security.

Synonym APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL

With a policy attached to synonym APPS.AR_PAYMENT_SCHEDULES.

In PL/SQL program you still need to set:

• fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id);

and for single OU access:

• mo_global.set_policy_context(‘S’,var_organization_id);

or for multi OU access:

• mo_global.set_policy_context(‘M’,null);

Accessible Organisation Units

In 11i it was easy to see what access you had:

• dbms_application_info.read_client_info(var_organization_id);

Which would return your current org_id however in R12 you need to do the following:

• select organization_id
  from HR_ORGANIZATION_UNITS
  where MO_GLOBAL.CHECK_ACCESS(organization_id)=’Y’
  ;

I usually use the following script:

declare

  l_user_id number;

  l_responsibility_id number;

  l_application_id number;

  l_organization_id number;

begin

--  dbms_output.enable;

  select application_id,responsibility_id

    into l_application_id,l_responsibility_id

    from fnd_responsibility_tl

    where responsibility_name = 'General Ledger Super User';

  select user_id

    into l_user_id

    from fnd_user where user_name='ORACLE';

  select organization_id

    into l_organization_id

    from hr_all_organization_units

    where name='Vision Operations';

  fnd_global.apps_initialize(l_user_id,l_responsibility_id,l_application_id);  

  --mo_global.set_policy_context('S',l_organization_id);

  mo_global.set_policy_context('M',l_organization_id);

--  dbms_output.put_line('Done...');

end;

Concurrent Requests

Concurrent request can now be setup to run as in 11i (default) or as MOAC compliant programs.

Use the “System Administrator” OAF screen “Concurrent Program” to set Operating Unit Mode to Single (OU) or Multi (MOAC compliant):

Back to R12 – Upgrade Overview

In 11i we assign collectors using the profile options and optionally manually override this at account level if needed.

This gets rather hard to manage in large departments especially when people leaves or joins.

However in R12 you have the ability to use Territory Manager which originally is a sales tool for sales territory administration.

You can now also assign collectors at Customer/Party level however this easily cannot be seen as the collector cannot be stored at this level but is stored in an internal table instead.

The Territory Manager will assign collectors to delinquent customers automatically hence removing the need to manage customer profile class plus account and bill to level overrides. When assigning collectors to customer profile class just use the “Default Collector” – this value will be overridden by the Territory Manager if the customer becomes delinquent.

The article below will mainly concentrate on the use of Territory Manager with Advanced Collections.

Overview

• Implementing
• Territories – Intro
• Resources
• Matching Attributes
• Territories – Defining
• Concurrent Programs

Implementing

JTY is a bit tricky to get started with in form of an extra layer of role based access control (RBAC).

In order to setup JTY you need to following:

• Login as user SYSADMIN
• Using responsibility “User Management” grant role to yourself: “Security Administrator”
  or if not allowed then just grant roles to yourself:
  ”Collections Territory Administrator”
  ”Territory Manager Application Administrator”
• Also assign yourself responsibilities “User Management” and “Territory Management”
• Login as yourself
• Using responsibility “User Management” grant roles to yourself (if not done above):
  ”Collections Territory Administrator”
  ”Territory Manager Application Administrator”

Also be aware that JTY uses full MOAC control so be sure to set correct Security Profile.

Note: You must set the profile option “MO: Default Operating Unit” due to an error in the 12.1.2 Territory Definition form. You should however leave “MO: Operating Unit” blank.

Territories – Intro

Territories in Advanced Collections are used to distribute the UWQ workload amongst collectors in large departments.

A single territory has one or more resources assigned and matching attributes that applies to customer attributes.

Territories can form a hierarchy where we have the following territory types:

• Child Territory – Contains resources and matching attributes
• Parent Territory – Contains one or more child territories
• Catch-All Territory – A parent territory containing rules not covered by child territories below
• Placeholder Territory – A parent territory not containing rules but only child territories
• OU Territory – The top level owning parent territory. There is one per OU accessible

All territories can be defined using OAF forms or by using WebADI except for the OU territory which cannot download to Excel. Therefore it is a good idea to have a placeholder territory just below the OU territory.

Territories have the additional following attributes:

• Effective Date Range – Value inherited from parent territory
• Rank – a number where lowest rank wins if customer matches more than one territory.
  Normally just assign value: 1
  This value is inherited from parent territory
• Winners – number of territories a customer can match at any one time.
  Default to 1 when left empty. 2 or higher can cause overlapping territories

Resources

In order to define resources you need to have access to the responsibility “CRM Resource Manager”.

Resources can be any one of:

• Individual – CRM resource
• Group – CRM defined group. Groups can be assigned to multiple individuals
• Team – Similar to group but normally used in lead management

Groups can be a handy way of managing customers so instead of reassigning individuals to customers you assign groups to customers. This enables you to manage your resources by reassigning individuals between groups rather than between specific customers.

Matching Attributes

Matching Attributes are building blocks for creating rules for assigning customers to territories.

Advanced Collections only supports custom made or Customer based matching attributes which is the following:

• Account Classification (this is actually a sales lead item and does not really work with Collections)
• Area Code
• City
• Country
• County
• Customer Category
• Customer Name
• Customer Name Range
• Customer Name Range Group
• D-U-N-S
• Number of Employees
• Party Hierarchy
• Postal Code
• Province
• Registry ID
• SIC Code
• Site Number
• State

So if there is a need to allocate collectors based on something different than the list above you will need to create a custom matching attribute.

In order to use a matching attribute it must be enabled first:

In the above I will be enabling Customer Category and Customer Name Range.

Next step is to define a Territory Type in order to use the enabled attributes above:

So now we have created a territory type allowing the use of Customer Category and Customer Name Range.

Territory – Defining

You start from the OU territory and work your way down:

Note the search default to what you have in your profile options “MO: Default Operating Unit” however if another OU is desired just change the value in “Operating Unit” and click GO. Do not leave “Operating Unit” blank as that may cause problems in pre-R12.1.4 versions.

Select the operating unit “Vision Operations” and click “Create”:

Pick the Territory Type we created earlier and click continue:

Lets create the following hierarchy:

Vision Operations – OU Territory
> Top – Placeholder Territory
>> Other
>>> Commercial – Parent
>>>> NameRange1 – Child
>>>> NameRange2 – Child
>>> Federal – Child

So we want a catch all if a customer has not been assigned to a customer category and we split the commercial customers into two name ranges to level the volume.

So first we create Top:

No resources and matching attributes – so just click Finish:

Lets create the Other territory:

Click Next and add resource:

Assigned just one resource as this is the resource for an exception – the catch all.

I will not show how to add resources to the remaining territories…

Click next:

In spite of what the manual says you need to add a matching attribute for a catch-all territory. To ensure we catch all customers we use name range of 0% to Z%.

To define ranges like the one above you need to follow some basic rules:

• Always use wildcard “%” so A to Z becomes A% to Z%
• Single wildcard range will not work like A% to A%
• If range for one letter is needed use: A0% to AZ%

Next we define Commercial and Federal territories…

Commercial matching attribute:

Federal matching attribute:

The we add another two Commercial child territories…

Name range 1:

and name range 2:

So now we have:

Nice and easy…

Concurrent Programs

When you have finished creating your territory hierarchy you need to run the following in JTY:

• Synchronize Territory Assignment Rules

This is one of these programs with no real purpose except for if you don’t run it – it will not work.

When you want to assign territories to collectors and customers you must run the following in IEX:

• IEX: Territory Assignment

But ONLY after you have run the IEX: Scoring Engine Harness with Delinquencies Management otherwise you may miss any newly delinquent customers.

So we have installed R12 on a external USB hard disk according to my instructions but now we want more performance and flexibility?

You can either run out and buy a huge server and re-install on that or try to use two laptops instead of one?

Equipment used:

• Router – Draytek 2820
• Laptop 1 – R12 server: Lenovo Edge 13 with AMD Turion Neo X2 CPU and 4Gb RAM
• Laptop 2 – Client: Dell XPS M1530 with Intel T8300 CPU and 6Gb RAM
• Hard disk – R12 disk: Akasa eSata/USB2.0 case with Seagate 500Gb 7200RPM

Follow this to make it work:

1. In the router set a static IP address for laptop 1 – I use 192.168.1.4
2. Connect the hard disk to laptop 1 and boot
3. So laptop 1 still thinks it is 127.0.0.1 but router makes it 192.168.1.4 for other computers
4. Start R12 on laptop 1 and ensure everything is up and running nicely
5. Update hosts file on laptop 2:
   192.168.1.4 localhost.localdomain
   Localhost is normally the loopback but as the R12 server is using this name we must do the same
6. In the browser on laptop 2 connect to http://localhost.localdomain:8000
7. Login and go!

Conclusion

R12 Performance is fine only taking 1.7Gb RAM on Laptop 1.

Cpu level is very low as well < 25% overall.

I/O could be better as the USB2 is not that fast.

Fitting the R12 hard disk inside Laptop 1 may boot performance thanks to Sata being 10+ times faster than USB2.

Concurrent Request Sets are great to use when having to submit multiple programs like period-end programs.

However it in large scale projects you may have to submit very large request sets depending on some logic which is virtually impossible to implement as a Concurrent Request Set.

It is easy to submit a program from a PL/SQL program using:

FND_REQUEST.SUBMIT_REQUEST

However how do we keep track of all the submitted sub-programs in similar way as a normal concurrent request set do it – retaining the parent request id?

So what we want to have is:

> Request Set
>> Request Job (parent request id = Request Set)

Also how do we ensure that we do not submit too many sub-programs at any one time in order not to clutter the request queue?

So what we really want to have is:

> Request Set
>> Request Job (parent request id = Request Set)
> Wait for child requests to complete
>> Request Job (parent request id = Request Set)

The problem is that when a parent program wakes up it re-submits itself. So in order to make this work you need to use recursive programming methods.

The trick is to use these three calls:

• FND_CONC_GLOBAL.SET_REQ_GLOBALS with Status=PAUSED and REQUEST_DATA
  Status = PAUSED will put the parent program into a wait state until child processes have completed
  REQUEST_DATA parameter will save data between runs
• FND_CONC_GLOBAL.REQUEST_DATA
  Retrieves data from previous run
• FND_REQUEST.SUBMIT_REQUEST with SUB_REQUEST=>true
  Submits the sub-programs with control of a parent program.
  If set to “false” you have no control of the sub-programs.
  If you set this to “true” but without setting parent program status to PAUSED you will get the issue where child programs are phase=“inactive” and status=“no manager”

So in my test I will create to sets of two jobs:

> Request Set
> Set 1:
>> 1: Request Job (parent request id = Request Set)
>> 2: Request Job (parent request id = Request Set)
> Wait for child requests to complete
> Set 2:
>> 1: Request Job (parent request id = Request Set)
>> 2: Request Job (parent request id = Request Set)

So running my concurrent request set:

Set 1:

So two first programs has just run and parent quest is about to start the second job set.

Set 2:

Note all jobs has the same Parent Request ID.

Nice and controlled.

Create the PL/SQL code:

Package:

create or replace
package XXKWICONCSET authid current_user as
  — this is exposed for conc manager
  procedure XXKWI_REQUEST_SET_CONCUR (
    ERRBUF OUT NOCOPY varchar2,
    RETCODE OUT NOCOPY varchar2
  );
  procedure XXKWI_REQUEST_CONCUR (
    ERRBUF OUT NOCOPY varchar2,
    RETCODE OUT NOCOPY varchar2,
    PARAM IN varchar2
  );
end XXKWICONCSET;
/

Package Body:

create or replace
package body XXKWICONCSET as
  — Concurrent child program
  procedure XXKWI_REQUEST_CONCUR (
    ERRBUF OUT NOCOPY varchar2,
    RETCODE OUT NOCOPY varchar2,
    PARAM IN varchar2
  ) is
  begin
    fnd_file.put_line(fnd_file.output,’Running job: ‘||param);
    ERRBUF:=’Done Job…’;
    RETCODE:=0;
  end XXKWI_REQUEST_CONCUR;
  — Concurrent Request Set
  procedure XXKWI_REQUEST_SET_CONCUR (
    ERRBUF OUT NOCOPY varchar2,
    RETCODE OUT NOCOPY varchar2
  ) is
    L_REQUEST_ID number;
    L_REQ_DATA varchar2(10);
    job_count number;
    set_count number;
  begin
    L_REQ_DATA:=FND_CONC_GLOBAL.REQUEST_DATA; — get previous job data
    if L_REQ_DATA is null then — first run set count to ‘0′
      L_REQ_DATA:=’0′;
    end if;
    set_count:=to_number(l_req_data)+1; — increment for every job
    fnd_file.put_line(fnd_file.output,’Running set: ‘||to_char(set_count));
    if set_count>2 then — stop after 2 jobs
      ERRBUF:=’Done Set…’;
      RETCODE:=0;
      return;
    end if;
    — submit 3 child programs
    for job_count in 1..2 loop
      fnd_file.put_line(fnd_file.output,’Submitting job: ‘||to_char(job_count));
      L_REQUEST_ID:=FND_REQUEST.SUBMIT_REQUEST(
        APPLICATION=>’FND’,
        program=>’XXKWI_REQUEST_CONCUR’,
        DESCRIPTION=>to_char(job_count),
        START_TIME=>null,
        SUB_REQUEST=>true, — True = This is a child program
        ARGUMENT1=>to_char(job_count) — data to job
      );
    end loop;
    — Wait until done and save set count:
    FND_CONC_GLOBAL.SET_REQ_GLOBALS(
      CONC_STATUS=>’PAUSED’, — wait for child request to complete
      REQUEST_DATA=>to_char(set_count) — save set data
    ); 
    Commit;
  end XXKWI_REQUEST_SET_CONCUR;
end XXKWICONCSET;
/

Register the two executables and programs.

Concurrent Job:

Concurrent Set:

Request Group:

Back to R12 – Upgrade Overview

This article will however not provide a full overview of IEX but only explain some of the basics to get you started with IEX after moving to R12. Beyond that – dig into the manual.

News

• Bulk XML Delivery per default in R12.1.2
• Staged Dunning to be introduced (again) in R12.1.3

11i –> R12 Crash Info

In R12 – Oracle have removed all collections functionality from AR and thereby forced an upgrade to IEX hence this article will cover both existing and new IEX functionality.

First lesson is – it is near impossible to mimic the 11i functionality so there is no easy upgrade path from 11i to R12.

Second lesson is – IEX uses MOAC security so most IEX settings are global and at site level. Transaction security is then handled by MOAC using security profiles.

General Need to Know

A small warning – with R12 the UI is now all over the place:

• Implementation and super user: Mixed old forms, CRM screens and OAF
• User: Forms and CRM screens. CRM screens are made with forms but have a different look and feel

So be sure to plan for loads of user training and testing in addition to the implementation effort.

Another warning – setting up Advanced Collections will need a hybrid consultant – as many areas need both SQL and XML knowledge:

• Scoring Components contains SQL select statements
• Scoring Engine use views to limit transaction scope
• Correspondence Template Query is using SQL select statements to create XML tags
• Correspondence Templates use XML to produce output
• Most output in Advanced Collections uses XML Publisher
• Advanced letters may need both XML and XSL-TEXT knowledge

Overview:

The chapters listed below will give you an overview of the configuration and integration points.

• New Concepts
• Collectors Management (HR and Sales integration)
• Collectors Assignment (Territory Management Integration)
• Collectors Work Queue (Universal Work Queue – UWQ)
• Collections Window (eBusiness Center)
• Aging (AR Integration)
• Activities (Payments,Promise to Pay,Disputes)

New Concepts

First of all the word “delinquency” is new to most 11i users and this means an overdue item.

Advanced Collections introduces many new concepts where the main ones are:

• Operational Level – item level for collections including delinquency determination and correspondence
• Scoring – points system calculated by a scoring engine
• Delinquency Status – status is one of: Current, Pre-delinquent or Delinquent
• Strategies – Handling of delinquencies based on multiple scoring engines
• Dunning Plans – Handling of delinquencies using a single scoring engine with associated aging buckets

During first setup you will have to make the following main decisions:

1. Operational Level which must be one of: customer, account, bill-to or delinquency (overdue transaction)
2. Collections method which must be either Strategies or Dunning Plans

Operational Level

Level defines the operational data level for collection items which includes:

• Delinquency determination
• Work queue items
• Correspondence

The following operational data level can be chosen:

• Customer: Party/customer level
• Account: Account level
• Bill To: Bill To level
• Delinquency: Transaction level

So if your level is account the customer could have one account being marked as delinquent and one being non-delinquent. Also correspondence will be made at this level including details of transactions by account.

So if you use delinquency level then if a customer has two concurrent delinquencies this customer will receive two separate dunning letters even if overdue on the same day.

In 11i delinquency management was normally conducted at account level thanks to the Account Details screen in the old collections workbench and staged dunning.

The operational data level is set when you setup IEX using the Collections Questionnaire.

Scoring

Scoring is a new concept of rating a delinquency based on various factors. The scoring is done by the scoring engine which is run from the concurrent program:

IEX: Scoring Engine Harness

The scoring engine use scoring components for generating score amounts.

Typical score components could be:

• Amount due
• Days overdue
• Time as customer
• Number of delinquent transactions
• Annual sales amount

Example of a scoring component definition:

Each score amount is mapped to a score value as the score amount can vary depending on its source and if it is comparable. If you want to score based on transaction amount and days overdue then those two amount will vary and would not be directly comparable however by mapping them into score values they become comparable.

The score engine values are normally within 0 to 100 and when using multiple scoring components these values will be summarised. The score values can be used with weighting – if enabled – however sum of weights must be 1:

For example if you have a score component returning the amount outstanding you would map this to a score value:

So if you a score component yielding amount due 5000 the score value would be 10 which would be added to any other score value.

If additional score components are used this would result in score values being added up.

The score component must always return a number within the range –999999999 to 999999999 and use 2 decimals precision – see example from a seeded setup:

The score component uses either an SQL select statement or a PL/SQL function.

Using PL/SQL function enables you to use parameters.

The SQL statement is easier to maintain if used with a custom database view.

Segments – which is a database view assigned to the scoring engine – can limit the transactions targeted by the scoring engine:

One one segment can be assigned per scoring engine.

The combination of multiple scoring components and multiple scoring engines with different segment assignments gives endless possibilities to meet business requirements.

Delinquency Status

Delinquency Status indicates if there is a delinquency for the current score value.

The status is determined by mapping score values to statuses.

Status is one of:

• Current
• Pre-Delinquent
• Delinquent

One delinquent transactions are scored so the current status will not yield delinquencies.

So using the example above we could do the following mapping of score values:

Example from seeded data:

Status is updated when a scoring engine run as long as “Used to determine status” check box is set and “concurrent program” is set to:

IEX: Delinquencies Management

Strategies

Strategies works with two scoring engines:

1. Delinquency determination
2. Strategy determination

A strategy is similar to a 11i dunning set but with the difference that a strategy is based on score values and the outcome is a work item which can be one of:

• Manual: phone call or review. This is visible as a task in the collectors work queue
• Automatic: sending of email, fax or letter. Any sent correspondence is recorded in the transaction history
• Workflow: automated customised task

The score values is generated by the score engine for strategies defined in similar way as the score engine for delinquency status determination.

The score value is mapped to a strategy:

The strategy will then map to a number of work items:

So a typical strategy concurrent run is:

IEX: Scoring Engine Harness – for delinquency determination

(IEX: Delinquencies Management – run as part of delinquency determination)

IEX: Scoring Engine Harness – for strategy determination and work item creation

(IEX: Strategy Management – run as part of delinquency determination)

IEX: Create Dunning And Broken Promise Call Backs – to create UWQ actions

So Strategies are very flexible and versatile however keep in mind a very open ended module is also harder to configure and test.

Dunning Plans

Dunning plans is Oracle’s solution for customers upgrading to 11i without having a license for Advanced Collections.

Dunning plans use only one scoring engine and ties delinquency determination and aging buckets together in one.

Dunning plans has the following limitations (quite a few I would say):

• Delinquency scoring engine and dunning plan scoring engine is one and same
• Scoring engine values are used both for delinquency status determination and aging bucket line determination so it can be tricky to obtain desired functionality
• A transaction can only be scored using one scoring engine – if you add a new scoring engine only new transactions will be scored with this (ouch – this is bad during test)
• AR Aging Buckets are used for days overdue determination only – unless you customise scoring components
• Correspondence are assigned to an aging bucket line so every time the aging bucket line are in the score range a letter will be sent – so beware you might want to ensure lines with correspondence only range one day to avoid duplicate letters
• Only one aging bucket can be used per dunning plan
• Each mapped Aging Bucket Line must yield correspondence and optionally a call – so you cannot have a call-only line unless you use a dummy letter or similar

So a typical dunning plan concurrent run is:

IEX: Scoring Engine Harness – for delinquency determination

IEX: Send Dunnings for delinquent customers – to send correspondence

IEX: Create Dunning And Broken Promise Call Backs – to create UWQ actions

Collectors Management (HRMS and CRM integration)

In 11i you just needed to have a normal apps user and a collections use – now in R12 it has become a bit more complicated.

So the Collectors setup in AR is still there to do…

Now you also need to do the following:

• HR: Create HRMS Employee and assignment
• SYS: Assign the HRMS Employee to your apps user
• CRM: Create CRM resource by importing the employee into CRM
• CRM: Assign collections roles and groups to the CRM resource
• CRM: For Territory Management assign Telesales Agent as well

For migrating from 11i to R12 you can create a resource for each collector defined in AR:

IEX: AR Collectors to Resource Collectors

That should help a little bit…

Also collectors can be generated by Collectors Assignment when running:

IEX: Territory Assignment

Collectors Assignment (Territory Management Integration)

In order to assign collectors you can still do as you did in 11i – using collectors at profile class level – however in R12 you have the additional option of using:

JTY: Territory Manager

This enables you to automatically assign collectors to delinquencies based on rules.

This is actually a sales tool but follow the link and it will explain how to use it for IEX.

To create the assignments run the following concurrent program:

IEX: Territory Assignment

Collectors Work Queue (Universal Work Queue – UWQ)

The UWQ is the collectors work-list which shows delinquencies, calls as tasks to be made and broken promises:

The collectors works queue is essentially the Universal Work Queue used by the CRM modules.

Strategy manual work items and dunning plan calls will show up i the collectors work queue as tasks.

The collectors work queue can be customised using EIU% profile options – see a few below:

By clicking an item on the work-list the Collections Window opens up…

Collections Window (eBusiness Center)

The collections window is essentially the CRM eBusiness Center.

This window shows the customer with tabs showing details:

The following tabs are displayed:

• Profile – Credit overview and metrics
  
• History – Correspondence, adjustments, calls and other interactions
  
• Accounts – Accounts and their details
  
• Transactions – List of delinquent transactions but can also include current and closed transactions
  
• Lifecycle – List of delinquent transactions and their current collection status
  
• Strategy – Current assigned strategy and work items pending or completed
  
• Aging – Delinquent transactions summarised by aging buckets
  
• Notes – Notes can be taken here and can optionally be visible to other collectors
  
• Tasks – List of tasks
  

Aging

A familiar term from 11i however yet so different.

Aging and aging buckets as we know them from 11i are still used for displaying or reporting on aging in the following places:

• Collections Windows – Aging Tab
• AR Aging Reports

But then the similarities stop.

For Strategies and Dunning Plans aging buckets are sometimes used in Score Components:

And also used in Dunning Plans for correspondence assignment:

But in very different way than in 11i.

Activities

In the Collections Window you can do the following activities:

• Take Payments or promise to pay
• Make adjustments and credit notes
• Send correspondence

The following payments can be accepted in IEX:

• Credit Card
• Bank Transfer (direct debit)

So no debit card payments.

Also bank transfer requires in most countries a signed agreement at beforehand so  this really narrow it down to credit card payment only.

The credit card payment method must be setup in Payments – IBY.

Activities send confirmation letters automatically:

• Payment Confirmation
• Promise Confirmation
• Dispute Confirmation
• Adjustment Confirmation
• Reversal Confirmation
• Leasing Invoice Confirmation
• Invoice Copy

All correspondence is created and sent using XML Publisher.

The promise to pay will create an event in the UWQ then you run the following concurrent program:

IEX: Promise Reconciliation

Well having installed and worked with R12.0.4  it very fast becomes clear that a new version is needed.

So I downloaded R12.1.1 from Oracle eDelivery. 40 files in excess of 45Gb to the joy of my ISP.

NOTE until 20/11-2009 there was a corrupt file on eDelivery and it took me a while to convince Oracle that it was the case.

The sick file was: V15571-01_2of3.zip

However the file has been fixed after the above date but be sure to test your downloaded files anyway using ziptest.

Otherwise follow the procedure for R12 Installation.

Some of the initial rapidwiz screen has changed though.

The Welcome screen is saying 12.1.1 – great:

Select express install:

Just click next on this one:

Update base directory:

Before logging in you should compile the jsp pages – see how to Compile JSP.

And then it is business as usual like in R12.0.4

Also in you environment script – the one I call vis.sh change this:

from:
TECHENV=/oracle/VIS/db/tech_st/10.2.0/$CONTEXT_NAME.env
to:
TECHENV=/oracle/VIS/db/tech_st/11.1.0/$CONTEXT_NAME.env

Have fun…

This is a couple of useful scripts to test downloaded files.

This approach is recommended when downloading huge amounts of data like when downloading Oracle R12 installations files.

In addition to testing the downloaded files also be sure to use a download manager.

The basic zip test command is:

$ unzip –t –qq {zipfile}

I made a Linux script for it named ziptest.sh:

A similar script can be made for Windows names ziptest.cmd:

As command line programming in windows isn’t great we need to call a subprogram names ziptest_call:

That should be it.

Be sure to update directory references for your own purpose.

Back to R12 – Upgrade Overview

Overview

In GL there has been a number of changes:

• Terminology Changes
  • Set of Books (SOB) is now Ledgers
  • Multiple Reporting Currencies (MRC) is now Reporting Currencies
  • Global Intercompany System (GIS) is now Advanced Global Intercompany System (AGIS)
• Obsolete
  • Global Accounting Engine (AX) replaced by Subledger Accounting
  • MRC as a workaround – now fully integrated as Reporting Currencies
• Accounting Setup manager – New central management of legal entities and legers
• Legal Entities – now really used
• Ledgers – new name and setup for SOBs
• Ledger sets – ledger grouping and security feature
• Reporting Currencies – MRC has now been cleaned up and is better integrated
• Period rates – now all daily rates and managed in same way
• Revaluation and Translation – changed functionality
• Journal Reconciliation
• Advanced Global Intercompany System (AGIS) – changed functionality

Accounting Setup Manager

The new Accounting Setup Manager simplifies and centralizes accounting-related setup for common financial components that are shared across financial applications. From a central location, you can define your legal entities and their accounting context, such as the ledgers and reporting currencies that perform the accounting for your legal entities.

The setup steps are:

• Legal Entity
• Primary Ledger
• Reporting Currencies
• Balancing Segment Value Assignments
• Subledger Accounting Options
• Operating Units
• Intercompany Accounts
• Intercompany Balancing Rules
• Sequencing
• Secondary Ledgers

Each of the setup steps is a number of sub screens where some are described later.

Legal Entities

Legal Entities part of Accounting Setup Manager now holds important information for both tax and VAT reporting.

General

Registrations

This is where you would put in information for the Corporations Office

Establishments

List of all locations

Balancing Segments

This is a new important feature that the balancing segment now relates to the legal entity.

Primary Ledger

Ledgers are mostly the same as the old Set Of Books however the setup screens has changed a bit.

Definition

Nothing really new here except for the OFA screen.

Options

Similar to the old screens in a new wrapping.

Advanced Options

Again similar to old days except for the new Journal Reconciliation option.

Ledger Sets and Data Access Sets

The Ledger Set is a great new feature which lets you manage multiple ledgers as one – a especially useful feature for faster closing. However the ledgers must share the following information:

• Chart of accounts
• Calendar/period type combination

You can open/close periods for multiple ledgers at once, run recurring journals that update balances for multiple ledgers. So it goes way beyond report sets or cross COA FSG reports.

Ledger Set

Strange though – this is a non-OFA screen…having thought that all new features was pushed to OFA.

Similar to the Ledger Set the Data Access Set provides security at same level so ledgers must still share the following information:

• Chart of accounts
• Calendar/period type combination

The security can be at the following levels:

• Full Ledger – access to the whole COA
• Balancing Segment Value – access to specific balancing segment values
• Management Segment Value – access to specific management segment values

Note the Management Segment is a new segment qualifier. If you what your cost centre to be secured and used in Data Access sets enable the Cost Centre segment as a Management Segment. Remember if your COA has been used there is a specific procedure for doing this to avoid corruption.

Data Access Set

The system always generate a Data Access Set with same name and full access for each:

• Primary Ledger
• Secondary ledger
• Ledger Set
• Reporting Currency (also creates a Reporting Currency + Source Ledger Data Access Set)

Data Access Set security can be combined with Segment Value Security Rules and will work as a logical AND so only where the two overlaps access will be allowed.

Reporting Currencies

The reporting currency definition is now comprised from the R11i options for reporting sets of books and the MRC profile options.

Period Rates

Period Rates Replaced by Daily Rates and all new OAF screens.

Currency Rates Manager:

Revaluation and Translation

Revaluation sets are now usable across ledgers that share a common chart of accounts. In some cases, you may need to enter the secondary tracking segment for revaluation sets involving a secondary tracking segment before running revaluations with upgraded templates.

General Ledger modifies revaluation templates to use corresponding daily rates for those that used period rates prior to the upgrade.

Journal Reconciliation

Journals can now be reconciled if an account has been marked as such.

The is a useful feature for clearing accounts or tax accounts which should balance to zero.

Account Setup

Note this is a cash clearing account which is a good candidate for journal reconciliation.

So in this case you would enable the segment qualifier “Reconcile” to “Yes”.

Journal Entry

Note the new “Reconciliation Reference” field. This is used both for automatic and manual reconciliation.

Unreconciled Lines

Search for unreconciled journal lines using the parameters above.

Reconcile Journal

No journals to reconcile here – but you see the point?

Back to R12 – Upgrade Overview

AR are now fully support new modules like E-Business Tax and Subledger Accounting.

Overview:

• Integration with E-Business Tax
• Integration with Subledger Accounting
• Centralized Banks and Bank Accounts Definitions
• Integration with Payments for Funds Capture
• Balance Forward Billing
• Late Charges Enhancements
• Customer UI Redesign
• Process Changes

Integration with E-Business Tax

Release 12 introduces Oracle E-Business Tax to manage tax across the E-Business Suite. During the upgrade, system and customer options used to control tax calculation and tax code defaulting are migrated from Oracle Receivables into Oracle E-Business Tax entities. See E-Business Tax in this appendix for further details.

Integration with Subledger Accounting

Release 12 introduces Subledger Accounting for managing accounting across subledger transactions. Receivables no longer creates any accounting entries. Existing Receivables accounting options and setups remain and affect the generation of accounting distributions in the Receivables data model. However, the accounting distributions are now simply one of many sources for generation of final accounting in the Subledger Accounting module.

Centralized Banks and Bank Accounts Definitions

In Release 12, all internal banks and bank accounts you had defined for your operations are automatically migrated to the central Cash Management entities. Remittance bank accounts are owned by a legal entity rather than by an operating unit.

Integration with Payments for Funds Capture

Release 12 introduces Oracle Payments, which is used by Oracle Receivables for processing funds capture. See Payments in this appendix for further details.

Balance Forward Billing

Release 12 enhances the Release 11i Consolidated Billing Invoices functionality to include more flexible billing cycles, to consolidate invoices at site or account level, and to present Balance Forward Bills using the user-configurable Bill Presentment Architecture.

Late Charges Enhancements

Release 12 enhances the Receivables Late Charges feature to incorporate the Global Interest Invoice setups, charge calculation logic, and charge generation processes. Charges for delinquent payments can now be generated as adjustments, debit memos, or interest invoices. The Interest Invoice Global Descriptive Flexfield is obsolete.

Customer UI Redesign

Release 12 introduces a new HTML user interface for entering and maintaining customer data. See the Oracle Receivables User Guide for further details.

Process Changes

The following features are obsolete in Release 12:

Collections Workbench – The Oracle Advanced Collections module delivers similar functionality. See the Collections Migration white paper and the Oracle Advanced Collections User Guide for further details.

Trade Accounting – Similar functionality is delivered by integration with the Oracle Trade Management module. Trade Management integration is available in Release 11i.

Bill of Exchange – This functionality has been replaced with the Bills Receivable feature. Bills Receivables is available in Release 11i.