Odoo POS: Kustomisasi Aturan Merge Order Line via `_can_be_merged_with`
Diposting pada 14 Apr 2026, 10:18
Halo teman-teman praktisi Odoo di sini! Saya Lestari dari tim IT di sebuah perusahaan retail yang pakai Odoo ERP.
Saat ini, kami lagi optimalisasi penggunaan Odoo POS, terutama untuk alur transaksi yang cukup dinamis. Kami menemukan behavior standar Odoo POS itu kan akan otomatis merge order line yang punya produk, harga, dan diskon yang sama. Nah, ini diatur via method `_can_be_merged_with` di backend-nya.
Kondisinya begini, kami punya beberapa jenis produk yang, meskipun secara produk ID, harga, dan diskonnya sama, tapi ada kebutuhan untuk tidak di-merge dalam kondisi tertentu. Misalnya, kami menambahkan field custom di order line (semacam nomor seri atau catatan khusus per item) yang jika nilainya berbeda, maka order line tersebut tidak boleh di-merge, meskipun yang lain sama. Atau sebaliknya, kami butuh aturan merge yang lebih fleksibel dari standar Odoo.
Ada teman-teman di sini yang sudah pernah kustomisasi method `_can_be_merged_with` ini di modul Odoo POS? Kira-kira best practice-nya seperti apa ya? Apakah ada trik atau hal-hal yang perlu diperhatikan saat override method ini agar tidak mengganggu fungsi POS yang lain? Mungkin juga ada panduan atau insight untuk pendekatan yang paling aman dan efisien.
Makasih banyak sebelumnya atas pencerahannya!
Balasan (1)
Halo Mba Lestari,
Wah, ini pertanyaan yang menarik dan memang sering jadi kebutuhan di skenario retail yang dinamis! Senang sekali Mba Lestari dan tim sudah sampai tahap optimalisasi Odoo POS seperti ini.
Mba Lestari benar sekali, behavior standar Odoo POS itu akan otomatis me-merge order line yang memiliki produk, harga, dan diskon yang sama, dan logika ini memang diatur via method `_can_be_merged_with` di model `pos.order.line` di sisi backend Odoo. Kebutuhan untuk memiliki aturan merge yang lebih granular, misalnya berdasarkan field custom seperti nomor seri atau catatan khusus per item, adalah hal yang sangat relevan.
Saya bisa konfirmasi bahwa kustomisasi method `_can_be_merged_with` ini adalah pendekatan yang tepat dan memang memungkinkan. Berikut adalah best practice dan hal-hal yang perlu diperhatikan:
Pendekatan Kustomisasi: Extend Method `_can_be_merged_with`
Alih-alih meng-override sepenuhnya, pendekatan terbaik adalah dengan meng-extend method ini menggunakan mekanisme `super()` Python. Ini memastikan bahwa logika standar Odoo tetap terpanggil, dan kita hanya menambahkan kondisi kustom di atasnya. Dengan begitu, kita meminimalkan risiko mengganggu fungsi lain dan membuat kode lebih tahan terhadap upgrade di masa mendatang.
1. Buat Modul Kustom: Pastikan Mba Lestari memiliki modul Odoo kustom (misalnya, `pos_custom_merge_rules`) yang bergantung pada modul `point_of_sale`.
2. Tambahkan Field Kustom: Jika Mba Lestari ingin menggunakan field kustom (seperti nomor seri atau catatan), pastikan field tersebut sudah ditambahkan ke model `pos.order.line`. Misalnya, tambahkan field `x_serial_number` atau `x_special_note` bertipe `Char` ke model `pos.order.line` melalui modul kustom Anda. Ini akan menjadi basis perbandingan Anda.
3. Implementasi Logika di `_can_be_merged_with`:
Di modul kustom Mba Lestari, extend model `pos.order.line`.
Di dalam method `_can_be_merged_with`, panggil terlebih dahulu `super()` dari method ini. Ini akan menjalankan logika merge standar Odoo (cek produk, harga, diskon).
Jika hasil dari `super()` adalah `False` (artinya Odoo standar sudah memutuskan untuk tidak me-merge), maka method kustom Anda juga harus mengembalikan `False`.
Namun, jika hasil dari `super()` adalah `True` (artinya Odoo standar mengizinkan merge), di sinilah logika kustom Mba Lestari masuk. Mba Lestari bisa menambahkan kondisi tambahan:
Bandingkan nilai field kustom (misalnya, `x_serial_number` atau `x_special_note`) antara order line yang sedang diperiksa dengan order line yang sudah ada.
Jika nilai field kustom ini berbeda, meskipun produk, harga, dan diskonnya sama, maka method kustom Anda harus mengembalikan `False` untuk mencegah merge.
Jika nilai field kustom ini sama, barulah method kustom Anda mengembalikan `True`, mengizinkan merge.
Ini akan memastikan bahwa sebuah order line hanya di-merge jika semua kondisi standar Odoo terpenuhi DAN semua kondisi kustom yang Mba Lestari tetapkan juga terpenuhi.
Hal-hal yang Perlu Diperhatikan:
Integrasi Frontend POS (JavaScript): Jika field kustom seperti nomor seri atau catatan ini diinput langsung dari antarmuka POS oleh kasir, Mba Lestari perlu memastikan bahwa field tersebut juga ditambahkan dan di-set nilainya di objek `Orderline` di JavaScript POS frontend. Logika merge di frontend Odoo (di file JavaScript seperti `models.js` atau `order.js`) mungkin juga perlu disesuaikan agar menampilkan behavior yang konsisten dengan backend. Jika tidak disesuaikan di frontend, kasir mungkin melihat dua item terpisah di layar POS, tetapi di backend mereka tetap di-merge (atau sebaliknya), yang bisa membingungkan. Idealnya, frontend juga mengikuti aturan merge yang baru.
Performa: Pastikan logika kustom yang ditambahkan tidak terlalu kompleks, karena method ini bisa sering dipanggil saat transaksi POS berlangsung. Perbandingan nilai field sederhana umumnya tidak akan memengaruhi performa secara signifikan.
Database Schema: Ingat untuk meng-update database Odoo setelah menambahkan field kustom baru ke model `pos.order.line`.
Pengujian Menyeluruh: Lakukan pengujian yang sangat detail untuk berbagai skenario:
Produk yang sama, harga, diskon sama, field kustom sama -> harus di-merge.
Produk yang sama, harga, diskon sama, field kustom berbeda -> tidak boleh di-merge.
Produk berbeda -> tidak di-merge (ini akan dihandle oleh `super()`).
Produk yang sama, harga berbeda -> tidak di-merge (ini akan dihandle oleh `super()`).
Fleksibilitas Aturan Merge: Untuk skenario "sebaliknya, kami butuh aturan merge yang lebih fleksibel dari standar Odoo", ini agak lebih kompleks. Jika Mba Lestari ingin memaksa merge item yang standar Odoo-nya tidak di-merge (misalnya karena diskon berbeda tapi ingin di-merge), ini berarti Mba Lestari perlu sedikit mengubah hasil dari `super()`. Namun, ini tidak disarankan sebagai best practice karena berpotensi melanggar integritas data standar Odoo, kecuali jika Mba Lestari sangat yakin dengan implikasinya dan sudah memikirkan semua kasus ekstrimnya. Umumnya, kita menambahkan kondisi untuk mencegah merge lebih lanjut, bukan untuk memaksa merge.
Dengan pendekatan extend method dan perhatian pada poin-poin di atas, Mba Lestari bisa mengkustomisasi perilaku merge order line di Odoo POS dengan aman dan efisien.
Semoga pencerahannya membantu Mba Lestari dan tim! Semangat terus optimalisasinya!
Wah, ini pertanyaan yang menarik dan memang sering jadi kebutuhan di skenario retail yang dinamis! Senang sekali Mba Lestari dan tim sudah sampai tahap optimalisasi Odoo POS seperti ini.
Mba Lestari benar sekali, behavior standar Odoo POS itu akan otomatis me-merge order line yang memiliki produk, harga, dan diskon yang sama, dan logika ini memang diatur via method `_can_be_merged_with` di model `pos.order.line` di sisi backend Odoo. Kebutuhan untuk memiliki aturan merge yang lebih granular, misalnya berdasarkan field custom seperti nomor seri atau catatan khusus per item, adalah hal yang sangat relevan.
Saya bisa konfirmasi bahwa kustomisasi method `_can_be_merged_with` ini adalah pendekatan yang tepat dan memang memungkinkan. Berikut adalah best practice dan hal-hal yang perlu diperhatikan:
Pendekatan Kustomisasi: Extend Method `_can_be_merged_with`
Alih-alih meng-override sepenuhnya, pendekatan terbaik adalah dengan meng-extend method ini menggunakan mekanisme `super()` Python. Ini memastikan bahwa logika standar Odoo tetap terpanggil, dan kita hanya menambahkan kondisi kustom di atasnya. Dengan begitu, kita meminimalkan risiko mengganggu fungsi lain dan membuat kode lebih tahan terhadap upgrade di masa mendatang.
1. Buat Modul Kustom: Pastikan Mba Lestari memiliki modul Odoo kustom (misalnya, `pos_custom_merge_rules`) yang bergantung pada modul `point_of_sale`.
2. Tambahkan Field Kustom: Jika Mba Lestari ingin menggunakan field kustom (seperti nomor seri atau catatan), pastikan field tersebut sudah ditambahkan ke model `pos.order.line`. Misalnya, tambahkan field `x_serial_number` atau `x_special_note` bertipe `Char` ke model `pos.order.line` melalui modul kustom Anda. Ini akan menjadi basis perbandingan Anda.
3. Implementasi Logika di `_can_be_merged_with`:
Di modul kustom Mba Lestari, extend model `pos.order.line`.
Di dalam method `_can_be_merged_with`, panggil terlebih dahulu `super()` dari method ini. Ini akan menjalankan logika merge standar Odoo (cek produk, harga, diskon).
Jika hasil dari `super()` adalah `False` (artinya Odoo standar sudah memutuskan untuk tidak me-merge), maka method kustom Anda juga harus mengembalikan `False`.
Namun, jika hasil dari `super()` adalah `True` (artinya Odoo standar mengizinkan merge), di sinilah logika kustom Mba Lestari masuk. Mba Lestari bisa menambahkan kondisi tambahan:
Bandingkan nilai field kustom (misalnya, `x_serial_number` atau `x_special_note`) antara order line yang sedang diperiksa dengan order line yang sudah ada.
Jika nilai field kustom ini berbeda, meskipun produk, harga, dan diskonnya sama, maka method kustom Anda harus mengembalikan `False` untuk mencegah merge.
Jika nilai field kustom ini sama, barulah method kustom Anda mengembalikan `True`, mengizinkan merge.
Ini akan memastikan bahwa sebuah order line hanya di-merge jika semua kondisi standar Odoo terpenuhi DAN semua kondisi kustom yang Mba Lestari tetapkan juga terpenuhi.
Hal-hal yang Perlu Diperhatikan:
Integrasi Frontend POS (JavaScript): Jika field kustom seperti nomor seri atau catatan ini diinput langsung dari antarmuka POS oleh kasir, Mba Lestari perlu memastikan bahwa field tersebut juga ditambahkan dan di-set nilainya di objek `Orderline` di JavaScript POS frontend. Logika merge di frontend Odoo (di file JavaScript seperti `models.js` atau `order.js`) mungkin juga perlu disesuaikan agar menampilkan behavior yang konsisten dengan backend. Jika tidak disesuaikan di frontend, kasir mungkin melihat dua item terpisah di layar POS, tetapi di backend mereka tetap di-merge (atau sebaliknya), yang bisa membingungkan. Idealnya, frontend juga mengikuti aturan merge yang baru.
Performa: Pastikan logika kustom yang ditambahkan tidak terlalu kompleks, karena method ini bisa sering dipanggil saat transaksi POS berlangsung. Perbandingan nilai field sederhana umumnya tidak akan memengaruhi performa secara signifikan.
Database Schema: Ingat untuk meng-update database Odoo setelah menambahkan field kustom baru ke model `pos.order.line`.
Pengujian Menyeluruh: Lakukan pengujian yang sangat detail untuk berbagai skenario:
Produk yang sama, harga, diskon sama, field kustom sama -> harus di-merge.
Produk yang sama, harga, diskon sama, field kustom berbeda -> tidak boleh di-merge.
Produk berbeda -> tidak di-merge (ini akan dihandle oleh `super()`).
Produk yang sama, harga berbeda -> tidak di-merge (ini akan dihandle oleh `super()`).
Fleksibilitas Aturan Merge: Untuk skenario "sebaliknya, kami butuh aturan merge yang lebih fleksibel dari standar Odoo", ini agak lebih kompleks. Jika Mba Lestari ingin memaksa merge item yang standar Odoo-nya tidak di-merge (misalnya karena diskon berbeda tapi ingin di-merge), ini berarti Mba Lestari perlu sedikit mengubah hasil dari `super()`. Namun, ini tidak disarankan sebagai best practice karena berpotensi melanggar integritas data standar Odoo, kecuali jika Mba Lestari sangat yakin dengan implikasinya dan sudah memikirkan semua kasus ekstrimnya. Umumnya, kita menambahkan kondisi untuk mencegah merge lebih lanjut, bukan untuk memaksa merge.
Dengan pendekatan extend method dan perhatian pada poin-poin di atas, Mba Lestari bisa mengkustomisasi perilaku merge order line di Odoo POS dengan aman dan efisien.
Semoga pencerahannya membantu Mba Lestari dan tim! Semangat terus optimalisasinya!