XJDF Master Data Modeli

NowToPrint master data'yi tek gercek kaynak olarak tutar ve bunu XJDF-native sozlesmeler uzerinden kullanir. XJDF burada sadece export formati degil, medya, cihaz, tedarik ve job snapshot semantigini tanimlayan kanonik modeldir.

---

Bes katmanli model

Her ana master-data ailesi ayni katmanli modeli izler:

Katman	Amac	Ornek
generic class	Tarafsiz teknik tanim	70x100 4 renk tabaka ofset
branded product	Marka ve urun kimligi	Sappi Magno Satin 130 gsm 70x100
supplier/source	Ticari ve tedarik gercegi	supplier, MOQ, lead time, validity window
organization override / installed asset	Kuruma ozel gercek dunya durumu	yerel makine opsiyonu, yerel fiyat, yerel kisit
job snapshot	Degismez calisma gercegi	teklif veya siparis aninda kullanilan kesin kaynaklar

Bu model sayesinde /admin kanonik gercegi yayinlar, /dashboard ise kontrollu override uygular.

---

Supplier intake ve onay kapisi

Supplier veya partner kaynakli catalog verisi, kanonik master data'ya dogrudan yazilmaz.

• POST ve PUT /api/b2b/suppliers/catalog aktif, invite-only x-api-key ve supplier_catalog_intake.write scope'u gerektirir; key, payload icindeki supplierId ile eslesmelidir
• supplier catalog write istekleri Firestore write baslamadan once XJDF supplier write butcesiyle local rate-limit edilir
• kabul edilen supplier submission'lari supplier_catalog_intake icinde pending_review ve canonicalPublished: false olarak stage edilir; API 202 review-only evidence dondurur ve kanonik veri publish etmez
• platform admin veya data steward, staged kayitlari internal supplier catalog intake review API ile gorur
• admin review kuyrugu, master-data yuzeyinden ayrilmadan pending_review, approved, rejected ve all status filtreleri arasinda gecis yapabilir
• ayni kuyruk, supplier kimligi, SKU verisi ve yakin donem review note alanlari uzerinde steward tarafli metin aramasi sunar
• admin review paneli, branded kagit adindan dusuk riskli generic media onerilerini prefill ederek steward hizini artirabilir
• onerilen generic mapping'ler artik hafif bir confidence sinyali tasir; boylece steward daha guvenli autofill vakalarini ayirt edebilir
• pending submission'lar artik server-side olarak kanonik supplier_catalogs projection'i ve aktif branded media master data ile enrich edilir; buna ek olarak duplicateSummary risk sinyali, blocking canonical match sayisini ve toplam duplicate aday sayisini one cikarir
• ayni intake list response'u artik hafif bir queue summary de doner; boylece review paneli basliginda high-risk pending, duplicate-reviewed approval ve duplicate reject sayaclari tek bakista gorulebilir
• review queue artik internal duplicate-risk supplier intake filtresiyle beslenen bir Duplicate risk filtresi de sunar; boylece steward duplicate baskisi en yuksek pending kayitlara hizla odaklanabilir
• ayni queue artik internal supplier intake SLA filtresiyle beslenen bir SLA status filtresi de sunar; boylece geciken pending review backlog'u ayni yuzeyde ayristirilabilir
• internal supplier intake analytics API artik duplicate review outcome sayaclari ile structured rejection reason sayaclarini ayri bir stewardship analytics snapshot'i olarak sunar
• admin master-data yuzeyi de artik canli kuyruktan ayri bir supplier stewardship analytics karti gosterir; boylece publish/reject deseni ayrica izlenebilir
• stewardship analytics route'u ve karti artik Activity window filtresi de destekler; All time, Last 30 days ve Last 7 days pencereleri son aktivite zamanina gore ayni metrikleri yeniden hesaplar
• ayni stewardship analytics snapshot'i artik pending queue aging bucket'larini ve geciken review isi icin SLA breached ile high-risk SLA breach sinyallerini de gosterir
• analytics karti artik Pending ownership ve Steward activity bolumlerini de gosterir; assignment metadata ve reviewDecision.reviewedBy alanlari ile unassigned backlog ve yakin donem reviewer workload'u okunabilir hale gelir
• ayni analytics snapshot'i artik duplicate review resolution ve rejection reason dagilimlarindan leading pattern ozetleri de uretir; kart bu lider desenleri yuzde paylariyla chip olarak gostererek steward'in baskin karar sablonlarini hizla okumasini saglar
• analytics karti artik Focus high-risk queue aksiyonu da sunar; bu sayfa ici focus sinyali review queue'yu dogrudan yuksek riskli duplicate backlog gorunumune tasir
• ayni analytics action bar artik Focus overdue high-risk kisayolunu da sunar; duplicate baskisi ve SLA gecikmesini tek triage aksiyonunda birlestirir
• ayni analytics action bar artik Focus duplicate: ... ve Focus rejection: ... kisayollarini da sunar; boylece approved veya rejected history gorunumu ilgili karar deseni arama alanina onceden yazilarak acilir
• Pending ownership bolumu artik Focus pending: ... kisayollarini da sunar; steward boylece workload sayacindan dogrudan ilgili assigned veya unassigned queue gorunumune gecebilir
• ayni Pending ownership breakdown'i artik steward bazli overdue high-risk kesisimini de hesaplar; Focus overdue: ... kisayollari ilgili owner veya unassigned overdue backlog'a tek tikla gecis verir
• review queue, unassigned + high-risk + overdue gorunumune gelindiginde artik tek tikli Claim shown overdue high-risk aksiyonunu da sunar; bu kisayol gorunen backlog'u mevcut bulk-assignment route'u uzerinden aktif steward'a sahiplenir
• ayni overdue triage seridi artik Bulk steward secimiyle de calisir; Assign shown overdue high-risk aksiyonu gorunen backlog'u her kaydi tek tek secmeden secili steward'a topluca yonlendirir
• stewardship analytics snapshot'i artik hem Suggested overdue steward hem de Fallback overdue steward sinyallerini uretir; her oneride pencere-baglamli bir confidence seviyesi, kisa rationaleSummary, Lowest overdue load gibi kompakt recommendationSignals, secili pencereyi bir onceki esit pencereyle kiyaslayan windowTrend ozeti ve ayrica Safe to auto-assign, Prefer manual check, Escalation needed gibi seviyelerle calisan bir assignmentRecommendation katmani bulunur. Kart böylece sadece kimi onerdigini degil, neden simdi one ciktigini ve backlog'un ne kadar otomatik yonlendirilebilecegini de gosterir; review queue ise ayni focus event'lerle Bulk steward alanini once asil sonra alternatif steward ile onceden doldurabilir
• analytics karti overdue assignment hedefi hazirlarken review queue artik bu recommendation payload'ini dogrudan tuketir: Bulk steward alani onceden dolar, queue tarafinda bir guidance alert gorunur ve recommendation seviyesi Escalation needed ise overdue bulk assignment ancak steward escalation gerekcelerini acikca onayladiktan sonra acilir
• ayni recommendation sozlesmesi artik internal supplier intake assignment API ve internal supplier intake bulk-assignment API tarafinda da server-side zorunlu hale geldi: secilen steward recommendation hedefiyle eslesmeli, escalation_needed atamalarda escalationAcknowledged gerekli olmali ve kabul edilen aksiyonlar assignmentRecommendationDecision audit objesiyle kayda gecmelidir
• stewardship analytics route'u artik bu audit izini assignmentRecommendationCounts, source breakdown'lari, acknowledged escalation toplamlari ve Leading assignment: ... desenleri olarak da raporlar; analytics karti bu outcome sinyallerini gosterir ve queue'yu assignment recommendation etiketine gore focus edebilir
• review queue ayni audit objesini her kayitta Assignment guidance, Assignment reasons, Assigned by ... at ... ve varsa Escalation acknowledged at ... satirlariyla geri gosterir; boylece recommendation destekli assignment baglami hem pending hem history gorunumlerinde gorunur kalir
• Steward activity bolumu de artik Focus activity: ... kisayollarini sunar; secili reviewer kimligi queue aramasina yazilarak review history dogrudan acilir
• review queue artik internal supplier intake assignment API uzerinden Assign to me ve Unassign aksiyonlarini da destekler; assignment state ayni master-data review modeli icinde tutulur
• ayni assignment route'u artik assignedToUserId ile steward'dan steward'a yeniden atamayi da destekler; review paneli platform user directory icindeki baska bir aktif admin steward'i hedefleyebilir
• admin review paneli artik internal supplier intake bulk-assignment API uzerinden coklu steward triage da destekler; Bulk assign to me, secili steward'a toplu atama ve Bulk unassign selected aksiyonlari ayni yuzeyde sunulur
• ayni queue artik internal supplier intake assignment filtresi ile Assigned to me, Unassigned ve Assigned only backlog gorunumleri arasinda da hizli gecis sunar
• high risk duplicate eslesmeleri artik dogrudan approve edilemez; internal supplier intake approval API publish etmeden once steward tarafinda acik bir duplicate review decision ve not girilmesi gerekir
• canonical publish siniri artik transaction baslamadan once canPublishCanonicalMasterData() ile korunur; full platform admin, master_data_steward veya standards_steward disindaki roller MASTER_DATA_PUBLISH_FORBIDDEN alir
• supplier catalog disindaki kritik Master Data kategorileri artik ortak master_data_publication_history contract'ina sahiptir; generic media, branded variant, generic-branded mapping, standards registry ve standard mapping publish'leri ayni immutable history dilini kullanabilir
• review paneli artik Mark as supplier-specific ve Reject as duplicate gibi hizli aksiyonlar sunar; boylece duplicate review ve rejection alanlari en yaygin steward kararlarina gore onceden doldurulabilir
• birden fazla high risk duplicate kayit secildiginde ayni panel Bulk mark supplier-specific ve Bulk reject as duplicate sablonlarini da sunar; boylece duplicate yogun backlog ayni draft metinleri tek tek girmeden triage edilebilir
• ayni bulk triage alani artik Select shown high-risk duplicates kisayolunu da sunar; boylece steward gorunen blocking duplicate kayitlari secip toplu duplicate template'lerini daha hedefli uygulayabilir
• steward bu draft sablonlarini geri almak isterse ayni bulk triage alani secili high risk duplicate kayitlar icin Clear selected duplicate templates aksiyonunu da sunar
• approved ve rejected history kartlari da artik duplicate review resolution veya structured rejection reason bilgisini gosterir; boylece yakin donem steward kararlarinin baglami ayni kuyrukta okunabilir kalir
• steward, onay sirasinda istege bagli bir publish note girerek kanonik yayin icin audit izi birakir
• Paper kategorisindeki her item, onay aninda bir kanonik generic media class kaydina baglanir
• approval endpoint'i If-None-Match: * ister; client timestamp'i, legacy genericMappings, unknown alanlar ve canonical standard id ile SHA-256 source checksum tasimayan standard ref'leri RFC 9457 422 ile reddedilir
• approval once intake kaydini hashed idempotency ve frozen plan digest'leriyle claim eder; raw idempotency key storage'a yazilmaz
• her generic-branded mapping canonical Master Data mutation Unit of Work uzerinden create ve publish edilir; CAS-korumali history, audit, receipt, publication lineage ve outbox evidence uretilir, approval route'undan direct Firestore mapping write'i yasaktir
• mapping publish tamamlandiktan sonra supplier catalog finalization kesilirse ayni operation identity publishing checkpoint'inden devam eder; post-claim conflict ve retryable dependency cevaplari cache'lenmez, sorun giderildikten sonra ayni key ile devam edilebilir
• active partial-commit replay frozen canonical payload'i, hash-backed standard authority'yi ve deterministic publish command identity'sini yeniden dogrular; original storage digest ile create/publish outbox event id'lerini yeniden kurar, drift varsa 412 ile fail-closed kalir
• farkli owner 412, snapshot digest conflict 409, retryable dependency sorunu ise resumable 503 alir
• sadece mapping'i tamamlanan kayit internal supplier intake approval API ile supplier_catalogs projection'ina publish edilir
• ayni approve akisi artik immutable bir snapshot'i supplier_catalog_publications koleksiyonuna da yazar; boylece mutable kanonik projection sonraki publish'lerle guncellense bile publish lineage kaybolmaz
• admin master-data yuzeyindeki Canonical supplier publication history karti internal canonical supplier publication history API uzerinden bu immutable publish trail'i son version, source intake id, mapping durumu ve duplicate review baglami ile birlikte gosterir
• ayni publication history route'u artik gorunen kayitlar icin previousPublication referansi ve diffSummary de uretir; addedSkuCount, removedSkuCount, mappingStatusChanged ve duplicateRiskChanged gibi sinyaller onceki supplier snapshot'ina gore hesaplanir
• publication history karti bu delta'yi dogrudan gosterir; boylece steward son kanonik publish'in bir onceki supplier snapshot'ina gore neyi degistirdigini admin master-data yuzeyinden ayrilmadan okuyabilir
• ayni publication history response'u artik skuDiff.addedSkus, skuDiff.removedSkus ve stateDiff icinde mapping status ile duplicate risk alanlarinin onceki/guncel degerlerini de doner; history kartindaki acilir Show SKU diff kontrolu steward'in bu farki hem SKU hem de state gecisi seviyesinde incelemesini saglar
• ayni route artik rollbackReadiness sinyali de uretir; ready, manual_review_required ve not_available seviyeleri ile reason listesi dondugu icin publication history karti onceki canonical snapshot'a geri donusun dusuk riskli mi yoksa once steward review mi gerektirdigini de anlatabilir
• publication history karti artik internal supplier publication history rollback filtreleriyle calisan rollback odakli gorunumler de sunar; boylece steward Manual review required, Ready veya No rollback base snapshot'larini ayni admin master-data yuzeyinde hizla ayri bir kesitte gorebilir
• ayni publication history response'u artik summary.totalItems ve summary.rollbackCounts alanlarini da doner; kart rollback filtre butonlarini bu sayaclarla etiketler ve Search supplier or SKU alani uzerinden q= contract'i ile supplier/SKU bazli hizli arama da sunar
• ayni summary payload'i artik summary.supplierCounts listesini de doner; kart bunu Quick supplier focus aksiyonlarina cevirir, gorunen arama metnini korurken arka planda exact supplierId filtresi uygular
• publication history route'u artik latestOnly=true contract'ini da destekler; karttaki Latest per supplier toggle'u steward'in tam history ile supplier basina tek guncel snapshot overview'i arasinda hizli gecis yapmasini saglar
• ayni route artik windowDays=7|30|90 contract'ini da destekler; karttaki All time, Last 7 days, Last 30 days ve Last 90 days aksiyonlari steward'in son donem publish hareketliligine hizli odaklanmasini saglar
• publication history route'u artik changedOnly=true davranisini da destekler; karttaki Changed only toggle'u summary.changeCounts.changed ile beslenir ve steward'in yalnizca gercek materyal delta tasiyan publish kayitlarina odaklanmasini saglar
• ayni publication history route'u artik attentionOnly=true davranisini da destekler; karttaki Needs attention toggle'u summary.attentionCounts.needsAttention ile beslenir ve steward'in yalnizca hem degisim tasiyan hem de rollback icin manuel review gerektiren publish kayitlarina odaklanmasini saglar
• ayni summary payload'i artik summary.attentionSupplierCounts listesini de doner; kart bunu Quick attention focus aksiyonlarina cevirerek exact supplierId ve attentionOnly=true ile steward'in riskli degisim tasiyan publish'lerde dogru supplier'a odaklanmasini saglar
• eksik veya hatali kayit internal supplier intake rejection API ile yapilandirilmis rejectionReasonCode ve steward notu kullanilarak geri cevrilir
• her approve/reject karari actor, zaman ve not bilgisini tasiyan bir reviewDecision audit objesi uretir
• onaylanmis veya reddedilmis kayitlar ayni kuyrukta tekrar acilarak yakin donem steward karar gecmisi incelenebilir
• procurement ve benzeri consumer yuzeyleri yalnizca onaylanmis kanonik projection'i okur

