Since Epicor rejected my idea . .

[Mark_Wonsil]

@mbayley

Don’t tell me a job doesn’t exist just because I forgot to order my DMT by company.

I’m used to “Object does not exist” errors when associated links don’t exist. Not the best error messages in DMT…

[Mark_Wonsil]

@zachg

I would probably write a function to do this

Well, at least with functions, you can pass the company and site in the call headers.

[mbayley (Michael Bayley)]

The DMT tool already does send callsettings header with the company and plant. Every row is another request to the api. You would think that changing the company for every row wouldn’t be an issue

I’ve had very few problems with multi company DMTs, which is why I’m surprised that @aosemwengie1 says it is. Must be something different in 2024 versions.

[klincecum (Kevin Lincecum)]

@mbayley

Every row is another request to the api.

Seriously?!

[Mark_Wonsil]

@mbayley

Every row is another request to the api.

Oh, they finally DID update this for the cloud! I still like the idea of getting the data up to the server and then calling the APIs. It would be so much faster I would imagine less chatter over the wire.

[jgehling (Jeff Gehling)]

“Server Processing” was introduced I think in 2024…maybe 2023.2 and that batches records buts its only available on a select few business objects.

[mbayley (Michael Bayley)]

Actually, it’s more like 5 for every row

[klincecum (Kevin Lincecum)]

I’m beginning to be glad I don’t have DMT.

[mbayley (Michael Bayley)]

I am speaking for 2023.2.

It looks like there have been changes in 2024. Hopefully for the better.

Update rows in table

so… ( Safe Harbor…We are doing stuff with DMT and UpdateEXT in a future release… and we did find something! During some changes that we are doing in DMT, we are changing it to be more efficient, and instead of adding/updating/deleting one record at a time, we are going to be sending larger blocks of data (also know as "page size)… What we found was that, while we are going to make this be a flexible setting, a page size of 200-300 maximum was the most efficient, and …

[Banderson (Brandon Anderson)]

@klincecum

glad I don’t have DMT.

DMT is a perfect example of tech debt that needs to be paid eventually. It was originally designed for a very different model. Since then it’s been “Updated” to follow along with the new cloud model, but probably needs a clean sheet redesign to take into account the new factors involved in the process. But that’s expensive and time consuming and not immediate, so it just hasn’t been done yet. I get it though, you can’t do everything at once.

[Ernie (Ernie Lowell)]

@Banderson

DMT (…) was originally designed for a very different model.

Truer words were never spoken.

[aosemwengie1 (Alisa Osemwengie)]

@mbayley

I’ve had very few problems with multi company DMTs, which is why I’m surprised that @aosemwengie1 says it is. Must be something different in 2024 versions.

Like I said, its only very specific templates. That’s what I don’t understand. If it can take the company context from the row for some templates, it should work for all. The explanation given on my idea makes absolutely zero sense.

[Ernie (Ernie Lowell)]

@aosemwengie1

The explanation given on my idea makes absolutely zero sense.

It makes zero sense IF we look at it through OUR lens and say, “this is how it really ought work”.

Receipt Entry has some unique sub-processes (Intercompany and Mass Receipt to name two) that might utilize non-standard methods that may well have been “finessed” when originally written. Even the original programmer may have been holding his/her nose just to get the thing out the door.

There are different lenses that may define “sensible” somewhat differently.

[aosemwengie1 (Alisa Osemwengie)]

The reason the response doesn’t make sense is because it insists that DMT must rely on the current user context when we can clearly see it works fine regardless of current context for many templates.

[Ernie (Ernie Lowell)]

@aosemwengie1

for many templates.

Yes. But maybe not for this one.

[aosemwengie1 (Alisa Osemwengie)]

So why doesn’t the admin response acknowledge that and explain why?

[aosemwengie1 (Alisa Osemwengie)]

This is why its so irritating to be told to enter an idea. First you go to support and support says working as designed, enter an idea. Then you enter an idea and you get shut down without any engagement on the real issue, or any explanation of what is even going on.

[JMPCONJ (John Magee)]

@Ernie

Receipt Entry has some unique sub-processes (Intercompany and Mass Receipt to name two) that might utilize non-standard methods that may well have been “finessed” when originally written. Even the original programmer may have been holding his/her nose just to get the thing out the door.

Dropship receipt is another one that’s likely non-standard…PUR-DRP and DRP-CUS transactions, the purchase order update, the sales order update…and just for fun, wrap EDI around it (ASN inbound from a vendor, invoice/ASN out to a customer). Yikes.

And in a small attempt to lighten the mood, here’s something funny involving lenses.

[Hally (Simon Hall)]

I am with you on that sentiment, it’s as if DMT got hijacked as a quick and dirty way to get data in and modify it for flawed parts of the system, that should have been fixed long ago. Either that or put in place because people have not understood how things work, and have given bad advice. Present company excluded. Crucify me frankly I am beyond caring.

[leonardpothier]

For those that think Price List Import/Export is usable, please create part number 348.000 in your system, add it to a price list and then export it, modify the price and try to reimport it. Bonus points if you also have part 348 setup. Let me know how that goes for you.

There are totally valid reasons to use DMT over the built in Import/Export tools.

Further on Price List maintenance tasks, there is no way I know of to remove expired PL from Customers and replace them with a new version with the hierarchy.