Showing posts with label Customer. Show all posts
Showing posts with label Customer. Show all posts

Updating Customer Site Profile Classes using SOAP Web Services in Oracle Fusion Applications

First off, there are two ways to upload/update Customer Site Profiles in Oracle Fusion Applications:
  1. Using File-Based Data Import (FBDI)
  2. Using Web Services such as SOAP and REST. 
However, I would recommend using Web Services instead of FBDI because it's more straight-forward and simpler than FBDI. More details can be found in a separate article: When to Use FBDI or WebServices in Oracle Fusion Applications.

This article will talk about how to upload/update Customer Site Profile Classes in Oracle Fusion Applications using SOAP web services and in the future, I will also discuss how to do this using FBDI.

Before we begin, let's first discuss what a Customer Profile Class is. Customer profile Class is a master data setup object that holds attributes that are important to the interaction between the organization and customers in terms of their selling relationship. It holds details such as the Customer's creditworthiness, credit tolerance, credit limit, its default payment terms, statement configurations, and its assigned collector.  A Customer Profile class is also used drive how the system will match receipts together with their invoices and defines how invoices are grouped together. For more in-depth information, check out a separate article: Defining a Customer Profile Class in Oracle Fusion Applications.

Below are some prerequisites before you can actually upload/update Customer Site Profiles using SOAP Web Services:
  1. Download a copy of ReadyAPI, a software that will drive the updates to Customer Site Profiles
  2. Prepare an "Extraction Report" that will generate the spreadsheet with the required Customer Data.
Since the first prerequisite is pretty straight forward, we'll move on to discuss the second prerequisite: Preparing the "Extraction Report". The script will be run from Business Intelligence Publisher (BIP), a reporting tool that we'll utilize to generate the actual data that will be fed to the Web Service.

To create the extraction report, you would have to create the following in order:
  1. A custom Data Model that contains the SQL Script
  2. A custom Report with CSV as the Output
  3. A custom "dummy" Excel Template
Check out this article for an idea on how to create a custom Data Model (Customize the Data Models of seeded Oracle Fusion Applications reports). In the future, i'll create a step-by-step guide on how to create a custom data model, report and dummy excel template.

The SQL Script to be used in the Data Model is as follows:


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
select  ACCT.ACCOUNT_NUMBER
 , hps.party_site_number
 , ACCT.CUST_ACCOUNT_ID
 --, 'DEFAULT' SET_CODE
 , STID.SET_CODE
 , custprof.CLEARING_DAYS
 , custprof.CREDIT_BALANCE_STATEMENTS
 , custprof.CREDIT_CHECKING
 , custprof.CREDIT_HOLD
 , custprof.PROFILE_CLASS_ID
 , decode(custprof.DISCOUNT_TERMS, 'N', NULL, custprof.DISCOUNT_GRACE_DAYS) DISCOUNT_GRACE_DAYS
 , custprof.DISCOUNT_TERMS
 , 'Y' DUNNING_LETTERS
 , custprof.EFFECTIVE_START_DATE
 , custprof.EFFECTIVE_END_DATE
 , custprof.LAST_CREDIT_REVIEW_DATE
 , custprof.NEXT_CREDIT_REVIEW_DATE
 , custprof.OVERRIDE_TERMS
 , HP.PARTY_ID
 , custprof.PERCENT_COLLECTABLE
 , custprof.SEND_STATEMENTS
 , custprof.TOLERANCE
 , coll.NAME CollectorName
 , custprof.EXCHANGE_RATE_TYPE
 , RTM.name  PaymentTerms
 , custprof.AUTOCASH_HIERARCHY_ID
 , null ApplicationExceptionRuleSet
 , aar.Name AutoMatchRuleSet
 , custprof.AUTOCASH_HIERARCHY_ID_FOR_ADR
 , cyc.NAME StatementCycle
 , grp.name GroupingRule
 , custprof.CREDIT_CLASSIFICATION
 , custprof.ACCOUNT_STATUS
 , custprof.RISK_CODE
 , custprof.CREDIT_RATING
 , custprof.CONS_BILL_LEVEL
 , custprof.CONS_INV_TYPE
 , custprof.LOCKBOX_MATCHING_OPTION
 , replace(custprof.PREF_CONTACT_METHOD, 'EMAIL', 'E-Mail') PREF_CONTACT_METHOD
 , replace(custprof.TXN_DELIVERY_METHOD, 'EMAIL', 'E-Mail') TXN_DELIVERY_METHOD
 , custprof.PRINTING_OPTION_CODE
 , custprof.MATCH_BY_AUTOUPDATE_FLAG
 , custprof.AUTO_REC_INCL_DISPUTED_FLAG
 , custprof.CONS_INV_FLAG
 , NULL CREDIT_REVIEW_CYCLE
 , custprof.CREDIT_ANALYST_ID
 , custprof.CREDIT_LIMIT
 , custprof.CREDIT_CURRENCY_CODE
 , replace(custprof.STMT_DELIVERY_METHOD, 'EMAIL', 'E-Mail') STMT_DELIVERY_METHOD
 , custprof.ORDER_AMOUNT_LIMIT
