Technology Services · Web Applications
Web application development: portals, dashboards and business apps.
Customer portals, vendor portals, dashboards and business web applications on modern stacks, with real business data behind them.
- 01It has a session with consequencesSomebody is logged in as a company, not just a person, and what they do creates documents in a real system.
- 02Being wrong is worse than being slowA page that takes an extra second is an irritation. A price that is out of date is a credit note.
- 03Most of the work is invisibleAuthorisation, resolution, validation and reconciliation. The interface is the small part on top.
- 04It is used every day by the same peopleWhich means it earns keyboard shortcuts, sensible defaults and remembered state, and forgives nothing that wastes a click.
Decision one
Who is allowed to see each number
Settled on paper before anything is built. Nearly every serious defect in a portal is an authorisation defect, and they are the expensive kind because the data has already left.
| Can they | Buyer | Buyer admin | Sales rep | Your finance team | TranzDigital support |
|---|---|---|---|---|---|
| See their own contract prices | Yes | Yes | Yes | Yes | ConditionalOnly while a ticket is open |
| See another account's prices | No | No | ConditionalAssigned accounts only | Yes | No |
| Place an order | ConditionalUp to their order limit | Yes | Yes | No | No |
| Release an order over the limit | No | Yes | No | Yes | No |
| See the account balance | No | Yes | ConditionalOn hold status only | Yes | No |
| Add or remove portal users | No | Yes | No | No | ConditionalOn written request |
| Change a price | No | No | No | No | No |
Decision two
How old is each number allowed to be?
Answered per figure, never once for the whole application. Get this wrong in one direction and the portal is slow; get it wrong in the other and it is confidently incorrect.
- 01
Read live, every time
Budget 0 seconds
Available stock on the order screen, the account balance, whether the account is on hold.
A wrong number here creates a promise you cannot keep. Worth the round trip to SAP Business One on every page view.
Slowest screens on the site, and they depend on SAP Business One being up. Both acceptable for these three.
- 02
Cached for seconds
Budget 5 to 60 seconds
Prices resolved for the logged-in account, credit limit, open order list.
These change during a session but not within it. A short cache removes most of the load without anybody noticing.
A price change takes up to a minute to appear. Fine, as long as the order confirms against live data.
- 03
Synced on change
Budget Minutes
The catalog, item descriptions, images, categories, the customer's own account details.
Pushed when SAP Business One changes them rather than polled. The portal serves its own copy, so a slow ERP does not make a slow website.
Requires the change to be detectable. Where it is not, this band drops to the next one.
- 04
Rebuilt nightly
Budget Hours
Search indexes, category trees, sitemaps, reporting extracts, anything aggregated.
Expensive to compute and nobody needs it to the minute. Overnight is the correct answer more often than people expect.
A new item is not searchable until tomorrow, unless it is also pushed into the index on creation.
One rule survives all four bands: whatever a screen displays, the order confirms against live data at the moment it is placed.
Scope
What we build
- 01
Customer and vendor portals
Self-service access to orders, invoices, statements, documents and status, backed by your ERP.
- 02
Business dashboards
Operational and financial views that replace the weekly Excel exercise.
- 03
Internal web tools
Browser-based tools for pricing, catalog management, approvals and exceptions.
- 04
Company websites with live data
Websites that show real catalogs, availability and pricing from SAP Business One instead of static pages.
- 05
eCommerce storefronts
Online stores connected to inventory, pricing and order processing.
- 06
Hosting and maintenance
Web hosting, domains, databases and ongoing maintenance for the applications we build.
Stack
What we actually build on
Chosen to fit the environment you already run rather than the one we would prefer. This list is what we use in delivery, not a list of things we have heard of.
SAP Business One
SDK, DI API, Service Layer
SAP HANA
Database and analytics
Microsoft SQL Server
Database, queries, reporting
MySQL
Web application databases
.NET and ASP.NET
Services, middleware, back-office apps
REST and Web APIs
Integration and application interfaces
React and Next.js
Web applications and portals
HTML, CSS and JavaScript
Web front ends
Crystal Reports
Operational and financial reporting
What it connects to
The rest of the system
- CoreSAP Business OneThe system of record everything else reads from and writes to.Overview
- Layer 01B2B eCommerceCustomers who order themselvesA portal with their pricing, live stock and account history. Orders arrive as SAP Business One sales documents.See it
- Layer 02Sales Rep AppCustomers who need a visitReps carry pricing and stock on the route, work with no signal, and sync orders when they reconnect.See it
- Layer 03Inventory CountingMaking the stock figure trueBarcode counts and cycle counts, with variances reviewed before anything posts to the ledger.See it
- Layer 04Price Label PrintingThe shelf edgeLabels generated from the same item and price data, so what is on the shelf matches the invoice.See it
Questions
About web applications
Next step
Describe the problem. We will tell you what it takes to solve it.
Send a few lines about the process or system you are dealing with. We come back with questions, options and a realistic sense of effort.