At a Glance
Persona: Purchaser / Purchasing Staff (+ Purchasing Manager) · Module: vendor-pricelist · Workflow stages: Template draft → active; Campaign draft → active → completed; Pricelist submitted → active / inactive / expired · Key permissions: build templates, launch campaigns, invite vendors, review / approve / reject submissions, preferred-vendor curation, high-value sign-off (Manager)
What this persona does: Owns the pricelist lifecycle end-to-end on the Carmen side — templates, campaigns, vendor submissions, approvals, and preferred-vendor flags.
The Purchaser persona file consolidates two organisational roles documented in the module landing Section 4: the Purchaser / Purchasing Staff (the operator who builds price-collection templates, schedules campaigns, sends invitations, reviews and approves submitted pricelists, manages individual price-item edits and the preferred-vendor flag, and uploads emailed vendor submissions on behalf of vendors who cannot use the portal) and the Purchasing Manager (the escalation layer who approves high-value pricelists, configures business rules for preferred-vendor and price-assignment logic, signs off on multi-currency cross-border pricing, and exercises the override authority over the regular Purchaser's queue). The two roles share the same screens and the same persona file because the activation, approval, and rejection actions are the same — the Manager differs from the Purchaser in authorization scope (VPL_AUTH_005, VPL_AUTH_006 for high-value approval, business-rule configuration, and multi-currency sign-off) rather than in screen surface. This persona owns the operational pricelist lifecycle end-to-end on the Carmen side: every transition that is not auto-driven by a cron job (VPL_POST_021 auto-expire), a vendor portal event (VPL_POST_015–VPL_POST_016), or an external Finance / Audit / Sysadmin actor is performed here. The Purchaser also operates against the Receiver / Store Keeper as an indirect consumer — the Receiver's GRN posting reads the active pricelist for variance calculation (vendor-pricelist/02-business-rules § VPL_XMOD_005), and a variance finding routes back to the Purchaser for resolution via amendment, inactivation, or re-collection through a new campaign. Together this makes the Purchaser the owner of the data quality contract that downstream PR / PO / GRN modules rely on.
Entry point: Sidebar → Vendor Management workspace → Templates / Campaigns / Pricelists tabs. Day-to-day operations use the Pricelists → Submitted (awaiting review) queue as the primary worklist; campaign launch and template authoring are episodic activities driven by procurement-cycle calendar (typically quarterly) or by ad-hoc collection requests from category managers.
Primary flow (happy path — full 6-phase cycle):
name (unique per VPL_VAL_001), description, vendor instructions (renders on the portal + email body), default currency_id, validity_period in days, and the reminder schedule [14, 7, 3, 1] (VPL_VAL_004). Save in draft.VPL_VAL_006); the JSON shape on tb_pricelist_template_detail.order_unit_obj carries { default_order: {unit_id, unit_name}, moq: [ {unit_id, unit_name, qty, note}, ... ] }. Each product can appear once per template (VPL_VAL_005 — unique (template_id, product_id)).VPL_POST_002 fires: tb_pricelist_template.status = draft → active; the template is now selectable for new campaigns. A system comment records the activation actor and timestamp.name, start_date, end_date (must satisfy VPL_VAL_010 — start < end, end > now(), minimum window 3 days), custom_message, and email_template_id (the email template tenant-id). Select the vendor cohort to invite. Click Launch.tb_request_for_pricing_detail rows — one per selected vendor — with a fresh cryptographic pricelist_url_token per row. Emails are dispatched via the configured channel; each carries the per-vendor portal URL embedding the token. Campaign status is now active (derived per VPL_POST_006).pending → in-progress → submitted → approved / expired). Email-delivery telemetry (sent / delivered / opened / clicked) is captured as system comments in tb_request_for_pricing_detail_comment with structured payloads in attachments / message JSON (vendor-pricelist/01-data-model § 2.7).tb_pricelist.submitted_at = now() is written and the Purchaser receives a notification. The submitted pricelist surfaces in the Pricelists → Submitted (awaiting review) queue.tb_pricelist.info.validation_results and info.quality_score (VPL_CALC_006). Walk each tb_pricelist_detail row — product, unit, MOQ qty, price-without-tax, tax, lead-time, the auto-calculated effective unit price per base UoM (VPL_CALC_003). Multi-MOQ rows on the same product are auto-sorted and validated as non-increasing (VPL_VAL_020).draft + submitted_at → active, VPL_POST_017). Requires VPL_AUTH_004 (below high-value threshold) or VPL_AUTH_005 for high-value / VPL_AUTH_010 for multi-currency. Mark the appropriate rows as preferred via is_preferred = true. A system comment captures approval.draft + submitted_at → draft, submitted_at reset, VPL_POST_018). Requires VPL_AUTH_006. Capture reason text; vendor receives email + retains the original token for resubmission until campaign end_date.VPL_AUTH_001 and adjust specific rows (e.g., toggle is_preferred, correct an obvious unit typo) then approve. Edits are logged in tb_pricelist_detail_comment with the actor and the diff.tb_pricelist.status = active, the pricelist becomes the live reference for (vendor, product, currency, validity window) and PR / PO / GRN modules see it on next read. PR-line creation defaults the price from the preferred row matching the line's product + currency + MOQ bracket per vendor-pricelist/02-business-rules § VPL_XMOD_001.tb_pricelist + detail rows with submission_method = email and an attached system comment recording the original email and the staff member who uploaded (per VPL_AUTH_003). The pricelist then enters the standard review flow at Step 8.end_date passes (or every invited vendor has submitted), the campaign auto-completes (VPL_POST_008). Outstanding invitations auto-expire (VPL_POST_014) and their tokens are revoked. The Purchaser reviews the campaign's analytics — response rate, average submission time, quality-score distribution — to inform the next cycle.is_preferred = true on exactly one tb_pricelist_detail row. The toggle is logged in tb_pricelist_detail_comment; PR-line defaulting follows the toggle (VPL_XMOD_001). When the business rules engine (carmen/docs price-assignment-workflow-documentation.md) is configured, the engine sets the flag automatically based on rule categories (vendor preference, price optimisation, quality assurance, supply chain); the Purchaser can still manually override an automatic assignment.VPL_AUTH_004 floor). The pricelist routes to the Purchasing Manager queue (VPL_AUTH_005) and, for multi-currency, the Finance Manager queue in parallel (VPL_AUTH_010). Approval requires both signoffs before VPL_POST_017 fires.in-progress near deadline. Reminder emails fire automatically per the template schedule (reminder_days), but if a vendor has the portal token but has not yet submitted with 24 hours remaining, the Purchaser can (a) open the campaign → Reminders → click Send one-off reminder, (b) extend the campaign end_date (writes a system comment), or (c) escalate to the contact person via phone / email out of band. Escalation is logged as a user comment so the audit chain is preserved.quality_score < tenant_threshold (default 70 per VPL_XMOD_009), the pricelist routes to Manager review rather than auto-approve. The Manager either (a) approves with the low score on file (e.g., new vendor entering the catalogue), (b) rejects under VPL_AUTH_006 with specific correction guidance, or (c) requests inline edits before activation. Score drift over multiple cycles is captured on the vendor's performance profile feeding the business-rules engine.submission_method = email and the activity log records the manual entry. The vendor's portal token remains issued and unused; it auto-expires at campaign end without affecting the email-sourced pricelist.VPL_AUTH_015 to revoke the token. Revocation invalidates the portal access immediately; any in-progress draft pricelist remains in draft status and can be either (a) deleted if no data is salvageable, or (b) re-routed by issuing a new invitation with a fresh token in a separate campaign.VPL_VAL_025, an active pricelist is immutable except for status. To correct a row, the Purchaser inactivates the pricelist (VPL_POST_019), opens a new campaign targeting the same vendor + template, the vendor re-submits with corrections, and the corrected pricelist is approved fresh. The old (inactive) pricelist remains queryable for audit. The downstream PR / PO / GRN cohort that referenced the old pricelist between activation and inactivation is preserved by snapshot semantics on the consuming-module side (purchase-order/02-business-rules § PO_XMOD_005).end_date passes with some invitations still pending / in-progress, the Purchaser reviews the laggards on the Vendor Tracking tab and decides per vendor: (a) extend the campaign for specific vendors (admin override), (b) accept the auto-expire and reach out to the vendor for the next cycle, (c) cancel the campaign entirely (VPL_POST_009) and re-launch with a corrected template. Each action is logged.The Purchaser's involvement on a given pricelist / campaign ends at one of several documented points; the document state at each handoff is anchored to the lifecycle in 03-user-flow.md § 2.
tb_pricelist.status = active. Handoff is to downstream consumers — PR-line defaulting (VPL_XMOD_001), PO snapshot (VPL_XMOD_003), GRN variance (VPL_XMOD_005). The Purchaser's responsibility transfers to monitoring the Active Pricelists dashboard and resuming on amendment, inactivation, or expiry.draft + submitted_at IS NOT NULL.end_date. Document state at handoff: draft + submitted_at = NULL plus a system rejection comment. The Vendor's exit point (see 03-user-flow-vendor.md) feeds the Purchaser back at Step 7 above.inactive.cancelled; pricelist drafts written so far remain at draft and may be either soft-deleted by the Purchaser or kept for audit.VPL_AUTH_015. Document state at handoff: invitation moves to expired immediately on token revocation; the corresponding draft pricelist (if any) remains at draft until soft-deleted or re-routed.PO_XMOD_007), (b) inactivating the pricelist and re-collecting, or (c) reaching out to the vendor for a credit note / amendment. Document state at handoff: pricelist active (unchanged); variance entry logged for analytics.Auto-transitions (VPL_POST_021 expiry; VPL_POST_014 invitation auto-expire) are not Purchaser actions — they fire from a background cron and the Purchaser observes them on dashboards.
VPL_AUTH_001–VPL_AUTH_006 (Purchaser / Manager template / campaign / approval / rejection scope), VPL_AUTH_014 (segregation of duties — Vendor ≠ Purchaser; high-value Purchaser ≠ Approver), VPL_AUTH_015 (token-revocation escalation).VPL_POST_001–VPL_POST_022 (all three lifecycles plus auto-expiry; the Purchaser drives VPL_POST_002, VPL_POST_003, VPL_POST_017, VPL_POST_018, VPL_POST_019, VPL_POST_020, VPL_POST_022).VPL_VAL_001–VPL_VAL_025 (the Purchaser triggers template, campaign, and pricelist-side validations across the full primary flow).VPL_CALC_001–VPL_CALC_008 (line tax decomposition, effective unit price per base UoM, multi-currency display, quality score formula).VPL_XMOD_001–VPL_XMOD_009 (preferred-vendor defaulting, PR / PO / GRN consumption, validation engine contract).pricelist_detail_pricelist_id_product_id_unit_id_moqqty_u), and the application-derived campaign / invitation status derivations.../carmen/docs/vendor-pricelist-management/design.md — 6-phase architecture that maps directly onto the 12-step primary flow above.../carmen/docs/vendor-pricelist-management/price-assignment-workflow-documentation.md — business-rules engine driving the preferred-vendor curation decision branch.