Scheduler and Colors

[GUTHTIRE]

Is there a setting somewhere to enable all of the colors in the scheduler?

When we post an Invoice the associated entry in the schedule automatically changes to standard color, grey, for Closed.

When a customer arrives and you click their entry in the schedule and create a Repair Order shouldn't the item in the schedule change to light green (Arrived)? Likewise, if you create an invoice from a Repair Order which was created from the schedule shouldn't the entry in the schedule change to the standard color, dark green, for Completed. Are we missing a setting somewhere, a bug, or new functionality that we have yet to see?

[ricmorin]

Schedule statuses are independent from WIP statuses and do not automatically change based on actions in Manager, other than when posting. You need to MANUALLY change statuses in the Scheduler.

[GUTHTIRE]

Schedule statuses are independent from WIP statuses and do not automatically change based on actions in Manager, other than when posting. You need to MANUALLY change statuses in the Scheduler.

Is this functionality being developed for a near future release?

[ricmorin]

It's possible, but logistically I doubt it. With user defined statuses, some people don't use the pre-programmed ones. Having the program automatically switch to pre-programmed statuses may cause issues with those users.

Of course there are those who say to make it user selectable. That would be awesome, but resources and time would be needed to develop something that many users would turn off. Not the best use of internal resources.

My personal take is this: why have a SEPARATE list of statuses in the Scheduler? I want ONE set that updates in BOTH places. SIMPLE.

I'll let M1 comment on what is being developed for the scheduler. Mine are strictly observations.

[murraymotive]

It's possible, but logistically I doubt it. With user defined statuses, some people don't use the pre-programmed ones. Having the program automatically switch to pre-programmed statuses may cause issues with those users.

Of course there are those who say to make it user selectable. That would be awesome, but resources and time would be needed to develop something that many users would turn off. Not the best use of internal resources.

My personal take is this: why have a SEPARATE list of statuses in the Scheduler? I want ONE set that updates in BOTH places. SIMPLE.

I'll let M1 comment on what is being developed for the scheduler. Mine are strictly observations.

Having them mappable is not a massive task. We made a small tool to accomplish this in about 45mins.

[Johnny5]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

[GUTHTIRE]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

Yes, please elaborate.

[murraymotive]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

We compared SM.RepairOrderStatus.RepairOrderStatusId to SM.ScheduleStatus.StatusId to make a map in lieu of a sync tool. It watches SM.BOT_RepairOrderStatus.StatusDescription for changes and updates SM.Schedule.StatusId as the RO progresses.

[GUTHTIRE]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

We compared SM.RepairOrderStatus.RepairOrderStatusId to SM.ScheduleStatus.StatusId to make a map in lieu of a sync tool. It watches SM.BOT_RepairOrderStatus.StatusDescription for changes and updates SM.Schedule.StatusId as the RO progresses.

Is this tool something that you can share?

[timbre4]

I believe this needs to be discussed further before sharing, to ensure an unsupportable condition is not being created.

[murraymotive]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

We compared SM.RepairOrderStatus.RepairOrderStatusId to SM.ScheduleStatus.StatusId to make a map in lieu of a sync tool. It watches SM.BOT_RepairOrderStatus.StatusDescription for changes and updates SM.Schedule.StatusId as the RO progresses.

Is this tool something that you can share?

No, not really. It is not something easily installed & managed by someone who isn't familiar with going on. The next version maps StatusIds to each other that then auto-updates. I could share that one once I have the time to test it further.

[John C.]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

We compared SM.RepairOrderStatus.RepairOrderStatusId to SM.ScheduleStatus.StatusId to make a map in lieu of a sync tool. It watches SM.BOT_RepairOrderStatus.StatusDescription for changes and updates SM.Schedule.StatusId as the RO progresses.

Well, THAT makes perfect sense... but, I kid!!!!

[Rich]

"...mappable is not a massive task. We made a small tool to accomplish this in about 45mins." Can you tell me more?

JD

We compared SM.RepairOrderStatus.RepairOrderStatusId to SM.ScheduleStatus.StatusId to make a map in lieu of a sync tool. It watches SM.BOT_RepairOrderStatus.StatusDescription for changes and updates SM.Schedule.StatusId as the RO progresses.

Well, THAT makes perfect sense... but, I kid!!!!

Glad you said it!