Bu review gate, branded product ve source truth'un tenant veya supplier tarafindan platform kanonigini bypass ederek kirletilmesini engeller.

---

Ana aileler

Media

Medya kaydi artik duz bir kagit listesi degildir. Tam zincir:

• generic media type
• branded media
• supplier/source validity
• organization override
• job-time resolved snapshot

Onemli alanlar:

• ebat ve stock size listesi
• gramaj ve kaplama
• XJDF product id
• reference price ve raw price unit
• supplier availability, MOQ ve lead time

Devices

Cihaz gercegi iki seviyede tutulur:

• generic device capability
• organization bazli installed machine truth

Routing ve costing ayni gercek makineyi gormelidir. Yalnizca makine ailesine bakmak yeterli degildir.

Finishing ve sarf kalemleri

Cilt, selefon, lak, kalip, iscilik ve enerji gibi alanlarda da ayni disiplin uygulanir:

• admin kanonik taksonomi
• organization override
• teklif, siparis ve uretimde immutable snapshot

Operasyon intent ayrimi

Kesim ve delgi ayri Platform Master Data gercekleridir. Kesim kayitlari master_data_cuttings koleksiyonuna yayimlanir ve cutting intent semantigini tasir. Delik delme, perforaj, zimba deligi ve benzeri delgi surecleri master_data_hole_makings koleksiyonuna yayimlanir ve HoleMakingIntent tasir. Delgi RFQ, admin, catalog projection, XJDF export veya uretim planlama icinde kesim alt tipi olarak modellenmemelidir.

