“DMT already requires the inclusion of the company field in every single template. I should not ALSO have to switch my context to that specific company to be able to run a DMT for that company. This problem seems specific to certain templates, for example PO receipts. If I need to run DMTs for 12 different companies, I now have to create 12 separate DMT files. Close DMT, relaunch Epicor, change companies, relaunch DMT, run the DMT. Then repeat 12 times. Instead of just doing one data load. This is preposterous and unnecessary.”
" * ADMIN RESPONSE
Nov 12, 2024
We will not be proceeding with this idea. The challenge is that DMT is not just dumping data into the database. It follows all the security rules. By changing the context, you are allowing Kinetic to know who you are and what company you are working in. then Kinetic can apply the security rules that YOU have against your login. Since there could be different security rules (Business Object, table and field level), as well as separate BPMs that might fire in each company, it needs to be in the correct context to handle those rules."
Anybody else find this response nonsensical?
For one, MOST DMTs already allow you to push records into many companies at once. Only certain ones are context sensitive. Why?
The entire point of DMT is BULK data loads. If I have to split what shoud be one load into 10 or 15 different files of 25 records each, how does that help me? Not to mention the absurdly tedious process of switching companies in the main application since DMT doesn’t have this facility?
You already know which BPMs to fire - by virtue of the company field on the DMT record. The context of the user running the file should have no bearing on it.
I’ll grant you that anyone running a DMT should be a power user. However, field level security can be down to user level so must be considered. I see your need but I also see their point.
Perhaps --if it doesn’t already exists-- they could add a powershell script switch command to switch companies and process the file for that company.
How is it that I can run one DMT to update every site record in every company at once. Yet if I want to update multiple Receipt headers, I need a separate file for each company?
And there is also no rhyme or reason nor documentation of which files require company context and which don’t. The only way I know is when I run one and get some strange error (of course the error doesn’t tell me the real problem), and then I guess that perhaps this is one of the ones that requires company context, and then validate that assumption.
It depends on the file. Some have to be split some don’t. I can’t figure it out. I do believe its new as of about the last year or two, I never used to have this problem with any template.
Given how consistent this hassle is, and that Epicor isn’t going to be resolving it, I would probably write a function to do this. Ruins the point of DMT but at least the system still has other routes.
Well…maybe there is. A lot goes on when we change companies. If I understand what is happening, a whole new session is created for each company we are logged into, and maybe again for each site within a company. All of those BPM context variables (currentplant, currentcompany, etc.) are pointed to the active company/plant. That has to be adding a lot of extra overhead with each context switch. If you look at all the active sessions, you’ll see multiple entries for each user who is logged into a company/site and the one that is currently active.
So it would seem that sorting by company/site would at least be more efficient than mixing everything up in a single file.
If this is the case, there should at least be some validation when a file is loaded. Don’t tell me a job doesn’t exist just because I forgot to order my DMT by company.
Frankly, I think DMT has outlived its usefulness. There are way too many ways to import data into Kinetic. In addition to DMT, you can import parts in Engineering Workbench, Price Lists have their own import, Intercompany processing, EDI import, etc. Move the actual functionality of import into the Business object.
And is batch processing what we really want? I’d really like to see process queues that you dump “records” on. You can have one (or more) of these queues per company/plant. The queue would call the business object’s import method. You might want to split validation from import so you could check all records first or just run them in a sequence. If there’s a validation or import error, the record goes into a retry queue like DMT would do.
DMT is great for initial loading. But having process queues would be better suited for cloud. Because you know I’d bring it up, you could use source control on your imports. Check an import file in, have it run a validation, then push the records onto the queue. Now you know who ran it, what was in it, and when it was done.
