← Webalkalmazás fejlesztők adatlapja

Skill · 1.0.0 verzió

Üzleti jóváhagyási folyamatok

A ténylegesen átnézett dokumentumhoz köti az üzleti jóváhagyást, végrehajtáskor is érvényes értékhatárokkal és felelősségekkel.

approval-workflows

Ezt a skillt használó csapattagok

Nézd meg, miben segít

Mikor hasznos?

Akkor használd, ha kedvezmény, rendelésérték vagy pénzügyi művelet dönti el, ki hagyhat jóvá és érvényes-e a korábbi döntés.

Miben segít neked?

  • Dokumentumverzióhoz és tartalomlenyomathoz köti a jóváhagyást.
  • Értékhatár, sorrend és szükséges jóváhagyói szám szerint irányít.
  • Végrehajtás előtt érvényességet ellenőriz és tiltja az önjóváhagyást.

Például ezt kérheted

Kérjen új jóváhagyást a rendszer egy jóváhagyott ajánlat kedvezményének módosításakor. Jóváhagyás után emeld a kedvezményt, majd próbálj rendelést létrehozni. A régi engedély legyen érvénytelen, a módosult ajánlat pedig kapjon új ellenőrzési feladatot.

Részletes dokumentáció

Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.

Részletek…Összecsukás

Approval Workflows

When to Use

Use when implementing business or security approval flows—such as discount/quote approvals, purchase orders, refunds/payouts, role elevations, or sensitive production operations.

Core Principle: An Approval Is Bound to a Specific Version & Payload

An approval is never a blank check on a mutable record. If Sales Rep A gets approval for a 5% discount on Quote #104 and then edits Quote #104 to a 40% discount before converting it to an order, an unbound status = 'approved' flag allows fraud!

1. Payload Hash & Revision Binding

Every approval_requests and approval_decisions record must bind to the exact state of the subject:

  • Subject Version & Canonical Snapshot Hash:
    • Compute a deterministic digest (subject_version + payload_sha256 over the canonicalized approval-relevant fields: line items, unit prices, discount, currency, counterparty, terms).
    • Freeze the subject record against direct edits while status = 'pending_approval' or 'approved'.
    • Re-Approval Trigger Rule: If any material field covered by payload_sha256 is modified (or if the price/discount moves in a risk-increasing direction), automatically transition the record back to draft / pending_approval and mark prior approvals superseded.
2. Separation of Duties (SoD) & Conflict-of-Interest Rules

Enforce SoD invariants at the database/service boundary:

  1. No Self-Approval: decision.approver_id !== request.requester_id AND decision.approver_id !== resource.created_by_id AND decision.approver_id !== resource.owner_id (unless an explicit, documented single-owner workspace exception is configured).
  2. Distinct Multi-Approver Quorum (Four-Eyes / $M$-of-$N$): When a high-value threshold requires 2 approvals (e.g., Sales Director + Finance Controller), the same person holding both roles cannot sign off on both steps (COUNT(DISTINCT approver_id) >= required_approvers).
3. Tiered Thresholds & Sequential / Parallel Routing

Model threshold rules declaratively:

  • Tier 1 (discount <= 10% and total <= 10,000): Auto-approved (no_approval_required).
  • Tier 2 (discount <= 25% or total <= 50,000): Requires sales_manager of the rep's department.
  • Tier 3 (discount > 25% or total > 50,000): Sequential approval—Step 1: sales_manager, Step 2: finance_director.
4. Expiration & Execution Re-Verification
  • Attach an expires_at timestamp to approvals where business validity is time-sensitive (e.g., quote price lock or temporary payout sign-off).
  • At execution time (converting the approved quote to an order or disbursing funds), atomically verify in a single transaction that approval.status === 'approved', approval.payload_sha256 === currentPayloadHash(resource), and approval.expires_at > NOW().

Csomagban lévő fájlok 1

  • SKILL.md