Requisition (SPB)

Modul: spb, berlabel Requisition di menu. Dokumen pertama dalam rantai procurement: permintaan untuk membeli barang atau jasa, dengan item-itemnya, yang disetujui lewat Document Routing lalu menjadi sumber RFQ dan Purchase Order.

Cara halaman ini diverifikasi

Ditulis dari master pada 2026-09-06 dan dibandingkan dengan big five di hari yang sama. Tidak ada halaman sebelumnya. Ini peta modul, bukan penelusuran baris per baris: modul ini punya 31 file dan sekitar 520 pemanggilan database.

Posisinya di rantai

Requisition (spb)  →  RFQ (rfq)  →  Purchase Order (purchase_order)
                                        ↓
                          Expediting (expedite)  →  Goods Received Report (mrr)

Setiap langkah adalah modul terpisah dengan bentuk yang sama: baris header, tabel item, persetujuan lewat routing, PDF yang dibuat otomatis dan diarsipkan di Procurement Documents. Dokumen hilir menunjuk balik: ts_rfq.spb_id dan ts_purchase_order.spb_id. Requisition menyimpan ringkasan apa yang dibuat darinya di list_rfq_number, list_rfq_status, list_powosc_number dan list_powosc_status.

Siapa yang punya

Rantai procurement terpasang lewat seed, tetapi dibaca pada 2026-09-06 dari database QA hanya situs master (inact-mysql, inact-psql, inact-sqlsrv) dan JOTRE yang menyalakan spb, rfq, purchase_order, procurement_documents, bid_evaluation, mrr, expedite dan vendor_management. Jadestone, Medco, Timas dan KTP hanya menjalankan modul pengelolaan dokumen. Lihat Perbedaan antar instance.

Datanya

Tabel	Berisi
ts_spb	header: spb_no, spb_date, project_id, vendor_id, client_id, person_in_charge, person_prepare_by, deliver_to_id, delivery_address, request_item, syarat (incoterms_id, payment_terms_id, packing_type_id, mode_transport_id, currency_code), field form cetak (no_form, rev_form, tanggal_form, subyek, lokasi_kerja, dibuat_oleh, diketahui_oleh, authorization_by), status persetujuan, revisi, daftar hilir, type_module, client_requisition_ref, department_org_function
ts_spb_item	item yang diminta
ts_spb_bid	penawaran vendor yang dicatat terhadap requisition, dipakai layar tabulasi
ts_spb_doc	dokumen terlampir
ts_file_reference	PDF hasil dan unggahan

Layarnya

spb.php dengan spb_browse.htm: grid requisition per project, form header (spb_main_form.htm), grid item, dokumen terlampir, pencarian, pratinjau form cetak (spb_preview.htm) dan dialog kirim lewat email. Toolbar: New, Edit, Delete, Cancel, Print, Export, Import from XLS, Help. Form header punya revisi dan aksi Submit for approval.

Persetujuan

Submit mem-POST routing dengan 'rout_group_mod' => 'procurement' (spb_handler_post.php). Itu membuat Document Routing biasa yang baris inbox-nya membawa routing_procure = 1, jadi alur Sign Off berlaku dengan varian procurement dari form respons. Header melacaknya di submit_approval (sudah disubmit), status_approval (hasil), fg_approval, approve_by dan submit_approval_date.

Saat routing selesai, RoutingProcurementUc di modules/routing/ memanggil class modul spb.class.php, yang mengimplementasikan RoutingProcurementInterface (contracts/routing_procurement.interfaces.php):

1. ProcessProcurement(): memperbarui status header.
2. GenerateDocument(): merender PDF requisition lewat proses cetak dan print flavour procurement (procure_print_template_code).
3. StoreDocumentsToProcumentDocs(): mendaftarkan PDF di Procurement Documents (ts_procurement_documents, ts_map_procurement_doc_file) di folder yang dibuat per requisition di ts_procurement_doc_library.
4. NotificationProcurement(): memberi tahu.

Interface yang sama diimplementasikan class RFQ, bid, Purchase Order dan Goods Received.

Yang masih memakai helper legacy

Dihitung pada 2026-09-06 pada baris aktif: 365 pemanggilan iw_mysql_query() berbanding 157 pemakaian $pdo. Per file:

Jalur	Keadaan di tempat helper legacy melempar exception
spb.php, spb_handler_main_form.php, spb_print_process.php, spb_preview.php	memakai $pdo, bekerja
spb_handler_form.php (75 legacy, 44 PDO) dan spb_handler_post.php (59 legacy, 84 PDO)	campuran; sebagian pemuatan form dan aksi mati
spb.inc.php (14 legacy, 0 PDO)	helper mati di tempat dicapai
tabulasi penawaran (spb_handler_tabulation_*, spb_handler__tabulation_form.php)	mati
kirim lewat email (spb_sendmail_*)	mati
upload multi-file (spb_multiupload_upload.php)	mati
spb_handler_form_041214.php (119 legacy)	backup bertanggal dari handler form, tidak dirutekan

Di master ini konsisten dengan modul yang dipakai di situs QA hanya untuk jalur PDO. Siapa pun yang mengambil tiket requisition sebaiknya berharap harus memindahkan jalur yang disentuh ke $pdo lebih dulu.

Hal yang perlu diwaspadai

• Form-nya punya dua nama. Menu dan grid menyebut Requisition; kode, tabel dan form cetak menyebut SPB dan memakai nama field Indonesia (subyek, lokasi_kerja, dibuat_oleh).
• File _041214 adalah backup, bukan handler alternatif. Abaikan saat menelusuri.
• Penomoran per tahun dan per tipe (increment_spb, increment_spb_a, increment_spb_t, years), dengan nomor sementara (proc_number_temp) sampai dokumen disimpan.
• is_used menandai requisition yang sudah dipakai dokumen hilir.

Perbedaan antar instance

Diperiksa pada 2026-09-06.

Instance	Perbedaan
JOTRE	Satu-satunya instance klien dengan rantai yang menyala. Menambah spb_ajax.php, spb_ajax_direct.php dan spb_handler_ajax_form.php, dan spb_handler_post.php-nya mendorong requisition yang disetujui ke sistem akuntansi Accurate (lihat cron accurate_* di halaman JOTRE). Jalur legacy di atas bekerja di sana.
Jadestone, Medco, Timas	Kode modul ada tetapi tidak terpasang di database QA mereka.

Terkait

• RFQ dan Purchase Order: apa yang menjadi hasil sebuah requisition.
• Sign Off: mekanisme persetujuan.
• Reporting: Procurement Status Report membaca rantai ini.