I have a Service Connect package to import Sales Orders. If the part on a line is type of Sales Kit, Service Connect does not automatically add kit component lines into the order. Has anyone done this successfully before?
You have to do a Trace in Epicor to see what Epicor does and replicate it in Service Connect. You need to call the GetKitComponents Method in the SO BO
Thank you, Jose. I did a trace and found that GetKitComponents is called right after MasterUpdate. So I think the GetKitComponents method needs to be called after order is created. I used BL-Tester to succesfully test the call which requires OrderNumber and OrderLine as parameters in addition to others. The result of BL-Tester also seems to suggest that you can only call GetKitComponents if the part type is Sales Kit. If you call it with a part of P or M, it returns runtime error.
I use SalesOrder.UpdateExt to create sales order. So I think I need to use a sub-workflow to loop through each line, check if the line is Sales Kit. If yes, call GetKitComponents. However, I could not get it to work. Order is created OK, but Sales Kit line is not expanded into kit components. I got an error saying “object reference is not set to an instance of an object” in the service connect log.
We also use DMT to import order. DMT before 10.1.600 automatically expands Sales Kit line. However DMT for 10.1.600 does not. Epicor says it will fix this. I was wondering if Service Connect used to automatically expand Sales Kit line, and 600 just have the same issue as DMT.
If someone has done this before and always call GetKitComponents, then I know I did something wrong with my workflow. Have you called GetKitComponents before version 600 from service connect.
Thanks again, Jose!
no Service connect will never automatically do it you have to call the get kit components yourself and you will need a sub workflow for it.
Although UpdateExt can be nice there is a lot of over-use and abuse where people shove entire orders ,details, releases into a single UpdateExt call and it just “WORKS” however it doesn’t make all the calls that it should (Like GetKitComponents) and can cause issues. I think that’s the final goal of UpdateExt but in my experience it isn’t 100% there yet.
I recommend that for any kit line you add those lines independently using the standard GetNewDtl, ChangePartNum, ChangeQty, ChangePrice, Master Update, GetKitComponents
I have successfully done this many times without issue, however using UpdateExt always causes grief in these instances.
1 Like
Thank you, Jose. Your comment confirms my guts feeling when I saw the “object reference” error. I think UpdateExt does not create a proper context for subsequent
call to KitComponents.
1 Like
Jose. Thanks for all the good info you put out on this site. This is a HUGE help.
1 Like
I agree… If you use UpdateExt pass in only what is needed.
I found several ocassions where simply using Update was a better option and avoided errors. For example Epicor BOM Materials when a sequence is involved, never played nice with UpdateExt. But worked flawlessly with Update.
I wonder if this is my problem… I’ve got an order import SC workflow that “works” in 10.2.700 that I’m trying to upgrade to 2022.2. When it calls UpdateExt to create lines, I intermittently don’t get lines created for some orders. There are no errors viewable in SC traces or anywhere in appserver logs… the OrderDtl records are just simply not in the UpdateExt response dataset. I can’t seem to find any pattern behind which datasets work and which fail to create lines…
When I look at the request side I find a bunch of fields I’m not passing in as well as a bunch I shouldn’t need to pass in… I was going to try passing in everything OR scaling back to only the fields I need… sounds like you’re recommending the latter…
Turns out my issue was due to case sensitivity of the Company field in the SalesOrder.UpdateExt request dataset… my xml file was putting Company “XYZ” in the OrderHed ds, and then “xyz” in the OrderDtl ds…