Proactively monitoring and addressing upcoming supply chain bottlenecks can have a direct impact on realizing revenue targets and meeting customer expectations. Leveraging Incorta Analytics, Perficient’s supply chain management solution for Oracle E-Business Suite provides a forward-looking view of inventory projections with increased visibility into SCM, order management, purchasing, and manufacturing.  

Watch the on-demand recording for a live demo of the supply chain dashboard and learn how this solution for Oracle EBS can help you: 

• Predict inventory shortages before they happen 
• Identify items with low projected days on hand and upcoming fill rates 
• Facilitate “make or buy” decisions and keep up with demand 

We are excited to announce our partnership with Incorta, the only unified data analytics platform that aggregates large complex data in real time with no data warehouse required.  Powered by Direct Data Mapping, Incorta can make tens of billions of rows of data across multiple source databases analytics-ready in a matter of minutes. Our new dedicated Incorta practice will enable our clients to leverage the platform to acquire, enrich, analyze, and act upon business data with unmatched speed, simplicity and insight.

In the 2021 Wisdom of the Crowds BI Market Study by Dresner Advisory, Incorta outperformed the overall sample of 26 software vendors, ranking above average across 78% of the key evaluation metrics, and received a perfect “recommend” score. In addition, the research highlights Incorta as an overall leader in Customer Experience and Vendor Credibility, with top-five rankings in vendor “Confidence” and “Sales and Service,” beating out Amazon, Google, Microsoft, MicroStrategy, Qlik and Tableau.

What differentiates Incorta?

• Blueprints (ready to use dashboards and data model) specifically built for Oracle EBS, Oracle Cloud SaaS, NetSuite, SAP, and Salesforce
• Faster initial implementation & ongoing enhancement rollouts
• Elevated performance and report response times
• Data Volume and scalability to handle billions of rows, without the need to build aggregate tables​
• Drill-down On-demand – Incorta lets users explore freely. Since all the data is available, users can drill into any level of detail, root cause analysis or new cuts or comparisons are available on-demand and instant.

“Perficient’s Incorta practice is closely aligned with our Enterprise Resource Planning and Corporate Performance Management teams. We believe the solution is synergistic with ERP implementations especially cloud migrations that provide business transformational opportunities for our clients,” said Joseph Klewicki, General Manager at Perficient.  With 14% of existing customers Fortune 500 companies, inclusion in the 2021 Gartner “Cool Vendors” report for Analytics and Data Science and $120 million in Series D funding led by Prysm Capital, we believe as do others that Incorta will continue to revolutionize the modern data analytics platform.

Proactively monitoring and addressing upcoming supply chain bottlenecks can have a direct impact on realizing revenue targets and meeting customer expectations. Leveraging Incorta Analytics, Perficient’s supply chain management solution for Oracle E-Business Suite provides a forward-looking view of inventory projections with increased visibility into SCM, order management, purchasing, and manufacturing.  

Join us for a live demo of the supply chain dashboard and learn how this solution for Oracle EBS can help you: 

• Predict inventory shortages before they happen 
• Identify items with low projected days on hand and upcoming fill rates 
• Facilitate “make or buy” decisions and keep up with demand 

Come prepared with your questions for Perficient’s team. If you’re unable to attend the live event, all registrants will receive links to the presentation materials and a recording of the on-demand webinar post-event. Register today!

Are you confident your business is sales tax compliant? After the Supreme Court of the United States ruled in favor of the state in South Dakota v. Wayfair, Inc., it’s not uncommon for tax compliance to come into question.

Our partner, Avalara, provides a cloud-based application that includes functionality to accurately calculate various types of tax including sales, consumer use, and VAT across a majority of the countries throughout the world. It is a web-based application that allows you to set up your companies, identify the jurisdictions in which you have nexus, enter customer exemptions, and define taxing rules specific to your business. It also employs a web-based REST server called AvaTax which accepts REST requests to calculate and store tax.

As economic nexus is now in effect in every state which charges sales tax, it has become an even bigger challenge for most businesses to accurately charge tax and maintain taxability for various products and services. Currently, Avalara maintains the taxability of over 2,500 products and services along with the rates charged in more than 10,000 jurisdictions automating the Sales and Use tax calculation process.

Perficient’s dedicated tax technology practice can assist your business in reducing the aggravation and complexity of automating your tax processing using our proprietary Tax Links for Avalara, a suite of pre-built solutions that provide tax functionality to facilitate the calculation of sales tax, consumer use tax, and VAT in various Oracle EBS Applications, including Receivables, Order Management, Trade Management, Payables, Purchasing, Inventory and Projects.

Tax Links At Work

Perficient’s team of experts recently implemented Tax Links for Avalara for a leading provider of products and services for process control and flow control in the Manufacturing, Industrial Machinery & Equipment, and Electronics industries.

• Strengthened and standardized controls that impacted tax processing and reporting
• Streamlined and simplified transaction data entry to minimize the risk of entry error which could impact tax processing,
• Improved the accuracy and efficiency of their sales tax calculation for Receivables Invoices
• Improved tax data consistency, validity, and availability
• Facilitated compliance with Sales and Use tax regulations for jurisdictions in which the client operates
• Leveraged Avalara tax rules and tax rate content to eliminate or reduce maintenances of user-defined tax rules and tax rates
• Provided audit support for tax compliance in business transactions

Contact Perficient to learn more about our Tax Technology practice and how the Tax Links for Avalara can be used to help your business automate your Sales Tax, Consumer Use Tax, and VAT tax compliance.

Below are some key questions asked and answered during the Q&A portion of a recent on-premises to cloud story: Remote Delivery: From EBS and Hyperion to Oracle Cloud webinar. To view the entire webinar click here. 

Why did NGL select Oracle’s ERP Cloud product? As opposed to upgrading to E-Business Suite or moving EBS into the cloud as a hosted service. Did NGL have other options that they looked at?

