Posts Tagged ‘bug’

Waiting for bugfixes, meanwhile implementing webservice

Monday, April 20th, 2009

Is it April allready? Wow. Time flies when you’re having fun. I’ve been pretty busy since my last update. Oracle provided several patches for the bugs we filed, but still hasn’t come up with a satisfactory solution. We did find a work-around for the geocoding problem, still not fixed though. We have the problem under control, we didn’t solve it, but it works: travel times are correctly calculated. The trick? Schedule the “find invalid address” for every 5 minutes. After running it, all tasks that lack a hz_location will now have one. Don’t ask me why, I haven’t had time to dive into the code. Please, please don’t tell me this is how it’s supposed to work.

Also some side projects have taken off. We’re implementing a webservice to create service requests from other applications. Nifty stuff. I had to test it, and review all kinds of documentation. I think we got it up-and-running pretty good now. With this webservice we can also connect a website through which customers can enter their Service Requests. Yeah, I know… sounds a lot like iSupport. But iSupport is not part of the architecture landscape, so we have to find other means. A general webservice does the trick nicely together with the allready existing websites.

Now the technology is working, we need to implement it within the organization. Although that sounds simple, it actually isn’t. SR’s used to be entered manually and any error correction was done at data entry. Now SR’s will be automatically inserted and you have to do some data validation before starting to schedule. This change takes some time to think it through, design the process, find the exceptions in it, fix / work around those, instruct the dispatchers, etc. Might take as long as creating the webservice itself. Maybe by then Oracle has come up with a fix.

One week of snow, one week of catching up

Friday, February 20th, 2009

The week of 9 feb has been full of snow in Hinterglemm, Austria! 2 days of sun and 5 days of snow. I think we got more than 50cm snow during those couple of days. It’s been more ploughing than skiing, but it was definitely fun! Even managed not to break anything! ;-)

This week has been as busy as the ones before. My project focus shifted somewhat to other-than-field-service related stuff, which is hard sometimes but always interesting. The bug I found two weeks ago wasn’t solved during my week of snow, even worse, it wasn’t considered a bug at all and therefore an enhancement request (that’s what Oracle Support said on my voicemail). I was really frustrated about that and I didn’t want to accept this, because the workaround for it isn’t workable at all. So when I came back from Austria I explained the problem again and now Oracle considered the behaviour a bug and is fixing it as we speak. Frustration gone, waiting for Oracle to come up with a patch. Let’s call it a miscommunication and leave it at that.

One thing that struck me was that Oracle Support mentioned that another customer was also asking for a resolution of this bug. So another customer is actively working with Field Service R12 and they’re supposedly on 12.0.4. Interesting. If someone knows who they are, I really want to get in touch with them to exchange some experience with R12.

Biggest challenge Field Service related is the geocoding of locations that doesn’t seem to go right. When scheduling a task, the traveling time is set to a default value. This happens a lot, but we can’t reproduce it on a test environment. It seems the postal code geometry is there but the coordinates aren’t copied to the hz_locations. This happens only on production… Challenging :-) I’m working on this problem from the sidelines, because my colleagues are tackling this one. I’m thinking a technical issue, because from a functional perspective (we think) we ruled out everything.

Oracle Field Service

Wednesday, January 28th, 2009

I’m neck-deep in a Field Service implementation. I’ve got a sort of love-hate relationship with this module. For companies Oracle Field Service is hardly ever the reason to choose Oracle EBS, but mostly it’s good enough to use. That’s something I have to live with and explain a lot. Usually companies choose Oracle EBS for financials, for CRM or just because everyone in the (vertical) market uses it. Field Service is then usually used because of its integration possibilities. You have to admit: integration is one of the better aspect of this module.

In a previous project I tried to think of as much reasons why Oracle Field Service was NOT the module they should use – some of them were:

  • absolutely no way of assigning tasks in bulk to external engineers without creating dummy engineers and still keep an eye on availability of these external engineers
  • the incredibly hard way for employees to trade shifts
  • the inability called Gantt chart (I can write a book about the inabilities of the Gantt)

In the current project, the business case is totally different. A lot less field employees, a lot of different skills and tight travel schemes. And actually I’m thinking: this project might be a very good fit for Field Service. Yes, there are external resources, but they need to have very specific skills and they have to do some kind of intake before they are allowed to be hired (I guess). But still there are some aspects that Oracle can’t handle. For example: Oracle can’t handle flexible constraints like “max of 10 hours a day of work+travel” or “if there are still internal resources available, use them instead of external resources”. The latter seems possible, but the scheduler first qualifies all the resources based on territory criteria and then checks availability. There’s no cost factor for external resources (enhancement request / bug nr = 6878526) unfortunately.

Talking about enhancements: I’ve logged enhancements for two ‘opposites’: the opposite of skills called inabilities (bug no 8203169) and the opposite of preferred resources, with the very inspiring name ‘unpreferred resources’ (bug no 8203096). Both sound very logical to me, because how else to deal with employees with allergies? Or employees who messed up at a customer, meaning sending that person again would lower customer satisfaction?

Now I’m thinking hard on how to optimize the current implementation, not only in the application but also in the organization. And I’m looking forward to 12.1 which promises more advanced scheduler optimization possibilities (RCD metalink note 561580.1). Yes, Field Service takes up a lot of my time, even while not working billable hours. Guess that’s a good thing, or is it? ;-)