Seller Applet

The seller’s side of the marketplace: a login linked to a merchant entity picks that seller and works on its marketplace products, its per-store stock balances and the seller orders allocated to it from the tenant’s sales orders, alongside the purchase invoices and payment vouchers that settle with it. A seller order is a marketplace record — no journal, no stock movement, no open balance — and nothing links it to a purchase invoice. Seller orders appear only when scheduled runs find exactly one seller for a sales-order line, and the Save, Final and Delete buttons on a seller order do nothing in this build, so treat that listing as read-only.

Overview

The Seller Applet is the seller-side workspace of BigLedger’s marketplace module. A tenant user who has been linked to one or more merchant entities picks a seller in the sidebar and then works on that seller’s marketplace product catalogue, the seller’s per-store stock balances, the seller orders that the tenant allocated to the seller out of its own sales orders, and the purchase invoices and payment vouchers the tenant uses to settle with the seller. The marketplace owner’s side of the same process (the queue of sales-order lines waiting for a seller) lives in a Seller Admin build that is not installable from the Applet Store, and the sales orders themselves come from the Internal Sales Order applet or a marketplace / storefront sync.

The applet is registered as “Seller Applet” (type TNT-ADMIN). It is a template clone of the generic document applets: several menus and buttons are present in the user interface but not wired up in the current build. Where that is the case this page says so.

Where it fits

Screens and menus

Sidebar:

Settings: Field Settings, Default Selection, Printable Format Settings; the shell adds Applet Access, Role Pricing Scheme Linking, the server-side permission screens, Triggers and the developer tools. Personalization: Default Selection, Sidebar.

Configuration

Before you can use it

Applet settings

Where settings live in the current build:

• Settings › Field Settings is an applet-local screen, not the shared one. Its eight slide toggles (Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project) are not bound to anything and SAVE does nothing — it saves nothing.
• Settings › Default Selection and Personalization › Default Selection are not wired to a settings container: changing Branch or Location throws an error and SAVE saves nothing. They cannot persist DEFAULT_BRANCH / DEFAULT_LOCATION.
• Settings › Printable Format Settings is the only screen that writes this applet’s settings: ticking Default Selection on a format stores it as PRINTABLE. The listing offers only formats of the payment-voucher type.
• Master settings are tenant-wide; a user’s personal Default Selection (where it can be saved) overrides the master DEFAULT_BRANCH / DEFAULT_LOCATION.

Settings are tenant-wide and can be changed by anyone who can open Settings (no permission check on the settings screens).

Keys read at runtime without a control in this applet. These are declared and consumed, but no screen here can set them; they take effect only if support writes them into the applet’s settings:

• DEFAULT_BRANCH, DEFAULT_LOCATION — seed the branch/location of a new purchase invoice, payment voucher and the Seller Order › Main Details form.
• HIDE_COSTING_DETAILS — hides the Costing Details tab of PI / PV line items.
• HIDE_PERMIT_NO, HIDE_TRACKING_ID — PI Main Details.
• The 21 line-field keys of the PI and PV line-item forms (HIDE_UNIT_PRICE_STD_PRICING_SCHEME, HIDE_UNIT_PRICE_STD_EXCL_TAX, HIDE_UNIT_PRICE_STD_INCL_TAX, HIDE_UNIT_DISCOUNT, HIDE_QTY_BASE, HIDE_QTY_UOM, HIDE_UOM_TO_BASE_RATIO, HIDE_UNIT_PRICE_STD_UOM_EXCL_TAX, HIDE_UNIT_PRICE_STD_UOM_INCL_TAX, HIDE_UNIT_DISCOUNT_UOM_EXCL_TAX, HIDE_UNIT_PRICE_NET_UOM_EXCL_TAX, HIDE_UNIT_PRICE_TXN_UOM_INCL_TAX, HIDE_UNIT_PRICE_NET_EXCL_TAX, HIDE_AMOUNT_STD_EXCL_TAX, HIDE_DISCOUNT_AMOUNT_EXCL_TAX, HIDE_AMOUNT_NET_EXCL_TAX, HIDE_TAX_CONFIG_SELECTION, HIDE_WHT_CONFIG_SELECTION, HIDE_UNIT_PRICE_TXN, HIDE_LAST_PURCHASE_PRICE, HIDE_AMOUNT_TXN); a hidden field reappears for a user who holds the matching SHOW_* permission.
• HIDE_SERVER_DOC_1..3, HIDE_CLIENT_DOC_TYPE, HIDE_CLIENT_DOC_1..5 — PV listing columns. The PV listing has one number column, Doc No (the tenant number): HIDE_SERVER_DOC_1 hides it from everybody, with no permission that brings it back, and HIDE_SERVER_DOC_2 / _3 change nothing there.
• ENABLE_CUSTOM_STATUS_LINE_1..5, NAME_CUSTOM_STATUS_LINE_1..5 — extra columns on the Seller Order listing.
• salesManLabels — the sales-agent label filter on the PI and Seller Order Main Details forms.
• HIDE_FINAL_BUTTON — declared but has no effect in this build.