[NGL Energy Partners] We did look at other options. Obviously, we were on a very dated version of EBS. We also were on Microsoft AX platform that we evaluated. We looked at other large systems, like SAP. We wanted to get as out of the box as possible, we wanted to have best practices across our businesses and we didn’t want to give people an excuse or reason to deviate from those best practices. So we thought going to the cloud where you’re limited in the amount of customization when it comes to things like processes, would be beneficial to us. Again, we wanted to limit the amount of customization that we would have, but we want to stay on the cutting edge.

We consulted with our IT group on what their preference was, whether they wanted on-premises versus cloud. You obviously have to weigh the economics of that decision as well. And at the end of the day, this was the best fit for NGL. Everybody has to make those decisions themselves. We had been using Oracle previously, so that was a benefit in choosing Oracle and going into the cloud. Those were some of the factors that weighed in our decision.

I think it is unique for each company. Everybody has to look at their own situation and sometimes you want to total change and move away from the platform you may be on, or you want to stick with some consistency. Those are things that are that are unique to everybody.

Can you provide some examples of efficiencies that helped to streamline the financial closed cycle?

[NGL Energy Partners] What we’re seeing at this point in time, is that by having all of our data in one location, we can generate reports much quicker than what we’ve been able to historically. One of the things that really drives your financial close as being able to closure your revenue and your expenditure processes. Those are still from a business perspective, managed in. For example, we use Rightangle for our liquids business, or we use custom built system in our water business for volumes. You still have to get those systems close, which does take several days, generally after the end of a month. You’re not going see any benefit there or we have not yet from an Oracle Cloud perspective, but getting all that data into one place has allowed us to accelerate some of our reporting.

That being said, we’re four months in and there’s a big learning curve in the new system, so each month we’re getting better.

I think we will ultimately be able to shave a day or two off of our close process, so to speak, to close the books. Having real-time reporting is going to be a significant benefit where we don’t have to generate reports on just a monthly basis. We can get some real-time information out of the system. And then, being able to essentially close the reporting process for each month on a much quicker basis, will help expedite and give us more time to analyze.

A lot of times as accountants we spend so much time accumulating the information that we don’t really get a chance to step back and look at it and say, “Does this all make sense?” That’s where I think we’ll get the major benefit.

How do you handle enhancements and customization changes? Does Oracle Cloud provide a development environment for migrating those changes to production?

[Perficient] A lot of people say or think there’s just no customizations in the cloud. I would say in the traditional sense, there aren’t  “customizations” in the cloud – you really can’t touch the code or the software directly. But there’s what’s called platform as a service (PaaS) where you can build custom applications of your own, and then integrate what’s called web services through REST APIs or soap web services that insert data into the environment and pull data out. So, that’s how you might integrate a custom application or you can integrate an existing legacy application, such as NGL is doing with a few of their operational systems where customer bills are being generated and then being imported into the cloud.

Any type of form enhancements, there are ways to do personalization in the traditional sense that we used to do in EBS. And most of the things we have found, you can do. This is one of many cloud projects we’ve delivered, and we have yet to meet a challenge that we honestly just could not fill.

[NGL Energy Partners] Yes, we haven’t dev a test and a production environment, and Matt can probably speak better to that an how they divvy those out, if that comes along with a number of user licenses, but we have plenty of environments to do our development efforts.

[Perficient] Thanks for reminding me, I forgot to mention the test platforms that Oracle does provide. Yes, when you subscribe to the product, Oracle gives you the production test environment. And then optionally, a development environment you can buy as many as you want. Usually we find you shouldn’t need more than two, three at the max.

Going back to the technical question, the code does not exist. It does not sit resonant in any one of those environments, it sits in the integration layer. Whether it’s MuleSoft, or Dell Boomi, or an integration platform of our own that’s based on Python type code. The code really exists there. It is just a matter of where you point it.

How do Ingredient Changes occur in Oracle OPM? Oracle Process Manufacturing (OPM) jobs have 3 parts; batch jobs, process operations, and recipe. The Recipe is a list of ingredients for the batch job(s).  The warehouse compiles the ingredient materials on the recipe to complete the batch job. The quantities cannot be easily revised once they are physically issued to the batch. However, each step of the process has its own process for handling material changes in the recipe. So, what do you do if there are material changes? In this post, we explore potential scenarios where the process manufacturing recipe needs to be revised.

Understanding Ingredient Release in EBS R12 with WMS enabled

There are several types of Manufacturing in Oracle EBS R12. We are going to focus on Batch/Process (OPM) Manufacturing. To better understand process manufacturing, think of making a batch of cookies. If you need additional examples, please see the blog post “Which Manufacturing type your ERP solution is using.”

Planned vs. Ad-Hoc Material requirements

Oracle’s process manufacturing has two processes to add ingredients to a batch; planned and ad-hoc. Planned ingredients are on the recipe. Ingredients issued to the batch “on the fly” are ad-hoc. Usually, this is a result of corrective action to a quality issue.

An example would be adding more flour to the cookie dough because the consistency is not right. Another example would be an on-the-spot substitution. You’ve run out of olive oil and chose to substitute canola oil for the batch.

Changes made before the release of the batch job need to be on the recipe. Ingredient changes after you release a batch job tend to be ad-hoc. A recipe revision is also an option. If this simplest and quickest way to fulfill the material needs is to grab and immediately issued the ingredients to the batch job; then use the ad-hoc method.

The scenarios that we are going to cover are not going to consider Ad-hoc materials.

Outside Processing vs. Make to Order

Outside processing (OSP) is where an external group is working on a piece of the manufacturing process. These processes are not in direct control of the manufacturer. An OSP process is sending out a batch of cookies to be packaged. To be internal, you would have a packaging station in-house. For this post, we are not talking about any material changes to an OSP manufacturing step.

Ingredient changes in Process Picking/OPM Tasks in Oracle WMS