---

Compatibility matrix

Media-device compatibility matrix artik bir yan not degil, ana karar katmanidir.

Su sorulari cevaplar:

• bu substrat bu makinede gercekten calisabilir mi?
• karar native mi, conditional mi, unsupported mi?
• hangi kural ve not bu karari acikliyor?

Bu kararlar su alanlara iner:

• quote confidence
• routing
• manual review gate
• operator review queue

---

Supplier validity ve inventory truth

Supplier/source katmani bir kaynagin ticari olarak kullanilabilir olup olmadigini belirler.

Izlenen gercekler:

• available stock
• required quantity
• minimum order quantity
• lead time
• price validity window
• active, discontinued veya not-yet-valid gibi source status

Sistem bunu dogrulayamiyorsa kesin fiyat numarasi yapmaz; confidence dusurur veya manual review ister. Generic-only source, sifir/reference price, expired price ve quality hold durumlari ERP posting veya production-ready sonucuna terfi edemez. Inventory lot secimi rezervasyon ve ERP hareket kaniti tasimadiginda source-ready kalir; operatora attach_inventory_lot aksiyonu duser.

---

Job snapshot disiplini

Teklif ve siparis kaydi, hesaplama aninda kullanilan gercegi saklamalidir.

Snapshot'a inen alanlar:

• resolved media ve brand id
• resolved supplier/source id
• resolved machine veya installed asset id
• raw price unit ve normalized price unit
• compatibility karari ve notlar
• manual review reason listesi
• imposition ve waste varsayimlari
• costing resolver kaynaklari (source, sourceId, name)
• masterDataExecutionSnapshot.digest ve resolutionTrace
• XJDF export metadata'sindaki masterDataExecutionSnapshot reference'i
• PrintTalk Header icindeki MasterDataExecutionSnapshotV1 reference'i
• ERP/MIS GatewayMessage.metadata.masterDataExecutionSnapshot reference'i

Bu disiplin olmadan audit, dispute ve quote-production parity yonetilemez. Production handoff API'leri bu disiplini artik opsiyonel metadata olmaktan cikarir: XJDF builder'in genel build() metodu dokuman hazirligi icin kalir, fakat uretime giden export buildProductionHandoff() kullanmak zorundadir. PrintTalk ve ERP tarafinda da ayni execution snapshot yoklugu P0 bloklayici hatadir.

---

2026 Master Data SSOT referansi

2026 analizine gore XJDF, XJMF, PrintTalk, ICC, ISO, GWG, GS1 ve FSC/PEFC gibi standartlar platform verisinin yerine gecmez. Bu standartlar, Master Data kayitlarinin dilini, dogrulama kurallarini, mapping'lerini ve entegrasyon sozlesmelerini belirleyen alt katmandir.

