Document Routing

Modul: routing, entri menu Document Routing di bawah DMS. Sebuah routing adalah satu revisi dokumen yang dikirim ke daftar orang secara berurutan, masing-masing dengan action yang harus dilakukan. Layar ini tempat routing dibuat, diterima, dijawab dan diaudit. Tiap tab punya halamannya sendiri (lihat tabel di bawah). Kode action routing ada di Action Indicated di halaman ini.

Cara halaman ini diverifikasi

Ditulis dari kode master pada 2026-09-06, dengan layar dibuka di inact-ktp.eris.place (snapshot produksi KTP, project VDRL, user Pangesti Risang Ardyanseto, seorang Document Controller). Template KTP lebih lama dan tidak punya tab Ready to Return maupun Transmittal Out; enam tab lainnya sama dengan master. Membuka form New membuat draft routing 7351 di snapshot itu; sudah dihapus lagi dari tab Drafts.

Document Routing, tab Inbox: routing yang menunggu user ini, dikelompokkan menurut action yang sudah diambil · click to enlarge

Tab-tabnya

routing_browse.htm mendeklarasikan delapan tab. Tiga ditampilkan ke semua orang; sisanya bergantung pada group user, privilege atau setting (routing_header.inc.php dan pemanggilan hideTab / showTab di template):

Tab	Isinya	Query, dari handler	Siapa yang melihat
Inbox	routing yang user-nya penerima dan routing-nya ada di inbox mereka	routing_handler_inbox.php: rout_have_send = 1 AND rout_is_oninbox = 1, rt.resource_id di resource user, project saat ini. Dikelompokkan per Action Taken: Open, re-Route, Return, Sign Off, Closed Without Action	semua orang
Sent Items	routing yang dibuat dan dikirim user	routing_handler_outbox_audit_drafts.php, outbox: rout_author = saya AND rout_have_send = 1. Dikelompokkan Open / Close	semua orang
Audit	setiap routing terkirim di project, siapa pun pengirimnya	file yang sama, audit: rout_have_send = 1 AND rout_is_oninbox = 1, filter project. Dikelompokkan per project, Open / Close, lalu per tanggal	group admin, Document Controller, Procurement Controll ($group_routing_auditor)
Ready to Return	routing yang approver-nya sudah menjawab dan menunggu transmittal return	routing_handler_ready_to_return.php	enable_return_on_audit = 1 dan privilege ready_to_return pada routing
Drafts	routing yang dibuat tetapi belum di-submit	drafts: rout_author = saya AND rout_have_send = 0	semua orang
Comment Sheet	file ber-comment yang terlampir di routing	routing_handler_commentsheet.php: baris ts_map_routing_file dengan rout_commented_by	tiga group yang sama dengan Audit
Completed	routing yang sudah sampai akhir	routing_handler_completed.php. Dikelompokkan Approved / Rejected menurut jawaban approver	semua orang
Transmittal Out	file yang dikirim keluar dalam transmittal batch	routing_handler_transmittal_out.php: ts_transmittal_out_files	kalau batch_routing_enabled menyala, atau consolidated routing view menyala untuk user

Kolom grid sama di semua tab, dengan perbedaan kecil: Inbox menampilkan Doc Number, Title, Rev, Rev Date, Issued Status, Originator, Author, Action, Due Date, Sign Off Date, Routing Status; Sent Items, Audit dan Drafts menampilkan Author, Doc Number, Title, Rev, Rev Date, Issued Status, Originator, Return Code, Routing Status; Completed menambah Closed By. Routing Status adalah teks langkah saat ini ("Reviewer to Action", "Completed").

Routing Slip

Setiap routing dibuka sebagai halaman Routing Slip di tab yang sama, dalam tiga bagian. View (dari Sent Items, Audit, Completed) hanya-baca; Edit dan Response membuka bagian yang boleh diubah user.

Routing Slip (View): Routing Detail dan grid Routing To · click to enlarge

Bagian Attachment: revisi dokumen dan file-nya, dengan Compare, Publish dan Unpublish · click to enlarge

Bagian	Isi	Tabel
Routing Detail	No, Author, Title, Date, Originating Company, Routing Type, Remarks, Transmittal Ref; blok invoicing (Invoice No, Amount, Currency, tanggal, Status) kalau routing type-nya invoice	ts_routing
Routing To	satu baris per penerima: Resource, User ID, Action Indicated, Sequence#, Start Date, Due Date, Action Taken, Response Date, Response, Comments, Remarks, Inbox Status	ts_map_routing_to
Attachment	revisi yang di-routing (rout_type = 1) dan file tambahan: Number, File, Title, Rev, Remarks, Upload By, Size; Compare, Publish, Unpublish	ts_map_routing_file, ts_file_explorer

