เตรียม DPP สำหรับเหล็ก: Data Contract ก่อนกฎฉบับสุดท้าย

การเตรียมรับ DPP สำหรับเหล็กไม่ใช่การรีบซื้อซอฟต์แวร์ก่อนกฎสุดท้าย สำหรับผู้ผลิต ศูนย์บริการ ผู้แปรรูป เทรดเดอร์ และผู้ผลิตชิ้นส่วนในไทย/อาเซียน งานที่ควรทำตอนนี้คือกำหนดว่าใครส่งหลักฐานใด ผูกกับหน่วยผลิตใด และมีผลเมื่อไร แล้วทดสอบด้วยกรณีแยก รวม และแก้ certificate จริง Delegated act และรายการข้อมูลเหล็กฉบับสุดท้ายยังไม่ประกาศ บทความนี้จึงแยกข้อกำหนด ESPR ที่ใช้แล้ว ข้อมูลแพลตฟอร์มปัจจุบันของ Commission และข้อเสนอทำงานของ JRC ปี 2026

สิ่งที่เปลี่ยนในปี 2026 และสิ่งที่ยังไม่ตัดสิน

ไทม์ไลน์เชิงบ่งชี้ของ European Commission วางเหล็กไว้ในปี 2026 และระบุ Q4 2026 เป็นหมุดหมายโดยประมาณของ delegated act พร้อมช่วงเปลี่ยนผ่านอย่างน้อย 18 เดือนหลังการประกาศ วันที่อาจเปลี่ยน และขอบเขต ฟิลด์สุดท้าย carrier การเข้าถึง และระดับ model/batch/item ต้องรอกฎเฉพาะผลิตภัณฑ์

ESPR Regulation (EU) 2024/1781 มีผลแล้ว มาตรา 9–11 และ Annex III วางกรอบ persistent unique product identifier และโครงสร้างเปิด ทำงานร่วมกันได้ และ machine-readable แต่ไม่ได้กำหนดว่าเหล็กทุกชนิดต้องใช้ระดับ coil ข้อมูลที่ Commission และเอกสาร JRC เดือนมีนาคม–เมษายน 2026 กล่าวถึงเป็นกลุ่มข้อมูล/ข้อเสนอสำหรับเตรียมงาน ไม่ใช่รายการบังคับที่ประกาศแล้ว อ่านภาพรวมได้ที่ คู่มือ EU DPP สำหรับการผลิต ส่วนบทความนี้เริ่มจาก data contract ของเหล็ก

แบ่งความรับผิดชอบตามห่วงโซ่

Economic operator ที่วางผลิตภัณฑ์ในตลาด EU รับผิดชอบ DPP หลัก แต่ผู้ขายจากไทยยังอาจต้องส่ง source data ที่เชื่อถือได้ตามสัญญา

บทบาท	งาน	ข้อมูลที่อาจต้องใช้	ประเด็นสัญญา
ผู้ผลิตเหล็ก	หลอม หล่อ รีด ทดสอบ	heat/cast ส่วนผสม กระบวนการ ผลทดสอบ	ฟิลด์สุดท้ายยังไม่แน่นอน
ผู้แปรรูป/ศูนย์บริการ	ตัด slit ปรับสภาพ รวม	input/output ID, genealogy, inspection	รักษา parent-child
เทรดเดอร์/ผู้นำเข้า	สัญญา ส่งออก วางตลาด EU	product ID หลักฐาน supplier การลงทะเบียน	ระบุ EU operator
ลูกค้าปลายน้ำ	แปรรูปและอนุมัติ	หน่วยรับเข้า การใช้ หลักฐาน	กำหนดสิทธิ์เข้าถึง

ต้องระบุ EU operator, DPP host, ผู้ลง Registry, ผู้อนุมัติ source และผู้แจ้ง correction ให้ชัด ไม่ใช้เพียงคำว่า “DPP-ready”

แยกสถาปัตยกรรมสี่ชั้น

