Thursday, June 5, 2025

Oracle Fusion vs EBS Procurement: 10 Key Differences

Transitioning from Oracle E-Business Suite (EBS) to Oracle Fusion Procurement is a major shift for functional consultants. While the core principles remain, the architecture, user interface, and functional capabilities differ significantly. In this post, we’ll explore 10 specific, real-world differences to help Oracle consultants navigate this transformation with confidence.


1. Procurement Dashboard and Navigation

Fusion: Fusion provides a role-based Procurement Work Area that consolidates tasks, analytics, and alerts into a single dashboard. Users with appropriate roles can view procurement tasks, supplier negotiations, purchase orders, and KPIs from one screen. The UI is modern, with intuitive navigation and actionable infolets.

EBS: EBS lacks a unified dashboard. Each module (iProcurement, Purchasing, Sourcing) has separate responsibilities and menus. Navigation is often fragmented, requiring users to switch between forms and responsibilities.

Consultant Tip: Understand the role-based UI structure in Fusion and how privileges are tied to job roles for seamless task execution.

Fusion vs EBS Procurement Dashboard and Navigation
Fusion vs EBS Procurement Dashboard and Navigation



2. Business Units vs Operating Units

Fusion:

  • Fusion Procurement replaces the traditional Operating Unit concept with Business Units (BUs), designed to better align with modern organizational structures.

  • Types of Business Units:

    • Requisitioning Business Unit: The BU that raises the requisition (request to buy goods or services).

    • Procurement Business Unit: The BU responsible for creating purchase orders and managing supplier contracts.

    • Servicing Relationship: A setup allowing one BU to procure on behalf of another, supporting shared services or centralized procurement models.

Flow (Fusion):

Requisitioning BU → [Service Provider Setup] → Procurement BU → Purchase Order

Real Example:

A company has two divisions: Manufacturing and Marketing.

  • Manufacturing BU raises requisitions for raw materials.

  • Procurement BU (centralized team) processes purchase orders and supplier negotiations for both divisions.

  • The servicing relationship allows the Marketing Business Unit to create purchase requests, which the Manufacturing Business Unit can handle and fulfill when necessary.

This separation improves control and reporting by BU, enabling shared service centers and better compliance.

EBS:

  • EBS uses Operating Units (OUs) under the Multi-Org Architecture, which represent the legal or operational entities within the organization.

  • Each OU manages its own transaction data and user responsibilities.

  • Typically, procurement activities happen within the same OU, which may limit centralized purchasing capabilities.

Real Example:

In the same company, EBS Operating Units could be:

  • OU1: Manufacturing Division

  • OU2: Marketing Division

Each OU handles its own procurement independently, making it difficult to consolidate supplier management or centralize purchases without complex cross-OU configurations.

Consultant Tip: In Fusion, carefully design Procurement BUs, Requisitioning BUs, and their relationships during implementation, especially for shared service models.


3. Self-Service Procurement Experience

Fusion: Fusion's Self-Service Procurement (SSP) offers a modern, consumer-like experience. It includes guided buying, catalogs, punch-out integration, smart forms, and flexible search options. Employees can easily shop for items with category-based restrictions and approval visibility.

EBS: EBS iProcurement supports catalogs and smart forms, but the interface is outdated, navigation is slower, and punch-out configuration is more complex.

Fusion vs EBS Self-Service Procurement Experience
Fusion vs EBS Self-Service Procurement Experience

Consultant Tip: Emphasize Fusion’s improved user experience in training and change management for end-users.


4. Workflow and Approval Management: BPM vs AME

Fusion: Fusion uses BPM (Business Process Management) Worklist for approvals. Approvals are managed via rules configured in BPM Worklist Composer, allowing for conditions based on roles, job levels, amounts, and document types.

EBS: EBS uses AME (Approval Management Engine) or standard workflow builder. Configuration often requires technical support and lacks the intuitive, self-service capability of BPM.

Flow (Fusion BPM Example):

Requisition Submitted → BPM Rule Check → Approver Assigned → Approved/Rejected

