Back to blog

Insights

Made2Manage Web API vs SQL: When SSRS and Excel Exports Stop Being Enough

When to use the Made2Manage Web API, read-only SQL Server views, or SSRS for reporting and apps, and when Excel beside the ERP becomes the problem.

David CaldwellOctober 26, 20264 min read
LinkedInPost

Short answer: Use the Made2Manage Web API when something needs to write a transaction or read one in real time, like a tablet at a machine or an EDI order becoming a sales order. Use read-only SQL Server views for heavy reporting such as backlog, throughput, or margin by job. Keep SSRS for printed documents and scheduled distribution. The problem is not any one of these tools; it is when small questions wait in a report queue and the real work moves into spreadsheets beside the ERP.

The report works, until you need something slightly different#

Most Made2Manage shops have SSRS reports that do their job. The trouble starts when someone needs a slightly different cut: the same backlog by work center, or the same job cost with this week's material receipts. That turns into a report project, and report projects get scheduled behind everything else. Small questions get a big queue, and after a while people stop asking. It is the first problem on our Made2Manage page.

What SSRS and Excel are still good for#

Made2Manage moved to SQL Server Reporting Services from version 7.5, and SSRS is genuinely good at printed documents and scheduled distribution: pick lists, packing slips, the weekly report that goes to the same five people. There is no reason to rip those out.

Excel is fine for one-off analysis. It becomes a problem when the file turns into the system of work. Scheduling, quoting, and capacity planning, the parts that decide whether a job makes money, end up in files beside the ERP and then get keyed back in. One job now lives in several systems and nobody has a single view.

The Web API: real-time reads and writes#

Made2Manage runs on .NET and SQL Server and ships a Web API. That API is the right route when something needs to post a transaction or read current state the moment it changes.

  • Shop floor apps. An operator reports production from a tablet at the machine. It posts through the Web API, so the transaction lands in Made2Manage the way it should and the schedule reflects it right away, without adding another seat in the client.
  • Integrations. An EDI order becomes a Made2Manage sales order through the Web API, and the shipment and ASN post back. Nobody keys anything twice.
  • Automations. Vendor confirmations arriving as PDFs get read, matched to the PO, and posted. Anything that does not match cleanly goes to a person with the reason attached.

Writes go through the application, so Made2Manage's own rules and audit trail still run.

SQL Server views: heavy reporting off the transaction path#

For dashboards, read-only SQL Server views are the better route. Backlog, throughput, on-time delivery, and margin by job are read-heavy questions that do not need to post anything. Reading them from views and publishing one shared dashboard means everyone sees the same numbers on a wall screen or a phone, and nobody waits on a report request to find out how the week is going.

We keep that reporting load off the live transaction database. The shop should not slow down because someone opened a dashboard.

Which one should you use?#

  • Creating or changing a record: Web API.
  • Current status for one order or job, inside an app: Web API.
  • Trends, totals, or a dashboard across many jobs: read-only SQL Server views.
  • A printed document or scheduled report that already works: keep SSRS.
  • An older version without the Web API available: SQL reads plus scheduled exchange still cover most of what people want first, which is seeing their own numbers without asking anyone.

What we will not do#

  • We do not write directly into Made2Manage tables. Writes go through the Web API so application rules and the audit trail still run.
  • We do not put reporting load on your live transaction database.
  • We do not rip out SSRS. We replace the reports people gave up on and leave the ones that work.
  • We do not hold your data. Everything is deployed to your infrastructure and your accounts.

A practical next step#

Make two short lists: the reports people stopped requesting because the turnaround was too slow, and the spreadsheets that decide whether a job makes money. Those lists usually show where a Web API app or a SQL-backed dashboard pays off first, and Made2Manage stays your system of record the whole time.

If you want a second set of eyes on those lists, book a 30-minute fit call and bring both. You can also read how we work with Made2Manage integrations, apps, and dashboards.

Want help implementing this in your business?

A 30-minute call. We'll tell you exactly what's possible.

Let's talk

Ready to build this in your business?

We'll look at your workflow and tell you exactly what's possible. No commitment.

Get in touch
LinkedInPost