Factory genealogy/events: MES/WMS เก็บ receipt, production, split, merge, rework, test, shipment พร้อมเวลา ปริมาณ หน่วย และ parent/child ID
Material/test certificates: mill certificate และ LIMS/QMS พร้อมเลขเอกสาร revision correction ผู้อนุมัติ และ product ID
Sustainability/circularity evidence: recycled-content/environment candidate พร้อม method, boundary, factor version, period และ verification; การเปิดเผยรอกฎสุดท้าย
External DPP/Registry: carrier/resolver, access, API และ identifier, registration data, high-level metadata

เตรียม DPP สำหรับเหล็ก: Data Contract ก่อนกฎฉบับสุดท้าย - figure 1

การแยกชั้นช่วยไม่ให้ correction เขียนทับประวัติ และเปลี่ยนผู้ให้บริการ DPP ได้โดยไม่ย้าย master data แนวทาง event ข้ามบริษัทดูได้ที่ chain traceability และ EPCIS

ตารางแหล่งข้อมูลชั่วคราว—รายการที่อาจต้องใช้และรอกฎสุดท้าย

ข้อมูลที่อาจต้องใช้	เจ้าของ	แหล่ง	ตัวอย่างระดับ	Version/effective time	หลักฐาน
Product ID/grade	Quality/sales	ERP/spec master	product/batch/coil	master version	approval
Heat/cast	Steelmaking	MES/cast record	heat, cast, slab/billet	event/final time	record
Chemistry	Lab	LIMS/certificate	sample/heat/batch	analysis/reanalysis	lab approval
Properties	Quality	LIMS/QMS	coil/plate/batch	test/approval	report
Dimension/mass	Production/logistics	MES/WMS/scale	coil/plate/bundle	measurement/correction	calibrated record
Split/merge	Processor	MES/WMS	parents/children	event time	operation
Circularity/environment	Procurement/environment	evidence/EMS	site/period/product	method/period version	verification
Registration	EU operator	DPP/Registry	persistent ID	register/update	API log

ตารางนี้ไม่ใช่รายการกฎหมาย ต้องชี้ owner, authoritative source, ID, effective time, approval และการเก็บ old version ให้ได้

ID และ version สำหรับ heat, coil, plate

เหล็กมีทั้ง one-to-many และ many-to-one เช่น heat → slab → hot-rolled coil → slit coil → shipment batch หรือ billet → bar batch → bundle ไม่ควรประกาศ hierarchy เดียวสำหรับทุกธุรกิจ ให้กำหนด transformation ของตนเอง Split ต้องเก็บ parent, children, input/output quantity, unit, yield, time, process; merge ต้องเก็บทุก parent และกฎสืบทอดหลักฐาน กำหนด conversion kg/tonne, mm/m และห้ามนำ ID กลับใช้ซ้ำ

Certificate correction ต้องเก็บ old/new revision, reason, approver, effective time และ affected products ผู้ใช้เห็นเวอร์ชันปัจจุบัน แต่ auditor ต้องย้อนดูเวอร์ชัน ณ เวลาส่งมอบได้

ขอบเขตของ DPP Registry

Commission อธิบาย Registry ว่าเป็น index ของ identifier, registration data และ high-level metadata ข้อมูล DPP รายละเอียดกระจายอยู่กับ economic operator หรือ service provider ไม่ใช่อัปโหลดข้อมูลทั้งหมดเข้า central EU database

Test environment, UI และ API ใช้เตรียมได้ แต่เหล็กต้องรอกฎสุดท้าย PoC ควรทดสอบ submission, response, update/cancel, retry, audit log และแยก public/customer/authority access เก็บ request, response, timestamp, actor, API version และ failure reason เป็น proof of registration

RFP ที่ตรวจการเปลี่ยนและหลักฐานได้

Clause	สิ่งที่ต้องการ
Scope/role	Product, site, EU operator, approver, host, registrant
Data contract	Candidate, type, unit, quality, configurable final-rule change
ID/version	Persistent ID, genealogy, effective time, correction history
Access/retention	Role, revoke, evidence, event/API log
API/export	Registry และ ERP/MES/QMS/LIMS; portable CSV/JSON
Security	Authentication, authorization, encryption, key, incident
Supplier onboarding	Template, validation, rejection, training, SLA
Exit	Full data, evidence, ID map, log, deletion proof

