Vendor and Supplier Collaboration Portal

The problem this solves

Procurement admin in SAP Business One is mostly transcription. A Purchase Order is raised and e-mailed as a PDF. The supplier replies — sometimes — with a confirmation that changes two dates and one quantity, buried in the body of an e-mail. A buyer re-keys that into the Purchase Order, or forgets to. The goods arrive with a packing list that nobody had advance sight of, so the warehouse counts blind. Then an invoice arrives as a PDF attachment, gets printed, gets stamped, gets keyed into an A/P Invoice, and fails three-way matching because the price on the invoice was never the price on the confirmed order.

Every one of those steps is a supplier telling you something you then type in yourself. Meanwhile the supplier is chasing your accounts payable team by phone to ask whether invoice 4471 has been paid, because they have no way to look.

What ECOSIRE builds

We build a supplier-facing web portal, delivered per tenant, backed by your SAP Business One company database. Suppliers log in and do the data entry themselves, against the real documents, with validation applied before anything is created in SAP Business One.

Purchase Order confirmation

A supplier sees their open Purchase Orders (OPOR/POR1) with line-level item code, description, quantity, price, required date and warehouse. They can confirm as-is, or propose changes: a revised delivery date, a partial quantity with a split date, a substitute item, or a price variance. Proposed changes do not overwrite your document. They land as a change request that a buyer accepts or rejects; on acceptance the Purchase Order lines are updated through the Service Layer, and if the variance crosses a tolerance you define, your existing SAP Business One approval procedure is triggered before the update commits.

Confirmation status, confirmed date and confirmed quantity are stored in UDFs on the Purchase Order and its lines, so buyers can filter unconfirmed orders and chase only those.

Advance shipment notices

The supplier posts an ASN against one or more Purchase Order lines: quantities shipped, carrier, tracking reference, expected arrival, pallet or carton identifiers and batch or serial numbers where the item is managed that way. The ASN is stored as a UDO — a first-class SAP Business One object with its own authorisations, queries and Crystal Reports layout — so it is auditable rather than living in an external database.

When goods arrive, the warehouse opens the ASN and it pre-populates a Goods Receipt PO (OPDN) with the shipped quantities, batches and serials already filled in. Receiving becomes a confirmation instead of a transcription. Discrepancies between ASN and actual count are recorded against the ASN so supplier performance is measurable from your own data.

Supplier invoice submission

Suppliers submit an invoice by referencing a Purchase Order or a Goods Receipt PO, entering their invoice number, date, currency, tax and line amounts, and attaching the PDF. The portal validates before submission: does the referenced document exist, is it still open, does the quantity exceed what was received, does the unit price match the confirmed order within your tolerance, is the tax code valid for that supplier's tax setup, is this a duplicate of an invoice number already submitted by that supplier.

A clean submission creates a draft A/P Invoice (OPCH) with the supplier's PDF attached, ready for the accounts payable clerk to review and post. That is a genuine three-way match: confirmed order, received quantity, submitted invoice — all keyed once, by the party that knows the number. Submissions that fail validation are rejected back to the supplier with the specific reason, before they ever become your problem.

Self-service payment status

Suppliers see their own document history: Purchase Orders, Goods Receipt POs, submitted invoices, posted A/P Invoices, Outgoing Payments (OVPM) and open balance with due dates. That is where the phone calls to accounts payable go.

How it is built technically

The portal is a web application; all reads and writes into SAP Business One go through the Service Layer (REST/OData), with the DI API used for the specific objects and behaviours that require it. No supplier is ever given SAP Business One access or a licensed user — the portal authenticates as a single integration user and enforces its own supplier-scoped authorisation on every request, so a supplier can only ever see documents where they are the Business Partner.

Extensibility follows SAP Business One conventions: UDFs on Purchase Order header and lines for confirmation state, UDTs for portal user accounts, tolerance rules and rejection reason codes, and UDOs for ASNs, change requests and invoice submissions. Attachments are stored through the SAP Business One attachment mechanism so they are reachable from the document. Crystal Reports layouts are supplied for supplier confirmation status, ASN accuracy and invoice submission ageing. Where a change or an invoice needs sign-off, your existing approval procedures do the work.

Who this is for

SAP Business One companies with a real supplier base doing repeat business: distributors, manufacturers buying components against production plans, retailers with inbound logistics, and any business where the accounts payable team spends more time keying invoices than reviewing them. It pays back fastest where you have dozens of suppliers sending hundreds of documents a month.

It is less useful if you buy almost everything ad hoc from long-tail suppliers who will never log into a portal, or if you have no Purchase Order discipline yet — the portal enforces process; it cannot invent one.

How delivery works

1. Scoping call. We map your actual procurement flow: do you confirm orders today, do you use batches or serials, which warehouses receive, what price and quantity tolerances are acceptable, how your tax codes are structured, whether you are on SQL Server or SAP HANA, and which approval procedures already exist.

2. Fixed quote. A written scope covering each portal function, the validation rules, the supplier authorisation model, branding, timeline and a fixed price.

3. Build. Typical lead time is two to four weeks depending on how many of the four functions you take and how complex your validation tolerances are.

4. Install into your test company. Portal and add-on installed against a copy of your production company database. We onboard one or two real suppliers into the test environment and run genuine confirmations, ASNs and invoices through it. You verify the resulting Goods Receipt POs and draft A/P Invoices yourself.

5. Production install and supplier onboarding. Scheduled cutover with documented rollback. We supply the supplier onboarding pack and help you bring the first group of suppliers live in waves rather than all at once.

6. Support window. A defect-fix window after go-live, with the length stated in your quote. Tolerance and reason-code changes are UDT edits your own team can make afterwards.

Everything is delivered per tenant, for your company database, with source code and documentation handed over.