from  HZ_PARTIES      hp
JOIN  HZ_PARTY_SITES     hps   on HPS.PARTY_ID     = HP.PARTY_ID
JOIN  HZ_CUST_ACCOUNTS   ACCT  on ACCT.PARTY_ID     = HP.PARTY_ID
JOIN  HZ_CUST_ACCT_SITES_ALL  ACTS  ON (ACTS.CUST_ACCOUNT_ID    = ACCT.CUST_ACCOUNT_ID
           AND  HPS.party_site_id     = ACTS.party_site_id)
JOIN  HZ_CUSTOMER_PROFILES_F   custprof ON (hp.party_id             = custprof.party_id
           AND  ACCT.CUST_ACCOUNT_ID    = custprof.CUST_ACCOUNT_ID)
join  HZ_CUST_SITE_USES_ALL  usg   ON (usg.SITE_USE_ID          = custprof.SITE_USE_ID
           and usg.CUST_ACCT_SITE_ID    = ACTS.CUST_ACCT_SITE_ID)
JOIN  HZ_CUST_PROFILE_CLASSES  class  ON (custprof.PROFILE_CLASS_ID = class.PROFILE_CLASS_ID)
JOIN  FND_SETID_SETS    STId  ON (STID.SET_ID       = ACTS.SET_ID)
join  AR_COLLECTORS    coll  on (coll.collector_id     = custprof.COLLECTOR_ID)
join  AR_STATEMENT_CYCLES   cyc   on (cyc.statement_cycle_id   = custprof.STATEMENT_CYCLE_ID)
join  RA_GROUPING_RULES   grp   on (custprof.GROUPING_RULE_ID = grp.GROUPING_RULE_ID)
JOIN  RA_TERMS      RTM   ON  (custprof.STANDARD_TERMS = rtm.TERM_ID)
left JOIN AR_AUTOMATCH_RULES  aar   on (custprof.AUTOMATCH_RULE_ID = aar.AUTOMATCH_RULE_ID)
where custprof.status      = 'A'
and  class.status       = 'A'
AND  ACTS.STATUS       = 'A'
and  hp.party_type       = 'ORGANIZATION'
AND  hp.status           = 'A'
and  custprof.site_use_id is not null
and  sysdate between custprof.EFFECTIVE_START_DATE and custprof.EFFECTIVE_END_DATE
and  class.NAME = 'DEFAULT'

This is the script I used to capture all the required information for the WebService Payload that will  update the Customer Site Profile Classes. Feel free to change it according to your Organization's requirements.