ให้ vendor สาธิต split/merge, late data, certificate correction และ API outage พร้อมแยกราคาว่าสิ่งใด config ได้หรือเป็น development หลัง final rule

Data contract ของ supplier ต้องครอบคลุมหลักฐาน ไม่ใช่แค่ค่า

หลักฐานเหล็กมาจากผู้ขายวัตถุดิบ โรงถลุง ผู้แปรรูป ห้องทดลอง และผู้ขนส่งในเวลา/รูปแบบต่างกัน สัญญาต้องระบุผู้รับรองความถูกต้อง กำหนดส่ง สถานะเมื่อข้อมูลขาด วิธีแจ้ง correction สิทธิใช้เอกสาร และหน้าที่ส่งหลักฐานซ้ำเมื่อ audit

หากค่าด้านสิ่งแวดล้อมที่อาจต้องใช้ยังมาไม่ถึงวันส่งของ ระบบไม่ควรใส่ศูนย์หรือใช้ค่ารอบก่อนอัตโนมัติ ให้แยก “ยังไม่ได้รับ”, “ชั่วคราว” และ “อนุมัติแล้ว” พร้อมผู้ตัดสินใจเผยแพร่ เมื่อข้อมูลมาถึง ให้เก็บเวลารับ ช่วงข้อมูล revision ของ supplier ผลอนุมัติ และ DPP version ที่ถูกแก้

เมื่อ structured value ขัดกับ PDF ต้องมี source priority และ discrepancy workflow การตรวจอัตโนมัติดูช่วง หน่วย ทศนิยม grade เลข certificate ซ้ำ และ product ID ส่วนผู้อนุมัติบันทึกเหตุผล/สินค้าที่กระทบ Supplier เล็กที่ไม่มี API ใช้ CSV หรือ portal ที่ควบคุมได้ หากยังเก็บผู้ป้อน เวลาเอกสารต้นฉบับ และผล validation

ออกแบบ correction, cancellation และ late arrival เป็น state transition

DPP ไม่ใช่หน้า static ข้อมูลอาจอยู่ใน draft, รอหลักฐาน, validating, approved, registered, correcting, revoked/cancelled หรือ archived ต้องกำหนดว่าแต่ละ state ใครดูได้ ส่งสินค้าได้หรือไม่ และต้อง update Registry หรือไม่

การแก้ certificate ควรรวมการแก้ source, คำนวณผลกระทบ, อนุมัติ, สร้าง DPP revision, แจ้งภายนอก และ re-register เมื่อจำเป็น หาก API ล่มกลางทาง ต้องแยก internal approval จาก external publish และใช้ idempotency ป้องกันส่งซ้ำ Cancellation ต้องเก็บเหตุผล/เวลาไว้ตาม retention ไม่ลบ audit trail

แยก effective time จาก transaction time เพื่อย้อนดูสิ่งที่ลูกค้าเห็นก่อนข้อมูลที่มาช้าถูกบันทึก และแสดง current version ที่แก้แล้วได้พร้อมกัน

ใช้ security และ data portability เป็นเกณฑ์รับ

การเข้าถึง DPP ภายนอกต้องไม่เปิดเผยสูตร เงื่อนไขกระบวนการ หรือชื่อลูกค้าเพียงเพราะมาจาก MES เดียวกัน กำหนด least privilege, public/customer/authority role, สิทธิ์มีอายุ, service account, key rotation, audit log, anomaly detection และ incident recovery

ทดสอบ token หมดอายุ authentication fail การเพิกถอน role บัญชีพนักงานลาออก และจบสัญญา supplier ตรวจว่าลูกค้าเก่าดูข้อมูลจำกัดไม่ได้ การเข้าถึงของ authority ถูกบันทึก และบริการภายนอกล่มแล้วไม่สร้างช่องทางอันตรายเข้าสู่โรงงาน

