Apex Development on REDA

Custom Apex around REDA Financials follows one golden rule: build against the global surface and the objects, never against internals. Here's the stable toolkit and the patterns that use it well.

The global surface — thirteen classes and interfaces

In a managed package, only global Apex is visible to your code; everything public lives behind the namespace wall. REDA Financials keeps that supported surface deliberately small — thirteen global types for customer and partner code. Five carry the day-to-day entry points; the rest are the e-invoicing extension contracts and the data types they exchange:

The abstract provider contracts are covered in Extension Packages; this article focuses on the two classes you call. All of the API classes ship at API version 65.0, and the standard managed-package promise applies: once released, global signatures cannot be removed or changed out from under you — they are the stable contract.

What you cannot call

The internal service layer that does the real work — posting, bank-statement import, PDF rendering, AI and FX callouts, bulk status updates, tax seeding — is public, not global. Subscriber Apex cannot call these classes at all: the compiler simply doesn't see them across the namespace boundary, and their internal shape can change in any release. If a capability you need lives only behind a public class, the supported route is the behavior it powers — posting via the status field, PDF generation via refin.PDFGeneratorAPI, tax seeding via the packaged Tax Setup Wizard — not the class itself.

refin.GlobalTaxService — tax math as a service

Two static methods give your code the same engines the documents use, with no side effects:

• calculateTax(TaxRequest) — indirect tax (VAT/GST/sales tax). Feed it entity, account, date, side ('Sales'/'Purchase') and lines (amount + product or explicit tax profile, with your own lineKey for correlation); get back per-line tax rows fully resolved — rate, amount, recoverable flag, and the GL account each tax would post to.
• calculateWithholdingTax(WHTRequest) — the WHT engine, same shape: lines in, per-line withholding out (rate, base, amount, exempt reasons, GL).
• The contract: no DML, no records created, never throws — errors return as success=false with a message. Persistence is entirely yours: perfect for quotes, calculators, pre-posting estimates, or external-system parity checks.

The full reference

Both entry points are static:

global static TaxResponse calculateTax(TaxRequest request)
global static WHTResponse calculateWithholdingTax(WHTRequest request)

The class doc states the contract plainly: "No DML is performed. No Source_Line_Tax or WHT_Transaction records are created. The caller owns persistence and posting." A response is "always returned, never throws to caller" — validation problems (missing entity, account, date, side or lines, or an invalid side value) come back as success=false with the reason in errorMessage, in the same validation language the documents themselves use. A GlobalTaxServiceException class exists in the global surface, but under the normal contract you read the response rather than catch.

The request and response DTOs are global classes with global members — everything below is yours to set or read:

The withholding set mirrors it:

How the GL accounts resolve. Indirect tax GLs come from the Tax Type GL Mapping records (refin__Tax_Type_GL_Mapping__c): an entity-specific mapping wins over an org-wide one, keyed by tax type and recoverability for the request's side; embedded taxes additionally receive a deduction GL from the 'Sales Deduction' / 'Purchase Deduction' side of the mapping. Withholding GLs come from the GL Account on the matched Withholding Tax Rate, falling back to the entity's Default WHT Payable account. In other words, the response tells you not just how much but where it would land — the same resolution posting performs.

A minimal call, Meridian-style — the US entity pricing a tenant's rent line before any invoice exists:

refin.GlobalTaxService.TaxRequest req = new refin.GlobalTaxService.TaxRequest();
req.entityId = meridianUsEntityId;
req.accountId = brightlineAccountId;
req.transactionDate = Date.today();
req.side = 'Sales';

refin.GlobalTaxService.TaxLineRequest line = new refin.GlobalTaxService.TaxLineRequest();
line.lineKey = 'unit-4b-rent';
line.amount = 9000;
line.productId = officeRentProductId;
req.lines = new List<refin.GlobalTaxService.TaxLineRequest>{ line };

refin.GlobalTaxService.TaxResponse res = refin.GlobalTaxService.calculateTax(req);
if (res.success) {
    for (refin.GlobalTaxService.TaxResultLine t : res.lines) {
        System.debug(t.lineKey + ' -> rate ' + t.taxRate + ', tax ' + t.taxAmount
            + ', GL ' + t.glAccountId);
    }
} else {
    System.debug(res.errorMessage);
}

The withholding twin follows the same rhythm. Meridian's India entity, estimating TDS on a contractor invoice before it's entered: build a WHTRequest with side = 'Purchase', one WHTLineRequest per invoice line carrying lineSubtotal, call calculateWithholdingTax, and read each WHTResultLine — rate, base, amount, and isExempt with its exemptReason when a certificate or threshold spares the line. Because nothing is persisted, the AP team can quote the net payable to the vendor and the numbers will match the posted document to the paisa.

refin.PDFGeneratorAPI — documents from code

generateOne(sourceRecordId, sourceObjectApiName) renders and attaches the PDF for a posted Sales Invoice, Credit Memo, Cash Receipt, Cash Disbursement or Purchase Order — returning the content IDs and, where the territory enables public links, the URL. The Flow twin is covered in Flows Integration.

The signature:

global static PDFResult generateOne(Id sourceRecordId, String sourceObjectApiName)

In the class's own words, "Extension packages call this from Apex when they need programmatic PDF generation outside of Flow context." The sourceObjectApiName must be one of the supported source objects:

The output PDF is attached to the source record as a ContentVersion with a ContentDocumentLink — a normal Salesforce File you can query, share, or email. The result's publicUrl is populated only "if the Entity has Auto Public URL enabled; null otherwise" — so code that emails links to customers should check for null rather than assume a URL exists. And you may not need code at all: each entity carries per-document auto-generation toggles (refin__Auto_Gen_PDF_Sales_Invoice__c, refin__Auto_Gen_PDF_Cash_Receipt__c, refin__Auto_Gen_PDF_Cash_Disbursement__c, refin__Auto_Gen_PDF_Purchase_Order__c, refin__Auto_Gen_PDF_Credit_Memo__c) — generateOne is for the moments outside those, like regenerating on demand or attaching to a custom send.

Posting from Apex — the status field is the API

There is no post() method to call, by design: the posting engine runs in the trigger phase of the source object's own update. Your Apex posts a document the same way a user does — flip refin__Status__c from 'Draft' to 'Posted' with a DML update, and the full machinery runs: tax and WHT engines, exchange-rate stamping on the transition to Posted, and every guard (approval gate, period validation, inactive entity/GL blocks). A refused posting surfaces as a DML exception carrying the guard's exact message — treat it as the API contract, not noise.

The reliable creation pattern is two steps: insert as Draft (header and lines), then update the status to 'Posted' in a second call. On insert, a null status defaults to 'Draft', document numbers auto-assign from the entity's document sequence (pre-setting the Name means manual numbering, and uniqueness is validated), and entity defaults auto-fill — ledger, accounting period, and due date from the vendor's payment term. Note that changing the entity or invoice type on a Draft re-sequences its number, so do your edits before you post.

Reacting to accounting events

Your triggers and record-triggered Flows on refin__ objects coexist happily with the package's own (order between packages and org automation follows standard platform rules — keep yours idempotent). The high-value pattern: react to status transitions — a trigger on Sales Invoice noticing Draft→Posted can feed your downstream system with the document already fully validated and numbered. React after the package's work: read the record's final state rather than trying to interpose.

The rules that keep you upgrade-safe

Common mistakes to avoid

Where to go next

1. Extension Packages — the provider contracts for ISVs.
2. Lightning Web Components — the UI counterpart.
3. API Overview — the map.

Frequently asked questions