Using a method directive to call the business objects required to create customer shipment. Used a trace file to identify the methods to use. When I check the enable checkbox on the method directive and click save, I get an error message “The type ‘SelectedSerialNumberTable’ exists in both 'Erp.Contracts.BO.CustShip…” and "Erp.Contracts.BO.SalesOrder. Additional error regarding the SNFormatTable as well.
I don’t see either of these referenced in the trace file and the parts I am using are not serial number traced.
The only execute custom code I have is to obtain the order information from a BAQ. Everything else is invoking the BO.
This is a known thing - especially for SN Tables because both objects use them. I can’t find it but there’s an old post from @josecgomez about it.
I wonder if a function (in another library) can get you around this now. Bring in your sales order data from a function but in a different dataset to prevent the conflict. 
I think I may have seen the posting from @josecgomez…will look for that. I think it had a reference to some code that needed to be added. Serial numbers have been a challenge for years, dating back to Epicor 9. I had to do some customization to get this to work with Service Connect as well. That was so long ago…
While I didn’t come up with a resolution to this specifically, I re-read your note and realized the issue is that the selected serial numbers is used by both order entry and the shipment entry - and I did not catch that in the error message. Since this was just done for testing, I just moved all of the work to a change on the job header so I can keep moving.
Thanks for the comments. The work around I think, for generating shipments automatically would be to trigger it from a scheduled event.
Funny thing is that this just happened to me this week. The official response from Epicor is KB0036627:
My unofficial response is to do the whole darn thing in a code block… ![]()
I did try to call an Epicor Function, Jsonify the tableset, return it as a string, and rehydrate just the tableset but that still somehow generated the type collision error.