Kabul edilen model:

• Standards Registry: dis standartlar, versiyonlar, terimler ve validation rules
• Platform Master Data: generic class, branded product line, branded variant/SKU, supplier/source, device, compatibility, color profile, process ve catalog spec gercegi
• Tenant Overlay: organization preference, negotiated price, installed asset, inventory ve customer-specific policy
• Resolved Snapshot: RFQ, quote, order, job ticket, XJDF package, PrintTalk exchange ve ERP posting aninda cozulmus degismez veri
• Catalog Projection: SEO/RFQ icin ticari gorunum; teknik SSOT degildir

Generic ve branded iliski basit bir genericId alani olarak ele alinmaz. Generic media publish kayitlari CanonicalGenericMediaSchema ile, branded product line ve variant publish kayitlari CanonicalBrandedMediaProductLineSchema / CanonicalBrandedMediaVariantSchema ile ortak Master Data zarfina girer; supplier/source gercegi CanonicalSupplierSchema / CanonicalMediaSourceSchema ile ayni history hattinda izlenir. Variant/SKU kayitlari generic siniflara confidence, mapping type, provenance, standard refs ve steward approval tasiyan ayri CanonicalGenericBrandedMappingSchema grafigiyle baglanir. M5 graph guard'i her pozitif mapping icin deterministic brandedVariantRef ve proof refs uretir; generic-only edge production_ready olamaz ve incompatible negative knowledge resolver sonucuna pozitif alternatif olarak karisamaz. M6 source bridge bu graph'i real steward approval, approval ref, source evidence refs, publication history refs, source version ref, generated olmayan provenance, supplier price, freshness, reservation, ERP movement ve lot releasability kanitlariyla tamamlar; generated seed/NTP-AI mapping veya governed source history tasimayan mapping production-ready sayilmaz.