Inbox Status adalah mesin sequence yang terlihat: Auto sent berarti sequence baris itu sudah tercapai dan routing ada di inbox orang itu; Not yet sent berarti sequence sebelumnya masih terbuka. Saat orang terakhir di sebuah sequence sign-off, sequence berikutnya dikirim (getRoutingToNextSequence), dan sign-off approver menutup routing (rout_status = 'close').

Membuat routing

Routing Slip (Add): draft-nya ada begitu form terbuka; Submit Routing mengirim sequence 1 · click to enlarge

New di Inbox, Sent Items atau Drafts membuka routing_add.htm dan langsung menyisipkan draft (rout_have_send = 0) dengan nomor routing berikutnya. Mengisi detail, menambah penerima di Routing To (New, Delete, Refresh) dan lampiran, lalu Submit Routing mengatur rout_have_send = 1, menandai baris sequence 1 rout_is_oninbox = 1, dan mengirim email ke mereka. Close tanpa submit meninggalkan draft di tab Drafts, tempat ia bisa diedit atau dihapus.

Sebagian besar routing tidak dibuat di sini. Langkah Upload di MDR membangunnya dari Distribution Matrix, itu sebabnya routing manual adalah pengecualian.

Action Indicated

Apa itu "Action Indicated"

Action Indicated adalah peran seorang penerima pada sebuah routing: apa yang diminta dari orang itu terhadap dokumen (Review, Approve, diberi tahu, memimpin, dan seterusnya). Ini atribut per penerima yang paling penting. Ia menentukan field respons mana yang tampil saat sign-off, bagaimana routing berurutan dan berakhir, anotasi dan stempel PDF mana yang boleh dipakai, dan notifikasi mana yang terkirim.

Setiap action punya tiga identitas, dipakai di tempat yang berbeda:

Identitas	Contoh	Dipakai di
action_id (angka)	9	ts_map_routing_to.rout_indicate, action penerima pada routing yang berjalan
action_matrix_type (satu huruf)	A	ts_matrix_rout.matrix_rout_action, action yang ditetapkan di matriks MDR
action_desc (label)	Approval	tampil di UI

Jadi matriks menyimpan huruf (misalnya A), sedangkan baris penerima menyimpan action_id numerik (misalnya '9'). Keduanya menunjuk ke baris ts_routing_action_indicated yang sama.

Action yang didukung

getRoutingActionIndicatedList() di reference_function.inc.php hanya mengembalikan action yang action_matrix_type-nya ada di $ACTION_CODE_FOR_ROUTING, sebuah konstanta kode di additional_global_variables.inc.php. Di master, Jadestone, JOTRE dan Timas isinya:

$ACTION_CODE_FOR_ROUTING = ["C", "S", "D", "R", "I", "A", "N"];

Medco menambah dua kode

Daftar Medco adalah ["C", "S", "D", "R", "I", "A", "N", "L", "W"]. L (Leader) dan W (Information Owner, action_id 17) ditawarkan untuk routing di sana dan tidak di tempat lain. Lihat Perbedaan antar instance.

Allowlist itu menghasilkan nilai-nilai berikut, dalam dua keluarga:

• Approval-type: A, D, C, S, dan di Medco L. Ini bisa mengisi Result Code saat sign-off, dan karena Result Code bisa berupa kode approve atau reject, action Approval-type bisa menolak dokumen. Itu ciri utamanya.
• Non-approval: R, I, N. Ini tidak bisa mengisi Result Code, jadi tidak bisa menolak. Mereka mencatat komentar (R, I) atau hanya diberi tahu (N).

action_id	action_desc	type matriks	Keluarga	rout_daysreview	Field respons yang tampil saat sign-off
9	Approval	A	Approval-type	0	Return Code + Next Expected Submission
12	Transmit	D	Approval-type	—	Return Code²
15	Checking	C	Approval-type	—	Return Code
16	Responsible	S	Approval-type	—	Return Code
11	Leader	L	Approval-type	1	Return Code¹. Hanya Medco yang memasukkannya ke allowlist.
8	Review	R	Non-approval	5	Comments / No Comments
5	Information	I	Non-approval	0	Comments / No Comments
14	Notify	N	Non-approval	0	tanpa respons inbox, lihat rules_action di bawah

Next Expected Submission hanya tampil untuk A (Approval). Tidak ada baris lain yang mencantumkannya: D/C/S/L hanya pernah mendapat Return Code. Di dalam A ada satu gerbang lagi: field itu disembunyikan untuk sisi non-owner, jadi praktiknya muncul untuk Approver milik project owner. Logika lengkapnya ada di Sign Off, kesimpulan Next Expected).