Next, open up ReadyAPI and create a new SOAP project and provide the Web Services Description/Definition Language (WSDL) for your Instance. Next, load the Spreadsheet generated from the Report and assign it as a Data Source for the XML Payload below:


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://xmlns.oracle.com/apps/financials/receivables/customers/customerProfileService/types/" xmlns:cus="http://xmlns.oracle.com/apps/financials/receivables/customers/customerProfileService/" xmlns:cus1="http://xmlns.oracle.com/apps/financials/receivables/customerSetup/customerProfiles/model/flex/CustomerProfileDff/" xmlns:cus2="http://xmlns.oracle.com/apps/financials/receivables/customerSetup/customerProfiles/model/flex/CustomerProfileGdf/">
   <soapenv:Header/>
   <soapenv:Body>
      <typ:updateCustomerProfileAsync>
         <typ:customerProfile>
            <cus:AccountNumber>${DataSource#AccountNumber}</cus:AccountNumber>
            <cus:SiteNumber>${DataSource#SiteNumber}</cus:SiteNumber>
            <cus:CustomerAccountId>${DataSource#CustomerAccountId}</cus:CustomerAccountId>
            <cus:ProfileClassName>${DataSource#ProfileClassName}</cus:ProfileClassName>
            <cus:ClearingDays/>
            <cus:CreditBalanceStatements>${DataSource#CreditBalanceStatements}</cus:CreditBalanceStatements>
            <cus:CreditChecking>${DataSource#CreditChecking}</cus:CreditChecking>
            <cus:CreditHold>${DataSource#CreditHold}</cus:CreditHold>
            <cus:CustomerAccountProfileId>${DataSource#CustomerAccountProfileId}</cus:CustomerAccountProfileId>
            <cus:DiscountGraceDays/>
            <cus:DiscountTerms>${DataSource#DiscountTerms}</cus:DiscountTerms>
            <cus:DunningLetters>${DataSource#DunningLetters}</cus:DunningLetters>
            <cus:EffectiveEndDate>${DataSource#EffectiveEndDate}</cus:EffectiveEndDate>
            <cus:EffectiveStartDate>${DataSource#EffectiveStartDate}</cus:EffectiveStartDate>
            <cus:LastCreditReviewDate/>
            <cus:NextCreditReviewDate/>
            <cus:OverrideTerms>${DataSource#OverrideTerms}</cus:OverrideTerms>
            <cus:PartyId>${DataSource#PartyId}</cus:PartyId>
            <cus:PercentCollectable/>
            <cus:SendStatements>${DataSource#SendStatements}</cus:SendStatements>
            <cus:Tolerance>${DataSource#Tolerance}</cus:Tolerance>
            <cus:CollectorName>${DataSource#CollectorName}</cus:CollectorName>
            <cus:ConversionRateType/>
            <cus:PaymentTerms>${DataSource#PaymentTerms}</cus:PaymentTerms>
            <cus:AutoCashRuleSet/>
            <cus:ApplicationExceptionRuleSet/>
            <cus:AutoMatchRuleSet/>
            <cus:ReminderRuleSet/>
            <cus:StatementCycle>${DataSource#StatementCycle}</cus:StatementCycle>
            <cus:GroupingRule>${DataSource#GroupingRule}</cus:GroupingRule>
            <cus:CreditClassificationValue/>
            <cus:AccountStatusValue/>
            <cus:RiskCodeValue/>
            <cus:CreditRatingValue/>
            <cus:BillLevel/>
            <cus:BillType/>
            <cus:MatchReceiptsBy/>
            <cus:PreferredContactMethod>${DataSource#PreferredContactMethod}</cus:PreferredContactMethod>
            <cus:PreferredDeliveryMethod>${DataSource#PreferredDeliveryMethod}</cus:PreferredDeliveryMethod>
            <cus:GenerateBill/>
            <cus:MatchByAutoupdate/>
            <cus:AutoReceiptsIncludeDisputedItems>${DataSource#AutoReceiptsIncludeDisputedItems}</cus:AutoReceiptsIncludeDisputedItems>
            <cus:ConsolidatedInvoice>${DataSource#ConsolidatedInvoice}</cus:ConsolidatedInvoice>
            <cus:CreditReviewCycleName/>
            <cus:CreditAnalystName/>
            <cus:CreditLimit/>
            <cus:CreditCurrencyCode/>
            <cus:StatementDeliveryMethod>${DataSource#StatementDeliveryMethod}</cus:StatementDeliveryMethod>
            <cus:OrderAmountLimit/>
         </typ:customerProfile>
      </typ:updateCustomerProfileAsync>
   </soapenv:Body>
</soapenv:Envelope>

Provide the Username and Password of the Application User you intend to use to update the Classes. Test out a few customers first one-by-one before doing a full bulk load to ensure you get the correct output.

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Managing Customer Bankruptcy in Oracle Fusion Applications

What is Bankruptcy?

Bankruptcy is a legal process by which a person or organization declares inability to pay outstanding debts.

How do we handle this process in the Collections application? 

A bankruptcy request is initiated on behalf of the customer. So the customer would let a collector know that they have started this legal process. And then the collector would go in to the application and initiate this process to make sure that collection activities are suspended.

How do I initiate a bankruptcy request?

The bankruptcy request are basically sent to an appropriate person for approval. There is a workflow process that will route that approval to a collections manager so that they can look at the request and approve or reject. 

After a bankruptcy request has been submitted and potentially approved, that bankruptcy request can be withdrawn. A notification is sent to the collections manager to approve that withdrawal request.  Once that bankruptcy withdrawal request is approved, the customer status switches from bankrupt to delinquent.

What configurations are necessary to use these bankruptcy requests functionality?

Enable Bankruptcy

There is an important setting in Global Preferences that needs to be turned on for your organization to use these functionalities. The setting is "Enable Bankruptcy". If this option is set to Yes, the Bankruptcy subtab appears under their Profile tab in the Collections work area.

Go to the Functional Setup Manager, under the Financials Offering, Collections Functional Area, go to the task "Manage Collections Preferences". At the top we have Global Preferences. Locate the Enable Bankruptcy option right at the bottom of the Global Preferences and set it to Yes. 

Note that this is not a setting that can be enabled for one business unit only or for a group of business units. It's something that's going to be available for all business units.

Bankruptcy Reasons

Bankruptcy Reasons allow you to report and track different types of bankruptcy requests. These are very useful for reporting and tracking purposes.

To add more Bankruptcy Reasons, Go to the Functional Setup Manager, under the Financials Offering, Collections Functional Area, go to the task "Manage Collection Lookups". Look for the Lookup type of "Bankruptcy_Disposition_Reason". These are all associated with a common set ID. There are already seeded reasons (Entered in Error, File for Bankruptcy, and Reorganized) but you have the option to add more to the list. 

How do we process a bankruptcy request? 

To actually initiate the bankruptcy request, navigate to the Collections work area and you select the customer in question and simply click on the "Request" button under the bankruptcy sub-tab. The approval workflow kicks in and routes a notification to the appropriate person, that Collections manager or supervisor that's supposed to review their request and approve or reject.

What is the impact of Bankruptcy?

All accounts and sites under that customer and all transactions will be suspended. Collection activities are also suspended and delinquent transactions no longer appear in the Collections work area. In addition, the customer will show a status of bankrupt.

A collector can still find the customer and view the transactions associated with the customer. But they won't be able to perform any Collections activities, such as receiving a payment, or even putting in a payment promise, or dispute a transaction because, again, the customer has filed for bankruptcy. They'll be unable to make payments.

What Type of Information do I need to store for Bankrupt Customers?

There may not be a field in the Collections application to capture information specific to your organization such as claims, attorneys involved, filing locations. This can be handled by Descriptive Flexfields. Descriptive Flexfields are fields that you can use to store information unique to your organization, your industry, or for special circumstances or scenarios like this one.

Below is a step-by-step video on how to Manage Customer Bankruptcy in Oracle Fusion Applications:


For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Creating a Customer Paying Relationship Assignment in Oracle Fusion Applications

This article will demonstrate how to create a Customer Paying Relationship Assignment in Oracle Fusion Applications. As a prerequisite, you need to have the role "Customer Data Steward" assigned to the desired user. For a demonstration on how to assign the role, check out the video below:


What is a paying relationship? 

A paying relationship is a configuration that enables customers to apply receipts to the transactions of related customers.So For example, you have two customer entites that are related. Maybe they roll up to the same corporate parent. A paying relationship enables the parent company to pay the bills for its subsidiaries, or a subsidiary wants to pay for the bills of the other subsidiaries. So this means the paying relationship allows you to manage these types of scenarios in the receivables obligation where a customer wants to pay the bills of a related entity.

The idea with party relationships is to model your customer records according to the way you conduct your business. A party relationship represents the way in which two entities interact with each other based on the role that each entity takes with respect to the other. 

There are two different types of paying relationships: party paying relationships (we'll call it PPR), and customer account relationships (CAR). 

What is the difference between the two?

In the simplest terms, PPR is at the Party Level (including the Accounts, Sites and Transactions) while CAR is only at the Account Level. 

Party paying relationships provide one party with access to another party's accounts and transactions. You may have a party with five accounts underneath and another party with three accounts underneath. And those eight accounts are going to be related to each other because the parties at the top are related.

Meanwhile, Customer Account Relationship is a flat relationship between two customer accounts only. A relationship at the customer account level is flat in the sense that it only involves one account on one side and another account on the other side. 

How do I Create a Party Paying Relationship?

To create a Customer Paying Relationship Assignment, go to the Functional Setup Manager > choose the "Financials" Offering > Search for the task "Manage Customer Paying Relationship Assignment".

From the Manage Customer Paying Relationship Assignment page, View the seeded Paying Relationship Assignment set or add a new one by clicking on the  "+" Icon. 

Add the preferred Hierarchy Type and the preferred Paying Relationship.

The Pay Below Paying Relationship consists of parties paying for their own transactions and the transactions of all parties that are lower in the hierarchy. What this means here is that we are going to have to build a hierarchy as a requirement, as a prerequisite, to a party paying relationship. For more information on creating party hierarchies, check out a separate article: Create a Party Hierarchy in Oracle Fusion Applications.

The Pay Any Paying Relationship means that any party in the hierarchy can pay for each other's receivable bills, regardless of where they are in the sequence. Any party within the relationship can pay for the accounts of any other party within the relationship.

Below is a quick video demonstration on how to Create a Customer Paying Relationship Assignment in Oracle Fusion Applications:



For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Customer Statements in Oracle Fusion Applications

What's the difference between a statement and a balance forward bill?


A statement is an information document that provides a customer with a complete record of transaction, receipt, and adjustment activity over a specified time period.

A balance forward bill is a single bill presented for payment that consolidates the open debit items of a customer over a specified time period. You use this instead of sending a separate invoice for each transaction.

Steps in Sending Customer Statements
  1. Make the that the the "Send Statements" checkbox is ticked at the Receivables Customer Profile Class. more on this at another article Defining a Customer Profile Class in Oracle Fusion Applications
  2. Go to Customer Site & Define if the customer site will be used for statements
  3. Submit the Customer Statement Program
Customer Statements Delivery Method
  1. Print
  2. Email
This can be set at either Customer Profile Level, Account Level or at the Customer Site level.

Customer Statement Defaults

Customer statements defaults such as Email From, Reply To, Name, Email Subject, among others, can be setup via Manage Receivable System Options.



Customer Statement Cycles


Statement Cycles are configurations that control the frequency of the sending of Customer Statements. More details on this can be found on another article: Overview of Managing Statement Cycles in Oracle Fusion Applications

For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Overview of Customer Receipts in Oracle Fusion Applications

What are Customer Receipts?

Customer receipts are documents that indicate that customers have received the provided goods and/or services from the Organization. This can be in the form of a Physically printed paper receipt or sent electronically (via a Lockbox) or via a Email containing a PDF. This will then be entered in the application, either manually one by one or in Bulk via a Spreadsheet.

How are Receipts Applied?

As mentioned above, once the receipt has been sent to the organization, it can either be entered manually one by one or in Bulk via a Spreadsheet. Once entered into the application, it can then be applied to an existing receivable transaction such as an Invoice, Credit Memo or Debit Memo. This will then update Customer Balances. If the receipt has been fully applied, it can then be cleared. The Receipt can then be matched to a Bank Statement line and reconciled using Cash Management. 

Below demonstrates a Receipt application against a Transaction in Oracle Fusion:




Receipt Creation Types

Receipts can either be created Manually (from the browser or via a Spreadsheet) or Automatically. Receipt Types such as Standard, Miscellaneous and Lockbox Receipts can both be created Manually from the browser or via a Spreadsheet, while Automatic Receipts can support Bank Account Transfers or Credit Cards (note: Credit Cards are currently only supported in Fusion on-premise. Will be available soon in Cloud as well).

What are SmartReceipts?


What are Lockbox Receipts?

Lockbox Receipts is a service that most corporate banks offer for a long time. Banks collect all our receipts for us, produces an electronic file, and we then take that electronic file, pull it through what is known as a Lockbox. It requires a very tight integration between your customer and and your bank provider.  

The benefit of using Lockbox Receipts is less manual intervention, speeds up collections, and converts your receivables into cash much more quickly. In case there are any issues with the file that the Bank has sent, there is an option to correct these errors using a Spreadsheet via FBDI.


For more full-detailed Tutorials and Tips, check out #TheOracleProdigy at https://lifeofanoracleprodigy.blogspot.com/
Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Creating a Customer in Oracle Fusion Applications

This article will show you how to create a Customer in Oracle Fusion Applications. 
First, navigate to Receivables > Billing from your Welcome Springboard:


On the Billing screen, click on the Task Panel, and click on the "Create Customer" function:



Fill up the required fields such as:

  • Customer Type - You have two options: Organization or Person. Choose Organization if this Customer is an Entity, and Person if this Customer is a direct individual.
  • Name - The Identifying name of the Customer
  • Registry ID - This is the Auto generated Customer ID as based on the Trading Community Architecture
  • Account Number - This is the Auto generated Customer Number that Oracle uses internally
  • Account Type - You have two options: External (for external customers) or Internal (usually used for Subsidiaries)



On the Address section, fill up the fields such as Site Name and the appropriate Address.



On the Address Purpose section, make sure to add the "Bill To" and "Ship To" purpose as these are the two most important purpose of a Customer Site.


Click on "Save and Close" to save your work.


To review and edit your inputs, you may search your newly-created customer from the "Manage Customers" screen:



Go to the Customer's Site and on the "Profile History" tab, click on the "Create Site Profile" button:



On the "Create Site Profile" screen, choose the appropriate Profile Class to auto-populate most of the fields on the Customer, and change other fields that are not applicable. Check another article to know more about Customer Profile Classes. Click on "Save and Close" to save your work.



Below is a quick video demonstration on Creating a Customer in Oracle Fusion Applications:




Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Defining a Customer Profile Class in Oracle Fusion Applications

What is a Customer Profile Class?

Customer profile Class is a master data setup object that holds attributes that are important to the interaction between the organization and customers in terms of their selling relationship. It holds details such as the Customer's creditworthiness, credit tolerance, credit limit, its default payment terms, statement configurations, and its assigned collector.  A Customer Profile class is also used drive how the system will match receipts together with their invoices and defines how invoices are grouped together. 

Is Customer Profile Class a Required Setup?

Yes, every customer in the system must be associated with a profile class before it can be created.

How does one create a Customer Profile Class?

Below is a Step-by-Step guide on creating a Customer Profile Class in Oracle Fusion Applications:
  1. Navigate to Setup and Maintenance > Task Panel > Search:




  2. Search for "Manage Receivables Customer Profile Classes":

  3. In the "Manage Receivables Customer Profile Classes" screen, you can search for an existing Profile Class to review existing setups. Since we'll be creating a new Profile Class for this article, click on the "+" Icon to add a new Profile Class:


  4. In the Create Receivables Customer Profile Class" screen, fill up the required fields such as:
    • Profile Class Name and Description - Identifier for the Customer Profile Class
    • Collector - Identifies the Collector responsible for Customers under this Profile Class
    • Tolerance - Defaulted to 0%
    • Allow Discount - Indicates if Customers under this Profile Class are allowed to have a discount

    You may also fill up some of the important optional fields below:
    • Credit Analyst - Person responsible for Reviewing Customers under this Profile Class
    • Credit Classifications - Identifies the Risk Level of Customers under this Profile Class
    • Credit Review Cycle - Review Frequency for Customers under this Profile Class
    • Credit Limit - The Maximum Credit Amount allowed for Customers under this Profile Class
    • Order Amount Limit - The Maximum Amount allowed per Order for Customers under this Profile Class
    • Conversion Rate Type - Defaulted to Corporate
    • Payment Terms - Indicates the Number of Days Customers under this Profile Class should pay their due amount


    • Match Receipts by - Identifies how Receipts will be matched to Customers under this Profile Class
    • Send Statements, Credit Balances, Dunning Letters - Identifies if Statements, Credit Balances and Dunning Letters should be sent to Customers under this Profile Class
    • Preferred Contact Method - Identifies how Customers under this Profile Class should be contacted for Dunning and Credit Balances
    • Statement Preferred Delivery Method - Identifies how Customers under this Profile Class should be contacted for Statements








  5. In the "Late Charges" Tab, Indicate if Customers under this Profile Class is allowed to have Late Charges. If checked, indicate important fields such as Calculation Method, Receipt Grace Days, Interest Days Period, etc. 








  6. Still in the "Late Charges" Tab, in the Currency Settings, add a currency and the Minimum Amounts for Receipt, Statement, Dunning and Invoicing. To know more about Late Charges, check out a separate detailed article: Overview of Processing Late Charges for Receivables in Oracle Fusion Applications.



  7. Once Done, click on "Save and Close" to save your inputs.
  8. You may review your newly-created Customer Profile Class by going back to the "Manage Receivable Customer Profile Classes" page and searching it using its Identifying name:

Below is a quick Video Demonstration of how to create a Customer Profile Class in Oracle Fusion Applications:


Follow The Oracle Prodigy on Facebook (https://www.facebook.com/theOracleProdigy/) and Twitter (https://twitter.com/D_OracleProdigy)

Recent Posts

SQL Fundamentals

Introduction to SQL and Syntax What is SQL? SQL stands for Structured Query Language. is a standard programming language for accessing datab...

Top Posts