Catalog projection kayitlari CatalogProjectionItem contract'i ile Master Data refs tasir: masterProductRef, genericSpecRefs, allowedOptionRefs, projectionVersion ve sourceMasterDataPublishedVersion. validateCatalogProjectionItem() eksik refs icin hata, guncel Master Data version farki icin stale sinyali uretir; assertCatalogProjectionPublishable() eksik ref'li projection publish'ini durdurur. Full Book RFQ field contract'ini iddia eden publication buyer RFQ projection'lari yayinlanmadan once required buyer option coverage'ini de kanitlamalidir. buildCatalogProjectionDraftFromMasterProduct() artik publication RFQ draft'lari icin paper, cover, binding, dimension, lamination, coating, color mode, quantity ve delivery boyunca brand-free buyer option refs uretir; XJDF factory ve projection contract testleri generated Book RFQ projection'in contract sinirinda publishable oldugunu kilitler. media-spec-registry kaynaklari da buildMediaSpecMasterDataRef() ve buildMediaSpecMasterDataRefs() ile master_data_generic_media kaynak ref'lerine projekte edilir. RFQ resolver contract'i tarafinda resolveRfqCatalogOptionRefs() once published allowedOptionRefs degerlerini kullanir; projection refs yoksa legacy allowed media ID'lerini Master Data refs'e cevirir ve bilinmeyen ID'yi hata olarak durdurur. Aktif buyer route'lari generated Kitap/publication RFQ projection'i route/helper seviyesinde production RFQ resolver uzerinden tuketir; paketlenmis publication RFQ seed bu bridge icin yalniz surface ve version metadata saglar. Rendered buyer section testleri generated projection'in paper ve binding kontrollerini besledigini kanitlar. Guncel product-behavior kaniti AI/manuel route yuzeylerini, RFQ submit/persistence'i, default-public gorunurlugu, admin'in yayin sonrasi duraklatmasini ve misafir devam akisini kapsar. Bu unstubbed production data, external deploy trafigi veya external GA kaniti degildir. Production cagrilari environment: 'production' gecmelidir; bu modda projection refs yoksa baseline fallback MASTER_DATA_PRODUCTION_BASELINE_FALLBACK_FORBIDDEN ile durur.