เมื่อเลิกใช้ vendor ต้อง export product ID, genealogy, revision, evidence, access setting, Registry response และ audit log ในรูปแบบมีเอกสาร ทดลอง import ตัวอย่างเข้าอีกระบบและสร้าง current/historical view กลับให้ได้

ประเมินส่วนต่างเมื่อ delegated act ฉบับสุดท้ายออก

ความพร้อมวัดจากความสามารถรับการเปลี่ยน ไม่ใช่จำนวนฟิลด์ชั่วคราว เทียบ scope, granularity, mandatory data, carrier, access, Registry และ retention ฉบับจริงกับสัญญาชั่วคราว แล้วจัดประเภทส่วนต่างเป็น existing source, supplier contract, master/genealogy, new evidence, configuration, development หรือ legal decision

จากนั้นประเมินสินค้า supplier ข้อมูลย้อนหลัง และ test ที่ต้องทำซ้ำ พร้อมวางแผนย้อนจากวันใช้จริง หากรายการ JRC ไม่อยู่ในกฎสุดท้ายให้ตัดสินคุณค่าทางธุรกิจ หากมีรายการใหม่ ให้ใช้รูปแบบร่วมคือ source, owner, version, effective time และ approval เพื่อเปลี่ยนอย่างควบคุม

กรอบประเมินความพร้อม 90 วันที่ TOMAS TECH เสนอ

นี่ไม่ใช่เส้นตาย EU และไม่รับประกันระยะติดตั้ง แต่เป็นกรอบวางแผนที่ต้องปรับตามขอบเขต

Inventory: เลือกหนึ่ง flow เข้า EU ทำแผน role, source, ID, version, gap, manual step
Provisional contract: กำหนด type, unit, candidate granularity, genealogy, effective time, evidence, approval, access โดยไม่ตรึง JRC เป็นกฎหมาย
One-flow proof: เชื่อม heat/วัตถุดิบจริงถึง processing, shipment, certificate และ external DPP; ใช้ Registry test เท่าที่มี
Exception tests: split, merge, correction, delay, conversion, access change, API outage, history
Decision: ประเมิน gap, workload, change tolerance, supplier, security, portability แล้วเลือก scale, correct data, revise RFP หรือ wait

เตรียม DPP สำหรับเหล็ก: Data Contract ก่อนกฎฉบับสุดท้าย - figure 2

Acceptance tests ก่อนซื้อซอฟต์แวร์

Test	Pass outcome
Duplicate ID	Reject/quarantine พร้อมเหตุผล
Split/merge	ย้อน parent, quantity, allocation, evidence ได้
Alternative material	เก็บ approval/effective time
Certificate revision	เก็บ old และแสดง current
Late supplier data	Controlled provisional state และ republish
Unit conversion	กฎและ rounding ทำซ้ำได้
Offline/retry	ส่งซ้ำโดยไม่ duplicate
การแก้ข้อมูลย้อนหลัง	เรียกดูทั้งค่าที่เคยแสดงและค่าที่แก้แล้วได้
Access change	มีผลทันทีและ audit log
API 4xx/5xx	Queue, alert, retry, manual recovery
Customs evidence	แสดงหลักฐานตามสิทธิ์และ registration proof
Archive/export	สร้าง ID, version, evidence link กลับได้

เตรียม DPP สำหรับเหล็ก: Data Contract ก่อนกฎฉบับสุดท้าย - figure 3

Business, quality, IT/OT, sustainability และ EU owner ต้องตัดสินร่วมกัน ระบบทำงานแต่ไม่มีคนอนุมัติ correction หรือ supplier ส่งหลักฐานไม่ทัน ถือว่ายังไม่ผ่าน

Checklist ผู้บริหารและขั้นต่อไป

ระบุสินค้า EU และ economic operator แล้วหรือไม่
กันงบ change เพราะ delegated act ยังไม่ประกาศหรือไม่
ติดตาม heat/cast, slab/billet, coil/plate และ split/merge ได้หรือไม่
ทุก candidate มี owner, source, version, time, evidence, approver หรือไม่
สัญญา supplier ครอบคลุม quality, correction, deadline, handover หรือไม่
แยก Registry index จาก detailed data และ export ได้ทั้งหมดหรือไม่
มี exception test และเจ้าของ final-rule gap assessment หรือไม่

