Peppol Ap Admin Applet

The console for operating BigLedger’s own Peppol Access Point — AP here means Access Point, not Accounts Payable: the inbox every inbound network message lands in, the history of what was delivered, the receiver mappings that decide which customer a document is handed to, and the PINT Malaysia testbed. It creates no accounting entries and moves no stock. A document in Inbox History that the customer never received usually means no receiver mapping matched — the message is recorded and delivered to nobody, with no error — and a mapping exists only for a Peppol ID that has been added to a company on the Organisation applet’s Peppol Config tab.

Your job, and the screen for it

Overview

The Peppol AP Admin Applet is the console for operating BigLedger’s own Peppol Access Point, not for a customer’s own Peppol traffic. Where the My Peppol Admin Applet is a tenant looking at its own outgoing and incoming documents, this applet is the access point looking at everything the network delivers to it — the inbox queue that every inbound AS4 message lands in, the history of what was delivered, the tenant-company receiver mappings that decide which customer a document is handed to, and the PINT Malaysia testbed used to prove conformance to OpenPeppol and MDEC.

It is an operations and accreditation tool. It creates no accounting entries, moves no stock, and has no document of its own that can be finalised or voided.

Where it fits

Screens and menus

The Registered Companies grid starts empty: its tenant code defaults to peppolap — the access point’s own tenant, which normally has no mappings of its own — and only fills in once a tenant is chosen from the dropdown.

Two things in the navigation do not do what their labels suggest. The Testbed parent entry only opens and closes its group — Sending Test and Validation Test beneath it are the screens. And the Personalization menu lists a Field Settings item that leads to the applet’s 404 page.

Inside the Inbox Queue listing there is an advanced-search box that does nothing; typing in it has no effect.

Screenshots needed

Screenshots for this applet are still to be captured. A capture session should take: the Inbox Queue listing with rows; the Inbox Queue Details read-only tab; the Registered Companies listing; the Validation Test listing; Validation Test → upload ZIP; the Checking grid showing VALID and INVALID rows with an error message; and the Sending Test input form with the Test Name dropdown open. Because every row on these screens is a real trading party’s identifier, captures must come from a scratch tenant or be redacted before publishing.

Configuration

Before you can use it

Applet settings

There are no working applet settings; both settings screens are inert:

• Settings → Field Settings shows eight slide toggles — Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project — that are not saved, and a SAVE button that does nothing. These are the labels of a sales-document settings screen and have nothing to do with Peppol.
• Settings → Default Selection and Personalization → Default Selection offer a Default Branch and a Default Location dropdown. Changing either raises an error and SAVE saves nothing — and nothing in the applet would use either value if it did.

Settings in other applets that control this applet

Feature visibility / permissions

The applet has no client-side permissions and no HIDE_* / SHOW_* keys, so the Feature Visibility screen has nothing to gate. Access is decided entirely server-side:

A role with none of these opens the applet and sees empty grids rather than an authorisation error.

Fields

Inbox Queue / Inbox History → Details — every control is read-only; this is a viewer, not a form. Several labels promise the Peppol envelope and deliver something else, and the gap matters when you are matching a message against the sender’s records. For a message received from the network:

Registered Companies → Details — also entirely read-only: Tenant Code, Tenant Comp Peppol ID, Company Name, Company Code, Created Date, Updated Date.

Validation Test → Create — Validation Test Code, Name and Description, none of them checked; a code is not required to be unique.

Sending Test → Create

Checking grid (Validation Test → open a test → open an uploaded ZIP): No., File Name, File Size, File Format, Validation Status, Validation Error, Error Message, User Error Message, Created Date, Updated Date — one row per XML file found in the ZIP.

Lifecycle and effects

This is a master-data and operations applet. It has no document of its own, no journal and no stock movement; nothing here is finalised or voided.

Receiving — what happens to an inbound document

1. An AS4 message arrives. The access point reads its Standard Business Document envelope, writes one Inbox Queue row and starts the routing job at once.
2. The routing job copies the row into Inbox History — the permanent access-point record.
3. It then looks up Registered Companies by the message’s receiver Peppol ID. For every mapping found it hands the document to that tenant, where it appears under External Reception.
4. Finally it permanently deletes the Inbox Queue row.

Two consequences follow directly, and they are the two facts an operator needs. Inbox Queue is transient — under normal operation it is empty, because rows are removed as soon as they are routed; a row sitting in it means the routing job has not run. And a receiver ID with no mapping is not an error — the job simply finds nobody to deliver to, the Inbox History row is written, and the message is silently not delivered to any tenant.

How a mapping appears, changes and goes

A receiver mapping is written when a company’s Peppol ID is saved on the Organisation applet’s Peppol Config tab. The backend copies the tenant, the company and the ID into the access point’s own database at that moment. Editing the ID rewrites that row, and deleting the ID deletes it. This applet only reads the table.

The participant registration on the same tab does not write a mapping. That is the SMP step, with the KYC PDF. So the two can disagree. An ID can be routable here and still unknown to the network, so nothing is sent to it. Or a registration can stay on the network after its company ID was deleted, so documents arrive and land in Inbox History with nobody to deliver to.

A tenant cannot see this table, so the check that a new ID is routable belongs to BigLedger. After a customer adds an ID, an operator picks that tenant in Registered Companies and confirms one row for the ID, against the right company. A missing row means the ID was never saved in Organisation. Two rows for one ID mean two companies hold it, and both will receive every document sent to it.

Validation Test — what “Run Checking” actually checks

Run Checking checks every file extracted from the ZIP. For each file:

• the document type is inferred from the file name — a name containing invoice selects the invoice rules, a name containing creditnote the credit-note rules, anything else yields an empty type;
• the XML is validated against the PINT UBL schematron for that type;
• it is validated a second time against the Malaysian jurisdiction rules, and every failed assertion is collected;
• one assertion is deliberately dropped before the verdict — [ibr-119]-A time MUST be formatted hh:mm:ss with optional fractional seconds .sss and time zone expression (ibt-168).;
• if nothing remains, the file is marked VALID; otherwise INVALID with the collected texts. The row’s Updated Date is stamped either way.

Revalidate on a single file checks that file again and returns either the failure texts or the single token THIS_DOCUMENTS_IS_VALID.

Uploading a ZIP attaches it to the open validation test. The success toast reads “Upload Image Successful” — a label inherited from the applet this screen was cloned from. The delete and download buttons on the uploaded-file screen do nothing.

Sending — Send Only Valid XML and the per-file Send do not work today; see Troubleshooting.

Related applets

• My Peppol Admin Applet — the tenant-side counterpart. Documents routed from here surface there under External Reception. Its Registration screen saves nothing and writes no mapping.
• My E-Invoice Admin Applet — the parallel LHDN pipeline; it shares the mandatory-field check but not this applet’s data.
• Organisation Applet — holds the company Peppol status and participant IDs. Adding, editing or deleting an ID there writes, rewrites or deletes the receiver mapping listed here. The SMP registration is made there too.

Troubleshooting

Related documentation

• PEPPOL Configuration Guide
• E-Invoice module