It is important to know that Virtual Trader does not modify any of Oracle’s database objects, which means that we are largely upgrade independent and any database changes by host system can be accommodated in a client layer, that is maintained through front-end forms.
As an endorsement of this approach, Virtual Trader has been approved for Oracle On-Demand ™ and we have a mixture of customers that run our solution on both hosted and non-hosted platforms.
Virtual Traders approach to Oracle development is to use the technology and coding standards that are provided and well documented for the host system. This means that the solution seamlessly integrates together and your IT team doesn’t have another set of technologies to deploy.
In fact, if you were to customize your existing Oracle EBS today, you would be using the same tools and techniques that we do.
Because we have utilized standard Oracle technology such as Oracle Forms, BI, Java and PL/SQL you can feel confident in the solution we provide.
Your users can access our front-end forms and concurrent processes through our default Oracle responsibility or sub-divide this menu to tailor it to your needs and integrate it with your existing processes. This approach reduces the total cost of ownership of your solution.
Virtual Trader Schema & Oracle On Demand
Virtual Trader is installed using the FNDLOAD processes, which your DBA will be familiar with. The tables and indexes reside in their own database schema, which complies with the Oracle naming standards for a custom application.
All the documented coding and security standards for operation with Oracle EBS have been observed. Virtual Trader is also approved for operation within an ‘Oracle On-Demand ™’ environment and many of our clients have already adopted this approach.
A variety of standard reports are produced through the Oracle standard facility of BI Publisher. This offers a variety of output formats such as PDF and Excel and offers client control over output layout through templates.
In addition to standard reports, a number of reporting views of the Virtual Trader architecture are provided to facilitate custom report writing.
Interfaces & API
Virtual Trader accommodates driving common Oracle interfaces such as General Ledger, Payables & Receivables etc., but allows mapping to any available interface.
Allows mapping to interfaces across instances, and mapping to interfaces of non-Oracle applications and customizations.
Allows directly driving published API functionalities within Oracle EBS for real time Oracle updates.
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.
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.
Virtual Trader is very flexible in the way that it captures data. A number of seeded methods of doing this are provided as standard.
Some of the most common collection methods are:
• Data can be gathered as it passes through the EBS open interfaces.
• Collected with our built-in data collectors that can be scheduled, as you require.
• Sent directly into our interfaces by your custom application.
• Triggered off table events
• Gathered from SLA and other Business Events
• Loaded by flat file or spreadsheet.
• Oracle Desktop Integrator ™
• Data loader program