Consultant Tip: Learn how to create and troubleshoot approval rules in Fusion BPM, especially for requisitions, POs, and supplier registration.


5. Supplier Management and Portal

Fusion: Fusion includes a fully integrated Supplier Portal, supporting self-registration, onboarding, profile management, sourcing participation, and communication. It supports internal supplier qualification and supplier lifecycle management (SLM).

EBS: Supplier Lifecycle management & iSupplier module in EBS is web form-based, with limited workflow-driven onboarding. Supplier Hub exists but lacks integration and automation features compared to Fusion.

Flow (Fusion):

Supplier Registration → Approval Workflow → Spend Classification → Qualification & Onboarding

Consultant Tip: Configure Supplier Registration flows in BPM and define approval hierarchies for streamlined onboarding in Fusion.


6. Role-Based Access Control (RBAC) vs Responsibilities

Fusion Role-Based Access Control (RBAC) vs EBS Responsibilities
Fusion Role-Based Access Control (RBAC) vs EBS Responsibilities

Consultant Tip: In Fusion, managing role provisioning and data access is more complex but more flexible. Understand Security Console usage.


7. Document Styles and Rules

Fusion: Fusion allows for Document Styles (Standard PO, BPA, CPA) which are configurable. Each style defines the allowed document types, numbering, and user controls.

EBS: In EBS, document types are static and controlled via Document Types form with fewer options.

Consultant Tip: Use Document Styles to streamline different procurement flows such as capital purchases, recurring services, or catalog orders.


8. Smart Forms and Guided Buying

Fusion: Fusion supports Smart Forms with advanced configuration. You can define category-specific templates, charge accounts, default suppliers, and attachments. Guided buying helps requesters choose correct paths.

EBS: Smart Forms exist in iProcurement but lack many Fusion features such as dynamic defaults and rules-based behavior.

Consultant Tip: Use smart forms to standardize service requests like AMC, consulting, and facility management.


9. Procurement Contracts Integration

Fusion: Fusion offers integrated Procurement Contracts tied to Purchase Agreements and Orders. You can create clauses, templates, and track compliance. Contracts auto-populate terms in downstream documents.

EBS: EBS contracts are separate or part of CLM module. Integration with PO is minimal.

Consultant Tip: Promote use of contract templates and approval rules for audit readiness.


10. Reporting: OTBI vs BI Publisher

Fusion OTBI vs EBS BI Publisher
Fusion OTBI vs EBS BI Publisher

Fusion Example: A procurement manager wants to track aging requisitions by buyer. Using OTBI, they create a real-time dashboard showing requisitions pending approval over 7 days, with filters by business unit and buyer. No need for SQL coding—just drag-and-drop.

EBS Example: To get similar data in EBS, a technical user must create a BI Publisher report or develop a custom form/report. This often involves writing SQL, deploying RDF/XML templates, and maintaining concurrent programs.

Consultant Tip: Leverage OTBI for real-time visibility into POs, supplier performance, and requisition aging reports. Encourage client business users to adopt OTBI to reduce dependency on technical teams.


💡 Final Thoughts

Understanding these key differences isn’t just about knowledge – it’s about being project-ready. Fusion Procurement introduces new functional layers and best practices that demand deeper configuration knowledge and proactive functional leadership. Whether you're migrating clients or supporting new implementations, mastering these areas will make you stand out as a capable Oracle Functional Consultant.

Monday, June 2, 2025

Oracle R12 Period Close: Resolving Pending Transactions

Closing an accounting period in Oracle EBS R12 is a critical task that ensures accurate financial reporting and data integrity. However, pending transactions can hinder this process. This guide provides a step-by-step approach to identifying and resolving these transactions, ensuring a smooth period close.

Learn how to resolve pending transactions in Oracle EBS R12 to ensure a smooth period close. Step-by-step guide for accurate financial reporting.

⎆Accessing Pending Transactions

To view pending transactions:

  1. Navigate to: Inventory > Cost > Accounting Close Cycle > Inventory Accounting Periods.

  2. Select the relevant open accounting period.

  3. Click on the [Pending] button.