Admin cockpit tarafinda quality-score.ts, category bazli Master Data kalite ve standards-readiness skorlarini ortak KPI diline cevirir: standards coverage, mapping coverage, supplier freshness, duplicate risk, stale projection ve RFQ auto-resolve. Internal Master Data stats API bu dashboard'u stats.quality olarak dondurur ve MasterDataQualityPanel ayni sinyali admin/master-data yuzeyinde genel skor ve zayif category listesi olarak gosterir.

Kalite panelindeki kategori kartlari score ile birlikte gorunur status etiketi de tasir. Steward, risk/watch/healthy durumunu yalnizca renkten veya ikondan okumak zorunda kalmaz.

Canonical lifecycle dili de MasterDataWorkflowStage ile ortaklastirildi: draft, validate, match, steward_review, publish, monitor. MASTER_DATA_WORKFLOW_TRANSITIONS ve assertMasterDataWorkflowTransition() helper'i steward review/publish oncesi state atlamalarini engeller; MasterDataLifecycleSchema ayni izi workflowStage ve lastWorkflowTransitionAt alanlariyla tasir.

Publication history pattern'i supplier catalog disina da genisletildi. publication-history.ts her kritik kategori icin source collection, publication collection, criticality ve deterministic publication id uretimini tanimlar; supplier catalog mevcut supplier_catalog_publications koleksiyonunu korur, diger kritik kategoriler ortak master_data_publication_history hattini kullanir.

Admin supplier/source create akislari canonical koleksiyonlara yazar ve XJDF namespace'i ntp:supplier:* / ntp:media_source:* olarak uretir. Supplier/source truth icin ntp:unknown:* kabul edilmez; servis testi bu namespace sozlesmesini master-data:ssot:guard altinda kilitler.

Legacy papers ve media-types kategori adlari artik public/admin API input'u degildir. Canonical write endpoint'leri bu adlarla gelen create/update/delete isteklerini MASTER_DATA_LEGACY_CATEGORY_WRITE_FORBIDDEN ile durdurur ve generic-media, branded-media, media-sources hedeflerini onerir. XJDF GenericPaperModel, SpecificPaperModel, GenericMachineModel ve SpecificMachineModel shallow modelleri de deprecated_adapter_only policy ile isaretlidir; yeni kod Platform Master Data ve tenant overlay ayrimini kullanmalidir.

XJDF organizasyon path'leri yalniz overlay context olarak degerlendirilir. Canonical okuma/yayin hedefi Platform Master Data collection'i, organizasyon altindaki veri ise preference, inventory, installed-device veya negotiated-rate overlay'idir.

M1 layer contract guard, XJDF/ERP consumer dosyalarinda retired root collection kullanimi, migration-only mapping path, typo alias, local static truth, generic-only media, AI-generated truth ve legacy seed terminolojisi kullanimini master-data:ssot:guard icinde durdurur. ERP gateway icin final is gercegi resolved_snapshot ve inventory_lot olmadan tamamlanmis sayilmaz.

Yeni Master Data modeli ekleme checklist'i

Yeni bir canonical Master Data ailesi eklemeden once admin/master-data yuzeyinde su kararlar net olmalidir:

