Pesanan Penjualan vs Pesanan Pengiriman vs Faktur: Waktu Stok AutoCount
Satu pesanan pelanggan dapat muncul di tiga tempat berbeda pada tiga waktu berbeda.
Penjualan dapat melihat pesanan hari ini.
Gudang dapat mengirimkan barang besok.
Akun mungkin akan menagih minggu depan.
Jika tim tidak memahami waktu pembuatan dokumen, laporan dapat terlihat tidak sesuai meskipun setiap dokumen menjalankan tugasnya masing-masing.
Inilah sebabnya mengapa Pesanan Penjualan, Pesanan Pengiriman, Faktur, dan waktu stok penting.
Pertanyaannya bukan hanya “laporan mana yang benar?”
Pertanyaan yang lebih baik adalah:
Langkah dokumen manakah yang sudah terjadi?
Satu Pesanan Dalam Dua Bulan
Bayangkan aliran sederhana ini.
- 28 Mei: pelanggan mengkonfirmasi pesanan 100 unit.
- 28 Mei: Pesanan Penjualan dibuat.
- 31 Mei: gudang mengirimkan 80 unit.
- 31 Mei: Delivery Order disimpan atau diposting sebanyak 80 unit.
- 2 Juni: Faktur dibuat untuk jumlah yang dikirim.
Dari sudut pandang permintaan penjualan, perusahaan mungkin mengatakan pelanggan memesan 100 unit pada bulan Mei.
Dari sisi pergerakan stok, 80 unit keluar gudang pada 31 Mei.
Dari tampilan penagihan akuntansi, faktur muncul pada bulan Juni.
Itu adalah jawaban yang berbeda karena menjawab pertanyaan yang berbeda.
Persoalan menjadi serius ketika bisnis memperlakukan keduanya sebagai hal yang sama.
Efek Dokumen Berbeda
Dalam alur dokumen gaya AutoCount, setiap dokumen memiliki peran berbeda.
| Dokumen | Arti utama | Efek stok yang khas | Efek akuntansi yang khas |
|---|---|---|---|
| Pesanan Penjualan | pesanan atau permintaan pelanggan | tidak ada pergerakan persediaan | tidak ada postingan G/L |
| Pesan antar | barang terkirim atau pergerakan stok | dapat mengurangi stok bila disimpan atau diposting dengan postingan stok | tidak ada postingan G/L |
| Faktur | penagihan dan catatan rekening | tergantung pada jalur dokumen | posting ke A/R dan G/L terkait |
Tabel ini disederhanakan, namun memberikan gagasan inti.
Sales Order bukan berarti stok sudah berpindah.
Delivery Order bukan berarti pelanggan telah ditagih.
Invoice tidak selalu berarti stok berkurang saat itu juga, karena tergantung apakah invoice tersebut langsung atau ditransfer dari dokumen lain.
Itulah mengapa jalur dokumen penting.
Invoice Langsung Dan Invoice Dari DO Tidak Sama
Di sinilah banyak tim menjadi bingung.
Invoice yang dibuat langsung, atau ditransfer dari Sales Order atau Quotation, dapat mengurangi stok karena invoice merupakan dokumen yang melengkapi tindakan stok dan penagihan.
Namun Invoice yang dialihkan dari Delivery Order tidak boleh mengurangi stok lagi.
Mengapa?
Karena Delivery Order sudah menangani pergerakan stok.
Faktur setelah DO pada dasarnya adalah langkah penagihan dan akuntansi.
Jika tim tidak mengikuti jalur dokumen secara konsisten, bisnis dapat menimbulkan kebingungan:
- satu pesanan ditagih langsung;
- pesanan lain menggunakan Sales Order ke Delivery Order ke Invoice;
- pesanan yang telah dikirim ditagih lagi tanpa transfer yang semestinya;
- pengiriman sebagian ditagih dengan jumlah yang tidak jelas;
- stok keluar di bulan Mei tetapi penagihan dilakukan di bulan Juni.
Laporannya kemudian terlihat berantakan karena prosesnya yang berantakan.
Masalah Waktu Biasanya Merupakan Masalah Aturan
AutoCount dapat mendukung dokumen.
Namun perusahaan tetap membutuhkan aturan.
Misalnya:
- Kapan tim harus membuat Pesanan Penjualan?
- Kapan gudang harus membuat atau memposting Delivery Order?
- Apakah invoicenya harus langsung atau ditransfer dari DO?
- Apa yang terjadi bila pengirimannya parsial?
- Apakah pengiriman sebagian harus ditagih sekarang atau ditunda?
- Laporan apa yang harus digunakan pemilik untuk permintaan, pemenuhan, dan akuntansi?
- Tanggal manakah yang sebaiknya digunakan manajemen untuk setiap tampilan?
Tanpa aturan tersebut, staf akan memilih jalur berbeda berdasarkan kebiasaan.
Satu orang menagih langsung karena lebih cepat.
Orang lain membuat DO terlebih dahulu karena gudang memerlukan pergerakan stok.
Orang lain menunggu konfirmasi pengiriman yang ditandatangani.
Setiap keputusan mungkin masuk akal.
Bersama-sama, mereka menciptakan pelaporan yang tidak konsisten.
Contoh Pengiriman Sebagian
Pelanggan memesan 100 unit.
Gudang hanya mengirimkan 60 unit hari ini.
Tim memiliki beberapa kemungkinan alur kerja:
- membuat Sales Order sebanyak 100, DO sebanyak 60, lalu Invoice sebanyak 60;
- buat Sales Order sebanyak 100 dan tunggu sebelum membuat faktur;
- membuat Invoice langsung sebesar 60 jika usaha tidak menggunakan DO;
- tahan penagihan hingga sisa 40 unit siap;
- tagihan 60 sekarang dan simpan 40 sebagai terutang.
Tidak satu pun dari hal ini yang secara otomatis salah.
Namun bisnis memerlukan satu aturan yang disepakati.
Jika staf yang berbeda menangani pengiriman sebagian secara berbeda, pemilik mungkin melihat:
- permintaan penjualan 100 unit;
- pergerakan stok sebanyak 60 unit;
- invoice sebanyak 60 unit;
- sisa pesanan 40 unit;
- ekspektasi pelanggan sebesar 100 unit.
Ini bukan hanya masalah pelaporan.
Ini adalah aturan waktu dokumen.
Jika masalah utama Anda adalah ketidaksepakatan laporan yang lebih luas antar departemen, baca [mengapa angka penjualan, stok, dan akuntansi tidak setuju](/blog/mengapa-penjualan-stok-dan-angka-akuntansi-tidak setuju).
Dikirim Tidak Ditagih Adalah Tampilan Terpisah
Salah satu pandangan praktis yang dibutuhkan banyak perusahaan adalah disampaikan tetapi tidak ditagih.
Hal ini membantu tim menemukan barang yang sudah keluar gudang namun belum ditagih.
Namun tampilan ini hanya berfungsi apabila Delivery Order dan Invoice telah terhubung dengan baik.
Jika dokumen pengiriman hilang, tidak ditransfer, atau ditangani di WhatsApp, akun mungkin tidak mengetahui apa yang siap ditagih.
Jika ini adalah masalah utama Anda, baca mengapa pesanan pengiriman hilang antara pengiriman dan penagihan.
Artikel ini membahas logika waktu yang lebih luas: Pesanan Penjualan, Pesanan Pengiriman, Faktur, dan stok masing-masing menjawab pertanyaan berbeda.
Untuk Apa Setiap Laporan Harus Digunakan
Bisnis harus memberi label laporan berdasarkan tujuannya.
| Tampilan laporan | Apa jawabannya | Kesalahan umum |
|---|---|---|
| Tampilan Pesanan Penjualan | apa yang pelanggan pesan atau minta | memperlakukannya sebagai penjualan terkirim |
| Tampilan Pesanan Pengiriman | saham apa yang dipindahkan atau dipenuhi | memperlakukannya sebagai pendapatan |
| Tampilan faktur | apa yang ditagih dan diposting ke akun | memperlakukannya sebagai status operasional penuh |
| Tampilan pergerakan saham | apa yang mengubah saldo stok | mengabaikan apakah pelanggan telah ditagih |
| Pemandangan luar biasa | apa yang masih terbuka | mencampur jumlah yang dipesan, dikirim, dan ditagih |
Ketika nama laporan tidak jelas, pengguna berdebat mengenai angka.
Jika tujuan laporan jelas, pengguna dapat melihat tahap mana yang sedang mereka lihat.
Mengapa Dasbor Membutuhkan Aturan yang Sama
Dasbor tidak dapat memperbaiki waktu dokumen yang tidak jelas.
Jika dashboard menarik Pesanan Penjualan sebagai penjualan, nomor tersebut mungkin menunjukkan permintaan.
Jika ia menarik Faktur sebagai penjualan, nomor tersebut mungkin menunjukkan penagihan.
Jika menarik Delivery Order sebagai pemenuhan, nomor tersebut mungkin menunjukkan pergerakan stok.
Ketiganya bisa bermanfaat.
Namun mereka tidak boleh berbagi label yang sama.
Sebelum membuat dasbor, tentukan:
- jumlah yang dipesan;
- jumlah yang dikirimkan;
- jumlah yang ditagih;
- jumlah yang luar biasa;
- dikirimkan tidak ditagih;
- ditagih tidak terkirim, jika aliran Anda memungkinkan;
- aturan pengiriman sebagian;
- aturan tanggal untuk setiap tampilan.
Inilah sebabnya mengapa memperbaiki data sebelum dasbor sering kali dimulai dengan pengaturan waktu dokumen.
Jika bisnis memerlukan pelaporan langsung setelah peraturannya jelas, dasbor bisnis dan BI harus menggunakan definisi dokumen yang sama.
Dimana Integrasi AutoCount Bisa Salah
Jika sistem lain mengirimkan catatan ke AutoCount, pengaturan waktu menjadi lebih penting. Di sinilah integrasi AutoCount harus mengikuti jalur dokumen, bukan hanya memindahkan bidang.
Integrasi harus mengetahui apakah ia mengirimkan:
- Pesanan Penjualan yang telah dikonfirmasi;
- Surat Pengiriman;
- sebuah Faktur;
- pembaruan pada dokumen yang sudah ada;
- pemenuhan sebagian;
- pengecualian yang belum disinkronkan.
Jika sistem sumber mengirimkan tahapan yang salah, AutoCount mungkin menerima catatan yang terlihat valid tetapi artinya salah.
Itulah sebabnya pesanan penjualan ke AutoCount dan pengiriman ke penagihan AutoCount harus dirancang berdasarkan waktu dokumen, bukan hanya transfer data.
Pertanyaan Umum
Apakah Sales Order AutoCount mengurangi stok?
Sales Order biasanya merupakan dokumen pesanan atau permintaan. Itu tidak membuat pergerakan inventaris atau posting G/L dengan sendirinya.
Apakah Delivery Order AutoCount dikirim ke G/L?
Delivery Order dapat mempengaruhi pergerakan inventaris ketika disimpan atau diposting dengan postingan stok, namun tidak diposting ke G/L dengan sendirinya.
Apakah Invoice AutoCount mengurangi stok setelah transfer DO?
Invoice yang dialihkan dari Delivery Order tidak boleh mengurangi stok lagi karena Delivery Order sudah menangani pergerakan stok. Faktur langsung, atau Faktur yang ditransfer dari Pesanan Penjualan atau Penawaran, dapat mengurangi stok tergantung pada aliran dan pengaturan.
Mengapa stok berkurang sebelum invoice?
Hal ini dapat terjadi ketika Delivery Order menangani pergerakan stok sebelum Invoice dibuat. Tampilan stok dan tampilan penagihan akuntansi kemudian melihat tahapan dokumen yang berbeda.
Apa yang dikirim tidak ditagih?
Delivered not invoice artinya barang sudah terkirim atau stok sudah berpindah, namun invoice belum dibuat. Hal ini berguna untuk menemukan kesenjangan penagihan.
Apa yang Harus Dilakukan Selanjutnya
Pilih satu pesanan terbaru yang membingungkan tim.
Telusuri melalui:
- Pesanan Penjualan.
- Pesan antar.
- Faktur.
- Pergerakan saham.
- Tanggal laporan.
- Kuantitas yang luar biasa.
Kemudian tanyakan apakah tim mengikuti jalur dokumen yang dimaksudkan.
Jika tidak, perbaiki aturan alur kerja sebelum membuat dasbor atau integrasi.
Result Marketing membantu UKM memetakan waktu dokumen ini sehingga AutoCount, gudang, dan akun dapat bekerja dari alur yang sama.