Document behaviour settings

No exposed control. The purchase invoice and payment voucher behave exactly as in their own applets; the seller order has no posting behaviour (see Lifecycle).

Settings in other applets that control this applet

Feature visibility / permissions

The registry seeds no client-side permission codes for this applet, so none of the codes the screens check can be granted from the Applet Access screen:

• SHOW_INTERCOMPANY_PI_SCREEN — renders the PI › Create › Search tab (build a PI from a FINAL intercompany sales invoice).
• SHOW_FINAL_BUTTON, SHOW_DOCUMENT_DELETE_BUTTON — PI / PV edit buttons.
• SHOW_DOC_NO_TENANT, SHOW_DOC_NO_COMPANY, SHOW_DOC_NO_BRANCH, SHOW_CLIENT_DOC_TYPE, SHOW_CLIENT_DOC_1..5 — Seller Order › Main Details.
• The SHOW_* partner of every line-field HIDE_* key above.
• INTERNAL_PAYMENT_VOUCHER_DISPLAY_PRICING — PV line listing.

Server-side gates that do apply: the login must be linked to the seller for every product, image, label, attribute, stock-balance, seller-order event and seller-order print call; API_TNT_DM_MKP_SELLER_ORDER_{READ,CREATE,UPDATE,DELETE,OWNER,ADMIN,MEMBER}, API_TNT_DM_MKP_PRICING_SCHEME_LINK_* and API_TNT_DM_MKP_ENTITY_BRANCH_STOCK_BALANCE_* on the back-office screens; TNT_API_DOC_INTERNAL_PURCHASE_INVOICE_READ/CREATE/UPDATE_TGT_GUID on the PI screens.

Fields

Seller Account › Login Create / Login Edit

Product › Information and Dimension Details

Pressing + on the listing immediately creates a TEMP item whose code is a random GUID; the Create Product form that follows (Seller Code, Seller Name, Description, Status) fails on save and its values are discarded. Rename the TEMP item on the Edit panel.

Type is free text, stored as the item’s transaction type; Sub Item Type is one of 18 fixed options and the form insists on one; Status is TEMP, ACTIVE or INACTIVE. All three are saved as chosen. The rows below are the ones where the screen and the saved item part company.

There is no field for the financial item, pre-order, require-delivery or require-production flags — the product record can hold them but nothing in the applet exposes or writes them. Delete is a soft delete of the item, its lines, extensions and images.

Product › other tabs

Seller Order › Edit Seller Order

Tabs: Main Details (document numbers, branch, location, date, remarks, permit no, tracking id, client key/value), Account (entity, billing and shipping address), Line Item (a grid over generic-document lines with a Delivery toggle), Export, Event. All three tabs bind to a generic-document draft, not to the seller order itself; SAVE, FINAL and Delete do nothing. Export prints the seller order. Event lists seller-order events — the filter by order is switched off, so it shows every event in the tenant.

Branch

The Create form asks for Branch Code, Branch Name, Description and Status (ACTIVE / INACTIVE), and saves code, description and status into the tenant’s branch master — not a store of the seller. The name you type is not carried through, so the branch is created without one. The listing’s “Address” column shows the company instead. The Edit panel shows only audit fields and its save blanks code, description and status. Create and maintain branches in the Organisation applet.

Purchase Invoice and Payment Voucher