¹ Leader memakai Return Code standar. Di master dan Medco, L dilebur ke kedua blok approval di form respons (routing_resp.htm), jadi Leader melihat field Return Code yang sama dengan action Approval-type lain. Tidak ada "Leader Return Code" terpisah. Baris #return_code_leader yang lama menulis kolom ts_map_routing_to.rout_result_code yang sama dengan daftar opsi yang identik. Di Jadestone, JOTRE dan Timas baris return_code_leader yang yatim masih ada di template sebagai markup mati.

² D (Transmit) bukan sekadar baris approval. Ia adalah checkpoint Document Consolidation (DocCon) dan berperilaku berbeda dari action Approval-type lain. Lihat bagian D.

Logika gating field berdasarkan tipe matriks didokumentasikan di Sign Off, Field respons per peran).

Tidak didukung, atau legacy

Baris-baris ini ada di ts_routing_action_indicated tetapi tidak ada di $ACTION_CODE_FOR_ROUTING, jadi tidak ditawarkan untuk routing:

• O, Originator (id 13): punya tipe matriks tetapi dikeluarkan dari allowlist saat ini. Dulu ada di daftar lama yang dikomentari.
• L, Leader (id 11), di semua tempat kecuali Medco. Kode sign-off masih menangani rout_indicate = 11, dan import matriks menulis huruf apa pun yang ada di template, jadi baris Leader masih bisa muncul di routing. Hanya saja tidak ditawarkan oleh fungsi daftar.
• Tanpa tipe matriks sama sekali, disposisi legacy non-routing: Action (1), File (2), See Me (3), Comments (4), Note And Return (6), Copy (7), Endorse (10).

Didukung tidak sama dengan dipakai

Allowlist adalah apa yang sistem izinkan. Action mana yang benar-benar dipakai sebuah project ditentukan oleh data template matriks MDR-nya. Di banyak instalasi matriks hanya memakai A (Approval) dan L (Leader) dari keluarga Approval-type, ditambah R dan I. Periksa ts_matrix_rout.matrix_rout_action untuk project kamu.

D (Transmit) adalah checkpoint Document Consolidation (DocCon)

D adalah yang berbeda sendiri di antara action Approval-type. Ia sebenarnya bukan peran reviewer. Ia adalah posisi di rantai routing: titik Document Consolidation (DocCon) yang memisahkan sisi internal routing dari sisi eksternal. Hampir semua hal khusus tentang D berasal dari situ. Beberapa jalur D yang terlihat masuk akal adalah kode mati dan disebut di bawah supaya tidak ada yang menemukannya kembali sebagai fitur.

Ia menentukan batas internal / eksternal

getPositionResourceMatrix() di routing.inc.php mencatat indeks matriks baris D sebagai doccon_postion dan menghitung baris D sebagai countDoccon. checkIsInternalApprover() lalu memperlakukan responder sebagai internal kalau posisinya di atau sebelum doccon_postion dan eksternal kalau sesudahnya. D sendiri ada di posisi itu. Pemisahan ini menentukan cabang finalize mana yang diambil sebuah sign-off di routing_handler_post.php. Kedua fungsi ada di semua big five.

Ia membatasi penempatan di matriks, ditegakkan saat upload

Kalau matriks berisi D, handler upload yang aktif documents_master_multiupload_upload.php menegakkan:

• D harus di atau sebelum A. D yang diurutkan setelah Approver ditolak.
• Semua baris D di satu sequence, semua baris A di satu sequence.
• Approver adalah langkah terakhir. Tidak ada yang diurutkan setelahnya.

Tidak ada action lain yang memicu aturan penempatan. Salinan kedua aturan ini ada di handler layar edit matriks, tetapi itu ada di balik tombol toolbar yang dikomentari. Penegakan yang aktif adalah yang di upload.

Timas tidak punya aturan D saat upload

Pemeriksaan docconFound tidak ada di handler upload Timas. Empat lainnya punya.

Kehadirannya menunda auto-publish

Juga saat upload: konsolidasi library dan auto-publish hanya berjalan if (!$docconFound). D di matriks berarti publikasi menunggu langkah konsolidasi, bukan terjadi saat upload.

Pada sign-off normal ia memublikasikan dokumen plus transmittal keluar

Di jalur finalize yang aktif, saat D sign-off dan enable_autopublish = 1 dan enable_transmittal = 1 dan routing-nya issued_matrix = 'external', cabang D di routing_handler_post.php:

1. memasukkan dokumen ke register (ts_documents), lalu
2. membuat Transmittal("out"), transmittal original / submission, dan mengarsipkannya ke dokumen (ts_map_doc_file plus doc_submission_number). Ia dipublikasikan bersama dokumen.

Penamaan "in / out" tertukar. Baca dengan teliti sebelum memercayai label.

Transmittal yang dibuat D bertipe "out", submission. Cabang Approver eksternal membuat salinan bertipe "in", yang sebenarnya adalah return. Hanya "in" yang mendapat sufiks (R), di routing_handler_transmittal.class.php. Kolom tujuannya juga tertukar: return ("in") menulis ts_documents.outgoing_transmittal_no, sedangkan submission ("out") menulis ts_documents.doc_submission_number. Bahkan string nomor submission diakhiri literal -IN. Jadi transmittal yang terlihat masuk di data bisa jadi adalah yang keluar milik D. Dalam istilah kode: D = keluar / submission; Approver = return (R).

Batch routing mengubah cara D merespons

Semua di atas adalah perilaku non-batch, di mana D sign-off lewat dialog Response normal dengan Return Code-nya dan tanpa Next Expected. Di project batch-routing (ts_projects.batch_routing = 1) pada routing external, D dikeluarkan dari sign-off normal ke alur External Transmission khusus: tombol inbox transmit_dc dan sebuah redirect di js/routing.js. Baris-barisnya ditandatangani otomatis oleh setAutoDCSignoff() di routing.inc.php. Lihat Sign Off) untuk kedua mode berdampingan.

Kode D yang mati. Jangan temukan kembali ini sebagai fitur.

• Penegakan peran dcc dan stempel di sisi server. $rulesPersonAs = 'dcc' di routing.php dan pemeriksaan stempel wajib rout_indicate == 12 di sebelahnya dihitung, tetapi pemakainya seluruhnya dikomentari. Tidak ada yang menegakkannya.
• Dua blok transmittal lama di routing_handler_post.php ada di dalam if (false), jadi mati. Pembuatan transmittal yang aktif adalah pasangan D dan Approver eksternal di atas. Kelima fork membawa tiga blok if (false) di file ini.

Aturan perilaku per action: rules_action

Tidak diandalkan. Praktis tidak bekerja untuk saat ini.

Blob rules_action dibaca di sisi klien, tetapi penegakan di sisi server belum terhubung. Kode yang seharusnya bertindak atasnya (pemeriksaan dcc dan peran serta pemeriksaan stempel wajib di routing.php) dikomentari, dan L (Leader) punya rules_action = NULL seluruhnya. Anggap tabel di bawah sebagai maksud desain, bukan perilaku runtime yang terjamin.

Setiap action yang didukung membawa blob JSON rules_action yang menyatakan cara action itu berperilaku. v2 tidak punya kolom ini. Ia dibaca oleh getActionRules.php dan getUserLevel.php, dan di-seed oleh DefaultTsRoutingActionIndicated.php. Medco juga membawa skrip sekali jalan, migrations/scripts/MIG-013_routing_action_rules.php, yang tidak dimiliki fork lain.

JSON-nya punya tiga area:

• pdf_viewer: anotasi dan stempel mana yang boleh dipakai peran itu, dan izin create / edit / delete / update di PDF viewer.
• notification: email mana yang terkirim (rejected, doc_con_issued, doc_return).
• routing: aturan alur kerja di bawah, plus daftar stempel yang diizinkan dan dilarang per hasil (approved / rejected).

Flag utama routing.* per action, dari seed:

Action	received_in_inbox	bypass_on_overdue	end_routing	return_code
Approval (A)	ya	ya	ya	ya
Transmit (D)	ya	—	ya	—
Checking (C)	ya	ya	ya	—
Responsible (S)	ya	—	ya	—
Review (R)	ya	—	—	ya
Information (I)	ya	ya	—	—
Notify (N)	tidak	—	—	—
Leader (L)	rules_action NULL

Artinya:

• received_in_inbox: apakah action masuk ke inbox penerima. Notify (N) false, jadi ia memberi tahu tanpa membuat tugas inbox.
• bypass_on_overdue: penerima bisa dilewati otomatis saat overdue.
• end_routing: menyelesaikan action ini bisa mengakhiri routing (action Approval-type A/D/C/S).
• return_code: kode return atau result berlaku. JSON menandai Approval dan Review; form merender input result-code untuk semua action Approval-type tetapi tidak untuk R atau I. Ketidaksesuaian kecil antara JSON dan form.

Di mana Action Indicated dipakai

