You’re lines aren’t sales kit components technically so should be fine. You basically made your own custom “Kit system” using UD fields.
My first job at a manufacturer had a sign in the break room: “Beat it to fit; Paint it to match!” Sometimes I swear we need to do that with Epicor.
@MIR that’s what I was getting at, what you just did is sweet! Thanks for sharing with us all and taking the time to do note all this out and work it out.
@Randy, my Data Directive makes the Sales Kit components available for Job Wizard.
I don’t think so but only way to know for sure is to test in our in your Pilot database.
How are you doing that, would you care to show us? I’d have to re-read this thread probably cause you’ve iterated through a lot. Is it that kit components can’t be marked as make-to-order on the order release in the normal UI and you’re using a data directive to override that?
You got it @utaylor!
I’m overwriting the Make Direct check box on the order release that Epicor made read-only for parts entered as Sales Kit components. By doing so, the Job Wizard gets activated enabling me to create jobs for those components.
Can you show us how you did that in the data directive? I think that will be something people are interested in to weigh in on this.
You did away with your UDs?
I feel like we need to attend @MIR 's webinar on “creating your own sales kits” haha This all sounds really cool, would be cool to see.
Insights EpiUsers customer presentation?!? @josecgomez
Below is the summary of my findings.
I believe now I have 2 answers to my own question about the Sales Kit functionality in Epicor.
To utilize hiding of some parts from SSRS reports, we can either create a scenario that mimics Sales Kits or change existing Sales Kits to our needs (I’m not sure of consequences yet and this is why I’m posting it so maybe somebody will warn me before anything explodes).
Personally, I like the second solution better, since it is well functional inside Epicor. As long as I can get away with it, that’s the route I would like to consider.
@josecgomez / @hkeric.wci , is this join in the widget above susceptible to this: E10 BPM Slow due to Join? - #7 by josecgomez
@MIR, I don’t have anything new to add. When I asked @hmwillett one time about how to know if a customization is truly ready to be implemented in production I think I got a response like, “you just have to implement it and find out.” Paraphrasing now as that was like 8+ years ago.
@Chris_Conn has made many a customization so maybe he can weigh in on this too.
Like @Randy, I think all you can do is test the crap out of it in your pilot environment. Everything from running MRP against it, shipping against it. What happens when you want to un-ship it, create a credit memo, RMA, etc.
Whoa! Going to try this out, but for Drop Ship. Also, since you’re able to write to the field with a BPM, has me wondering if in Kinetic there’s simply a data rule or two setting those fields (Make, Drop Ship, etc.) for the kit components to read only that I can hijack and make them editable in the UI.
Yes that join would return ALL OrderDtls and the filter down.
Thanks man.
I have no specific warnings, other than sometimes it is exceedingly difficult to test all the edge cases for changes like this.
This is for several reasons, but mainly due to the footprint of the logic. For example, even if you were to decompile the entire logic for something like the Sales Order screen related to your goals - it can also touch quotes, shipments, MRP. You can certainly test all avenues, but just knowing WHAT\WHERE all to test is challenging.
I dont say that as a way to scare you aware from it, but to just be cognizant of the potential impact.
Also, even if you do catch all the edge cases for a particular cfg\setup, if your internal process (or Epicor’s underlying logic) changes in the future, you can find yourself in a pickle.
@josecgomez and @utaylor are you saying that it isn’t a good practice to user a ttOrderRel in my Data Directive Query?
Would it be better to use ERP.OrderRel instead?
No, the issue is joining a ttTable to a non ttTable see that post that was refered here.
In summary the LINQ doesn’t know how to do a SQL join between an in memory table and a Db table. So the better approach is to get variables which contain the filters you need and then just use the DB Tables with Criteria to return the data you want.
I’m not sure what you are trying to do but yes that’s better as long as you are limiting / filtering those tables down correctly.
The problem is having a join between a light blue tt table and a green table.
