Our IT manager will not let anyone use DMT except himself and one other person because “DMT can mess up our database and cause a lot of damage if used incorrectly”
Doing a little research, I can see where it could overwrite a lot of stuff if someone fat fingered a whole column of data… but beyond that, how risky is DMT? Could you corrupt a database with it? With proper training and custom templates, how valuable could it be for, lets say, AR/AP wanting to mass upload Cash Receipts and Payments?
Our controller wants access to DMT and to give a couple other key players access as well. Is this a huge no-no?
Huge no-no Maybe give it to a single power user that understands the database, but definitely not AP/AR staff. Maybe if there is a way to lock down the security, but even with that I would not allow that kind of regular use.
It is very risky. You can delete data unintentionally easily. For example: I recently did a mass sales order line update where I was replacing the part number on the lines. That update also wiped out the line costs, even though the cost field was not required by the DMT template. I should have expected that behavior but wish DMT would have warned me or made that field required.
Point being there are more risks beyond fat fingering data. You need to have an understand of the database relationships.
However, it’s a fantastic tool and very powerful if you know how to use it!
You can control DMT with security, that being said, I agree and do not let normal users access it.
I’ve setup a few UBAQ’s for distinct purposes and limit those to specific people. Can update them about the same way as DMT.
That’s a great example, I appreciate the response! I will let our controller know this.
Most modules have the list view where you can paste insert/update records that could be a good alternative. It works similarly to DMT and does all the proper BO calls. We have some excel templates / macros that users use to mass upload/update records.
Also there are several validations that are done in the UI, which DMT does not interface with, which is why it is possible to cause problems. Best practice is that all validations are centrally controlled but that’s hard to enforce when developing software. DMT usually only interfaces with certain Business Object Methods (I think it’s usually .UpdateExt but there are exceptions).
DMT should be viewed and treated as a Technical Tool. From an end users perspective it can look pretty quick and easy, but if it’s being used properly, DMT loads should first be tested against a Test DB. Also, DMT follows a separate development path and should be treated as a Third Party Tool (though Epicor owns DMT), this forum has many posts about DMT bugs.
Now this doesn’t mean that AR & AP functions cannot be improved or even automated, perhaps with DMT somewhere, but that does not mean AR & AP has direct interaction with the tool.
BTW - Don’t forget about the Paste Insert option in Epicor, which can be very helpful for copy and pasting data from Excel into an Epicor grid. Still need to be careful, but it’s at least safer.
You mentioned they wanted to mass upload Cash Receipts and Payments… you may want to review the ‘Bank Receipts File Import’ program. Depending on your company’s processes you may be able to use other tools that Epicor provides.
For AR there is an optional Lockbox License for processing Lockbox files which may help with this as well.
If you haven’t yet, review the Cash Management Course, there are many options for handling things like this.
Proper BO calls can be important!
Great explanation and suggestions!! I’m guessing Epicor’s original intent was for DMT to be used for “migration” (i.e. new implementation) purposes only, but it has morphed into a powerful technical tool.
That’s a great explanation and I appreciate the advice. I will review the Cash Management Course and take a look at the tools you have mentioned.
I’m far from an accountant, I started as IT support, but after displaying some skill with C#, and fixing a few issues that no one else could, I quickly became the local ERP specialist. I can’t count how many times this site has helped me out. Thanks again Rick!
Only myself and my associate have the rights to use DMT. WE give a template for users to fill out. This way we can validate the data. I also make sure I have a data grab first before updating data. Customer records, Updating parts as @jnbadger mentioned and so on.
One kind of half-way in-between YES its ok and NO it’s not ok for them to use DMT is to remove their shortcut to DMT and instead set up DMT using command line options and create a .BAT file which executes this one and only very specific import with parameters that IT predertmined in the .BAT file. The user could double-click the BAT file to do that specific import but would not have access beyond that.
Optionally, you could configure the .BAT file to fire via Windows Task Scheduler so that it only runs once per day at a time you specify.
Do you have examples of batch files? I have looked at a few things in power shell.
I don’t have any examples, it has been two years since I did a similar thing, but if you open PowerShell and go to the path where DMT.exe is located, you can execute it at the command line with “dmt.exe /?” and it will show you all of the command line options and syntax.
One really odd quirk about this is that the window that pops up can be too large for your screen and you have to really crank up the resolution temporarily to actually be able to see all of it.
You will probably find PowerShell can provide more flexibility as you get all the PowerShell extensions. Here is my blog post on my 2017 Insights Presentation on DMT PowerShell. There is a download with examples (note: from 2017)
Not to pile on, but DMT is not a user friendly tool. Sure, it looks easy, but it has a habit of doing not-obvious things without telling you.
In my most recent example, I was helping an engineer up-revise a thousand or so parts that all needed to be modified in the same way. Building the export script took an hour, DMT took a couple hours to import into a new ECO group. So far so good, right?
Except when it imported each operation, it ignored my estimated times and other data fields. If we hadn’t gone over everything, we’d have checked in effectively blank MoM’s. Did I receive any warning about the tool ignoring my data? Did the screen explain how I needed a 2-step process to write one line? Was there a not-obvious field I needed to include in my import file?
No. It just did what it did silently. Which is the worst thing a tool like this should do. Unless I’ve previously vetted a specific import process, I treat it as just as dangerous as a SQL update against the raw DB. Actually, more so, because at least I know exactly what a update script will do to the data.
For your AP/AR users, I second the dashboard opinion. Alternatively, Epicor sells a module called “Excel Connect” that allows users to import spreadsheets into the system. I don’t have experience with it directly, but I’ve spoken to accountants at other companies who love it. As an IT person, the idea of dump Excel spreadsheets into a controlled ERP system scares me, but YMMV.
DMT replicates the behaviour in the UI. You’ll find that if you change a PartNum on the Order Entry screen, the price will also be wiped out. It is because it’s pulling the price from either a Price List attached to that Customer, or if it doesn’t find that you’ll get the default Selling Price from the Part record.
Always perform the action in the UI first, to understand what DMT is going to do.
It was definitely a good lesson learned Going to adapt your suggestion of performing the action in the UI first. Thank you!
I try to do DMT’s in the Pilot first, especially a nice fresh copy. Harkening back to the book “Unicorn Project”, this is why the ability to create a test system quickly helps with this kind of work. In a DevOps world, we would check the DMT file into Source Control, a job would kick off to spin up a test system, run the DMT and wait for user acceptance testing. If bad, alter the DMT file and check back in to start the process again. If good, a new job might bounce users out, back up production, apply the DMT, and wait for UAT. Once, given, the system would be opened up to users.
Are there ways to actually restrict a user accounts from being allowed to use DMT? Are do you mean “don’t let the users have access to DMT.exe”?
If I’m not mistaken, all a user has to do is to copy dmt.exe (and an accompanying DLL file) to the client folder on their workstation.
Granted anything done via DMT still uses E10’s security settings (but just Process and Field, not menu), a user could still do the things you don’t want them to do.
@jnbadger - Changing a PartNumber on an order line causes it to “refresh” the selling price. It would do that in the UI as well - either a single line edit, or if copy& pasting in the List view of order lines.
It also does the selling price “refresh” if you change the Ship To
you need to sort out your people from those who are switched on, vs thos who are not… we don’t mind the switched on users running it
running without it would make a lot of system task incredibly slow to perform, just need your people to know what they are doing and run their checks prior to commiting it