DMT into field with RO field secuirty set - no error

Has anyone else noticed this?

If a user who has security for a field set to read-only attempts to update a record containing the field using DMT then DMT reports no error and the field is left unchanged.
Test performed in our environment of 10.2.400.8 and using DMT 4.0.57.0

DMT has a habit of quietly not doing things you tell it to do, or occasionally doing things you didn’t tell it to do. Every time I try a new import module for the first time I treat it like a development effort and give it a full battery of test records just so see how it will act.

The field security is honoured - the field is unchanged, but it would be good to see a warning in the logs

RIght. My point was, “DMT did(n’t do) this thing and didn’t alert me” is a wider issue than just field security.

I raised this with Epicor support and the response came back that it is ‘by design’
I pushed it as feature request for DMT, but development have rejected the request.

If Epicor themselves are saying that DMT is not the right tool for this job then maybe it’s time to look at something that gives you more control over the error processing. Might I recommend Epicor Functions? DMT isn’t cheap and if you’re not in need of many batch imports any longer, you can save some serious money by not paying support for it. Just a thought.

Hello Mark,

Epicor functions? Is that one of the recent enhancements to the REST api? We are on 10.2.400 atm.

I think lots of people bought into DMT when they initially migrated data to Epicor and had then sought to utilise it for various processes afterwards.

Epicor Functions start with 10.2.500. They CAN be called from REST but they can also be called from BPMs. I believe in 10.2.600 that they can even be scheduled.

You are exactly right. DMT started as a migration tool but people continue to use it afterwards because it became familiar. Is it the best tool for daily work? I think batch oriented processing is not always the best way to handle daily transactions. I think the same can be said for ServiceConnect when used as a batch tool but it has a little more flexibility than DMT when handling errors.

We have a Service Connect licence, but for various reasons have never installed it. I really ought to make the effort i think.
10.2.600 is also on my ‘to do’ list

I’m not sure sure I would invest too much effort in Service Connect myself. It integrates with a specific version of Epicor so the upgrades are more work. If you can get to 10.2.500+ then you can do similar things with Epicor Functions. You can still used REST with 10.2.400 but you’re putting the logic in the client instead of keeping at the server, which again is more work at upgrade time. You’ll find that if you optimize your modifications to be “upgrade friendly” and you do upgrades more often, it’s surprisingly smooth. The SaaS people upgrade twice a year with a monthly patch. The more you do it, the better you get at it.