Similar to the Sales Order Fulfillment process, Ingredient picking is a two-step process. Staging the ingredients and issuing the ingredients. In Oracle EBS R12, component picking for the discrete job is a one-step process. Components are picked and issued to the job in one process.

Within this process, there are five phases in the OPM Batch Job lifecycle with Material requirements. They are Job Release, Ingredient request, Ingredient move, Ingredient Issue, and Job completion. The process of making a revision or a cancelation depends on which phase you are in. Ingredient changes can only be made if there are no active move tasks or issued ingredients. So, if you are to look at where you are at. You can then decide which steps are the most efficient way to handle to job.

The Phases of Ingredient needs for an OPM Batch Job are as follows:

Scenarios in OPM & WMS with Material Changes:

1. Ingredient changes after the Batch Job(s) are approved (Ingredient Pick Release has not occurred)
2. The Warehouse receives the Batch Job and then ingredient changes to the Task/Job occur
3. Ingredient changes occur during the Picking of the ingredients for the Batch
4. Ingredient changes after materials are staged
5. Ingredients have been issued to the Batch when a change occurs

Scenario #1 – Ingredient changes before the batch job is released to the warehouse for picking

Scenario details:

The Process Manufacturing Batch Job is in a “released” status. However, the Warehouse has not received instructions to perform the ingredient picking allocation. Production scheduling requests a change to the Batch Job or cancellation of the batch in its entirety.

Solution Action Plan:

There are no active tasks in the warehouse.  Manufacturing operations can easily revise the Recipe. So, the first action is to make sure that the warehouse doesn’t release the batch job for ingredient picking. To do this, Manufacturing operations must inform the Raw Material Warehouse to not release the materials until the Recipe is updated. Once updated, the raw material warehouse can release the job.

Scenario #2 – Warehouse receives the Batch Job and then ingredient changes occur

Scenario details (Assuming a Make-to-Order environment):

In this case, the Batch Job is in a “released” status. The Warehouse has reviewed the ingredients for the job. Warehouse picking tasks exist. In this scenario, the recipe has changed due to an issue discovered with an earlier batch. The ingredient amounts have to change. The corrective action may require the removal of the ingredient in its totality.  Manufacturing operations request a cancellation of the entire batch. The batch will be released again after the recipe is updated.  Manufacturing Operations and the Raw Material Warehouse leadership talk. The result is the cancellation of the task(s) for the ingredient picking. The Raw Material Warehouse Manager/Supervisor (or Lead) has not assigned this order to be actively picked.

Solution Action Plan:

Expediency is key in this situation. As ingredient picking is not occurring, we want to keep it that way. Revisions and cancelations must happen before the warehouse actively starts picking the batch job. To do this, the Manufacturing Production team will need to communicate and work with the Warehouse leadership.

Warehouse leadership will need to perform two actions:

1. Ensure ingredient picking doesn’t start
2. Cancel the open picking tasks in the system

For the first part, they will need to pull the batch job from the queue of active orders. You can do this by removing the pick-slip from the stack of orders. The next step is to cancel the open tasks in EBS. If you reverse these steps you run the risk of having a warehouse worker trying to pick that work order. They will be unable to access the order to pick in EBS but will have a pick-slip instructing them to pick it. This will cause confusion and delay. If the warehouse is running in a paperless mode, simply proceed to the step of task cancellation in EBS. The raw material warehouse will need to let production operations know when the tasks have been canceled.

To actively cancel these tasks, query up the corresponding task in the “Transact Move Order” form. From there you can cancel the move order by selecting the function of “Back Order Line” from the Tools option.

If the Warehouse Manager/Supervisor (or Lead) has assigned the work order to be actively picked, please see the next scenario.

Batch Job Revisions

For Recipe Revisions at this phase in the process, you would follow the same steps. However, instead of canceling the Batch job, the job would be re-released once the revisions have been made.

Scenario #3 – Batch Job is Released and then Cancelled while ingredients are Picked

Scenario details:

The Warehouse is actively picking the ingredients for the batch job. For some reason, the job needs to be changed. Either the equipment is down or a change in the recipe. Production operations call the Warehouse Supervisor/Manager to request that they stop picking ingredients for the batch. The Warehouse Worker is in the middle of actively picking the raw materials. This means that some of the tasks are complete. However, several tasks are still in the process of picking.

Solution Action Plan

Active picking of the order is taking place at this phase. Operations will need to stop the active picking of the order. This will require coordination with the Raw Material Warehouse leadership team. Depending on how far into the fulfillment cycle, it may take several hours before the ingredients on the batch job can be revised. The Warehouse leadership will need to evaluate where the order is in the fulfillment process. Will it be easier for the Warehouse Worker to return the material to where they found it (and reverse the execution of those picking tasks) or finish the fulfillment tasks?  Once they have arrived at a decision, the leadership must communicate their intention with the warehouse staff.

Similar to Order Fulfillment; Ingredient fulfillment for batch jobs consists of two steps. They are material transfer and material issues. With batch jobs, you can revise the recipe if there are no open tasks or reservations.

The task is in one of four states of picking. These states are as follows:

1. Dispatched – Task is in the queue for action
2. Active – Actively picking material
3. Loaded – Transaction is in an interim state (in transit to Production)
4. Completed – Production receives the material. The material is no longer in inventory because it is now on the WIP Job.

Dispatched Task

For dispatched tasks, the worker needs to abort the action.  Once aborted, proceed with the steps taken in Scenario #2.

Active Task

For Active tasks, the warehouse worker needs to put the material back to where they were taking it from and abort the task in the system. Once aborted, proceed with the steps taken in Scenario #2.

Loaded Task

Loaded tasks can go one of two ways. Complete the task or abort the task. To abort the task, two events must occur in unison. First, the task needs to be undone in the system. Second, the ingredients need to be physically returned. Oracle’s Mobile Warehouse Application (MWA) refers to this action as a “Manual Unload” of the LPN. This function will tell the worker where to return the material to. Once completed, you can proceed with the steps outlined in Scenario #2.