The system displays three zones:

  • Resolution Required: Transactions that must be resolved before closing the period.

  • Resolution Recommended: Transactions that should be addressed to prevent future issues.

  • Unprocessed Shipping Transactions: Shipping transactions that need resolution prior to period closure.


 Resolution Required Transactions

These transactions must be addressed to proceed with period closure:

1. Unprocessed Material Transactions

  • Description: Transactions residing in the MTL_MATERIAL_TRANSACTIONS_TEMP table, indicating they have not been fully processed.

  • Resolution Steps:

    • Navigate to: Inventory > Transactions > Pending Transactions.

    • Identify and review the unprocessed transactions.

    • Correct any errors and resubmit the transactions for processing.

2. Uncosted Material Transactions

  • Description: Transactions in the MTL_MATERIAL_TRANSACTIONS table without associated accounting entries.

  • Resolution Steps:

    • Run the Cost Manager to process uncosted transactions.

    • Ensure that all necessary costing setups are correctly configured.

    • Review and resolve any errors preventing costing.

3. Pending WIP Costing Transactions

  • Description: Unprocessed resource and overhead accounting transactions in the WIP_COST_TXN_INTERFACE table.

  • Resolution Steps:

    • Navigate to: Work in Process > Discrete > Costing > Pending Resource Transactions.

    • Review and process the pending transactions.

    • Address any errors that prevent successful costing.

4. Uncosted WSM Transactions

  • Description: Warehouse management system (WSM) transactions that have not been costed.

  • Resolution Steps:

    • Identify uncosted WSM transactions through relevant reports.

    • Ensure that all WSM transactions are correctly interfaced and costed.

5. Pending WSM Interface Transactions

  • Description: Transactions awaiting processing in the WSM interface.

  • Resolution Steps:

    • Review the WSM interface tables for pending transactions.

    • Process or correct the transactions as necessary.



⇒ Resolution Recommended Transactions

While these transactions do not prevent period closure, it's advisable to resolve them:

1. Pending Receiving Transactions

  • Description: Unprocessed purchasing transactions in the RCV_TRANSACTIONS_INTERFACE table, including purchase order receipts and returns.

  • Resolution Steps:

    • Navigate to: Purchasing > Receiving > Transactions.

    • Identify and process pending receiving transactions.

    • Correct any errors and resubmit as needed.

2. Pending Material Transactions

  • Description: Material transactions pending in the MTL_TRANSACTIONS_INTERFACE table.

  • Resolution Steps:

    • Navigate to: Inventory > Transactions > Interface Transactions.

    • Review and process pending material transactions.

    • Address any errors to ensure successful processing.

3. Pending Shop Floor Move Transactions

  • Description: Unprocessed shop floor move transactions in the WIP_MOVE_TXN_INTERFACE table.

  • Resolution Steps:

    • Navigate to: Work in Process > Move Transactions > Pending Transactions.

    • Identify and process pending move transactions.

    • Resolve any issues preventing successful processing.

Note: If these transactions remain unresolved and the period is closed, they cannot be processed later due to their transaction dates falling within a closed period.


 Unprocessed Shipping Transactions

Transactions in this category must be resolved before closing the period:

  • Description: Transactions in the WSH_DELIVERY_DETAILS table with a status indicating they are shipped but not fully processed.

  • Resolution Steps:

    • Navigate to: Order Management > Shipping > Transactions.

    • Identify and process pending shipping transactions.

    • Ensure that all shipping interfaces have been successfully completed.


🛠️ Best Practices for Period Close

  • Regular Monitoring: Consistently monitor transaction interfaces and pending transactions throughout the period to prevent accumulation of issues.

  • Concurrent Programs: Schedule and run necessary concurrent programs such as Cost Manager, Material Transaction Manager, and Move Transaction Manager to process transactions timely.

  • Reporting: Utilize standard reports like Unprocessed Material Transactions Report, Uncosted Transactions Report, and Pending Transactions Report to identify and address issues proactively.

  • Data Fixes: In cases where transactions are stuck due to data issues, collaborate with your DBA or Oracle Support to apply appropriate data fixes.


