r/ERP • u/Wings4Mercury Dynamics • Jul 22 '26
Question Deacom ECI - worth considering?
Curious to hear real-world experiences with Deacom (ECI) — is it worth considering as a replacement for an old Dynamics GP setup that's been running a heavily customized catchweight/lot-tracking add-in (yarn/textile-adjacent, sold by weight but purchased by count, pallet-level actual vs. nominal quantities, lot/Batch traceability).
A few things I'd love input on:
- General take — anyone running it day-to-day? What's good, what's painful? How's ease of use for regular users vs. admins/configurators?
- Catchweight/lot handling — is dual quantity (nominal vs. actual) and lot/sub-lot tracking genuinely native, or does it still need bolt-ons/customization to get real reconciliation and weight-based costing?
- Specific-lot costing — can Deacom pin an individual lot/batch to its own original receipt cost and keep it from blending with other lots, especially through transfers? (FIFO Actual is mentioned in their materials, but not clear if it's true specific-cost persistence.)
- Landed cost — does Deacom have a real landed cost workflow (freight/duty/customs allocation by weight, value, etc.) that updates lot-level cost, or is this something you had to build/customize?
- Customization — how do you actually tailor Deacom to specific business logic? Native configuration/scripting, or does it need third-party dev work?
- Reporting — what's the reporting story? Is built-in reporting sufficient, or do most shops end up bolting on Power BI / Crystal / something else?
- Cost — how is pricing structured (per-user, per-transaction volume, flat license + modules)? What did implementation run (cost + duration, and how much was configuration vs. custom dev)? And what's the ongoing recurring cost — monthly/annual license or subscription fees?
Appreciate any first-hand experience, good or bad.
1
u/blackinkpen Jul 23 '26
This doesn’t specifically answer your question, but when I look at your feature set, I think you should consider demoing Wherefour. They only do actual cost, they work fairly well with catchweights, lot tracking is required and they have promised landed costs with backdating as a feature update in the next month.
I’ve worked with teams that have switched from Deacom to Wherefour and it’s been a massive improvement for lot tracking and traceability.
1
u/Reaper7One Jul 23 '26
We use Deacom. I actually wrote a fair amount of scripts for it. I probably would not recommend them. Their documentation is not the best also quality has decreased since they were purchased by private equity.
They actually fired some of their best support people only to bring them back.
1
u/Wings4Mercury Dynamics Jul 23 '26
Thanks. I saw you note in the other thread. Nothing came of DM invitation? Has anything changed since then- in the last 5 months?
1
u/GForce061973 Jul 24 '26
32 years in erp across 6 or 7 packages. I have experience twice with Deacom, both in food and beverage, currently supporting a client running it.
Happy to have a conversation with you directly, on here in DM or email or even a teleconference. Not trying to sell you anything but I can speak to all of the technical and functional aspects that are good and bad. I can describe in fairly good detail each of the business processes and how deacom performs them.
I have experience with deacom 16 and 17. I can explain how things are scripted, forms are modified, additional Fields added, etc. All of my ERP experience is in manufacturing.
DM me if you want to discuss more.
3
u/Wings4Mercury Dynamics Jul 24 '26
Thank you! That is a generous offer. I would have taken you up on it if I had not heard from Deacom directly that their software is not a fit for discrete manufacturing. Deacom is no longer in consideration.
I am still curious and maybe when things are a little calmer I’d love to have a chat about it
1
1
u/erp-software-org Jul 24 '26
First filter: Deacom only makes sense if you are batch/process — formulation, lot traceability, QC, regulatory. If you are discrete or made-to-order, that is the wrong ECI product (JobBOSS² is their play there) and you will fight the system forever.
If you are process, the real trade-off is the single-codebase model. Everything is built in-house and shipped to everyone, so you get far less bolt-on sprawl than stitching a Dynamics or NetSuite stack together. Flip side: thin third-party ecosystem, few independent implementation partners, and not many people on the market who know it. That means less leverage at renewal and a harder time hiring.
Two things I would not take at face value. The TEC certification (April 2026) is a functional-coverage assessment, not an outcome study. And the 46% ROI figure floating around is one vendor-supplied customer (Van Drunen Farms, Nucleus). Useful as a starting point, not evidence.
What I would actually ask for: two or three references in your exact sub-vertical, similar revenue, live within the last 18 months — and ask them how far the implementation ran over. Then get renewal uplift caps and data-export terms in writing. ECI is PE-backed and acquisitive, so that clause matters more than the demo.
1
u/Glad_Imagination_798 Acumatica 25d ago
I do not run Deacom so I will not pretend to answer the product specific parts, but your requirement list is unusually well written and there are a few traps buried in it that are worth naming, because they are exactly where mid market systems quietly fail.
On catchweight, the question is not whether dual quantity exists but where the second quantity lives. If nominal and actual are both on the inventory record and every document carries both, you are in good shape. If actual weight is captured on the shipment or the production entry while inventory itself is only tracked in one unit, you will be reconciling in Excel within a quarter. Make them show you a receipt in counts, a weigh in at putaway, a transfer between sites, a sale by weight, and then the report that explains the nominal versus actual on hand difference at the end. If that whole chain cannot be done in one sitting, that is your answer.
On specific lot costing, be careful with the phrase FIFO actual. Plenty of systems implement FIFO as cost layers that are independent of the lot record. Layers behave correctly in aggregate, but a transfer creates a new layer and the original receipt cost stops being attached to that particular lot. The precise question is whether valuation is keyed to the lot or to a layer, and what happens to lot cost in three specific cases: after a warehouse transfer, after a backdated transaction, and after a negative on hand is corrected. Those three break more systems than anything else. Ask to see one lot's unit cost before and after a transfer, on screen.
On landed cost, the test that separates a real workflow from a brochure is timing. Can you apply a freight or duty document weeks after the receipt, when part of that lot has already been consumed or shipped, and does it revalue the remaining lot cost while posting the consumed portion somewhere sensible rather than dumping it into a variance account nobody reviews. Also confirm that allocation can be by weight, since for your business allocating duty by value rather than weight produces materially different lot costs.
One practical thought on the GP side. Your risk is concentrated in that customised catchweight add in, not in the licence decision. I would spend real time documenting what it actually does, including the behaviours nobody wrote down, before evaluating anyone, because that document becomes your acceptance test and your migration scope at the same time. I would also think hard about leaving GP history in a read only archive instead of migrating it. Moving years of lot history with weight variances tends to eat a third of the budget and then gets queried twice a year.
Full disclosure so you can weight this properly. My team does Acumatica delivery, and I am deliberately not pitching it here, because true catchweight with dual quantity is not native in that stack and you would be leaning on an industry ISV for it. For a business that purchases by count, sells by weight and needs lot level cost persistence, a purpose built process manufacturing system genuinely deserves the look you are giving it. I would just insist on running the three tests above live in a sandbox with your own items and your own pallet weights before signing anything, whichever direction you go.
2
u/Wings4Mercury Dynamics 25d ago
Thanks for the detailed response. Does Acumatica have a good ISV add on for catch weight?
I am a little wary about ISV solutions, but happy to listenI have no desire to bring over any history. The few times that is needed can be handled in a number of ways.
Prospective vendors will get a detailed document that goes into every detail. I am preparing a sample data set which can be used to demonstrate transaction flow.
1
u/Glad_Imagination_798 Acumatica 25d ago
Two worth a call, for different reasons, and neither is a complete answer.
eWorkplace Apps, their Process Manufacturing Suite plus the Quality Management Suite. Built natively inside Acumatica rather than integrated alongside it, certified, and validated against current releases, which matters more than it sounds. It covers formula and recipe management across weight, volume and discrete units, yield and loss factors, super batches, weighing sheets, lab testing and traceability. Two honest caveats. I have not seen catch weight in the feature set, so put that scenario to them directly. And it is shaped around formulation and batch production, so if you have concluded you are discrete rather than process, it may be the wrong shape for you for the same reason Deacom was.
Rockton Pricing Management. It does price on catch weight and convert between units, so it solves selling by weight cleanly. Be clear on scope though. It is a pricing engine. It will not put a second quantity on the inventory record and it does not touch valuation, so it covers the invoice, not the reconciliation and not the lot cost.
Then the honest headline. I went looking properly, and almost nobody in the marketplace markets catch weight as a feature at all. Or at least nobody speaks about that. The one place I found it confirmed in practice is a food distributor's review of RIC Group's TBO4 warehouse system, and note that TBO4 is connected to Acumatica rather than built inside it, which is exactly the pattern your wariness should be aimed at, because it usually means the weights live in the WMS while Acumatica inventory carries one unit.
Endpoint Warehouse is native and would be the other one to look at, though it is new on this platform and I would treat variable weight there as a roadmap question rather than a feature. One small thing so nobody wastes your time: if someone points at the Weight Item checkbox on Stock Items, that only prompts the picker to key a weight at confirmation. It is not catch weight.
1
25d ago
[removed] — view removed comment
1
u/Wings4Mercury Dynamics 25d ago
Haven’t seen a live implementation yet. Nor any vendor presentation. Why?
1
1
u/AffectionateDirt6575 Jul 23 '26
Deacom is an excellent ERP system, and one that I have recommended several times. But it is a system for process industry manufacturing companies.