If the revisions are not related to the picked ingredients, it might be easier to just finish the active tasks. This is done by dropping the Loaded LPN into the production area. If one or more of these items need to be returned, see the steps taken in Scenario #4.

Completed Task

For completed tasks, follow the steps outlined in scenario #4.

Scenario #4 – Recipe is adjusted after Ingredients have been Picked

Scenario details:

Ingredients are in the production staging area. Ingredient changes to the batch occur. This is because of corrective action in the manufacturing process. Also, the batch could have been canceled or rescheduled to be produced at a later point in time. This event could be due to an equipment failure, or a production schedule change.

Solution Action Plan:

In all of these cases, raw materials need to return to the warehouse. To remain in the production staging area would take up valuable space and cause inefficiencies in the production process. The material reservations need to be removed. Once removed, the ingredients can be returned.

To remove the material reservations, go into the Batch Job transaction and remove the reservations on the ingredients. Once this is complete, perform a directed LPN putaway and move the LPN back into the warehouse to an appropriate locator. Also, after all of the reservations have been removed you can adjust the recipe and release the batch back to the floor as necessary.

Scenario #5 – Canceling the Batch after Ingredients are Issued

Scenario details:

Batch Job has consumed the raw materials. Ingredient changes to the Batch Job occur. This is because of an equipment failure or a quality corrective change.

Solution Action Plan:

In all of these cases, raw materials need to return to inventory. However, we need to review where the batch is in the process.  If ingredients have been physically issued to the batch, you’ll have to perform a scrap transaction. However, if the ingredients have not physically been issued, you can perform a return. In the scenarios where the ingredient change is to add material, an ad-hoc transaction would be the preferred action.

To perform a material return, go into the Batch Job transaction and perform a material return transaction. Receive the material back to the production staging area. The rationale behind this is to repack the materials onto an LPN. The LPN is then putaway back into the warehouse to an appropriate location.

In WMS, a Batch Return can also be performed in mobile applications using the Material Txn Return function.

The return function performs two necessary things. First, it reverses the issuing of raw material components to the work order. The reversal places the materials back into inventory. These materials are also no longer reserved for the Batch Job.  Ingredient changes are now possible for the work order. Second, it allows for the materials to be putaway back into stock for another job.

OPM Ingredient Changes – Conclusion

Work Order revisions for Batch Jobs will happen in a manufacturing environment. Efficiently managing these revisions is paramount. The key to achieving efficiency is to understand the process. The proper management of these changes comes with communication.

You can apply these principles to other fulfillment processes. If you are interested in learning about this process for order management, check out the Ways to easily solve Order revisions in the Oracle R12 Warehouse Management blog post. To explore applying these to discrete manufacturing check out the More ways to easily resolve material changes in Oracle R12 WIP and WMS post.

To learn more about this process or similar processes in further detail, please contact the Perficient team for more information.

Oracle Discrete Manufacturing jobs have 3 parts; jobs, operations, and bills of materials. The Bill of materials (BOM) is a list of components for the job(s).  The warehouse compiles the materials on the BOM to complete the job. The quantities cannot be easily revised when the warehouse is collecting the components. So, what do you do if there are material changes? In this post, we explore potential scenarios where discrete manufacturing components need to be revised.

Understanding Component Release in EBS R12 with WMS enabled

There are several types of Manufacturing in Oracle EBS R12. We are going to focus on Discrete (WIP) Manufacturing. To better understand discrete manufacturing, think of building a car. If you need additional examples, please see the blog post “which Manufacturing type your ERP solution is using.”

Planned vs. Ad-Hoc Material requirements

Oracle’s discrete manufacturing has two processes to add materials to a job; planned and ad-hoc. Planned materials are on the Bill of Materials (BOM). Materials issued to the job “on the fly” are ad-hoc. Usually, this is a result of corrective action to a quality issue.

An example would be adding more soil to a pot because the original amount wasn’t enough to properly cover the plant. Or the bill requires a black pot and you only have red pots. So, you use a red pot and paint it black. That would be the cancellation of the original item, the addition/substitution of the red pot(s), and then the adding on the fly of the black paint.

Changes made before the release of the job need to be on the BOM. Component changes after a job are released tend to be ad-hoc. A BOM revision is also an option. If this simplest and quickest way to fulfill the material needs is to grab and immediately issued the materials to the job; then use the ad-hoc method.

The scenarios that we are going to cover are not going to consider Ad-hoc materials.

Outside Processing vs. Make to Order

Outside processing (OSP) is where an external group is working on a piece of the manufacturing process. These processes are not in direct control of the manufacturer. An example of this would be sending a car to a paint shop instead of having your own painting station in your manufacturing plant. For this post, we are not talking about any material changes to an OSP manufacturing step.

Material changes in Discrete Picking/WIP Tasks in Oracle WMS

There are four phases in the WIP Job lifecycle with Material requirements. They are Job Release, Component Release, Component Issue, and Job completion. The process of making a revision or a cancelation depends on which phase you are in. Component changes can only be made if there are no issued components. Also, there have to be no active tasks. So, if you to look at where you are and decide which steps are the most efficient way to handle to job.

The Phases of a WIP Job are as follows:

Scenarios in WIP & WMS with Material Changes:

1. Material changes after the WIP Job is approved (Component Pick Release has not occurred)
2. The Warehouse receives the WIP Job and then material changes to the Task/Job occur
3. Material changes occur during the Picking of the components to the Job
4. Material Changes are required after the components have been issued to the Job

Scenario #1 – Material changes before the job is released for picking

Scenario details:

The Manufacturing Work Order (WIP Job) is in a “released” status. However, the Warehouse has not received instructions to perform the component picking allocation. Production scheduling requests a change to the WIP or a Cancellation of the Work Order in its entirety.

Solution Action Plan:

