How API Wizard benefits increase in Year 2

New customers generally have specific pain points that they want to eliminate using API Wizard.  Those pain points may be in one specific area, like AP Invoices, there may be several across a functional area, like a set of manufacturing processes, or there may be usage across multiple functional areas.  Whatever the case is, most new API Wizard customers have a clear understanding of the problem(s) they wish to solve.  After purchasing API Wizard, those processes are quickly addressed and the old and tedious Oracle forms are set aside in favor of the newer and more efficient API Wizard solution.  Generally that's the win needed to have a very favorable ROI on the API wizard purchase.

But what happens after a customer has been using API Wizard for a year?  The first thing that generally happens is that API Wizard becomes second nature to the user(s) of those initial processes and they look to replace their other, tedious Oracle processes with an additional API Wizard process.  For instance, an inventory manager using API Wizard to create new items and update existing items may want to start using it for Item Category maintenance, or BOM creation and update, or reporting on on-hand quantity.  With API Wizard's user-based pricing model, there is no additional cost when users do more with API Wizard, so that's a big win for the customer.  The next thing that frequently happens is that co-workers of the API Wizard users start to recognize that their own processes could be optimized using API Wizard and this generally is the driver behind purchasing additional API Wizard licenses and getting more benefit out of the tool.  Once an organization has seen success in its first few processes, the business case for adding additional processes becomes self-evident.  The third thing that happens is that the organizational knowledge and expertise in API Wizard develops to the point where they can leverage API Wizard not only for standard EBS processes but also to manage their custom processes as well.  In almost all cases, an API Wizard data entry/update solution for a custom process has a huge return on investment.  We see these a lot with custom tables and APIs, even those where an Apex form has been previously developed for daily usage.

Organizations with strong internal capabilities often do nearly all of this on their own.  Organizations with limited internal capabilities or very little bandwidth often ask the API Wizard team or third-party providers to help them add additional processes.  

As time goes on and more people in the organization become aware of how API Wizard can streamline EBS and custom processes, usage grows, and the organization improves processes and saves time and money.  


To learn more about API Wizard, visit us at:

www.api-wizard.com

End of Life for Oracle EBS?

The reports of EBS' demise have been greatly exaggerated!

As Oracle has been pushing all things cloud, it has left EBS customers to wonder whether the 'end of life' has arrived for Oracle EBS.  There's been a lot of confusion but the reality is that Oracle EBS is not in it's 'end of life'.  In fact, here are three recent updates from Oracle:

1) Oracle announces EBS 12.2.7 (9/8/2017)

www.oracle.com/us/products/applications/ebs-ga-2017-09-08-3876665.pdf

This is the latest/greatest release of EBS, announced just last week.

2) Oracle Roadmap shows support for R12 until at least 2030

(from Oracle.com)

3) EBS R13 is in the works

Cliff Godwin, Oracle Senior VP, Oracle EBS Development, announced at the OAUG Collaborate (April, 2017), that version R13 will be released in 2019/2020. 

Why the confusion?

Oracle has been pushing Cloud and their salespeople have been overly aggressive with their position of EBS' future, in hopes of signing new cloud contracts.  This appears to be how much of the confusion started - and then it spread, as rumors do!

Bottom Line:

Oracle has made it clear that neither their support for, nor their investment in, Oracle EBS is going away.  While everything 'Cloud' may be the marketing push for new revenue, the reality is that EBS support revenue makes up an important part of Oracle's overall annual revenue and they won't risk losing those customers by forcing them to switch to a cloud application or anything else.  

So for all you Oracle EBS customers out there, rest easy!  Oh, and if you want to get your EBS work done faster and easier, take a look at API Wizard (www.api-wizard.com).

Vendor Site trx failed: Inconsistent data entered as compared to TCA records.

Vendor Site trx failed: Inconsistent data entered as compared to TCA records.

Working with supplier site API ap_vendors_pub_pkg.create_vendor_site (also pos_vendor_pub_pkg.create_vendor_site) and ran into the following error:

Vendor Site trx failed: Inconsistent data entered as compared to TCA records.  For details, refer to the Concurrent Program log.  Invalid Payee Contrxt values.

Resolution:

The issue was a fairly simple one - I was creating a vendor site address in the US and didn't pass a value for State, so to resolve this all I needed to do was pass a valid US state.

Leave it to Oracle to provide the most cryptic message possible!  I did some more research into this error and found that additional messaging is passed to the FND Debug logfile, where you see a message such as:

Begin of getAddrValStatus procedure
     Map status is E. Check for address validation level.
     Address validation level is ERROR.
     Please enter valid address elements : STATE
     516- Calling create_gnr with map status E.

Of course, when you are calling an API, you'd rather get the message in real time as part of the output parameters.  I guess that's asking too much?

In my research, I also find some interesting suggestions, like turning off address validation:

As System Administrator, navigate to Profile >System, query where application = Payables and profile = HZ: Address Validation Level%, and set the value to 'no validation').  

That's probably not the right approach in most cases but I guess if you're really stuck, it's an option!

WIP Discrete Jobs and wip_job_schedule_interface / Allow Explosion and Scheduling

WIP Discrete Jobs and wip_job_schedule_interface / Allow Explosion and Scheduling

One of our customers was working with a process to create and update WIP Discrete Jobs via the wip_job_schedule_interface.  While this work was being performed via API Wizard (the great Oracle EBS tool which lets you use Excel to perform data entry, updating, and reporting), this blog is relevant to both those using API Wizard and those working directly with the interface table wip_job_schedule_interface.

The issue the customer was having was that they would often change routing information in WIP Operations and on the Job, sometimes modifying and sometimes removing resource requirements.  When they would update existing Discrete Jobs using wip_job_schedule_interface, both the WIP Operations and the Discrete Job's resource requirements would be defaulted back to that of the item Routing.  

It turns out that all that was needed to resolve this was to set the 'ALLOW_EXPLOSION' field to 'N' (for no!).  Once that was done, the WIP Operation and Discrete Job's resource requirements were not changed.

So far, so good.

There was an issue though.  Once the allow_explosion parameter was set to 'N', the records were failing with a scheduling error "Invalid value for scheduling method".  Here there were two issues; first they needed to change the scheduling method to manual, required when allow_explosion is set to 'N'.  Once that was done, the next error was "You must enter both dates for nonstandard jobs without a routing reference".  They were already passing the first unit dates (first_unit_start_date, first_unit_completion_date) but also had to pass the last_unit dates (last_unit_start_date, last_unit_completion_date).  With those final changes, everything worked as desired!  However, it must be noted that the sacrifice made here is that the schedules must be calculated manually rather than using the interface's routing-based schedule option.  This was handled through some logic in a wrapper to ensure the dates were populated correctly.  

A quick note for completion's sake:

In addition to wip_job_schedule_interface, this process also uses wip_job_dtls_interface for loading components, operation sequences, and resources.

Addendum:

One of our customers who wanted to use the Routing-Based Scheduling option without having the Job operations and resources overwritten by the BOM Routing default found that they could use the private API:

wip_infinite_scheduler_pvt.schedule

They say it works great.  Being a private API, not all organizations will use it but since its scope is fairly limited (to the scheduling of an existing job), it appears to be fairly low risk in the scheme of things.

So that throws another option into the mix!