Oracle Integration, Multi-Instance & Other Systems
Often Multinational companies struggle to balance the benefits of remaining within their core ERP system functionality and trying to meet all of the intercompany requirements of their business. Virtual Trader has been specifically designed to deliver the benefits of both of these approaches.

By fully integrating with the host Oracle EBS environment, retaining an Oracle user interface, sharing many standard functions and being ‘Oracle On Demand’ compliant, Virtual Trader delivers the benefits of being consistent with the skills of in-house EBS teams.

However, Virtual Trader still retains a vital independence, with all of its components stored in a separate schema within the database. For companies unable or unwilling to operate a single global instance, Virtual Trader can also support intercompany activity across multiple instances. It can handle different versions of Oracle EBS, and even accommodate non-Oracle applications or existing Oracle customizations.

Responsibilities & Menus

In keeping with the full integration of Virtual Trader and the E-Business Suite, the system is supplied with it’s own Oracle Responsibility called ‘Virtual Trader Super-User’ and Menu structure.

Because these are standard Menu items, they can be copied to other Oracle Menus that are deployed in order to provide integration to other business processes.

This can also improve security to parts of the Menu, based on the Oracle Responsibilities given to users.

Job Submission

Our transaction engines and reports are provided as concurrent jobs, which are run and managed through the Oracle Standard Job Submission system.

This supports on demand or scheduled submission, and incorporation into Request Sets in conjunction with standard Oracle processes and Import jobs.

To promote automation, Virtual Trader can provide email notification where intervention is required

Calendars & Currencies

To prevent duplication of data and configuration, Virtual Trader integrates with the standard calendar definitions, currency and currency conversion facilities within Oracle EBS.

This provides consistent exchange rate calculations across the whole E-Business Suite.

Virtual Trader can also provide triangulation between two currencies that are not maintained directly, as long as there is a common currency maintained.

Source & Target Definitions

The sources from which originating transactions are captured, and the targets to which the resulting outbound transactions are sent are configurable.

Oracle source and targets are provided as standard, but the configurability of the product allows multiple instances to be accommodated, and non Oracle applications and customizations to be incorporated.

Virtual Trader Schema & Oracle On Demand

Virtual Trader is installed in the normal way and all its components are stored in a separate Schema within the database.

All the documented standards for operation with Oracle EBS have been observed, and Virtual Trader is approved for operation within ‘Oracle On Demand’.

Interfaces & API

Virtual Trader accommodates driving common Oracle interfaces such as General Ledger, Payables & Receivables etc., but allows mapping to any available interface.

Virtual Trader supports this mapping across instances, also mapping to interfaces of non-Oracle applications and customizations.

Virtual Trader also facilitates directly driving published API functionalities within Oracle EBS for real time Oracle updates.

Instance Views

All functionality within Virtual Trader that touches Oracle does so through ‘Views’. This approach provides a protective layer between Virtual Trader and the architecture of the underlying system.

These ‘Views’ are part of Virtual Traders client layer and can be modified to change the relationship to Oracle where necessary. New definitions can be added to work with multiple instances or even non-Oracle applications.

Dynamic Interfaces

This function within Virtual Trader facilitates retrieving additional data from the source transaction.

The data can be on the source transaction, or on any table related to that transaction.

This data can be used directly within the business logic, included on outbound transactions or simply stored for reporting purposes.