Card Inventory Use Cases

Card Inventory tracks every physical card from the moment its personalisation file is loaded until the card is issued to a customer, destroyed or confirmed lost. Each card has one status, one location and one person responsible for it, and every move is recorded with who did it and when.

Use it when a tenant orders physical cards from a bureau, holds them in a Card Centre, sends them to branches, and issues them to customers through the card API. The Card Inventory Management portlet gives each role a screen for its part of the work. The same functions are available through the APIs described below.

The following Card Inventory functions are currently supported:

• Order cards from the bureau and capture the bureau's packing list
• Record deliveries at the Card Centre
• Branch stock requests, and dispatches against them
• Branch receipt, allocation to issuing officers, and issue to a customer
• Transfers between branches, handovers between custodians, and returns to the Card Centre
• Exceptions: flag damaged cards, correct a status, adjust stock, quarantine, destroy with a witness, and confirm missing cards as lost
• A custody history for every card, a stock dashboard and 12 reports
• Maker-checker approval of the sensitive steps

Prerequisites:

• A valid JWT for the acting user. Positions are read from the token, so sign in again after a user's positions or the tenant configuration change.
• Card Inventory is turned off by default. Contact EFT Corporation to have it enabled for your tenant (tenant config cim.enabled).
• The Card Centre and each branch set up as divisions, with staff assigned to the Card Inventory positions.
• Each role mapped to a tenant position through the cim.position.* settings: cim.position.custodian, cim.position.issuer, cim.position.ops, cim.position.opsSenior, cim.position.compliance and cim.position.management. A role with no position configured takes no part.
• The CardInventory.* permissions given to each role's position. See Permissions Required.
• For ordering, a card programme and bureau arrangement agreed with EFT Corporation. Optionally, cim.programmes lists the programmes offered on stock requests, as name:labelScheme:expiryYears, comma separated. If it is not set, any programme is accepted.
• Optional tenant settings: cim.issuanceGuard.enabled (when true, a card is issued only if it is allocated to the issuing officer, not expired and at an active branch), cim.reservation.expiry.days (days a shipment can wait for approval before its cards are released, default 7) and cim.expiry.warning.days (days before expiry that a card counts as nearing expiry on the dashboard, default 60).
• To use the portlet, the portlet added to the tenant. See Portlets.
• The CIM_* report definitions made available to the tenant, for the dashboard and the Reports screen.

How a card moves

A card goes through seven steps. Two of them, the delivery at the Card Centre and the dispatch to a branch, need a second person to approve them before the cards move on. At any point once a card is in stock, it can also be transferred between branches, handed over, returned to the Card Centre, flagged as damaged, corrected, counted, quarantined, destroyed, or confirmed as lost.

Roles

Each role maps to a tenant position through a cim.position.* setting, so a tenant uses its own positions. A role with no position configured takes no part. The positions in the table (LEVEL_11 to LEVEL_16) are example values.

• Branch roles see and act only on their own branch. Card Operations, Compliance and Management see every division.
• When Card Inventory is on, admin-user rules apply. A Card Operations position cannot be combined with a branch position, a custodian or issuer sits on exactly one branch, and a user who still holds cards cannot lose their position, change division or be deleted.

Approvals

Sensitive steps need a second person. Each permission can be set as a single position, or as a maker and checker pair such as LEVEL_13->LEVEL_14, in which case the call runs as an approval task. A person cannot approve their own request. In the reference set-up:

A shipment that waits for approval holds its cards. If the approval is rejected, or the shipment waits longer than cim.reservation.expiry.days (default 7), the cards are released.

The portlet

The Card Inventory Management portlet is a standalone page for the admin portal. To open it, sign in to the admin portal, open the tenant, choose Portlets and select Card Inventory Management. The portal signs you in as the portal user, and the portlet shows the screens for that user's role. A user can also sign in directly on the portlet's own sign-in page. Global administrators can open it as any role. To add the portlet to a tenant, see Portlets.

A guided tour for each role is available from the Guided tour button in the header.

Stock Dashboard. Stock by programme, low-stock and expiry alerts, shipments in transit and open stock requests.

Stock Requests & Dispatch. Card Operations sees requests from every branch, and can dispatch, reject or cancel them.

Receipt & Allocation (Card Operations). Batches waiting to be recorded as delivered at the Card Centre.

Approvals. The second person reviews and approves or rejects each pending task. The person who made a request cannot approve it.

Receipt & Allocation (branch custodian). The custodian signs for incoming shipments and allocates, flags, transfers, returns or hands over the cards they hold.

Shipments. Every delivery, dispatch, transfer, return and handover, with its status.

Card Lookup. Find a card by PackID and see its details and every move from order to customer.

Reports. Twelve reports, including stock reconciliation, custody history, missing cards, quarantine and destruction, and a maker-checker audit.

API overview

All Card Inventory calls use the tenant's conductor base path and a JWT for the acting user. The user's positions come from the token, so sign in again after changing a user's positions or the tenant configuration.

• Tenant level: /eclipse-conductor/rest/v1/tenants/{tenantId}/card-inventory/...
• Division level: /eclipse-conductor/rest/v1/tenants/{tenantId}/divisions/{divisionId}/card-inventory/... — {divisionId} is the division acted on, such as the branch that sends or receives.

Cards are identified by cardPackId. Card responses carry cardBin and cardLast4, never the full card number. List calls take offset (default 0) and limit (default 50, maximum 1000).

Settings, programmes and branches

Ordering and packing

Stock requests

Shipments and receipts

Custody and exceptions

Cards

Existing APIs that change

These behave differently only when cim.enabled is true for the tenant.

📘

Note

Calls that are set up as maker-checker steps are queued as an approval task and run only once approved. The response to the first call carries the task ID in the task-id header, not the result. See Maker-Checker Tasks.

Permissions Required