Question for the CDK guys

[Zep33]

Do you all use "Autofill" ? not sure if that's exact term

This where the parts are automatically billed to the RO and/or parts invoice the moment they are receipted

thanks

[TimK]

no

[tmundal]

Nope.

[marko65]

YES WE DO IT FOR OUR BODY SHOP AND THE IT PRINTS A PICK TICKET AFTER I RECEIPT IT. WE USE THE PICK TICKETS FOR PROOF OF DELIVERY. WE HAVE THE BODY SHOP SIGN THEM AS PROOF.

[queenbee]

we did when we were on CDK and we loved it. Pick ticket automatically printed to let us know what we received.

[Zep33]

OK, wanted a few answers before I posted my dilemma with this

We use it and I love it - except for one thing:

On internal repair orders, if service closes the repair order while a part is still on order, the system will automatically create a parts ticket / repair order that cannot be accessed by either parts or service and can only be voided out by the CDK helpdesk (if you want to call it a helpdesk).

Our service department is under strict orders to NOT close any internal repair orders that have parts still on order. Every now and then one gets closed and I have to spend a minimum of an hour in a chat with some tier 1 guy that's never heard of this issue and won't ask someone sitting near him for help. It gets extremely frustrating.

I had one happen yesterday - We'll call it RO 220971 - a part was ordered and then they realized it didn't need the part and closed the RO without telling parts. Part comes in this morning, gets receipted and has no where to go so it created 220971X1 because it has to go somewhere. If you try to access it through the parts invoice screen, it tells you that it's an RO and to use PRO. When you try to access it using PRO, you get a message that the labor record is missing and it won't go any further. So the need to deal with support comes in to play and each time (probably dealt with this 10 times over the last 2+ years) and only one guy had ever heard of it and was able to fix it in a couple minutes. Each other time it took at least an hour for them to figure it out and fix it. Today they guy couldn't and said he'd get back to me and still hasn't.


About a year and half ago, I got tired of this happening and had them turn off something to fix it and that turned out to be the autofilll. The problem with that was we didn't realize all the parts we handed out over the course of that morning weren't billed like everyone was used to. We will not hand out a part until it's been receipted but had no idea they weren't being billed so I had CDK turn whatever they turned off back on.

So I'm looking for anyone else that has had this happen. It's only internal ROs that use the same customer # over and over for different vehicles. I believe that is why it happens to those and none others. Other cars at least have a customer to attach it to if the RO is closed. If someone else is having this happen, what are you doing to get rid of those X1 inaccessable invoice/ROs? The problem is the part is actually billed on it and the on hand is off until they fix it. Plus I get hammered by corporate if I have open invoices and it shows up as a parts invoice, not an RO. And it can't even be seen in Fastlane / open invoices either. It only shows up in reports.

Thanks for reading

[queenbee]

we had this happen a handful of times over several years. I refused to let CDK close out any of my cases without a reasonable explanation/resolution, so I would just update the same case each time with "this happened again- 220971X1" instead of starting from scratch with a brand new person.

[Zep33]

is it only for internal ROs for you as well?

[queenbee]

My memory isn't great, but I believe they were. Same as you said, the internal customer number without a name that had tons of vehicles attached to it.

[Stevenspeaking]

Keep a copy of the case number handy as well in case they do close it. I have a custom report that will have the file it is looking at change location from time to time. Providing an old case number has saved a bunch of time. They just look at the solution notes that corrected the problem before.