There are no active tasks in the warehouse.  Manufacturing operations can easily revise the BOM. So, the first action is to make sure that the warehouse doesn’t release the job for picking. To do this, Manufacturing operations must inform the Raw Material Warehouse to not release the materials until the BOM is updated. Once updated, the raw material warehouse can release the job.

Scenario #2 – Warehouse receives the WIP Job and then material changes occur

Scenario details (Assuming a Make-to-Order environment):

In this case, the WIP Job is in a “released” status. The Warehouse has reviewed those material requirements for the job. Warehouse picking tasks exist. In this scenario, the WIP Job exists to fill an active sales order. The customer calls to cancel the order. This means that the need for this item isn’t there anymore. The WIP job is no longer necessary. Manufacturing operations request a cancellation of the Work Order in its entirety.  Manufacturing Operations and the Raw Material Warehouse leadership talk. The result is the cancellation of the task(s) for the component picking. The Work Order is terminated after the tasks are canceled. The Raw Material Warehouse Manager/Supervisor (or Lead) has not assigned this order to be actively picked.

Solution Action Plan:

Expediency is key in this situation. As component picking is not occurring, we want to keep it that way. Revisions and cancelations must happen before the warehouse actively starts picking the work order. To do this, the Customer Service and Manufacturing Production team will need to contact and work with the Warehouse leadership.

Warehouse leadership will need to perform two actions:

1. Ensure work order picking doesn’t start
2. Cancel the open picking tasks in the system

For the first part, they will need to pull the work order from the queue of active orders. You can do this by removing the pick-slip from the stack of orders. The next step is to cancel the open tasks in EBS. If you reverse these steps you run the risk of having a warehouse worker trying to pick that work order. They will be unable to access the order to pick in EBS but will have a pick-slip instructing them to pick it. This will cause confusion and delay. If the warehouse is running in a paperless mode, simply proceed to the step of task cancellation in EBS. The raw material warehouse will need to let production operations know when the tasks have been canceled.

To actively cancel these tasks, query up the corresponding task in the “Transact Move Order” form. From there you can cancel the move order by selecting the function of “Back Order Line” from the Tools option.

If the Warehouse Manager/Supervisor (or Lead) has assigned the work order to be actively picked, please see the next scenario.

Job Revisions

For BOM Revisions at this phase in the process, you would follow the same steps. However, instead of canceling the WIP job, the job would be re-released once the revisions have been made.

Scenario #3 – Work Order (WIP Job) is Released and then Cancelled while being Picked

Scenario details:

The Warehouse is actively picking the material components for the WIP job. For some reason, the job needs to be changed. Either the equipment is down or a change in the assembly details. Production operations call the Warehouse Supervisor/Manager to request that they stop picking materials for the job. The Warehouse Worker is in the middle of actively picking the raw materials. This means that some of the tasks are complete. However, several tasks are still in the process of picking.

Solution Action Plan

Active picking of the order is taking place at this phase. Operations will need to stop the active picking of the order. This will require coordination with the Raw Material Warehouse leadership team. Depending on how far into the fulfillment cycle, it may take several hours before the material on the job can be revised. The Warehouse leadership will need to evaluate where the order is in the fulfillment process. Will it be easier for the Warehouse Worker to return the material to where they found it (and reverse the execution of those picking tasks) or finish the fulfillment tasks?  Once they have arrived at a decision, the leadership must communicate their intention with the warehouse staff.

The task is in one of four states of picking. These states are as follows:

1. Dispatched – Task is in the queue for action
2. Active – Actively picking material
3. Loaded – Transaction is in an interim state (in transit to Production)
4. Completed – Production receives the material. The material is no longer in inventory because it is now on the WIP Job.

Dispatched Task

For dispatched tasks, the worker needs to abort the action.  Once aborted, proceed with the steps taken in Scenario #2.

Active Task

For Active tasks, the warehouse worker needs to put the material back to where they were taking it from and abort the task in the system. Once aborted, proceed with the steps taken in Scenario #2.

Loaded Task

Loaded tasks can go one of two ways. Complete the task or abort the task. The material has to be returned to the locator of origin to be aborted. Oracle’s Mobile Warehouse Application (MWA) refers to this action as a “Manual Unload” of the LPN. This function will tell the worker where to return the material to. Proceed with the steps taken in Scenario #2 after all of the material has been unloaded.

If the revisions are not related to the picked components, it might be easier to just finish the active tasks. This is done by dropping the Loaded LPN into the production area. This will also issue the components to the job. If one or more of these items need to be returned, see the steps taken in Scenario #4.

Completed Task

For completed tasks, follow the steps outlined in scenario #4.

Scenario #4 – Order is Released and then Cancelled while Order has been Picked

Scenario details:

WIP Job has consumed the raw materials. Material changes to the WIP Job occur. This could be due to an equipment failure or a schedule change.

Solution Action Plan:

In all of these cases, raw materials need to return to inventory. To do this, a material return transaction must occur.

To perform a material return, go into the Discrete Job transaction and perform a material return transaction. Receive the material to a WIP staging area. This is done so that they can be packed onto a new LPN and putaway back into the warehouse to an appropriate locator.

In WMS, a WIP Return can also be performed in mobile applications using the Material Txn Return function.

The return function performs two necessary things. First, it reverses the issuing of raw material components to the work order. The reversal places the materials back into inventory. These materials are also no longer reserved for the WIP Job.  Material changes are now possible for the work order. Second, it allows for the materials to be putaway back into stock for another job.

WIP Material Changes – Conclusion

Work Order revisions will happen in a manufacturing environment. Efficiently managing these revisions is paramount. The key to achieving efficiency is to understand the process. The proper management of these changes comes with communication.

You can apply these principles to other fulfillment processes. If you are interested in learning about this process for order management, check out the Ways to easily solve Order revisions in the Oracle R12 Warehouse Management blog post. We will explore applying these to process or batch manufacturing in ways to easily resolve material changes in Oracle R12 OPM and WMS post.