• Matriks MDR / Upload: import matriks menulis matrix_rout_action (huruf) per resource. Upload mengubah matriks menjadi baris ts_map_routing_to per penerima, mengurutkan sequence sebagian berdasarkan action. Lihat Upload.
• Sign Off: rout_indicate (action_id) menentukan perilaku per peran dan gating field di form respons. Rincian lengkap di Sign Off, Perilaku per Action Indicated).
• PDF viewer: rules_action.pdf_viewer seharusnya mengontrol anotasi dan stempel yang diizinkan, tetapi penegakan sisi server dikomentari. Anggap sebagai maksud desain.
• Notifikasi: rules_action.notification menyatakan email mana yang terkirim, tetapi bagian dari subsistem yang sama yang tidak ditegakkan.

Tabel database

Tabel	Kolom	Berisi
ts_routing_action_indicated	action_id, action_desc, action_matrix_type, rout_daysreview, rules_action	definisi referensi
ts_matrix_rout	matrix_rout_action	huruf action yang ditetapkan di matriks MDR
ts_map_routing_to	rout_indicate	action_id penerima pada routing yang berjalan

Ada varian _corr (ts_routing_action_indicated_corr, dan rout_indicate bertipe char(1) di ts_map_routing_to_corr) yang dipakai alur routing correspondence. Routing dokumen utama memakai tabel di atas.

Hal yang perlu diwaspadai

• Tiga identitas untuk satu action (id / huruf / label). Matriks memakai huruf, baris penerima memakai id. Mudah tertukar.
• Didukung (allowlist), dipakai (data matriks) dan didefinisikan (tabel) adalah tiga himpunan yang berbeda.
• O (Originator) didefinisikan tetapi tidak ada di allowlist routing. L (Leader) tidak punya JSON rules_action, dan di luar Medco juga tidak ada di allowlist.
• D (Transmit) bukan baris approval biasa. Ia checkpoint Document Consolidation dengan aturan penempatan, penundaan publish, pembuatan transmittal dan alur khusus batch-routing. Memperlakukannya seperti action Approval-type biasa akan menyesatkan.
• Allowlist adalah konstanta kode, bukan setting database atau admin. Mengubah himpunan yang didukung adalah perubahan kode.

Perbedaan antar instance (Action Indicated)

Diperiksa pada 2026-09-06.

Instance	Perbedaan
Medco	$ACTION_CODE_FOR_ROUTING menambah L (Leader) dan W (Information Owner, action_id 17, dengan rules_action-nya sendiri). Form respons punya cabang Information Owner tambahan yang bergantung pada resp_is_terminal. Membawa skrip sekali jalan migrations/scripts/MIG-013_routing_action_rules.php.
Jadestone	Form respons masih menentukan gating field dari tipe matriks seperti master, tetapi menyimpan baris return_code_leader yang mati di template.
JOTRE	Form respons menentukan field dari label action (`a == 'Approval'
Timas	Form yang sama dengan JOTRE. Tidak ada aturan docconFound saat upload, jadi batasan penempatan D dan penundaan publish tidak ada di sana.

Master dan Jadestone sama dalam allowlist, seed dan mekanisme D.

Hal yang perlu diwaspadai

• Audit dan Comment Sheet dibatasi berdasarkan nama group, bukan privilege: group harus bernama admin, Document Controller atau Procurement Controll (sic). Group Document Controller dengan nama lain tidak pernah melihat Audit.
• New membuat baris sebelum apa pun diketik. Menutup form meninggalkan draft; user yang klik New hanya untuk melihat berakhir dengan draft kosong.
• Inbox per resource, bukan per person. Orang dengan dua resource melihat keduanya; orang tanpa resource tidak melihat apa-apa.
• Sent Items dan Audit menyembunyikan routing yang sudah keluar dari semua inbox (rout_is_oninbox = 1 di kedua query), aturan yang sama yang dipakai MDR Report.
• Visibilitas tab diputuskan saat halaman dimuat. Menyalakan enable_return_on_audit butuh reload untuk menampilkan Ready to Return.

Perbedaan antar instance

Diperiksa 2026-09-06.

Instance	Perbedaan
KTP	Template tanpa tab Ready to Return dan Transmittal Out; Comment Sheet ada tetapi group-nya tidak melihatnya.
JOTRE, Timas	Tanpa tombol Return; form response berbasis label dan aturan finalize approver yang dijelaskan di Return).
Medco	Report Comment Summary, action W dan pengerjaan ulang multi-process yang dijelaskan di Sign Off).
Jadestone	Seperti master.

Terkait

• Action Indicated: kode action routing.
• Master Doc. Register: asal routing.
• Routing Overdue: report atas ts_map_routing_to.