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

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

　　一是貨物已經發給客戶了，產品已經在客戶那邊了。那作為企業，如何對這些產品進行跟蹤呢?如何知道發了多少產品給客戶，但是，還有多少還沒有產生應收帳款呢?

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

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

　　現在假設，倉庫根據銷售的要求，要發一批貨，包括產品A與產品B，給他的客戶。

　　第一步：

　　在系統基礎設置的時候，設置一個虛擬的倉庫，名字為“客戶倉庫”。這個倉庫專門用來存儲發給客戶但是客戶還沒有通知產品用掉的企業資產。

　　倉庫首先在系統里面開立庫存調撥單，把要發的產品A與B，通過庫存調撥單轉移到客戶倉庫中去。然后審核庫存調撥單，并且打印庫存調撥單，我們把該單據打印的抬頭叫做送貨單。該單據一式兩份，一份給銷售，一份由送貨人員隨貨帶到企業客戶那邊去。

　　最佳實踐：

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

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

　　第二步：產品用掉通知。

　　當客戶用完產品后，對方會通知業務員，說產品已經用掉了。此時，我們要注意一些小問題。

如我們可能發了多種產品給客戶，如產品A與產品B，那到底是哪個產品已經用完了呢?企業銷售員要向對方確認。其實，最好能夠讓對方告知我們的送貨單號，如此的話，對于我們企業的操作來說，是非常方便的。

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

　　第三步：倉庫進行出貨作業。

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

　　最佳實踐：

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

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

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

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

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

　　為此，我們根據企業用戶的需求，進行了一些二次開發，實現了從銷售定單到庫存調撥單的自動轉換。

　　在這個轉換過程中，實現了以下功能：

　　一是庫存調撥單的內容有銷售定單自動轉換過來。同時，調撥單上有銷售定單上的客戶、銷售定單號信息。不過，還是要采用批號管理功能，不然的話，仍然不能區分，客戶倉庫的貨到底是誰的。當然，這個批號就不用用戶自己填寫了，在轉換過程中，會自動根據相應的功能生成。

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

　　三是在當送貨單審核時，也會更新銷售定單上的相關信息。如此的話，在銷售定單上，也可以查詢出銷售定單的送貨信息。這方便業務員的處理跟蹤。

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

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

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