Would this be it? I logged enhancement request 6878526 with the idea of Scheduler taking into account the rank of the territory when scheduling. The RCD of 12.1.1 has this in it: “Sort Winning Territory Resources by Absolute Rank”. Meaning my previous post would be solved? I notice it says Casema wanted this feature… 
So yeah, I’m thinking this might be it! I still wonder whether costs are assigned to rank… without higher costs for lower ranks Scheduler might still choose a resource from a lower ranked territory because the travel time is lower. Questions, questions.
Other than that, Oracle also has done some significant optimization on the Scheduler part. When scheduling tasks to resources, Scheduler will firstly sort the tasks to their geographic proximity. This means travel times will be more optimized. I wonder how much better this works when you don’t use plan windows, but we’ll have to test that. I mean, sorting on geographic proximity is quite worthless if you want to optimize the promised time (as opposed to a window), but in that case you find the promised time more important than the reduction in travel time. Which might be very valid for your business case. Nevertheless, this feature could be very useful.
The other major feature in Scheduler is the long awaited cross-engineer-optimizing. Scheduler used to optimize single trips only, but R12.1.1 now optimizes across trips / across engineers. Basically this is what you want. If you have 100 engineers to schedule every day, you can’t verify manually if Oracle really optimized all schedules. Optimizing all individual trips would still not tackle the case in which some of the tasks at engineer 1 would be lower in cost when assigned to engineer 2. This new feature promises to solve this issue. You might want to schedule this Optimization Program (it comes as a concurrent program) a few times a day, so you don’t have engineers doing nothing at the end of the day (because optimization might reschedule the tasks to less engineers).
Tags: 12.1.1, assignment manager, ebs, enhancement request, field service, oracle, scheduler, teleservice
Hi Klaas,
Its very interesting to read your notes about FS. Keep on doing!
It seems to me that there is also a strange bottleneck with providing latitude and longitude information and takes it into account when calculating distance by means of TDS (point to point). For example, I need to calculate the distance by point-to-point method and the latitude and longitude should be sufficient for it. So I cannot see the way how can I populate geometry columns of hz_locations table with latitude and longitude information without using spatial data.
Thanx,
Lennox
Basically you need spatial data to calculate distance. At my current project we added the spatial data for postal codes (latitude and longtitude) to EBS and we use that to calculate distances between tasks which are scheduled at certain locations.
There’s a peculiar thing with how spatial data is copied from the postal codes table to the hz_locations table. I thought it should be automatically done when creating a task, but it actually doesn’t. I’m not sure if that’s a bug. We didn’t dig into this, because the workaround is sufficient for now. The workaround is to schedule the concurrent request “Find invalid address” every 5 minutes or so. Somehow this request also copies the spatial data to the hz_locations table. And Adv Scheduler then calculates point-to-point correctly.
Don’t ask me how, I haven’t had time to figure it out.
Hope this helps, though.
Klaas
update: I’m talking about release 12 btw. 12.0.3 to be exact.
Thanx Klaas,
Can you please to briefly answer on:
1. There is no way to provide spatial data (latitude and longtitude) by means of application (for Adv Scheduler). Am I right?
2. Is there any way to directly provide spatial data (latitude and longtitude) to hz_locations table?
3. I cannot find any information how to correctly provide spatial data without using Navteq datasets =(. If you have some, can you please send it to llllennox@yahoo.com.
I am appreciate your help.
Lennox
Hi Lennox,
1. You cannot enter spatial data through the front end (GUI). It’s something to be entered directly in the database.
2. no, for long-lat data you need to fill the csf_lf_postcodes table. The geodata is then copied to the hz_locations automatically (see my previous reply about the workaround). This way you have 1 truth which is the postcodes table, and when you’re adding new locations, the data should be copied to them as well. Filling the hz_locations table would only temporarily fix your problem. And second: I don’t think Oracle supports that.
3. Frustrating, isn’t it? We just asked Oracle through a Service Request to cough up some documentation on how to do this. Oracle does not provide this through Metalink. This was a question regarding full blown route optimization btw, not just point-to-point.
But: Oracle did help us to get the postal code information in the csf_lf_postcodes table. The spatial data was not Navteq’s, but our own. I would suggest to open an SR through Metalink and refer to SR nr. 6568355.994, that contains all the information you need. Please understand that I cannot directly give you the content of it, because basically my contract says I can’t :-/
But how does Oracle supports the direct DMLs on csf_lf_postcodes or other csf_lf% tables?
They support the working of the application, but not the calculation based on the data. In other words: it works fine as long as you upload the correct data.
Yes, but Oracle should provide how to upload data correctly and what data upload format is considered to be correct.
These tables are intended for data upload, but they are not marked as interface tables by Oracle. If they dont marked as interface tables and Oracle didnt documented this interface, they should consider as standart tables with all DML restrictions applied.
I agree.
But when we asked Oracle how to get the geodata into the tables, they provided us with plain update statements. Please refer to the SR number I wrote down and ask Oracle on how to proceed.
Definitely not good and frustrating.
It seems that Oracle only supports compatibility with Navteq datasets.
Other variants:
1). Use non-Navteq vendor for spatial data
In this way, customer should care about convertation program from vendors-format to CSF-format. There is also no metalink notes for other vendors.
By the way, Klaas, have you got an experience to load spatial data into CSF schema from non-Navteq vendor?
2). Not use vendor’s spatial data at all.
In this way, customer should use DML.
It looks like closed interface.
Hi Lennox,
Oracle only supports Navteq datasets, that’s correct afaik.
1) -> correct
2) -> also correct, but you probably need to insert the data directle with any non-Navteq vendor as well.
I do have (some) experience in handling non-Navteq data, but only for point-to-point data, not the full blown “calculating actual travel time”.
I don’t think it’s a closed interface, it’s no interface at all…
Hi Klaas, thanks for your so quick replies.
We logged SRs, and keep trying to get something from Oracle guys.
You’re welcome, good luck and let me know if you get it working.
cheers.
They support the working of the application, but not the calculation based on the data. In other words: it works fine as long as you upload the correct data.