庫存盤點業務應該不少程序員都不陌生,由於但凡是涉及到庫存管理的方面的系統,都必需要有盤點的功能。盤點,其實就是商品的實際庫存數與系統帳面庫存數對照,並在系統中錄入盈虧並調整系統庫存數量的一個過程。一句話,就是作到賬實相符。這小小的業務,在咱們項目中也把我折騰的夠嗆。
通常狀況下,在盤點的這個時間內,不容許系統單據操做,最主要是出入庫單據的操做,由於這會影響到系統的庫存;一樣的理由,也不容許實際倉庫的出入庫操做。
這就涉及到一個問題,是否須要在系統中限制用戶對系統的操做?是否須要在系統中判斷單據的完成狀況?
大多數的系統可能都不會限制用戶的系統操做,至少這樣給用戶的感受就不太好。咱們的CRM系統、門店系統以及咱們如今作的這個系統都沒有作這個限制。主要從管理上來解決這個問題。可是我也見一個系統,用戶能夠開單,可是系統會限制對單據的審覈等操做。
如今咱們這個系統就沒有作這個限制,甚至是連盤點表的打印功能也是經過當前庫存查詢的界面直接導出成Excel才能打印,這有點不方便,可是還能忍受,主要是導出數據的時候,若是導出的數據量太大,速度會很慢,會很影響系統的效率。
盤點以後,把盤點結果錄入系統,咱們系統採用的方式是,直接錄入盤盈盤虧單來調整庫存。盤點錄入功能放到系統其它出入庫單中去操做,只是設置不一樣的科目就能夠了。程序員
基本上盤點功能作到這裏就能夠了,後來業務方面的人來提出來,盤點單打印以前,必需要可以提供一個功能,提醒當前哪些單據尚未完成。這主要是擔憂盤點過程當中還有業務繼續操做,以至影響盤點結果的正確性。
開發方對這個功能提出來講,實現難度很大,並且沒有必要。主要是原本系統內出入庫的單據種類不少,要一個一個類型的去判斷。同時,就算判斷出來了也只能作提醒功能,系統不強制限制,沒有太大的意義,考慮到項目目前的進度延期以及工做量等方面的緣由,就不作了。
基本上個人觀點和開發方的觀點是同樣的,後來咱們內部本身也討論了一下,就不開發這個功能了。設計
財務方面的人某天給我打電話,說盤點錄入,也就是其它出入庫的盤盈盤虧不能錄入單據日期,可能會有很大的問題!
咱們系統最初提交需求的時候,沒有說可以修改單據日期,後來開發方在作系統的時候,就默認單據日期是當前日期,而且不容許修改。(這個項目中,不少沒有明確的東西,開發方都按照他們的意思直接默認一種方式開發,這一點很讓咱們頭痛!)後來咱們本身也默認了不能修改單據日期的這個現狀。
可是財務的人說,盤點完成以後,要對盈虧查找緣由,還須要經理簽字確認才能修改庫存,這通常狀況下須要幾天才能完成。等領導簽字以後,才錄入系統,這就形成了庫存改動的滯後。若是恰巧是在月末盤點,庫存盈虧錄入是在下一個月,那麼會形成上一個月的賬不許確,或者說系統賬與財務系統賬對不上的問題。
財務系統是容許錄入的時候修改單據日期,直接作到上一個月的賬裏邊去,並且實際中也是這樣操做的,咱們業務系統不能這樣作,就會出現差別。
而且,財務說,碰到跨年的時候更是會出現這個問題,會形成全年的數據對不上。
我後來提出來講,讓他們每月提早盤點,月底以前錄入系統就不會出現這個問題了。這是從管理上來解決問題。可是財務的人說,平常的盤點是能夠這樣操做,可是年底的時候,上市公司的財務審計,審計會要求監督盤點(簡稱監盤),都是他們說哪天盤點就是哪天,若是碰到跨年,可能審計會認爲兩個系統賬對不上。爲此在會議室吵了半天。(再加上咱們的財務模塊的負責人,有一點點耳聾,日常跟他說話都要聲音大一點才行,此次幾方面一塊兒來爭論,我靠,那叫一個聲勢浩大啊!)
沒有辦法,只有讓開發方對盤盈入庫和盤虧出庫單獨作一個功能,容許修改單據時間。開放時間以後,又要作限制。好比已經結帳以後,就不能提早到上一個月等等,也很複雜。開發
總結:不少簡單的業務,只要扯上財務,都會變得比較複雜。財務和審計的要求都是很複雜的。上市公司的業務系統,也是有審計要求的。系統設計的時候必定要當心!效率