WHEN AN SOR IN GENERATED SOME OF THE TIME SOME OF THE CUSTOMERS NEEDED PARTS ARE ALREADY ON THE SHELF ONE WAY OR ANOTHER (STOCK, FORCED STOCK, ETC. WE HAVE A SPECIAL ORDER PRIORITY SET UP CALLED "IS" (FOR IN STOCK).
HOWEVER WHEN THE REST OF THE SPECIAL ORDER PARTS ON THAT CUSTOMERS ORDER ARE RECEIVED THE ORDER WILL NEVER SHOW FULLY RECEIPTED BECAUSE OF THE UNORDERED LINES ON THE SOR.
THIS MEANS WHEN WE ARE SENDING CUSTOMER NOTIFICATION POSTCARDS USING RRS MANY SORS SHOW "PARTIAL" SO IT BECOMES VERY TIME CONSUMING TO REVIEW EACH SOR TO SEE IF IT HAS IN STOCK PARTS OR THEY JUST HAVE NOT ARRIVED YET
THE ONLY WORK-AROUND WE HAVE IF FOR OUR ORDERING DEPT TO DAILY "CLOSE" THE "IS" LINES.
ITS OK, BUT I RESENT MANUAL LABOR IN THE AGE OF COMPUTERS. PERHAPS THIS "IS" COSE CAN BE PROGRAMED TO SHOW AS RECEIPTED?
ANY OTHER IDEAS?
PS, WE USE COMBINATIONS OF ALL METHODS TO GET OUR CUSTOMERS BACK.....PRE-PAYS, SERVICE ADVISORS CALLING, APPOINTMENTS BEFORE LEAVING, ETC. I'M JUST TRYING TO FIX ONE OF THE PROCESSES
ADP'S SOR NOTIFICATION USING RRS AND CMU
-
jazdale
ADP'S SOR NOTIFICATION USING RRS AND CMU
Rad,
Using a priority of HERE or IS seems to solve the issue up front, but as you state, creates problems on the back end of the transaction.
A couple of alternatives (and a request from others as to how they handle this)
1. Are you creating manual SORs, counter invoices or RO orders? Your staff may be using the wrong type of SOR for the transaction.
A. Only use manual SORS for RO customers that don't have an open RO. Remember to use the correct name and VEHID so it ties back to the not-yet-open RO. Otherwise, don't use manual SORs, it doesn't verify correct numbers the way I/PRO do.
B.If you're using counter invoices, then you should sell the parts you have and order the rest then SAVE, don't print the invoice.
This will reduce the onhand immediately on the stock parts. Physically move the sold parts to the SOR bins. If you need to print something, use the PIK feature. Also consider prepaids to assure the customer will be back.
C. With open ROs, like counter invoices, sell the parts that are here and physically move the parts to a tech or holding bin.
Something I ponder in your situation of in-stock parts.
Would it hurt to go ahead and order the parts that have an on-hand?
When using your scenario, don't you run the risk of someone selling your IS parts before the rest of the order comes in?
I know these aren't perfect solutions, but a small change in your procedures may alleviate the tedium of detailing partial orders in RRS.
Dale
Using a priority of HERE or IS seems to solve the issue up front, but as you state, creates problems on the back end of the transaction.
A couple of alternatives (and a request from others as to how they handle this)
1. Are you creating manual SORs, counter invoices or RO orders? Your staff may be using the wrong type of SOR for the transaction.
A. Only use manual SORS for RO customers that don't have an open RO. Remember to use the correct name and VEHID so it ties back to the not-yet-open RO. Otherwise, don't use manual SORs, it doesn't verify correct numbers the way I/PRO do.
B.If you're using counter invoices, then you should sell the parts you have and order the rest then SAVE, don't print the invoice.
This will reduce the onhand immediately on the stock parts. Physically move the sold parts to the SOR bins. If you need to print something, use the PIK feature. Also consider prepaids to assure the customer will be back.
C. With open ROs, like counter invoices, sell the parts that are here and physically move the parts to a tech or holding bin.
Something I ponder in your situation of in-stock parts.
Would it hurt to go ahead and order the parts that have an on-hand?
When using your scenario, don't you run the risk of someone selling your IS parts before the rest of the order comes in?
I know these aren't perfect solutions, but a small change in your procedures may alleviate the tedium of detailing partial orders in RRS.
Dale
-
radfahrer
ADP'S SOR NOTIFICATION USING RRS AND CMU
hi jazdale,
all "front counter" sors are handled by invoicing, with the exception that we do print the first partial invoice and then "filling" the invoice when the parts have arrived, using an "s" in front of the original invoice number which then rolls the parts to a new invoice (all stuff you're well aware of i'm sure)
the manual sors are used for the ro customers exactly how you have stated
however we do not use sor bins as our size and physical layout and space prevent this. we have other control systems in place
i don't like to order the on hand parts unless they are on blank(stock) status and we are ordering on a stock order. for all other status' then stocking and for all orders other then a stock order we use whats on the shelf. sor's that have instock parts actually get printed so that my warehouse can tag the parts so they do not get sold.
(which by the way, will open up a whole other can of worms because i have an irritation with sor programs available from you and r & r. my first real sor control program i really used was from a company called coin or convergent technologies (later bought out by r & r) however their special order control program was the best by far and has never been equaled. everytime you inquired on a part number the system would check for sors and then tell you in words right on the screen you have x number of parts in stock and you have x on order for each sor you might have. then it would ask you which part you wanted to sell. i can go on and on but back to the original topic)
i've been struggling off and on with this for the last 10 years of adp useage and still cannot find a good workaround.
as a side i do have and know how to use user programing and tcl access at least enough to be dangerous but even with that access cannot make things work the way i would like
i guess what i'm thinking is it should be simple for adp to supply a permanment "hard coded" priority that would not keep the sor "open" if all the other lines were receipted. possible?
all "front counter" sors are handled by invoicing, with the exception that we do print the first partial invoice and then "filling" the invoice when the parts have arrived, using an "s" in front of the original invoice number which then rolls the parts to a new invoice (all stuff you're well aware of i'm sure)
the manual sors are used for the ro customers exactly how you have stated
however we do not use sor bins as our size and physical layout and space prevent this. we have other control systems in place
i don't like to order the on hand parts unless they are on blank(stock) status and we are ordering on a stock order. for all other status' then stocking and for all orders other then a stock order we use whats on the shelf. sor's that have instock parts actually get printed so that my warehouse can tag the parts so they do not get sold.
(which by the way, will open up a whole other can of worms because i have an irritation with sor programs available from you and r & r. my first real sor control program i really used was from a company called coin or convergent technologies (later bought out by r & r) however their special order control program was the best by far and has never been equaled. everytime you inquired on a part number the system would check for sors and then tell you in words right on the screen you have x number of parts in stock and you have x on order for each sor you might have. then it would ask you which part you wanted to sell. i can go on and on but back to the original topic)
i've been struggling off and on with this for the last 10 years of adp useage and still cannot find a good workaround.
as a side i do have and know how to use user programing and tcl access at least enough to be dangerous but even with that access cannot make things work the way i would like
i guess what i'm thinking is it should be simple for adp to supply a permanment "hard coded" priority that would not keep the sor "open" if all the other lines were receipted. possible?
-
DWIL
ADP'S SOR NOTIFICATION USING RRS AND CMU
This problem is not new to ADP or to it's dealers. It has been around ever since SOR came out. It falls into the same category of why we can't prepay a special order on a repair order. Clients have been complaining about these items for to long. ADP just released their new 7.0 release and it has some great features on it. Were they not listening about the SOR problems?? Or are clients just tired of complaing and coming up with their own work arounds instead.
I have been using SOR to the max ever since it came out and find it to be a user friendly system that works well. It just seems a shame to never get the updates to it that it has needed over the years.
I have been using SOR to the max ever since it came out and find it to be a user friendly system that works well. It just seems a shame to never get the updates to it that it has needed over the years.