By diligently addressing all pending transactions and adhering to best practices, organizations can ensure a smooth and accurate period-end close process in Oracle R12.

If you require further assistance or detailed steps for specific transaction types, feel free to ask!

Assign Concurrent Programs in Oracle EBS: Step-by-Step

If you're attempting to run a concurrent program (like "Autoinvoice Import Program") but can't locate it under your responsibility (e.g., "Order Management Super User"), it's likely because the program hasn't been linked to that responsibility yet.

This guide walks you through the steps to assign a concurrent program to a responsibility in Oracle E-Business Suite.


Step 1: Identify the Request Group Linked to the Responsibility

  1. Log in using the System Administrator responsibility.

  2. Navigate to: Security > Responsibility > Define.

  3. Query the responsibility (e.g., "Order Management Super User").

  4. Note the Request Group Name associated with it (e.g., "OM Concurrent Programs").


Step 2: Add the Program to the Request Group

  1. Still under the System Administrator responsibility, navigate to: Security > Responsibility > Request.

  2. Query the Request Group Name you noted earlier (e.g., "OM Concurrent Programs").

  3. In the list, insert a new line and add the program name (e.g., "Autoinvoice Import Program").

  4. Save your changes.


Step 3: Verify the Program is Accessible

  1. Switch to the Order Management Super User responsibility.

  2. Navigate to: View > Requests > Submit a New Request > Single Request.

  3. In the Name field, enter the program name (e.g., "Autoinvoice Import Program").

  4. You should now see the program listed and be able to run it.


By following these steps, you ensure that the concurrent program is available under the desired responsibility.

Saturday, May 31, 2025

Mapping ISD under GST in Oracle EBS: Process Document

 Definition: Input Service Distributor (ISD)

Who is an Input Service Distributor (ISD) under GST? An Input Service Distributor (ISD) is a taxpayer that receives invoices for services used by its branches. It distributes the tax paid known as the Input Tax Credit (ITC), to such branches on a proportional basis by issuing ISD invoices.

 

Input Service Distributor (ISD) Under GST:

An Input Service Distributor (ISD) is a special type of GST taxpayer that plays a role in the distribution of the Input Tax Credit (ITC) for services to its branches or establishments. ISD is not involved in the direct supply of goods or services but acts as a conduit to allocate ITC to various units or branches that use the input services.


What is ISD in India:

ISD (Input Service Distributor) is a mechanism under the GST (Goods and Services Tax) framework in India where the head office (or a centralized office) receives invoices for services (like consulting, audit, legal, advertisement, etc.) that are used by multiple branches or units across different states. ISD facilitates the fair distribution of Input Tax Credit (ITC) to the respective branches.

 

How ITC is Distributed:

The Input Tax Credit (ITC) on the central services is distributed proportionately to different branches (based on their turnover or usage).

This distribution is done using a special invoice called the ISD Invoice.

Each branch or unit that receives the ITC must be eligible to use the credit (i.e., they must be registered under GST).

 

Conditions for Distribution:

The distribution is based on a pro-rata basis or a ratio as per the turnover of each branch, but the method has to be consistently applied.

No Direct Supply of Goods/Services: The ISD does not make any outward supply of goods or services; it only distributes the credit.

 

Registration: 

Business gets an ISD registration for the location handling shared services (common expenses).

Only one ISD registration per legal entity is allowed.

The location with receipt of service bills for common expenses must register as ISD.

ISD only applies to input services, not goods.

Parent Company needs to define Additional Inventory/OU with ISD Location and the first party needs to define at the OFI Setups.

 

Simplified ISD approach under GST that end users are required to follow

 

1.      Expense & GST Accounting:

ISD location receives invoices (Bill to) for common services (expenses).

The ISD location accounts for the common expenses.

 

    ISD location (Head office) claims ITC in GSTR-6

It pays the applicable GST on services received.

The GST paid becomes eligible for ITC (Input Tax Credit).

 

2.      ITC Allocation to Branches: 

The ISD allocates the ITC and proportionate expenses to branches under the same PAN.

This is done via internal transactions (manual intercompany AR Invoices) for the services used by each branch.

 

