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.
Tags: bug, field service, fix, geometry, oracle, patch, r12, snow, spatial