The forms are the standard generic-document forms; see the field tables on Internal Purchase Invoice and Internal Payment Voucher. Differences in this build:

• PI: Create works. On the Edit panel the FINAL, SAVE and DISCARD buttons do nothing; there is no batch FINAL / DISCARD on the listing. The listing is not filtered by the selected seller.
• PV: Create posts nothing. Edit › SAVE and FINAL (toast “Posting Successfully”) work; there is no VOID button. Payment lines come from the cashbook settlement methods; Contra links the voucher to any open document, including a PI.

Lifecycle and effects

Seller order

The seller order is a marketplace record, not a finance document. It has no journal, no stock movement and no open (outstanding) balance.

Posting summary: document type Seller Order · amount sign positive · quantity sign positive · Dr/Cr equation: none · GL precedence: none · stock processor: none · VOID: none — the only removal is a delete.

How a seller order comes to exist (three scheduled runs; none is scheduled for you out of the box — ask support whether they are scheduled on your tenant):

1. The sales-order queue run — every sales order (internal or storefront) that has not yet been queued is marked, and one allocation-queue entry is created per line.
2. The allocation run — for every queued line, the seller is found by following the sales-order line’s item → the marketplace item that represents it → its marketplace pricing-scheme link → the scheme’s owner. Only when exactly one seller matches does it create a provisional seller-order line (quantity = ordered − already allocated, purchase price = the seller’s price from the link) and close the queue entry. Items with several candidate sellers stay in the queue. The backend accepts a per-seller allocation through its API (permission API_TNT_DM_MKP_SELLER_ORDER_CREATE), but no screen sends one — the Seller Admin build’s Seller Account & Allocation tab is empty — so such a line waits until somebody allocates it through the API, or until the item’s links leave one eligible seller and the next run picks it up. In both paths the line amount is set to the quantity, not price × quantity.
3. The seller-order creation run (or the marketplace owner’s create order from provisional lines action) — each provisional line becomes one seller order with one line (seller, customer, the originating sales order, amounts carried from the provisional line), and the provisional line is marked finished. One provisional line = one seller order; nothing groups lines per seller.

Status: the record status is the generic ACTIVE / INACTIVE / DELETED. Order Status and Delivery Status are never written for seller orders by any part of the product — the fulfilment statuses in the listing stay empty. Seller-order events are audit rows (event code, date, user, device, description) that only create, edit and delete actions produce.

Marketplace item and stock balance

• Item: created TEMP, then ACTIVE / INACTIVE from the Edit panel; delete is a soft delete. Server checks: a linked inventory item must exist; the client key + source + value combination must be unique among non-deleted items; a company, cashbook or label named on the item must exist. The financial-item link is not validated.
• Stock balance: the quantity is whatever the seller typed. EcomSync’s seller-stock mode works out available = balance − open sales-order quantity per row and is meant to roll the totals up onto the EcomSync item, but the roll-up discards its result, so the EcomSync totals stay 0.

Purchase invoice and payment voucher

Posted by the generic-document engine exactly as documented on Internal Purchase Invoice (amount sign negative, quantity sign positive — stock in; Dr Purchase + Input Tax / Cr Creditor) and Internal Payment Voucher. Nothing links a PI or PV to a seller order — no part of the product creates a PI from a seller order.

Related applets

• Merchant Applet — creates the seller entity and the first login links this applet depends on.
• Marketplace-owner side — a Seller Admin build holds the sales-order line queue (SO Processing Queue) but cannot allocate a line by hand, and it is not installable; no reference page until it is registered.
• Internal Sales Order — source of every seller order.
• Pricebook — marketplace pricing schemes; the automatic allocation resolves the seller through them.
• Doc Item Maintenance — the financial item behind a marketplace item.
• Internal Purchase Invoice, Internal Payment Voucher — the settlement documents; use those applets to FINAL a PI or to create a PV.
• Cashbook, Organisation — settlement methods and knock-off configuration.
• CP Commerce Admin — storefront orders that enter the allocation queue alongside internal sales orders.

Troubleshooting

Related documentation

• E-Commerce module — where the marketplace and storefront applets sit.
• Merchant Applet — seller entities and login links.
• Internal Purchase Invoice and Internal Payment Voucher — full field and posting reference for the settlement documents.