3.      Branches Claim ITC: 

Branches record accounts payable (AP) invoice received from ISD.

They apply the GST to claim the transferred ITC.


 

4.      Utilization & Settlement: 

Branches use the credited ITC to offset their output GST liabilities. Branches receive ITC and reflect it in their GSTR-3B

The ISD can offset its overall IGST/CGST/SGST liabilities against its ITC during GST return filing. 

 

Example of an Input Service Distributor (ISD)

Let’s take a real-world example to better understand the concept of ISD under GST:

Example:

Suppose there is a company called ABC Ltd., which has its head office and 3 regional offices in different states. ABC Ltd. centralizes certain services like legal services, accounting, and IT support in its head office.

The head office of ABC Ltd. receives an invoice for legal services worth ₹100,000 and pays a GST of ₹18,000 on the service (₹100,000 * 18% GST).

The head office is registered under GST and is eligible to receive the Input Tax Credit (ITC) of ₹18,000 on these services.

However, the legal services are not only used by the head office but are also used by the 3 regional offices. Therefore, the GST credit needs to be distributed among the head office and regional offices based on their turnover.

Let’s assume that the turnover of the offices is as follows:

Head office: ₹50,00,000

Regional office 1: ₹30,00,000

Regional office 2: ₹10,00,000

Regional office 3: ₹10,00,000

The total turnover is ₹1,00,00,000.

Now, the ISD will distribute the ₹18,000 ITC to each office based on their turnover proportion.

Calculation:

Total turnover = ₹50,00,000 (head office) + ₹30,00,000 (regional office 1) + ₹10,00,000 (regional office 2) + ₹10,00,000 (regional office 3) = ₹1,00,00,000.

Each office’s share of the ITC:

Head office: ₹18,000 * (₹50,00,000 / ₹1,00,00,000) = ₹9,000

Regional office 1: ₹18,000 * (₹30,00,000 / ₹1,00,00,000) = ₹5,400

Regional office 2: ₹18,000 * (₹10,00,000 / ₹1,00,00,000) = ₹1,800

Regional office 3: ₹18,000 * (₹10,00,000 / ₹1,00,00,000) = ₹1,800

Result:

The Head office will retain ₹9,000 of the ITC.

Regional office 1 will get ₹5,400 of the ITC.

Regional office 2 and 3 will get ₹1,800 each.


Reference Document Source: 

1. OFI: What is The Functionality To Raise Input Service distributor (ISD) Invoice And Is There Any Separate trial balance Available for that? (Doc ID 3042592.1)

2.    OFI: Need To Understand The Functionality For (Input Service Distribution) ISD Under GST (Doc ID 2287567.1)

Oracle Sourcing Module: Features with Real-Life Examples

1. Request for Information (RFI)

- Used to gather preliminary information from suppliers before a formal procurement process.
Example: A company sends an RFI to IT vendors to understand their capabilities before issuing an RFQ.

2. Request for Quotation (RFQ)

- Used to invite detailed pricing and delivery quotes from suppliers.
Example: After RFI review, an RFQ is issued to shortlisted vendors for IT equipment pricing.

3. Auctions

- Supports auctions for real-time competitive bidding.
Example: A auction is conducted for office supplies where suppliers lower prices to win the deal.

4. Sealed and Blind Quotes

- Sealed: Quotes remain hidden from both competitor suppliers and the buyer until the deadline.
- Blind: Suppliers cannot see competitors’ quotes, but the buyer can view all submitted quotes once they are submitted by the suppliers.

Example: For a confidential project, sealed bidding is used to ensure impartiality.

5. Negotiation Templates

- Templates standardize and speedup sourcing events with predefined formats, controls, questions and terms.
Example: A company uses a template for yearly hardware procurement to save setup time.

6. Terms and Conditions Acceptance

- Suppliers must accept terms and conditions before submitting bids.
Example: Suppliers agree to standard T&Cs before quoting for an infrastructure RFQ.

7. RFQ Controls

-  Purpose: Manage how suppliers interact with the RFQ and how the negotiation is conducted.

Features Include:

