我在國內(nèi)實施ERP項目的時候，在整理銷售出貨流程的時候，經(jīng)常會碰到一個比較特殊的流程。如企業(yè)在產(chǎn)品發(fā)給客戶的時候，該產(chǎn)品還不算真正的賣給客戶，而是要到客戶產(chǎn)品用掉以后，才算真正的賣給了客戶。而按正規(guī)的作業(yè)流程的話，企業(yè)把貨物送給客戶，客戶簽收完畢后，該產(chǎn)品就已經(jīng)賣給對方了。

　　其實，這企業(yè)也有難言的苦衷。畢竟客戶是上帝，客戶怎么說，我們只好怎么辦。但是，這就給我們業(yè)務(wù)處理上帶來了不少的麻煩。主要遇到兩大問題。

　　一是貨物已經(jīng)發(fā)給客戶了，產(chǎn)品已經(jīng)在客戶那邊了。那作為企業(yè)，如何對這些產(chǎn)品進行跟蹤呢?如何知道發(fā)了多少產(chǎn)品給客戶，但是，還有多少還沒有產(chǎn)生應(yīng)收帳款呢?

　　二是什么時候確認應(yīng)收帳款?按照企業(yè)客戶的要求，企業(yè)只能在收到客戶產(chǎn)品用掉通知后才能確認應(yīng)收帳款，那財務(wù)以什么單據(jù)為準(zhǔn)做應(yīng)收帳款呢?若以給客戶的出貨單為準(zhǔn)做單據(jù)，明顯系統(tǒng)在根據(jù)客戶的付款條件計算應(yīng)收帳款的時候，會遇到問題。

　　我已經(jīng)多次遇到這種需求。現(xiàn)把這需求的解決方案歸納如下，或許多大家有所幫助。下圖是我一家客戶這個問題的實際作業(yè)流程。我將根據(jù)這家客戶的流程，來具體講解在ERP系統(tǒng)中如何實現(xiàn)這個需求。

　　現(xiàn)在假設(shè)，倉庫根據(jù)銷售的要求，要發(fā)一批貨，包括產(chǎn)品A與產(chǎn)品B，給他的客戶。

　　第一步：

　　在系統(tǒng)基礎(chǔ)設(shè)置的時候，設(shè)置一個虛擬的倉庫，名字為“客戶倉庫”。這個倉庫專門用來存儲發(fā)給客戶但是客戶還沒有通知產(chǎn)品用掉的企業(yè)資產(chǎn)。

　　倉庫首先在系統(tǒng)里面開立庫存調(diào)撥單，把要發(fā)的產(chǎn)品A與B，通過庫存調(diào)撥單轉(zhuǎn)移到客戶倉庫中去。然后審核庫存調(diào)撥單，并且打印庫存調(diào)撥單，我們把該單據(jù)打印的抬頭叫做送貨單。該單據(jù)一式兩份，一份給銷售，一份由送貨人員隨貨帶到企業(yè)客戶那邊去。

　　最佳實踐：

　　1、在客戶倉庫設(shè)置的時候，我們要注意一個問題。因為客戶倉庫是一個已經(jīng)發(fā)給客戶的資產(chǎn)，所以，這個倉庫里的產(chǎn)品，從本質(zhì)上來說，企業(yè)已經(jīng)不再擁有這些產(chǎn)品。故，企業(yè)在進行物料需求計劃計算的時候，就不能把這個倉庫里的數(shù)量考慮進去。所以，要把該倉庫的性質(zhì)設(shè)置為“不納入MRP計劃計算”。如此，系統(tǒng)在考慮物料需求計劃的時候，就不會考慮這個倉庫中的數(shù)量。

　　2、有時候，送貨單給企業(yè)客戶要兩份。由對方倉庫人員簽字確認后，司機要帶回一份交給企業(yè)的收貨人員。此時，為了操作的方便，可以使用按種一式三聯(lián)的紙張，利用針式打印機打印。如此的話，對方在簽字的時候，不用復(fù)寫紙就可以進行簽名。這即方便了客戶，也有利于自己的管理。可謂是一箭雙雕。

　　第二步：產(chǎn)品用掉通知。

　　當(dāng)客戶用完產(chǎn)品后，對方會通知業(yè)務(wù)員，說產(chǎn)品已經(jīng)用掉了。此時，我們要注意一些小問題。

如我們可能發(fā)了多種產(chǎn)品給客戶，如產(chǎn)品A與產(chǎn)品B，那到底是哪個產(chǎn)品已經(jīng)用完了呢?企業(yè)銷售員要向?qū)Ψ酱_認。其實，最好能夠讓對方告知我們的送貨單號，如此的話，對于我們企業(yè)的操作來說，是非常方便的。

　　同時，還可能存在這種情況。如我們的產(chǎn)品A可能有多張定單，現(xiàn)在客戶倉庫里，產(chǎn)品A的數(shù)量是由兩張送貨單組成的。那客戶現(xiàn)在到底是使用了哪個單的產(chǎn)品呢?因為這關(guān)系到我們后續(xù)的處理。所以，業(yè)務(wù)員在收到對方的通知時，同時確認送貨單號是非常有必要的。

　　第三步：倉庫進行出貨作業(yè)。

　　倉庫在收到業(yè)務(wù)員的通知，該筆貨客戶已經(jīng)確認可以出貨時。就要開立出貨單。不過在這支作業(yè)進行上時，我們要注意幾個問題。

　　最佳實踐：

