We are still not implemented yet and one of my challenges is for something we call our “Install Contract”.
We are a mostly a sign manufacturer, we also sell installation as a service option. Each sign has a “Mounting Method” which will add some hardware or materials to the MoM of the line item. One item we call the Install Kit, sometimes this kit is just a piece of paper for install instructions.
We contract out much of our installation and our installers are have a set payout schedule based on what I call “Install Codes”. Our Install Contract is a list of quantities and Install Codes.
Install Codes is a combination of the Install Kits and in many cases Small, Medium, Large.
In our older ERP I was able to maintain a variable that housed this Install Code. I could do the same in Epicor with a UD Column, which I have created.
Now comes the part I am unsure:
Our Install Contract is tied to our Payout Sheet where each Install Code has a given rate. In our current system I created an external database table with these codes/rates and combined this in the Install Contract.
I don’t want to create an external table of these codes/payouts in Kinetic. I would prefer to do this within Kinetic.
One option I considered was to create these as parts and add them to the MoM, but this seems to be creating some difficulties with the buyers workbench. We have 20+ sales people that act as their own install coordinators so they would all be in and out of the buyers workbench and have lots of parts in there at any given moment will create a lot of confusion. We prefer to populate the Buyer workbench with a single line for each install to simplify that process.
The Install Contract doesn’t need to be directly tied to a PO, it can be a separate report that gets combined. I pondered if I could create a table in Epicor SaaS to reference? Or maybe have these as parts and simply reference them in a report? Is it best for me to leave this as an external system?
There are a few options available to you right out of the box. As you have already determined, you can add UD Fields to any existing table. There are also built in UD tables that you can claim for whatever use you like. They can be a simple UD table, or there are even some set aside specifically for a parent-child relationship between them. There are also UD Codes that you can define a Code Type for and then a list of Codes under that type that you can define. For simple things like combo boxes, these tend to be a good option.
As you mentioned, you could also create a non quantity bearing part number for your install codes. Since they aren’t items you will be purchasing, I would try to keep them off the PO Suggestions if it were up to me. You can disable the Generate PO Suggestions checkbox and then create a dashboard/report to monitor them. It would be easy enough to create a distinct product group and part class for these. Depending on how you want this to work, it might even be something you could pull off with Misc Charges.
You have lots of options. The reporting/planning side on this seems like it might be the easy part. How does accounting want the debits and credits to work might end up being the harder part.
Are they truly considered part of the job or they “add-ons” to the sales order? Is there any time and expense tracking that needs to be recorded for these? Where does the revenue go? How about the cost?
I like to think of moving from one system to another like learning a new language. In languages, there are different idioms and sentence order. I can try to force the old syntax into the new language, but I will never sound like the native speakers if I insist on using the new language the old way.
The old ERP has “Install Codes” because that was the syntax. Instead of trying to implement the Install Codes as is, step back and consider what you are trying to do.
You need a way to:
- Tell the installer what to do
- Schedule the installer
- Bill for the materials
- Bill for the installer
- Pay for the installer
It helps me to pretend I am a new business and all I know is the new ERP and then see what we can come up with.
Could not agree more with Mark here.
Take the opportunity to re-evaluate what you are trying to accomplish here and then work your way backwards to how you can make that fit into an Epicor based solution. You can smash that square peg through the round hole if you hit it hard enough, but you might find a better way to do it before you try that.
Some folks might even go as far as using Field Service for some of what you are describing.
I agree with the sentiment, if we had more time I would want to delve into this deeper, but our implementation has been slowed down by our heavy reliance on CPQ and the amount of time it is taking us to get to that.
My original pitch was to have each of these as “parts” and the PO would become the contract. The worry was/is the buyers workbench becoming cluttered with these parts. Also the many number of vendors (installers) we work with to fulfill these might make this approach challenging.
I appreciate the stepping back, if you had a direction I might want to look feel free to give a little nudge. I have to admit my lack of deep understanding of part settings and the buyer workbench or alternatives has kept me from trying this avenue further.
I agree with Marks suggestion 100%.
If you wanted to go down the PO path then you could put a ud field on the POHeader to identify the PO type (Std or Installer). Then a customisation to the buyer workbench to apply a filter (maybe a button) that show or hides those PO’s
If you have external parties doing the work then you need some way to “ask them to do the work” and a PO is that document.
I’m going to print this out and frame it.