-      Invited Supplier Participation: Only specific, approved suppliers can view and respond to the RFQ.

-      Manual Early Close: The RFQ can be manually closed before the scheduled close date if required.

-      Extend Close Date: The RFQ close date can be extended based on business needs or low participation.

-      Allow Multiple Quotes: Suppliers can submit more than one quote if enabled, allowing for different pricing or delivery scenarios.

-      Allow Quote to Alternate Lines: Suppliers can propose quotes for alternate items or configurations if allowed.

-      Response Style Options: Open, Sealed, or Blind quote settings can be configured for fairness and transparency.

-      Negotiation Style: Can be set as RFQ, Auction, or RFI depending on the requirement.

Example: A procurement officer sets up an RFQ where only shortlisted suppliers are invited. As few suppliers respond initially, they extend the RFQ deadline. A supplier submits two different quotes for alternate products on the same line item, which are all captured and evaluated.

 

8. Attachment Upload with Quote Submission

- Suppliers can upload supporting documents with their quotes.
Example: A vendor submits compliance certificates with their quote for lab equipment.

9. Scoring and Evaluation

- Enables objective bid evaluation based on price, delivery, etc.
Example: Proposals are scored for cost, delivery time, and warranty to identify the best supplier.

10. Questionnaires

- Add detailed questions for suppliers within sourcing events.
Example: An RFQ includes a questionnaire on environmental compliance and certifications.

11. Collaboration Team

- Involve technical, finance, and legal teams in sourcing decisions.
Example: A technical expert is included in evaluating the technical specs of vendor bids.

12. Award Analysis

- Analyze bids using tools and reports to support award decisions.
Example: The team compares total cost and delivery options to finalize a vendor.

13. Auto Awarding

- Automatically awards bids based on scoring thresholds.
Example: The system auto-selects the vendor with the best score when the event closes.

14. Award Approval

- Route award decisions through approval hierarchy.
Example: The final award is reviewed and approved by procurement and legal teams.

15. Purchase Order (PO) Creation

- Converts awarded negotiations into POs in Oracle Purchasing.
Example: A PO is auto-generated and sent to the awarded supplier after approval.


Oracle iSupplier Portal: Real-Life Usage in Procurement

 

1. Purchase Order (PO) Collaboration

- Suppliers can view and confirm purchase orders (POs) online.
- They can request changes to quantity, price, or delivery dates.
- Partial shipments can also be proposed by suppliers.

Example: A supplier logs into the portal, sees a new PO, confirms it, and requests a delivery date change.

2. Shipment Management

- Suppliers submit Advance Shipment Notices (ASN) to notify buyers about shipments.
- Advance Billing Notices (ABN) can also be sent along with ASN for early invoice processing.

Example: A supplier sends an ASN and ABN before dispatching goods, helping the buyer prepare for receiving and payment.

3. Invoice and Payment Tracking

- Suppliers can create and submit invoices online.
- They can check the status of their payments at any time.

Example: A supplier sees their invoice has been approved and scheduled for payment next week.

4. Inventory Management

- Vendors can manage inventory at the buyer’s site using Vendor Managed Inventory (VMI).
- Consigned Inventory allows suppliers to retain ownership until items are used.

Example: A supplier keeps stock at a buyer's warehouse and gets notified when it runs low.

5. Supplier Profile Management

- Suppliers can update their contact info, tax details, and certifications.
- They can manage user access for their team members.

Example: A supplier updates their GST number and adds a new contact person.

6. Communication and Collaboration

- Suppliers receive real-time alerts for new orders and changes.
- Files like product specs and agreements can be exchanged online.

Example: A supplier is notified of an urgent PO and sends back the signed terms through the portal.

7. Improved Accuracy and Efficiency

- Automation reduces manual work and errors.
- All information is centralized and easily accessible.

Example: No need to call or email—the supplier finds PO, ASN, and payment info in one place.

8. Internal View Usage for Buyers

- Buyers can use 'Internal View' to monitor all supplier transactions.
- It helps with auditing, tracking acknowledgments, and ensuring compliance.

Example: A buyer checks if a supplier acknowledged a PO and submitted an ASN as expected.

