Auto Attachments in Engineering Workbench

Sometime between 905 and 10.2.700 the behavior of attachments in Engineering Workbench changed for us. Now, any attachment that exists on a Part record is automatically copied to the BOM when that Part is added in Engineering Workbench. It did not used to work like that, and we don’t want all the quotes, specs, ROHS pdfs, etc to be copied to every BOM where they end up getting copied to a Job Traveler.

Is there a setting somewhere that can turn this off?

I have attempted to make a BPM on Engineering Workbench methods of ChangeECORevApproved, ChangeECOMtlMtlPartNum, and CheckECOMatlMtlPartNum to find and delete these attachments, but I can not find the right place to see them.
There is a ttECOMtlAttch, but no corresponding db.ECOMtlAttach. And that ttECOMtlAttch has never had any data in it when I have put it in a info box.
When I right click an attachment in Engineering Workbench, and choose Remove, nothing seems to show up in a trace log that tells me what method actually removes the attachment.
I can see BOM attachments in XFileAttch with RelatedToFile=‘ECOMtl’. I might create a Data Directive that could prevent them from ever being created, but that seems heavy-handed and occasionally we do want something attached to a part in a BOM.

Has anyone solved this problem in any way? Or have a hint on how the Attachments flow from Engineering Workbench to XFileRef and XFileAttach?

@alintz That is how Epicor intends for it to work. It is just another pointer to the original file. There was an error in my version that would leave orphan records when a boo was resequenced so I wrote a bpm on checking that removed any orphaned XFileAttch records. You could do the same without checking for orphans. You would have to add something to Part for those that were allowed.

It would be nice to have it optional, but I imagine that would be a large undertaking.

Thanks for the confirmation, @gpayne. Two questions:

  1. How do you know if you have orphan attachments (in general)?
  2. Would you share your BPM that deletes them?

@alintz Bad attachments reference ECOMtl sequence numbers that don’t exist any longer. When a resequence is done the attachment pointers should also be changed.

I have managed to get 95% of the way to a BPM that deletes all those auto attachments from the BOM in a Pre-Processing directive on ChangeECORevApproved. Here are some screen shots of the what worked for me.

I first fill an Attachment tableset variable with any attachments that are found in the XFileAttach table, then use Attachment.Update method with the RowMod set to “D” to perform the deletions. These are removed from the XFileAttach table for RelatedToFile = “ECOMatl” (not the original “Part”).

I have a dataform so the user can choose to have all the attachments deleted or not:


All this works to delete the attachments from the BOM. What does not work is that the tree view of the materials dos not get updated and it still shows the attachments. If I hit Refresh or Save, they go away. So, I need a way to force a screen refresh from the BPM. I guess that is harder than it sounds.
Things I have tried to refresh the tree:

  1. Tracing suggests that EngWorkBench.GetDatasetForTree should reload the tree with attachments gone, but when I run that widget after the Attachment update, I get a Business Logic Error “ECORev has not changed”.
  2. I put this code in a Post-Processing directive. It did not generate any errors but it did not update the tree and it stopped the Approval from completing:
Erp.Contracts.EngWorkBenchSvcContract ECOSvc = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.EngWorkBenchSvcContract>(Db);
EngWorkBenchTableset EngDs = ECOSvc.GetECORevData(GroupIDVar,true);

Unless anyone has any better ideas, I may just add a info message at the end telling the user to hit the refresh button, at least for now until I get smarter.

@alintz I think the only way would be to pass back something in a call context and then do code to refresh the tree. I did mine on check in so the screen clears anyway.