Sourcing: V3+V4 Compliance- und Security-Anforderungen inline lesen

Ein Bidder, der einen Job priced, muss sehen, was der Job verlangt. Wenn Compliance- und Security Picks drei Klicks vom Bid Form entfernt leben, priced die Hälfte der Bids den falschen Scope. Das Sourcing Module surfaced V3 (Compliance) und V4 (Security) Requirements inline auf der Bid Detail Page, damit der Bidder sie liest, während er den Price tippt.

Was V3 und V4 tragen

V3 ist die Compliance Section der Request: die Frameworks, die der Customer verlangt (GDPR, R2v3, ADISA, NAID AAA, sector-specific). V4 ist die Security Section: die Erasure Standards, die On-site Flag, die Nachweiskette Requirements. Zusammen definieren sie, was die Disposal für den Customer erfüllen muss — und wozu sich der Bidder committen muss.

Inline rendering

Die Bid Detail Page (/sourcing/bids/[id]) rendert V3 und V4 als labeled chips neben der Request Summary, vor dem Price Input. Jeder Chip zeigt den Requirement Name und (für Security) das picked level. Hover oder Tap reveal die full code definition aus dem Catalog, sodass ein Bidder, der ein bestimmtes Framework nicht kennt, lesen kann, was es tatsächlich verlangt, ohne die Page zu verlassen.

Warum auf Bid Detail, nicht Request Detail

Weil das Bid Detail der Ort ist, an dem der Bidder den Price Commitment macht. Requirements dort zu platzieren heißt, dass der Bidder sie in dem Moment liest, in dem es zählt. Das Request Detail hat weiterhin die full breakdown für Neugierige; das Bid Detail hat die Teile, die der Bidder nicht skippen kann.

Coverage-driven filtering

Wenn V3 oder V4 einen Code enthält, den der Tenant des Bidders nicht in active Coverage hat, routet die Plattform die Request gar nicht erst zu ihm. Die Codes, die auf dem Bid Detail erscheinen, sind Codes, die der Bidder laut Coverage Configuration liefern kann. Das ist by design — Bidders sehen nie Requests, die sie nicht fulfilen können.