Oracle Supplier Lifecycle Management: Real-Life Use Cases You Should Know

1. Supplier Registration and Onboarding

Use: Automates the supplier registration process through a self-service portal. Buying organization can invite the supplier for registration or Supplier can proactively self-register through the iSupplier portal/ SLM.

Features:

        - Necessary information collection: Suppliers need to be provided necessary information during online registration, like company details

        - Attachment of Necessary Documents: Suppliers can upload mandatory documents such as GST certificates, PAN, ISO certifications, and company profiles.

        - Terms and Conditions Acceptance (Optional): Organizations can configure the system to optionally prompt suppliers to accept terms and conditions during registration.

        - Multiple Levels of Approval (Optional): Approvals for new supplier registration can be routed through multiple stakeholders like Procurement, Finance, and Legal, based on the company’s policy.

Example: A supplier registers through the portal, provide necessary informations, uploads tax documents, and the registration is routed to Procurement → Finance → Compliance teams before activation.

2. Supplier Qualification and Approval

Use: Assesses supplier capabilities using qualification questionnaires.

Example: Before approving a supplier for raw materials, buying company can sends out a qualification questionnaire. Based on the responses and scoring, the supplier is either approved, rejected, or assigned corrective actions.

3. Supplier Profile Audit

Use: Facilitates internal audits to ensure supplier compliance and verify data accuracy.

Example: The Internal Compliance Team initiates an annual/periodic audit requesting updated profile information, ISO certification and insurance documents from key suppliers.

4. Supplier Performance Assessment

Use: Collects performance ratings of the suppliers from internal stakeholders of the buying organization based on KPIs like delivery time, quality, and responsiveness.

Example: A retail chain rates suppliers monthly on delivery timeliness and product quality. Underperforming vendors are reviewed and may be given improvement plans.

5. Notify Supplier

Use: Buyers can send system-generated notifications or manual messages to suppliers.

Example: A supplier receives an automated notification when their registration status changes or a manual message if, for instance, some documents are missing.

6. Online Chat and Collaboration Team Features

Use: Enables cross-functional team collaboration and real-time chat internally.

Example: Procurement, Finance, and QA collaborate using the 'Collaboration Team' feature to evaluate a high-risk supplier before onboarding.

7. Advanced Search Using User-Defined Attributes (UDA)

Use: Allows complex searches using standard and custom-defined attributes.

Example: A category manager filters suppliers with ISO 9001 certification and MSME status using UDAs.

8. Invitation List

Use: Manages the supplier invitation process during sourcing or registration.

Features:

        - Dynamic Invitation List: Based on rules like region, category, or UDA values, the system auto-generates eligible suppliers for events or registrations.

        It's also possible to create invitation list and add suppliers manually without using any rules.

Example: A buyer invites all suppliers for sourcing, or profile audit, tagged under 'Chemical Raw Materials' using invitation list.

9. Supplier Profile Information Change Request

Use: Allows suppliers to request changes to profile data, which is subject to buyer review.

Example: A supplier submits a request to update their bank account, address and contact number. Procurement reviews and approves the request before it is finalized in the system.

10. View and Edit Privileges for UDA

Buyers can create custom fields (UDA: User Defined Attribute) to capture supplier-specific information that isn’t available in standard supplier master attributes (e.g., Environment Certifications, CSR Ratings, MSME Code).

Use: Controls who can see or modify specific UDAs.

Example: Only the Finance team can edit 'Payment Terms' UDA, while others can view it only.

11. Single-Row and Multi-Row UDAs

Use:

        - Single-Row UDA: Captures individual fields such as PAN or GST number.

        - Multi-Row UDA: Captures tabular data like list of past audits or product certifications with expiry dates.

Example: A supplier uploads multiple ISO certificates in a multi-row UDA, each with issue and expiry dates, while contact info is stored in a single-row UDA.


Oracle Fusion vs EBS Procurement: 10 Key Differences

Transitioning from Oracle E-Business Suite (EBS) to Oracle Fusion Procurement is a major shift for functional consultants. While the core pr...