Selecting the Ideal Entities and Fields for a Successful Integration
Determine the Optimal Syncing Direction to Meet your Business Needs
A partner like Clarity can even go further with the off-the-shelf integration capabilities, by highly catering and customizing them based on the business analysis outcome of the needs analysis and discovery project phase. Your organization
should identify the key entities and fields that need integration in your business setting but your partner must be able to assist in this process. In many standard scenarios, the integration is going to include:
By including invoices and quotes, they can be sent from Oracle EBS into AspDotNetStorefront and enable the end user to complete a payment inside of AspDotNetStorefront on an invoice that originated in Oracle EBS. The user could also convert
a quote into a sales order, pay on AspDotNetStorefront, and then have the updated state return to Oracle EBS. The information of sales orders, invoices, and quotes is typically a two-way integration between AspDotNetStorefront and Oracle EBS through a bi-directional sync. This definitely isn't an absolute requirement but the most common
choice. Of course, it can be set up as a uni-directional sync if that’s what makes the most sense for your business.
Within the sales order syncing, the typical fields and related entities would include:
Once the order actually goes from AspDotNetStorefront into Oracle EBS, it is processed and then proceeds to fulfillment. During fulfillment, it's possible to
integrate the related data back into AspDotNetStorefront to provide a real self-service type of model for the end user. If there's a split shipment, the user can see whether an item is on backorder or if it is delayed. As items are
dispatched, or when the entire order is shipped, the user can interact with the dashboard in AspDotNetStorefront eCommerce to get the corresponding tracking information. If desired, whenever an order is received damaged, or if the end user
requests a refund because they perhaps ordered the wrong item, the AspDotNetStorefront eCommerce can send that data back to Oracle EBS. Thus, the two systems can effectively talk to each other and enable the end users to exercise any of the
different automated options you choose to make available.
In addition, it could prove useful to incorporate the catalog data from Oracle EBS into AspDotNetStorefront eCommerce, which can be done through a bi-directional sync as well. So you may initially bring baseline product data from Oracle EBS,
for example the SKUs and the manufacturer part numbers. Further options include custom fields, like basic description information, advanced attributes, and additional details that are specific to certain products or to the overall business
model. Care must be exercised to ensure the data comes into AspDotNetStorefront eCommerce in a presentable way that is standard for your industry. You may choose to include variants, variant masters, kits, visuals, and the ability to
dynamically generate relationships within AspDotNetStorefront based on the relationships within Oracle EBS. In a number of cases, this can extend to the ability to drill down and have an advanced builder or wizard for products and
relationships to categories associated with related products.
Finally, other fundamental pieces are pricing and inventory data, while making sure they are either syncing in real-time, or near real-time, between Oracle EBS and AspDotNetStorefront. It's further possible to integrate things like user
locations and set up omnichannel eCommerce within Oracle EBS and AspDotNetStorefront, and really to integrate any custom entities and fields that make sense for your business, either in your initial phase of your project or in later phases as
you continue to build on and expand your capabilities with this integration. As you can observe, there are quite a few nuances and details around multiple integration areas.