• canonical category adi, collection sabiti ve gerekiyorsa legacy alias/migration policy
• kritik publish kategorisi ise schema-adoption.ts icindeki MasterDataSchemaEnvelopePolicy kaydi
• createCanonicalMasterDataSchema() veya defineCanonicalMasterDataSchema() ile zorunlu ortak zarf alanlari: canonicalCode, schemaVersion, platformAuthorityRefs, uygulanabiliyorsa externalStandardRefs, uygulanamiyorsa noExternalStandardApplicability, source/provenance, lifecycle, governance, quality ve audit. standardTermRefs sozluk/provenance alanidir; L2 publish authority kazandirmaz.
• ilk adoption ornekleri olarak CanonicalGenericMediaSchema, CanonicalGenericBrandedMappingSchema, CanonicalBrandedMediaProductLineSchema, CanonicalBrandedMediaVariantSchema, CanonicalSupplierSchema, CanonicalMediaSourceSchema ve legacy schema ayrimlari
• standart uyumlulugunun Standards Registry ref'leriyle nasil ifade edilecegi
• generic, branded, supplier/source ve tenant overlay ayriminin nerede durdugu
• kritik category ise master_data_publication_history veya category-specific immutable history karari
• RFQ, quote, costing, production, XJDF, PrintTalk veya ERP icin MasterDataExecutionSnapshotV1 etkisi
• RFQ/SEO katalogunda gorunecekse CatalogProjectionItem refs ve stale detection contract'i
• admin/master-data stats ve quality-score.ts tarafinda hangi KPI ile izlenecegi
• publish aksiyonunun canPublishCanonicalMasterData() ve steward workflow'u ile nasil korunacagi
• schema, category alias, write guard, publication history, snapshot/export, canonical-envelope-guard.test.ts ve master-data:ssot:guard testleri

Yasayan proje referanslari:

• docs/MASTER_DATA_SSOT_2026_RAPORU.md
• docs/strategy/NOWTOPRINT_MASTER_DATA_SSOT_UYGULAMA_PLANI_2026_TR.md
• docs/help/MASTER_DATA_SSOT_REFERANS_REHBERI.md
• docs/guides/MEMBER_COMPANY_MASTER_DATA_ADOPTION_GUIDE.md

---

Uye firma kullanim modeli

Uye firmalar platform master data'yi uc modda kullanir:

1. Aynen kullanim — canonical veriyi degistirmeden kullanma (yeni uyeler icin varsayilan)
2. Tenant overlay — canonical truth'u koruyarak firma-ozel fiyat, stok, tedarikci tercihi veya installed asset ekleme
3. Yerel yetenek — platform katalogunda olmayan ekipman veya malzemeleri canonical kayitlari degistirmeden kaydetme

Overlay katmani fiyat, stok sinyali, tedarikci tercihi ve installed asset uzerine yazabilir. gsm, kaliper veya ISO grade gibi canonical teknik spesifikasyonlari degistiremez. Overlay stale veya canonical guncellemeyle celisirse tenant-overlay-conflict.ts policy'si ciddiyet derecesine gore uyari veya blok davranisi tetikler.

Teklif veya siparis finalize aninda platform, canonical master data ile tenant overlay'i birlestirerek degismez resolved snapshot uretir. Bu snapshot karar anindaki veri versiyonunu korur ve platform verisi sonradan degisse bile eski teklif/siparis tutarli kalir.

Tam onboarding adimlari ve SSS icin docs/guides/MEMBER_COMPANY_MASTER_DATA_ADOPTION_GUIDE.md dosyasina bakin.

---

Bu rehber ne zaman kullanilir

Bu sayfa su durumlar icindir:

• XJDF master-data export veya import entegrasyonu
• admin ve dashboard override davranisi tasarimi
• ERP/MIS verisini NowToPrint kanonik modeline esleme
• snapshot ve audit semantigini gozden gecirme

Yuzey bazli detaylar icin alttaki rehberleri kullanin.

Network snapshot guncellemesi

XJDF ve PrintTalk entegrasyonlarinda external network readiness execution kuralini degistirmez: job payloadlari immutable resolved snapshot kullanmalidir. Catalog Projection discovery ve RFQ context saglayabilir, fakat export payloadlari canonical snapshot referanslarini korumali ve public DTO uzerinden private supplier pricing veya evidence okumamalidir.