A build-to-order SAP Business One add-on that converts A/R Invoices into UBL 2.1 documents,
submits them to MyInvois for validation, and writes the returned UUID and QR back onto the B1 document before it reaches the buyer.
Built to order
A build-to-order SAP Business One add-on that converts A/R Invoices into UBL 2.1 documents, submits them to MyInvois for validation, and writes the returned UUID and QR back onto the B1 document before it reaches the buyer. Built to order by ECOSIRE for SAP Business One (build-to-order) — indicative price from $1499.00 USD; request a quote for a scoped proposal.
Under the Malaysian e-invoicing model, an invoice is not finished when you post it. It has to be rendered as a UBL 2.1 XML document, submitted to MyInvois, validated, and returned with a UUID and a QR code — and only that validated version is the one your buyer is entitled to receive. There is also a rejection window during which the buyer can push back, and a cancellation window during which you can withdraw. Miss the sequencing and you have handed over a document that does not officially exist.
SAP Business One has none of this. OINV and INV1 hold the commercial content — Business Partner, TIN, line items, quantities, unit prices, tax codes, totals — but B1 produces no UBL, has no MyInvois client, and has nowhere to put a returned UUID or QR. Nor does it distinguish a submitted invoice from a validated one, which is the distinction that actually matters.
The manual workaround is portal entry, which caps out quickly. And because the mandate is phased, an organisation that is comfortably outside it this year is inside it next year, usually along with its subsidiaries — so the workaround has an expiry date.
We build a SAP Business One add-on that makes MyInvois validation part of the invoice lifecycle instead of a parallel manual process.
The add-on maps posted A/R Invoices, A/R Credit Memos and A/R Down Payment Invoices into UBL 2.1 Invoice, CreditNote and related document types. Supplier and buyer parties are built from the Business Partner master (OCRD) and your company details — TIN, registration identifiers, MSIC classification, and the address structure MyInvois expects. Lines come from INV1: item classification code, description, quantity, unit of measure, unit price, discount, tax type and rate, and the tax subtotals that must reconcile to the document total. Currency and exchange-rate handling follows the rate held on the B1 document, so a foreign-currency invoice carries both the transaction currency and the ringgit equivalent.
Submission runs through the Service Layer (REST) for read and write-back and through a dedicated MyInvois client for the API calls themselves. Documents are batched to the submission endpoint, and the returned submission identifier is retained. Because validation is asynchronous, a poller re-checks each submission until every document within it resolves to valid or invalid, then writes the outcome back.
What lands on the B1 side: UDFs on the invoice holding the MyInvois UUID, the validation status, the validation timestamp, and the QR payload; and a User-Defined Table holding the full submission history, including the exact UBL sent and the validation errors returned. That history is what you use when a document is disputed or an auditor asks what was actually transmitted.
The add-on tracks the buyer-rejection window and the supplier-cancellation window against each validated document, so the finance team can see which invoices are still inside a window and which have passed out of one. Cancellation is exposed as an explicit action with a mandatory reason, written to the submission history, and reflected in the document's status UDF. Post-window corrections are steered toward a credit note rather than a cancellation, because that is the only route left once the window closes.
A pre-flight validator runs the document against the structural rules before anything is sent: buyer TIN present and well-formed, classification codes assigned on every line, tax subtotals reconciling to the header, mandatory party fields populated, currency and rate consistent. Failures are reported against the specific line or field, on screen, at the moment of posting or submission — not as an opaque rejection an hour later.
MyInvois requires classification on every line. We add UDFs on the Item Master (OITM) for the classification code and a User-Defined Table holding the catalogue, with a bulk-maintenance path so the whole item master can be classified without touching items one at a time. Item groups can carry a default that individual items override.
Only the validated document goes out. We build a Crystal Report layout bound to the A/R Invoice that renders the QR and the MyInvois UUID, and gate the send action so it is unavailable until the document has come back valid. Where you want automated distribution, the send is driven off validation status rather than posting status.
A UDO-based cockpit gives finance a single worklist: awaiting submission, awaiting validation, invalid with reasons, valid, cancelled. It includes a retry action, a cancellation action with reason capture, and a reconciliation view comparing posted A/R documents in a period against validated MyInvois documents.
Companies running SAP Business One in Malaysia that are inside the mandate now or expect to be in the next phase. It suits businesses with enough invoice volume that portal entry is already painful, groups with several Malaysian entities on one B1 landscape, and organisations issuing foreign-currency invoices or a meaningful volume of credit notes — the cases where the sequencing rules bite hardest.
Built for SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted, using the Service Layer, the DI API, and UDF/UDT/UDO extensibility. Delivered per tenant and installed into your own company databases.
1. Scoping call. We review your B1 version and platform, the entities and document types in scope, your tax code setup, currency handling, item classification state, and how you currently deliver invoices to buyers. We agree the first release scope explicitly.
2. Fixed quote. A written scope and a fixed price, issued before development starts.
3. Build. We develop against your configuration — your tax codes, your item master, your entities. Typical lead time is one working week depending on scope. This app is built for you on order; it is not an existing product waiting to be downloaded.
4. Install in test, then production. Installed first into your test company database and exercised against the MyInvois sandbox with your own documents. Production installation follows your sign-off.
5. Support. A support window from go-live covering defects, configuration questions, and classification-catalogue maintenance as your item master changes.
A short call to confirm the workflow, your platform version and where the integration boundaries sit.
You receive a written scope and a fixed price. Nothing is built until you approve it.
We develop against a copy of your configuration and test it there. Typically two to four weeks.
We install on your instance, hand over the source, and include two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Needs certainty that what the buyer received is the validated document and not a pre-submission draft, and that credit notes and cancellations followed the right route. Gets validation status on the invoice itself, a send action that cannot fire before validation, and window tracking that shows what can still be cancelled.
Would otherwise re-key invoices into the portal and manually chase which ones came back valid. Works from a single worklist showing exactly what is awaiting submission, awaiting validation, or invalid with the specific reason and a retry action.
Runs SAP Business One across several Malaysian entities and cannot have a localisation that only works for one company database or breaks on upgrade. Gets a Service Layer and DI API add-on using UDF, UDT and UDO extensibility, installed per tenant and documented for internal handover.
| Criterion | ECOSIRE | Custom Build | Competitor | SAP Business One Native |
|---|---|---|---|---|
| Generates UBL 2.1 documents from posted SAP Business One A/R documents | Included | Partial support | Included | Not included |
| Asynchronous validation polling until every document in a batch resolves | Included | Partial support | Included | Not included |
| Buyer-rejection and cancellation window tracking with reason capture | Included | Not included | Partial support | Not included |
| Send action gated so only validated documents reach the buyer | Included | Not included | Partial support | Not included |
| Pre-flight validation reporting the specific failing line or field | Included | Not included | Partial support | Not included |
| Line classification catalogue with item-group defaults and bulk maintenance | Included | Partial support | Partial support | Not included |
| Retains the exact UBL transmitted for dispute and audit | Included | Partial support | Partial support | Not included |
| Built against your live tax codes, currencies and entity structure | Included | Included | Not included | Not included |
A build-to-order SAP Business One add-on that submits A/R Invoices and credit notes to Jordan's JoFotara platform and returns the QR-stamped rendition to your customer. Built for your company after a fixed quote.
A build-to-order SAP Business One add-on for ZATCA Phase 2: compliant UBL 2.1 XML, cryptographic stamping, hash chaining, QR codes and FATOORA clearance or reporting from your own invoices.
A build-to-order SAP Business One add-on that stamps CFDI 4.0 through your authorised PAC, issues complementos de pago, and handles the SAT cancellation workflow end to end.
Puts SAP Business One customer context, email filing and approval actions inside Outlook and Microsoft Teams. Built to order for your company database and your Microsoft 365 tenant.