　　1、出貨單原則上可以手工開，也可以根據(jù)銷售定單來轉(zhuǎn)換。不過，我建議用戶還是要根據(jù)銷售定單轉(zhuǎn)換成出貨單。如此的話，價格可以跟銷售定單一致，而且，銷售定單的狀態(tài)也會隨之更新。不過，若根據(jù)銷售定單轉(zhuǎn)換成出貨單的時候，要注意一個小細節(jié)，就是我們的出貨倉庫要選擇“客戶倉庫”，而不是成品倉庫。這就可以在單據(jù)性質(zhì)里進行默認設(shè)置，如此的話，就不用每張單據(jù)上都進行手工的更改。萬一忘記改了，就會造成庫存數(shù)量的不準(zhǔn)。

　　2、系統(tǒng)中提供了“已送貨未出貨報表”，可以查看該倉庫中，還有多少數(shù)量。其實，這里我只是把報表的名字改了，其實，就是一份庫存明細表。用戶可以通過查詢這份報表，查詢庫存數(shù)量。而這個庫存數(shù)量，就是已經(jīng)發(fā)給客戶，但是，還沒有收到客戶通知的產(chǎn)品。不過，這里還有個問題，這份報表中，是沒有顯示客戶信息的。也就是說，光憑這份報表，我們不知道這些產(chǎn)品是發(fā)給哪些客戶的或者是哪張定單的。為了能夠正確做出區(qū)分，而且在現(xiàn)實中也有這個需求，我們最好在庫存調(diào)撥作業(yè)的時候，采用批號管理的功能。如此話，客戶倉庫里的每進一筆貨，都有一個批號。而這個批號唯一的對應(yīng)銷售定單。如此的話，我們就可以知道該倉庫中的產(chǎn)品，到底是發(fā)給哪個客戶，是根據(jù)哪張銷售定單來的。如此的話，就利于用戶進行管理。在這份報表上，有銷售定單信息的話，對于用戶進行事后的追蹤與管理，是非常方便的。而且，我們系統(tǒng)中，已經(jīng)有了批號管理功能，不需要進行二次開發(fā)。只不過我們在設(shè)置的批號管理時，在進行批號編碼設(shè)置時，要注意一些技巧。如我們可以設(shè)置為客戶編號+銷售定單號+流水號。如此的話，一看這個批號，就知道是哪個客戶、哪張銷售定單的了。而不用再根據(jù)批號去查詢銷售定單、客戶的信息了。

　　3、有的企業(yè)，接到客戶通知單以后，出貨作業(yè)是由銷售部門來完成的。因為后續(xù)的出貨，跟實際的作業(yè)已經(jīng)不一樣了。當(dāng)然，如此處理也是可以的，而且，根據(jù)我個人的意見，可能這個處理還更加的合理。不過，我現(xiàn)在這個客戶還是由倉庫來負責(zé)這個后續(xù)的處理。

　　4、財務(wù)是根據(jù)出貨單來生成應(yīng)收帳款，并根據(jù)出貨單上的出貨日期來進行應(yīng)收帳款日期的計算。這里我們要注意，我們這里不是根據(jù)送貨單來產(chǎn)生應(yīng)收帳款，而是根據(jù)出貨單來生成應(yīng)收帳款。所以，最后應(yīng)收帳款的日期，是根據(jù)客戶通知的日期開始計算的。故意，出貨單上的通知日期就非常的重要。一般情況下，該日期是系統(tǒng)當(dāng)前的日期。根據(jù)系統(tǒng)的設(shè)置，當(dāng)前日期可能是用戶本機的日期，也可能是ERP服務(wù)器的日期。所以，該出貨單用戶要及時的開立。若不能及時開的話，用戶也要把出貨日期進行調(diào)整，否則的話，會影響應(yīng)收帳款的計算。

　　根據(jù)以上的步驟，這個問題就解決了。根據(jù)我上面買描述的這些功能，用戶不需要額外的進行二次開發(fā)，就可以實現(xiàn)。但是，按照上面的方法處理的話，有個缺陷，就是送貨單用戶要自己開，而不能夠根據(jù)銷售定單來轉(zhuǎn)換。雖然在進行庫存調(diào)撥作業(yè)時，我們可以采取批號管理，跟銷售定單關(guān)聯(lián)起來。但是，畢竟要手工的開立送貨單，而不能根據(jù)銷售定單直接轉(zhuǎn)換送貨單，這給用戶的工作帶來一定的影響。

　　為此，我們根據(jù)企業(yè)用戶的需求，進行了一些二次開發(fā)，實現(xiàn)了從銷售定單到庫存調(diào)撥單的自動轉(zhuǎn)換。

　　在這個轉(zhuǎn)換過程中，實現(xiàn)了以下功能：

　　一是庫存調(diào)撥單的內(nèi)容有銷售定單自動轉(zhuǎn)換過來。同時，調(diào)撥單上有銷售定單上的客戶、銷售定單號信息。不過，還是要采用批號管理功能，不然的話，仍然不能區(qū)分，客戶倉庫的貨到底是誰的。當(dāng)然，這個批號就不用用戶自己填寫了，在轉(zhuǎn)換過程中，會自動根據(jù)相應(yīng)的功能生成。

　　二是在銷售定單上，還有客戶的定單號碼。我們在轉(zhuǎn)換過程中，還把客戶的定單號碼帶入到送貨單上。如此的話，通過客戶的定單號碼，就可以查到相關(guān)的信息。

　　三是在當(dāng)送貨單審核時，也會更新銷售定單上的相關(guān)信息。如此的話，在銷售定單上，也可以查詢出銷售定單的送貨信息。這方便業(yè)務(wù)員的處理跟蹤。

　　在原來的功能上，再配合以上的二次開發(fā)功能，那這個需求的解決就比較完美了。

　　不過反過來說，企業(yè)若有這個能力，能夠改變客戶，只要我們出貨就相當(dāng)于賣給他們，那是最好了。畢竟，這對于企業(yè)來說，是一個不公平條約。

來源：巨靈鳥 歡迎分享本文