If you are interested in learning about this process or similar processes in further detail, please fill out the form below or contact the Perficient team for more information.

Order revisions occur regularly in order fulfillment. Once a Sales Order has been “Released” to the Warehouse to fulfill and ship, the order can not be changed unless the desired line(s) on the order are in a revisable status. For this post, we’re going to cover potential scenarios where a Sales Order may be canceled or changed. These changes will result in the need to move part or all of the Sales Orders into a revisable status.

Understanding Order Release in Oracle EBS R12

There are six actionable phases with a Sales Order. There are seven phases in total, but we will only consider the following five:

Starting with a booked order, any change will need to be documented. These are revisions. The order management/customer service team is the one that makes revisions. As the order travels down to each subsequent phase, their ability to easily make revisions decreases. Active involvement from the warehouse increases with each progression.

Changes are only possible when the Order is in the “booked” phase. You can also reset the order to the “Booked” phase once it has been Picked or Staged. This is the act of actively back-ordering the Sales Order. Back-ordering cancels the picking and staging of the order. This moves the order or order line back into a revisable state. This also removes the allocated material from the picked goods. The Sales Order no longer has these goods on it. You will have to pick these goods again to get them on the order.

When a change request occurs, you will need to evaluate your approach. The overarching question for the approach is based on operational efficiency. Which is easier, backing out of the order or finish picking it?

Order Revision Scenarios Covered:

We will walk through how to cancel or revise an order in Oracle E-Business Suite (EBS) at each phase. These phases are as follows:

1. Sales Order revisions after the orders are booked (Warehouse hasn’t received the Order)
2. The Warehouse receives the Order and then it needs to be revised
3. Order is actively being Picked when it needs to be revised
4. Order/Line is canceled after the Sales Order/Line has been picked & Staged
5. The order has been Shipped and needs to be revised

Scenario #1 – Order is Revised/Cancelled before being Released

Scenario details:

Sales Order is in a booked status. The Warehouse has not received the order.  The customer calls and requests a change or a cancellation of the order in its entirety.

Order Revision Action Plan:

Customer Service (Order Management Group) cancels the Sales Order/Line or makes a change to a specific line. Upon completion, the Warehouse receives the revised order. The canceled order has no additional steps.

Scenario #2 – Warehouse receives the order before order revisions are needed

Scenario details:

The Warehouse has received the Sales Order. The Customer calls and requests a change to the Order or a Cancellation to the Order in its entirety.

Order Revision Action Plan:

Expediency is key in this situation. As order picking is not occurring, we want to keep it that way. Revisions must happen before the warehouse actively starts picking the order. To do this, the Customer Service team will need to contact the Warehouse leadership.

Warehouse leadership will need to perform two actions:

1. Ensure order picking doesn’t start
2. Cancel the open picking tasks in the system.

For the first part, they will need to pull the order from the queue of active orders. You can do this by removing the pick-slip from the stack of orders. The next step is to cancel the open tasks in EBS. If you reverse these steps you run the risk of having a warehouse worker trying to pick the order. They will be unable to access the order to pick in EBS but will have a pick-slip instructing them to pick it. This will cause confusion and delay. If the warehouse is running in a paperless mode, simply proceed to the step of task cancellation in EBS. Sales Order or Order Line revisions can occur after the tasks have been canceled.

If the Warehouse Manager/Supervisor (or Lead) has assigned the order to be actively picked, please see the next scenario.

Scenario #3 – Order revisions occur during active Picking

Scenario details:

The Warehouse is actively picking an order to fulfill.  Customer calls and requests a change to the Order or a Cancellation to the Order in its entirety.

Order Revision Action Plan:

Active picking of the order is taking place at this phase. Customer Service will need to stop the active picking of the order. This will require coordination with the Warehouse leadership team. Depending on where the order is in the fulfillment cycle, it may take several hours before the order can be revised. The Warehouse leadership will need to evaluate where the order is in the fulfillment process. Will it be easier for the Warehouse Worker to return the material to where they found it (and reverse the execution of those picking tasks) or finish the fulfillment tasks?  Once they have arrived at a decision, the leadership must communicate their intention with the warehouse staff.

Once the tasks have been completed (by returning the goods or completing the pick), the Warehouse leadership can return the order to an editable state. In the case of reversing the picking tasks, they will perform the same steps that were taken in scenario #2. If they chose to complete the picking and then backorder, they will need to follow the steps outlined in scenario #4.

Scenario #4 – Order is Revised or Cancelled after Order has been Picked, but not Shipped

Scenario details:

The order fulfillment phase is complete. The next step is to ship the order out of the warehouse. Customer calls and requests a change to the Order or a Cancellation to the Order in its entirety.

Order Revision Action Plan:

To make changes to the sales order, there can’t be any confirmed reservations. The easiest way to perform this to a sales order at this point is to cancel the confirmed shipment. You can perform this action for one line or the entire order. In Oracle EBS, this action is a backordered ship confirmation. Instead of confirming the shipment of goods, you instruct the system to cancel the entire picking confirmation process. This will place the order back into a revisable state.

Follow this same methodology for damaged goods in the staging area. You will need to split the damaged goods onto a delivery that is separate from the rest of the order. Backorder the delivery for the damaged goods. This will allow for the damaged goods to be moved to QC to be repackaged or properly disposed of. Then re-release the order to the warehouse to pick the next available good supply to be shipped to the customer.

Unfortunately for the warehouse, additional steps will need to be performed. These additional tasks are to deconstruct the pallets and return the goods back to the warehouse. Once the revisions are complete, customer service will re-release the order to the warehouse. The entire process will start over. The entire picking of the order starts anew.

Scenario #5 – Order revisions after shipping the sales order

Scenario details:

Sales Order has shipped out of the Warehouse.  Customer calls and requests a change to the Order or a Cancellation to the Order in its entirety.

Order Revision Action Plan:

The point of shipment confirmation is the point of no return. The goods have left the warehouse and are on their way to the customer. At this point, Customer Service will need to authorize a return shipment. Crediting the customer for the goods is also necessary. However, the point of credit issuance will depend on company policy.

Conclusion

Sales Order revisions will happen in an order fulfillment environment. Efficiently managing these revisions is paramount. The key is achieving efficiency is to understand the process. The proper management of these changes comes with communication.

You can apply these principles to other fulfillment processes. We will explore applying them to manufacturing in additional posts. For discrete manufacturing, see the More ways to easily resolve material changes in Oracle R12 WIP and WMS post. If you are interested in seeing this applied in a process or batch manufacturing environment, please check out the More ways to easily resolve material changes in Oracle R12 OPM and WMS posts.

Vertex has replaced Adobe Flash with HTML5 in O Series version 9.0.  Access to the Vertex 9.0 user interface (UI) will be available after January 2021 using the major browsers other than Microsoft IE.  So, access to Vertex O Series version 9.0 is not an issue.

That’s not true of previous versions of Vertex O Series.  Versions 6.0, 7.0 and 8.0 all use Adobe Flash to provide screens to the user via the user interface. With the de-support of Adobe Flash by the major browsers at the end of 2020, access to the user interface for the older versions of Vertex O Series will no longer be available in 2021 using Microsoft IE and MS Edge, Google Chrome and Apple Safari.  Mozilla Firefox has recently extended support of Flash through January 26, 2021 (https://blog.mozilla.org/futurereleases/).  That doesn’t help very much, but it could help in situations where the upgrade of Vertex O Series to version 9.0 is being completed in early January 2021.

Monthly updates for Vertex O Series 6.0 will no longer be available after January 2021 which will provide an additional push to get off of that version of Vertex O Series.  Monthly updates will be available for versions 7.0 and 8.0 through September 2021.  However, due to the de-support of Flash, the major browsers will not allow you to access the Vertex UI unless you are on an older version of a browser where Flash support has not been de-activated.  Some clients who have upgraded to Vertex 9.0 also want to have the option to access a previous version or previous versions of Vertex O Series.

Flash support is not available in the updated versions of the browsers, but access is possible using an older version of the browser which is not updated.  This can be done by locking down a browser, typically on a remote desktop or in a Citrix window which can then be accessed and used to access the older versions of Vertex.  This same solution can also be made on a local machine by locking down updates to a browser, or using a version of Chrome Portable, Firefox Portable or Pale Moon where flash updates have been disabled.

Due to the security risks after Flash support is ended, this type of solution has to be done by and with the blessing of the IT and Data Security groups.  It will take some effort and coordination to get the solution in place before Flash support is ended, so if you want to be able to access the old versions of Vertex and you don’t currently have a solution in place, it needs to be started as early as possible so that you’re prepared for 2021.  And, let’s hope that 2021 is an improvement over 2020!

Vertex Exchange, the premier conference for tax professionals looking to learn from and network with Vertex subject matter experts and other information technology professionals, is being held October 30 – November 2 in San Antonio. Perficient is excited to be a conference sponsor and we look forward to engaging conversations with show participants.

During Vertex Exchange, Perficient experts will be available to discuss Oracle solutions and services that address various tax technology needs. As an Oracle Platinum Partner and E-Business Suite systems integrator, Perficient provides implementation and optimization services for clients integrating Vertex with Oracle’s E-Business Suite (EBS) through its proprietary solution Nascent Tax Links – Powered by Perficient. Tax Links provide a two-way channel between Oracle and Vertex O Series that populates and formats Oracle data for tax processing in Vertex and then returns and writes the tax results back to Oracle, thereby delivering a seamless tax solution.

For more than 15 years Perficient has been providing automated tax solutions for Vertex and Oracle clients like Overhead Door, Herbalife, and Plantronics. We are the proven leader in designing and delivering automated transactional tax solutions. If you’re headed to Vertex Exchange this year and you use Oracle E-Business Suite, please stop by our booth. We’d love to talk tax with you.

Enterprise Design in EBS is one of the first things you tackle when beginning a new client engagement. It will likely include chart of accounts design, number of business groups, ledgers, legal entities, operating units (OU), and inventory organizations. This document will brush lightly on a few of these areas but will focus primarily on the concept of operating unit.

The operating unit sits directly below the ledger in the enterprise design. For point of reference, inventory organization is directly below the OU. A ledger may have multiple OUs, and an OU may have multiple inventory organizations.  An OU may only belong to one ledger, and an inventory organization may only belong to one OU.

Over the years, I have come across a lot of confusion at client sites as to the use and purpose of the OU.  It goes without saying, that at minimum, your enterprise will require at least one OU per ledger if that ledger has Accounts Payable and/or Accounts Receivable activity, if it is required to hold inventory, conduct sales, or write purchase orders.  Sometimes the question arises, “Do we need more than one OU for that ledger?” and the confusion arises as a result of not fully understanding the purpose of the OU and how it works in the most simplistic terms.

The OU, in laymen terms, organizes and segregates your data from other sources of operations.  This prevents you from mixing apples and oranges.  And if you have two totally different companies working out of the same home currency (one ledger), with their own bank accounts for paying bills and issuing invoices, you may very well want to create a separate OU.

Looking at the OU from a simple Payables perspective, you need only ask one basic question: Can you or Do you use one bank account to pay all your bills for a given ledger (home country).  If that answer is YES, then you need to challenge yourself pretty hard to find rationale to open up multiple OUs within a single ledger.  This is because Oracle will simply pay all bills within an OU, without regard for the bank account/legal entity arrangement.  It is designed for shared services functionality, meaning that one group within an organization, within a country, pays all the invoices for all legal entities.  If in fact this is not the case, and each legal entity has its own paying bank account, and you do not operate in a shared services model, you should consider multiple OUs, especially if there are concerns for liabilities and taxes.

Many people express concern over the ability to cross charge legal entities within a single OU.  As long as those legal entities are members of the same ledger, then yes, you can charge one invoice to multiple legal entities, and providing your intercompany accounting rules have been properly setup, then Oracle will handle the cross charges by adding in intercompany lines.  This functionality allows you then to enter invoices without concern for the legal entity relationships.  When running your payment batch, all invoices (due for payment) will be swept into the batch.

Case Study:

International Clothing Retail with 3,000+ retail locations (under different brand names), operating in North America, Latin America, and EMEA

Oracle Footprint: GL, AP, FA, PO, Inventory (for supplies only).

Initial Design Decision: One OU per brand within the North America implementation, under one USD Ledger

After several weeks on site, we found that the Payables team was struggling to understand when to enter an invoice under OU for brand A versus the OU for brand B.  Especially for invoices that are charged across all the brands, such as a utility bill.

We asked one key question: “Do you care who pays the bill?”  The answer was a simple: Well, NO, because we only have one bank account anyway.

Once that simple question was asked and answered, we very quickly shut down all the other operating units.  In fact, in our next test environment, we did not even configure them.  They served absolutely no purpose.  They did not match up to the legal entity structure (which was property based, and not brand based), and did not match up to how they operated.

They were initially directed to use 8 operating units because of the legal entity on the payables account (they have one legal entity per major brand, but is not a true legal entity).  They wanted this legal entity to match the legal entities on the expense distributions (mind you, in this context, the legal entities were only representing the brand, and not the actual true legal entities).  The only purpose in this setup was to make sure a balance sheet could be produced at the brand level, with each brand holding its own liability.  Oracle has a simple setup to resolve for this functionality, without having to enable multiple operating units, and that is the “Balancing Option” in Payables Options.  With a simple flip of a flag, each invoice could have multiple liability accounts, and when paid from the single bank account, intercompany accounting would close the loop between the banks legal entity and the invoices multiple legal entities.  Once this issue was resolved, the client had no purpose for multiple OUs.

It should be noted that this client had no need for Receivables and was not issuing any customer facing documents which might require unique branding based on the store name where the purchase took place.  However, even if that were the case, similar tricks can be configured in Receivables and Order Management to utilize multiple brands within a single operating unit.

In short, within a country, within a ledger, all best efforts should be made to keep a single OU with the following litmus tests:

1 – Do you pay your bills out of one or multiple bank accounts?

2 – Does your AR and AP departments operate with the same group of people?  ie: Are your collectors the same across all of your customers, are your payables associates entering bills for all of your operations?

3 – Is there a large overlap in suppliers and customers across the operations?

4 – Are legal relationships between your company and your customers and suppliers uniform across the enterprise?

5 – Are sales tax rules the same across the enterprise within the country?

If the answers to these questions are yes, then best efforts should be made to create and live within a single OU.

Why avoid mulitple OUs?

Without a true purpose, multiple OUs can cause confusion for end users.  Even with a true purpose, it adds complexity to your system.  Each OU requires a unique set of responsibilities and security rules.  Role assignment can become more complex.  If you’re going to entertain multiple OUs within a single ledger then the following should be clear:

1 – You have distinct legal obligations that are uniquely different across each OU.

2 – You have bank accounts that, for purposes of payments and receipts, cannot be co-mingled with other bank accounts.

3 – Your operations are vastly different, and different groups of people work within them, different collectors and different payment groups, ie: your organization is not setup for shared services.

Oracle has made it easier in Release 12 to move across OUs by placing an OU field within each transaction.  And yet many clients have asked that this be turned off, creating one unique responsibility that has access to only one OU.  This is because of “user error”, and they wish to force their users to pick an absolute OU to work within, especially for large batches.  This defeats the purpose of attempting a shared services model across multiple OUs, forcing users to constantly switch responsibilities.

In conclusion, from this consultants point of view, keep your implementation simple.  If anyone thinks you need multiple OUs within a given ledger, be sure to ask some basic questions as outlined above.  In 17 years, I have had one client which actually required multiple OUs within one ledger, and they “failed” all the basic questions in that they OUs were of completely different industries, different members in ownership, different legal entity models, unique employees, vendors,  and bank accounts.

Perficient Oracle EPM team is in NOLA for the annual ODTUG Kscope13 conference, June 23-27.  The conference is tailored to developers, technical architects and business users to gain insights on Oracle technologies and applications including business intelligence, Oracle EPM, Fusion Middleware and Application Express.  The conference format and activities provide a vehicle for extensive networking and sharing content around Oracle tools and solution offerings.

Serving as an elite Silver Sponsor, Perficient Oracle EPM team will be exhibiting in booth #405 and be on-hand daily to discuss our Oracle Hyperion expertise and your financial business and reporting needs.  We understand that when making sound, financial business decisions that nimbleness and transparency are key elements and that many companies are still utilizing manual reporting processes to budget, forecast and report on key metrics.  Perficient partners with clients to implement key Oracle technologies and applications like Hyperion Financial Management and Essbase solutions to help automate processes and ensure financial data integrity, resulting in more accurate and timely information for business-decision making.

SHOWCASING OUR EXPERTISE
During Kscope13, Perficient Oracle EPM expert Matt Hopkins, (professional bio) will present the case study “Mid-Market Energy Co. Uses HFM with Essbase for Seamless Reporting” in which he will review how Carrizo worked with Perficient to implement Oracle technologies to perform their financial close and external reporting process, and detailed operating and management reporting. Matt also will highlight how, with Perficient, Carrizo addressed their needs of reporting their lease operating statements for gross and net dollar amounts, and reporting based on general ledger and production dates.  Check out this interactive Session 10 on June 25 from 3:30 to 4:30 p.m. and meet Hopkins and the team.

Visit us at #405.  For more information on Perficient expertise in Oracle technologies, visit www.perficient.com/Partners/Oracle, or follow Perficient experts on Twitter @Perficient and @PRFT_Oracle.  Recent press release 6.2013