ขั้นต่อไปคือทำ inventory หนึ่ง flow และ provisional data contract ก่อนเลือกแพลตฟอร์ม แล้วใช้ผล exception test กำหนด RFP และขอบเขตลงทุน

แบ่งการตัดสินใจลงทุนเป็นสามด่าน

ฝ่ายบริหารไม่จำเป็นต้องอนุมัติการติดตั้ง DPP ทั้งองค์กรในครั้งเดียว ด่านแรกคือความพร้อมของข้อมูล ด่านที่สองคือการพิสูจน์หนึ่งเส้นทางผลิตจริง และด่านที่สามคือการลงทุนขยายผล การกำหนดสิ่งส่งมอบและเงื่อนไขหยุดของแต่ละด่านทำให้เดินหน้าได้โดยไม่ถือว่ากฎเหล็กฉบับสุดท้ายที่ยังไม่ประกาศเป็นข้อเท็จจริงแน่นอน

ที่ ด่านความพร้อมข้อมูล ต้องตกลงเส้นทางสินค้าสู่ EU และผู้รับผิดชอบ สำหรับข้อมูลที่อาจต้องใช้ทุกตัว ให้ระบุแหล่งข้อมูลหลัก เจ้าของ revision และ effective time ช่องว่างสำคัญต้องจำแนกว่า จะขอผ่านสัญญา supplier จะสร้างบันทึกใหม่ในโรงงาน หรือจะรอการตัดสินจากกฎสุดท้าย การผ่านด่านนี้ไม่ได้แปลว่าข้อมูลครบทั้งหมด แต่หมายถึงมองเห็นช่องว่างและผู้รับผิดชอบการจัดหา

ที่ ด่านพิสูจน์หนึ่งผลิตภัณฑ์ ใช้ heat หรือวัตถุดิบจริงเชื่อมผ่านการแปรรูป การส่งมอบ certificate การแสดงภายนอก และหลักฐาน Registry ทดสอบ split, merge, correction, late arrival, access change และ API failure แยกให้ได้ว่าความล้มเหลวมาจากข้อมูล กระบวนการทำงาน supplier หรือฟังก์ชันผลิตภัณฑ์ แล้วประเมินค่า configuration การแก้สัญญา development หรือการลด scope

ที่ ด่านลงทุนขยายผล ให้ประเมินปริมาณงานเมื่อเพิ่มผลิตภัณฑ์ โรงงาน และ supplier ไม่ดูเพียงจำนวน registration ต่อเดือน แต่รวมคิวรอหลักฐาน อัตรา correction เวลาการอนุมัติด้วยคน retry คำถาม access request และการอบรม supplier เงื่อนไขขยายควรมี SLA จัดการ exception กำลังคนรับผิดชอบ และความสามารถสร้างตัวอย่าง audit กลับมาได้

ด่าน	สิ่งส่งมอบให้ฝ่ายบริหาร	เงื่อนไขไปต่อ	เงื่อนไขพักหรือย้อนกลับ
ความพร้อมข้อมูล	Role map, provisional contract, รายการ source/gap	ตกลง owner และทางได้มาของข้อมูลสำคัญ	EU responsibility หรือสิทธิใช้หลักฐานยังไม่ตกลง
พิสูจน์หนึ่งผลิตภัณฑ์	Genealogy, DPP view, registration proof, exception result	ประมวลผล exception สำคัญพร้อมประวัติครบ	Correction ลบประวัติ, ใช้ ID ซ้ำ หรือ export ไม่ได้
ลงทุนขยายผล	Scope, ปริมาณงาน, ค่าใช้จ่าย, change plan	อนุมัติคน SLA migration และ exit term	ไม่มีงบหรือสถาปัตยกรรมรองรับส่วนต่างกฎสุดท้าย

