期間雖然說是財務模組需要用到的概念，但是在erp系統中則是貫穿到所有的erp模組中。如銷售、採購、倉庫等等都受到期限制。可見，從系統開發的角度看，期間在erp系統中也是乙個全域性化的變數。具體的來說，在設計期間的管理思路時，筆者認為需要從如下幾個角度出發。
1. 期間並不是以月為單位
從理論上來說，會計期間是以月為單位的。即相關的單據，如收貨單或者發料單，必須在每個月月底都要結帳。不過在實際工作中，可能會與這個有差異。如有可能 企業並不是以自然月作為期間。筆者以前在給多家企業實施專案的時候，都遇到過類似的問題。他們可能認為，等到每個月月末再結賬的話，開發票或者發票驗證會 來不及。因為這國家都有比較嚴格的時間限制。為此這些企業會人為的定義期間，如定義每個月結帳的時間為25日等等。
雖然這不怎麼合法，但是這卻在情理之中。而且在現實工作中，會計事務所等審查機構，對此也是睜乙隻眼、閉乙隻眼。特別是對於非上市公司來說，這麼做是允許 的。為此我們在進行erp系統設計與開發的時候，也需要考慮到企業這方面的需求。簡單的說，就是在期間管理的時候，不但要能夠實現按自然月來劃分期間，而 且還允許按非自然月來進行劃分。如每個月的26日到下月的25日作為乙個期間。當7月26日的收貨單，系統就會當作是8月份的單據。
不過在開發的過程中，需要注意的是，這個期間不光光是財務上面的控制。其還涉及到其他報表的內容。如現在需要通過8月份的銷售訂單出貨情況，那麼其統計的口徑就必須使7月26日到8月25日的出貨明晰。不然的話，就會與財務部門的帳因為統計口徑的不同而出現誤差。
可見，會計期間的管理是乙個統籌全域性的問題。為了能夠適應大部分企業的應用，需要根據使用者的需求來實現自定義。這對系統的開發提出了比較高的要求。
2. 期間關閉後仍然要允許進行一些管理性工作
一般來說，如果期間關閉，那麼對於關閉期內的單據是不能夠進行更改或者操作的。如7月份的期間已經關閉，則不能夠將出貨單的日期改在7月份，同時也不能夠 將7月份的出貨單重新開啟更改數量等等。這是會計期間管理的基本要求。不過在實際工作中，仍然允許在關閉的期間內，做一些管理性質的更改工作。具體的說， 有如下內容需要注意。
一是單據的重新編號。對於企業內部的單據來說，有連續編號的要求。如採購訂單、應付憑單、付款單等等需要連續編號。這有利於後續相關部門的審計。但是在實 際工作中，由於單據刪除等原因，會導致單據的不連號。在這種情況下，erp系統中往往會開發乙個重新編號的作業。即在關閉期間之後（這主要是為了防止在重 新編號作業執行中或者執行完畢後使用者又更改相關的單據從而影響其執行的效果），執行這個作業。此時系統會根據單據的建立時間對付款單等單據進行重新編號。 然後使用者重新列印並歸檔。這看起來雖然麻煩一點，但是從長遠來看，還是必須的。如果要實現這個需求的話，那麼在期間管理時，就不能一刀切，而要允許及時期 間關閉後，也允許使用者執行這個"重新編號"的作業，對相關單據進行重新的編號。
二是自動扣料的作業。在一些設計比較完善的erp系統中，都會有自動扣料的作業。如企業可能會有一些連續性的材料，如pvc等等。在領料的時候，都是整包 整包領的。而不是按需領料。等到某張訂單生產完成後，再計算用掉的數量和剩餘的數量。此時執行以下自動扣料作業，系統會自動生成退料單，將多於的材料退回 給倉庫。在實際工作中，這個作業往往是在系統結賬之後、成本結轉之前才操作的。故這又涉及到會計期間的問題。如在8月2日做自動扣料作業，而這些材料又是 涉及到7月份的完工產品。那麼這些退料單時間必須在7月份，否則的話，就會影響到後續成本的統計。但是此時7月份的會計期間已經關閉。按照期間管理的要 求，是不允許再在7月份這個會計期間進行交易的。不過由於自動扣料這個業務存在著特殊性，在系統開發時就需要給其開一道後門。允許自動扣料作業向關閉期間 的月份內做交易。不過出於資料安全的考慮，最好對其也進行相關的控制。如只允許其向上乙個會計期間做相關的單據。如在8月份執行這個作業，那麼其自動扣料 的時間只能夠是7月份，不能夠是6月份。這可以促使使用者及時的執行這個作業。
雖然這些例外性的內容並不是很多。但是在實際工作中，這些例外是必不可少的，是管理上的一種需要。如果erp系統沒有這類似的功能，那麼就必需要進行二次 開發或者採取其他一些折中的方式。如筆者以前實施過易飛erp系統。它在期間管理的時候，沒有自定義的功能，即指能夠按照月份作為會計期間。而此時使用者需 要使用的是25日作為結賬日期。最後使用者只能夠人為的更改日期。即將每月26之後發生的交易該在此月1日。這雖然也是可行的，但是給後續的資料分析與管理 帶來了很大的麻煩。因為此時每個月的26到月末的資料是空白的，而此月1日發生的交易又超多。為此筆者建議，在系統開發時，為了提高系統的靈活性，還是需 要體現使用者這方面的需求。其實開發的思路也比較簡單，只需要加乙個if語句，並採用一定的限制條件即可。主要的關鍵是，在開發時，思路需要嚴謹。
3. 會計期間與成本結轉之間的關係
在會計期間的設計與開發中，還需要注意前後之間的聯絡。在erp系統中，有三個比較典型的作業跟會計期間相關，分別是關帳、成本結轉和結賬。關帳後，普通 使用者不能夠再往這個期間內作相關的交易，而像自動扣料、單據編號調整等作業還是可以執行的。成本結轉作業執行時必須系統已經關帳，這可以防止系統運算的死 迴圈。當結帳作業執行後，這個期間內的資料就不能夠做任何的更改。如果確實有錯誤的話，那麼系統建議的是通過差錯更正或者成本調整作業來處理。
可見，在會計期間設計開發時，還必須考慮到這三個階段。並且需要了解，每個階段中其可以進行哪些操作。不同的操作，往往需要涉及到不同的限制。特別是對於 成本結轉這個作業，需要引起特別的注意。成本結轉作業一定要在關帳之後才能夠執行。因為如果在這個作業執行後，系統的資料，如採購的單價等內容還發生變更 的話，那麼系統辛辛苦苦計算出來的成本資料就會跟實際有比較大的誤差。
總之，在期間的設計中，需要特別注意跟其他各個模組之間的關係。在erp系統中，會計期間已經不再是財務專用的乙個概念，而是牽涉到系統的各個模組中。作為erp開發專案組的負責人，需要在各個模組之間進行協調，讓會計期間的觀念深入到每個系統分析人員的心中。
ERP系統開發隨筆系列六（論ERP的設計模式
最近設計模式在網上很是個焦點，什麼這個模式，那個模式的，有用論，沒用論，這些對於軟體開發設計很重要嗎？一點都不重要。大家為這些花了不少時間，其實我覺得不必太要在意你的功能採用了哪些設計模式，因為那些是概念性的東西，只有真正參與實質開發經驗的人才知實用最重要。我在開發erp過程中我確實用了不少設計模式...
對WebService的在企業應用中的思考。
webservice能給企業應用軟體帶來什麼好處，答案很多，但回答最多莫過於 跨平台 難道我們為企業開發中應用程式的目的是 跨平台 嗎，答案是否定，這不過是一種噱頭。估計有很多人會反對，理由是google ibm 等等的那個什麼什麼應用不就是webservice的，可以跨平台，呵呵，但別忘了，那些個...
設計模式 在軟體開發中的應用
論設計模式在軟體開發中的應用 在解決這個論題之前，我們首先要了解設計模式的概念，及其基本的分類。設計模式 這四個字，相信大家在很多地方都會看到，什麼是設計模式呢?乙個設計模式提供一種提煉子系統或軟體系統中的元件的，或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的元件中重複出現的結構，...