การติดตามกฎต้องอยู่ในโครงการ กำหนดผู้ตรวจ European Commission, EUR-Lex และ JRC/Product Bureau ความถี่ เวทีตัดสิน และ change register เมื่อใช้ Q4 2026 หรือช่วงเปลี่ยนผ่าน 18 เดือนในแผน ให้ระบุว่าเป็น “indicative” พร้อมวันที่ดึงข้อมูล และไม่ใช้เป็นวันผลิตหรือวันสัญญาที่ตายตัว

การวินิจฉัยการใช้กฎและความหมายทางกฎหมายเป็นหน้าที่ผู้เชี่ยวชาญด้านกฎ/กฎหมายร่วมกับ economic operator ฝั่ง EU ทีม IT/OT และ quality มีหน้าที่ให้หลักฐาน ประวัติ version และผล test ที่ทำซ้ำได้ ไม่ใช่ใช้การตั้งค่าระบบแทนคำวินิจฉัยทางกฎหมาย

ขยายเป็นขั้นตามคุณภาพข้อมูลและความรับผิดชอบการปฏิบัติงาน เริ่มให้การอนุมัตินิ่งที่หนึ่งโรงงาน/หนึ่ง flow ต่อด้วยผู้แปรรูปและ supplier แล้วจึงขยายงาน registration/access ฝั่ง EU การแปลงทุกผลิตภัณฑ์ขณะที่กฎยังชั่วคราวจะเพิ่มงานแก้ แต่ฐาน genealogy/evidence ที่ดีนำกลับใช้ได้เมื่อ field สุดท้ายเพิ่มหรือลด

FAQ

โรงงานไทยต้องเตรียม DPP เหล็กหรือไม่?

ไม่ได้ตัดสินจากประเทศอย่างเดียว ต้องดูว่าสินค้าเข้าสู่ตลาด EU หรือไม่ บทบาทใน chain และ delegated act ในอนาคต แม้ EU operator รับผิดชอบหลัก ผู้ขายไทยอาจต้องส่งข้อมูลและหลักฐานตามสัญญา

ฟิลด์ DPP เหล็กสรุปแล้วหรือยัง?

ยัง ESPR ใช้แล้ว แต่ delegated act และ final data list ของเหล็กยังไม่ประกาศ Commission/JRC เป็นข้อมูลเตรียม ไม่ใช่รายการบังคับ

Registry API เก็บข้อมูลทั้งหมดหรือไม่?

ไม่ Registry เป็น index ของ identifier, registration และ high-level metadata ส่วนข้อมูลละเอียดกระจายอยู่ภายนอก

ระดับเป็น model, batch หรือ item?

ยังไม่สรุป จึงควรเตรียม genealogy ที่เชื่อม heat/cast, slab/billet, coil/plate และ shipment ได้หลายระดับ

SME เริ่มอย่างไร?

เลือกหนึ่งสินค้า EU ทำตาราง role, ID, certificate, owner, correction จาก ERP, spreadsheet และ PDF แล้วแก้ gap ด้วย supplier data contract

ก่อนซื้อ software ควรทดสอบอะไร?

ทดสอบ duplicate ID, split/merge, certificate revision, late data, unit conversion, access change, API outage, history และ full export

สรุป: สร้างฐานหลักฐานที่ปรับได้เมื่อกฎสุดท้ายมา

การเตรียมเหล็ก DPP ตอนนี้คือแยกความรับผิดชอบ EU กับหลักฐาน supplier เชื่อม factory genealogy, material certificate, sustainability evidence และ external DPP/Registry ด้วย ID และ version ที่ตรวจสอบย้อนหลังได้ โดยไม่อ้างว่าฟิลด์ชั่วคราวเป็นกฎหมาย

TOMAS TECH สนับสนุนผู้ผลิต ผู้แปรรูป เทรดเดอร์ และผู้ผลิตชิ้นส่วนในไทย/อาเซียนด้าน discovery, source mapping, RFP, DPP/Registry PoC และ acceptance test เราไม่รับประกัน compliance แต่ช่วยเปลี่ยนประเด็นที่ยังไม่ชัดให้เป็นหลักฐานสำหรับการตัดสินใจลงทุนได้ ติดต่อเรา