房屋維修資金軟件需求規格說明書編寫日期：2008年重慶光大網絡技術有限公司1產品描述 41.1編寫目的 41.2產品名稱 42產品需求概述 42.1開發意圖 42.2應用目標 52.3作用范圍 52.4主要功能 52.5與產權交易系統的交互 52.6運行環境 63功能需求 63.1功能劃分 64功能描述 74.1單位機構管理 74.1.1單位設置 74.1.2單位管理員帳號設置 84.1.3單位信息錄入登記 84.1.4單位信息審核 94.1.5單位組織機構設置 104.2區域管理 104.3樓盤項目管理 114.3.1開發項目登記 124.3.2開發項目審核 124.3.3樓棟樓盤登記 134.3.4樓棟樓盤審核 134.3.5業主登記 144.3.6業主登記審核 144.4小區管理 154.4.1小區設置 154.4.2樓棟管理 164.4.3業委會設置 164.4.4物管企業設置 174.4.5業主管理 174.5系統管理 184.5.1單位權限授予 184.5.2角色管理 184.5.3員工管理 184.5.4操作員管理 194.5.5上機、操作日志 204.5.6口令設置 204.5.7利率設置 214.5.8計息日設置 214.5.9繳存標準設置 224.5.10賬戶管理 234.5.11公告管理 244.6資金歸集管理 254.6.1首次歸集 254.6.2續交歸集 274.6.3綜合處理 284.7資金使用管理 294.7.1申請使用維修資金 304.7.2授理申請 304.7.3審批申請 314.7.4資金使用分攤 324.7.5資金撥付執行 324.7.6使用入賬 334.7.7資金使用結算 334.7.8歸檔備案 344.8資金賬務管理 344.8.1利息結轉 354.8.2資金賬目移交 354.8.3資金退伙 364.9資金增益管理 364.9.1增益入賬 364.9.2增益分攤 374.10資金查詢 374.10.1小區賬面 374.10.2樓棟賬面 374.10.3房屋賬面 384.10.4使用查詢 384.10.5退伙查詢 384.10.6業主查詢 384.10.7銀行賬單對賬查詢 384.11報表統計 394.11.1小區賬面統計 394.11.2分棟賬面統計 394.12相關打印 391產品描述1.1編寫目的 在完成了針對《物業維修資金管理系統》軟件市場的前期調查，提出了這份軟件需求規格說明書。此需求規格說明書對《物業維修資金管理系統》軟件做了全面細致的用戶需求分析，明確所要開發的軟件應具有的功能、性能與界面，使系統分析人員及軟件開發人員能清楚地了解用戶的需求，并在此基礎上進一步提出概要設計說明書和完成后續設計與開發工作。本說明書的預期讀者為客戶、業務或需求分析人員、測試人員、用戶文檔編寫者、項目管理人員。1.2產品名稱產品全稱：物業維修資金管理系統產品簡稱：維修資金管理系統版本：V2.02產品需求概述2.1開發意圖滿足維修基金管理辦法要求。滿足不同用戶對象的使用需求。實現維修基金規范、高效、準確、公正、透明管理。提高業主滿意度。2.2應用目標2.3作用范圍2.4主要功能1、單位機構管理★單位設置★單位管理員賬號設置★單位信息錄入登記★單位信息審核★單位組織機構設置2、區域管理★區域信息維護3、樓盤項目管理★開發項目登記★開發項目審核★樓棟樓盤登記★樓棟樓盤審核★業主登記★業主登記審核4、小區管理★小區設置★樓棟設置★業委會設置★物業管理企業設置★業主管理5、系統管理★操作員管理★上機、操作日志★口令設置★利率設置★計息日設置★繳存標準設置★賬戶管理★公告管理6、資金歸集管理★首次歸集★續交歸集★綜合處理7、資金使用管理★使用申報★申報授理★申報審批★使用分攤★撥付執行★使用入賬★使用結算★歸檔備案8、資金賬務管理★利息結轉★賬目移交★資金退伙9、資金增益管理★增益入賬★增益分攤10、資金查詢★小區賬面★樓棟賬面★房屋賬面★使用查詢★退帳查詢★退伙查詢★業主查詢★銀行賬單對賬查詢11、報表統計★小區賬面★分棟賬面★結息記錄★總賬2.5與產權交易系統的交互如果使用了光大產權交易系統。存在產權信息的房屋信息從產權交易系統中查詢房屋信息。產權辦理時，從維修資金管理系統中查詢維修資金是否已經交存、交存的量是否足夠。產權轉移時，從維修資金管理系統中查詢當前維修資金余額是否足夠。 2.6運行環境硬件環境軟件環境操作系統(Windows2000或者WindowsServer2003（SP1以上）數據庫系統(SqlServer2000、SqlSever2005)客戶瀏覽器(IE6.0、IE7.0)3功能需求3.1功能劃分 本系統主要功能劃分為：單位機構管理、區域管理、樓盤項目管理、小區管理、系統管理、資金歸集管理、資金使用管理、資金賬務管理、資金增值管理、資金查詢、報表管理等十一部分。4功能描述4.1單位機構管理4.1.1單位設置A、功能描述：完成使用維修資金系統的單位的新建、修改、刪除、查詢。設置單位分為：房管單位、開發單位、售房單位、業委會、物業管理單位。B、輸入信息：單位名稱C、輸出信息：D、功能要求： a)系統管理員具有此權限。 b)新建、修改時單位名稱不允許重名。 c)如果使用了產權交易系統，允許從產權交易里查詢直接添加開發商單位，添加后的開發商單位只存在引用關系。 d)自動生成單位代碼4.1.2單位管理員帳號設置A、功能描述：對各單位設置管理員帳號和密碼。B、輸入信息：管理員帳號C、輸出信息：管理員帳號、管理員默認密碼。D、功能要求： a)系統管理員具有此權限。 b)賬號自動生成。4.1.3單位信息錄入登記A、功能描述：各單位錄入基本信息及相關證件復印件、提交審核。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制，本單位用戶具有此權限 b)提交審核后的信息不能修改。 c)房管單位不用錄入信息登記。 d)從產權交易中直接添加的開發商信息不用錄入信息登記。4.1.4單位信息審核A、功能描述：對各單位錄入的信息進行審核。B、輸入信息：C、輸出信息：審批結果、審批意見D、功能要求： a)進行功能權限控制，房管單位具有此權限。 b)對于待審核的信息給予提示。 c)對于審核結果給予提交審批人提示。 d)對于審核未通過的單位不能進行其他功能的操作。4.1.5單位組織機構設置A、功能描述：用于各單位組織機構的添加、修改、刪除。B、輸入信息：組織機構全稱、組織機構簡稱。C、輸出信息：D、功能要求： a)進行功能權限控制，單位管理員具有此功能權限。 b)自動生成單位組織機構代碼4.2區域管理A、功能描述：對省市、區縣、鄉鎮、街辦(村)、路、各級區域信息進行添加、刪除、修改操作。B、輸入信息：區域名稱C、輸出信息：D、功能要求： a)進行權限功能控制,房管單位具有此功能權限。 b)如果使用了產權交易系統，則可以從產權交易系統中進行區域信息共享。 c)自動生成區域編碼。 d)同級區域名稱不能重復。 e)對于刪除的區域信息只作刪除標志。4.3樓盤項目管理如果使用了光大產權交易系統，商品房項目可以直接從產權交易系統中查詢，不用進行樓盤項目維護。4.3.1開發項目登記A、功能描述：對開發項目信息的添加、刪除、修改、提交審核。B、輸入信息：項目名稱、項目建設地址、計劃開工時間、計劃竣工時間、綜合驗收竣工時間、項目總規劃面積、在建面積、總幢數、計劃總投資（萬元）、完成投資（萬元）、總套數、住宅均價、非住宅均價、住宅面積、非住宅面積、拆遷面積、拆遷戶數、項目工程總造價（萬元）、用款金額、保證金賬戶余額（萬元）、項目選址意見書。C、輸出信息：D、功能要求： a)進行權限功能控制。 b)從產權交易中選擇直接添加的項目不用審核。 c)自動生成項目編號 d)提交審核的項目不能修改。4.3.2開發項目審核A、功能描述：提交審核的開發項目進行審核。B、輸入信息：C、輸出信息：審核結果、審核意見D、功能要求： a)進行功能權限控制，房管單位具有此權限。 b)對于待審核的信息給予提示。 c)對于審核結果給予提交審批人提示。4.3.3樓棟樓盤登記A、功能描述：進行樓棟及樓盤信息的添加、刪除、修改、提交審核B、輸入信息：樓棟位置(包括所在小區、小區內樓棟號、坐落信息、房屋種類、所屬單位、樓棟描述、竣工日期、備注)、樓棟情況(總層數、單元數、住宅數、業主戶數、地下層數、有無電梯)樓盤信息(層數、住宅數、單元數)、房屋信息（房屋編號、房屋序號、產權證號、用途、實測建筑面積、預測建筑面積、房屋單價）；C、輸出信息：D、功能要求： a)進行功能權限控制。 b)提交審核的信息不能在此環節進行修改。4.3.4樓棟樓盤審核A、功能描述：進行樓棟信息的審核B、輸入信息：C、輸出信息：審核結果、審批意見。D、功能要求： a)進行功能權限控制，房管單位具有此權限。b)對于待審核的信息給予提示。 c)對于審核結果給予提交審批人提示。4.3.5業主登記A、功能描述：設立購房業主B、輸入信息：業主姓名、身份證號、購房時間、工作單位、聯系電話C、輸出信息：D、功能要求： a)進行功能權限控制4.3.6業主登記審核A、功能描述：對登記的業主信息進行審核B、輸入信息：業主信息、業主所購房屋信息C、輸出信息：審核結果D、功能要求： a)房管單位具有此功能權限 4.4小區管理4.4.1小區設置A、功能描述：對小區基本信息的編輯和設置小區所包括的樓棟。B、輸入信息：小區名稱C、輸出信息：D、功能要求： a)根據權限進行功能控制。4.4.2樓棟管理A、功能描述：對審批后的樓棟信息(樓棟位置、樓棟情況、樓盤情況、房屋信息)的修改。B、輸入信息：樓棟信息C、輸出信息：D、功能要求： a)進行功能權限控制，房管單位具有此功能。4.4.3業委會設置A、功能描述：為相應小區或者樓棟設置業委會。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制，房管單位具有此功能權限。 4.4.4物管企業設置A、功能描述：為相應小區或者樓棟設置物業管理企業。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制，房管單位具有此功能權限。4.4.5A、功能描述：對業主的基本信息進行維護、業主變更處理。B、輸入信息：業主姓名、身份證號、購房時間、工作單位、聯系電話C、輸出信息：D、功能要求： a)進行功能權限控制，房管單位具有此功能。 b)業主和房屋為對應關系。 4.5系統管理4.5.1單位權限授予A、功能描述：對不同單位進行不同操作權限的授予。B、輸入信息：C、輸出信息：D、功能要求：此功能只屬于系統管理員4.5.2角色管理A、功能描述：不同單位管理員添加、刪除、設置角色操作權限。B、輸入信息：C、輸出信息：D、功能要求：進行功能權限控制4.5.3員工管理A、功能描述：用于各單位對員工的添加、修改、刪除、查看。B、輸入信息：C、輸出信息：D、功能要求：進行功能權限控制。4.5.4A、功能描述：添加、修改、刪除和授權操作員。B、輸入信息：操作員姓名、聯系電話、聯系地址、性別。C、輸出信息：D、功能要求： b)添加、修改、刪除和授權操作只能由本單位管理員進行操作。 c)單位管理員只能把單位所擁有的權限用來進行授予。 d)操作員創建成功后生成賬戶和密碼。4.5.5上機、操作A、功能描述：查閱操作員的上機信息、操作信息。B、輸入信息：C、輸出信息：D、功能要求： a)系統管理員可以查看所有操作員的上機及操作日志。 b)單位管理員可以查看本單位操作員的上機及操作日志。4.5.6A、功能描述：用于操作員進行密碼修改。B、輸入信息：C、輸出信息：D、功能要求： a)系統中的任何用戶都可以設置修改自己的密碼4.5.7A、功能描述：對維修資金的利息利率進行設定。銀行利率方式為兩種，一種按360天算（及大月31號不計算利息），一種按365天算(按實際天數計算)。B、輸入信息：C、輸出信息：D、功能要求： a)房管單位具有此權限。 b)利率為年利率。 c)利率生效日精確到時分秒。4.5.8A、功能描述：設置一年中銀行的計息日（幾月幾號）。B、輸入信息：C、輸出信息：D、功能要求： a)系統管理員具有此權限。 b)設置不同銀行的計息日。4.5.9 (首次歸集標準業務流程圖)A、功能描述：設置維修資金首次歸集和續交的繳費標準。按照房屋性質不同，分商住宅與售后公有住房。按面積收1）商品住宅首次歸集標準業主：按物業的建筑面積交存，每平方米建筑面積交存數額為當地住宅建筑安裝工程每平方米造價的5%至8%（多層、高級、有無電梯交存標準可能不同）。2）商品住宅續交歸集標準業主：業主分戶賬面住宅專項維修資金余額不足首期交存額30%，按續交方案續交(續交方案可以是按每平方米交多少金額進行收取、按首次歸集的百分比繳納、用戶自定義)。3）售后公有住房首次歸集標準售房單位：按照多層住宅不低于售房款的20%、高層住宅不低于售房款的30%從售房款中一次性提取。業主：按物業的建筑面積交存，每平方米建筑面積交存首期住宅專項維修資金的數額為當地房改成本價的2%。4）售后公有住房續交歸集標準業主：業主分戶賬面住宅專項維修資金余額不足首期交存額30%，按續交方案續交(續交方案可以是按每平方米交多少金額進行收取、按首次歸集的百分比繳納、用戶自定義)。按房價收商口住宅首次歸集標準業主：設置業主首次交存維修資金的交存比例(與房價的比例，普通、多層、高層、電梯房繳交比例可能不同）。商品住宅續交歸集標準業主：設置業主首次交存維修資金的交存比例(與房價的比例)（普通、多層、高層、電梯房繳交比例可能不同）。3）售后公有住房首次歸集標準售房單位：設置售房單位首次交存維修資金的交存比例(與房價的比例，普通、多層、高層、電梯房繳交比例可能不同)業主：設置業主首次交存維修資金的交存比例(與房價的比例，普通、多層、高層、電梯房繳交比例可能不同)售后公有住戶續交歸集標準業主：設置業主首次交存維修資金的交存比例(與房價的比例，普通、多層、高層、電梯房繳交比例可能不同)B、輸入信息：C、輸出信息：D、功能要求： a)維修資金首次歸集標準由房管單位制定。 b)業委會未成立的，續交標準由房管局制定。 c)業委會成立的，續交標準由業委會成立。 4.5.10賬戶A、功能描述：用于專項維修資金賬戶的創建、修改、注銷、變更。 主要分為房管局帳戶、業委會帳戶。B、輸入信息：C、輸出信息：D、功能要求： 4.5.11A、功能描述：用于公告信息的發布管理。B、輸入信息：C、輸出信息：D、功能要求： a)業委會、物管單位能在自己的管轄范圍內進行公告管理。 b)發布的公告有區域限制（區域內用戶可以看見，區域外用戶不能看見）。 c)進行權限功能控制。4.6資金歸集管理 （資金歸集業務流程圖）4.6.1首次歸集A、功能描述：根據首次歸集標準和業主物業信息進行首次維修資金的交納。首次歸集的業務劃分為以下幾種：開發商代收：開發商與房管部門簽訂代收協議，開發商向業主收取維修資金。(開發商代收業務流程圖)公有售房單位繳納：公有售房單位向房管單位繳納維修資金。 3）個人繳納：個人向房管單位繳納維修資金，分為商品房和售后公有房，未銷售的商品房 由開發房繳納。B、輸入信息：繳存標準、銀行存款憑證、房屋信息C、輸出信息：繳款憑證D、功能要求： a）進行功能權限控制 b）房管單位具有此功能權限4.6.2續交歸集(續交歸集業務流程圖)A、功能描述：根據續交方案進行維修資金的交納。 交納對象為商品房業主和售后公有房業主。B、輸入信息：繳存方案、銀行存款憑證。C、輸出信息：繳款憑證D、功能要求： a)進行功能權限控制。 b)房管單位或者業委會具有此功能權限4.6.3綜合處理A、功能描述：綜合處理主要是對歸集過程中對資金歸集的多退少補、未入賬金額的退款等進行處理。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制 4.7資金使用管理（資金使用業務流程圖）4.7.1申請使用維修資金A、功能描述：用于物業共用部位、共用設施設備保修期滿后的大修、中修、更新、改造項目的費用申請。B、輸入信息：C、輸出信息：申請審批表D、功能要求： a)進行功能權限控制 b)能打印申請審批表4.7.2授理申請A、功能描述：對提交的維修資金使用申請進行授理和對相關材料進行登記收件。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制 b)對于不授理的申請退還申請人，并打印不予授理通知書。 c)對于授理的申請提交到審批環節。 d)對于不未授理的申請在修改信息后可以重新提交申請。4.7.3審批申請A、功能描述：對授理的申請進行審批。B、輸入信息：申請審批表C、輸出信息：審批結果及意見D、功能要求： a)進行功能權限控制 b)業委會成立前，房管單位具有此權限。 c)業委會成立后，業委會具有此權限，但需要提交房管單位備案。 d)對于審批未通過的申請直接退回申請人。 4.7.4資金使用A、功能描述：對維修物業涉及的費用分攤到相關業主分戶賬上。B、輸入信息：業主信息C、輸出信息：資金使用分攤表D、功能要求： a)進行功能權限控制 b)分攤不盡的金額進入公有賬戶。 4.7.5資金撥付A、功能描述：對于分攤好的資金進行撥付，打印撥付通知書。B、輸入信息：C、輸出信息：維修資金撥付通知書D、功能要求： a)進行功能權限控制4.7.6使用A、功能描述：根據銀行的支取憑證進行入賬計息。B、輸入信息：銀行支取憑證C、輸出信息：D、功能要求： a)進行功能權限控制 b)房管單位具有此功能權限4.7.7資金使用結算A、功能描述：對同一個項目的維修資金撥付與使用情況進行結算B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制 b)房管單位或者業委會具有此功能權限4.7.8歸檔A、功能描述：對于項目的使用的相關材料進行歸檔。B、輸入信息：相關材料C、輸出信息：D、功能要求： a)進行功能權限控制 b)房管單位具有此功能權限。4.8資金賬務管理4.8.1利息結轉A、功能描述：對維修資金進行利息的結轉處理，分為手動結息和自動結息。B、輸入信息：C、輸出信息：D、功能要求： a)能夠對以前的帳重新結息。 b)能具體到對個人進行結息。4.8.2資金賬目移交A、功能描述：房管單位將維修資金劃轉自業委會帳戶、賬目移交。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能4.8.3資金退伙A、功能描述：因拆遷等原因致使住宅滅失的，將專項維修資金退還所有人。B、輸入信息：銀行消戶回單、分戶注銷手續、退伙申請表。C、輸出信息：退還分戶中的所有余額。D、功能要求： a)進行功能權限控制4.9資金增益管理4.9.1A、功能描述：利用業主依法享用的物業公用設置經營所得的收益進行審核入賬管理。B、輸入信息：銀行存款憑證C、輸出信息：D、功能要求： a)進行功能權限控制4.9.2增益分攤A、功能描述：利用業主依法享用的物業公用設置經營所得的收益分攤到相關業主分戶賬上。B、輸入信息：C、輸出信息：D、功能要求： a)進行功能權限控制 b)分攤可按業主擁有的物業面積進行分攤，也可按比例進行分攤，分攤不盡的計入物業區域的公共帳目。4.10資金查詢4.10.1小區賬面A、功能描述：對小區的賬目進行查詢，主要包括（小區帳目概況、單位繳存明細、業主繳存明細、基金使用記錄、分攤記錄、業主帳面、結息記錄）B、輸入信息：C、輸出信息：D、功能要求： a)進行權限功能控制4.10.2樓棟賬面A、功能描述：對樓棟的賬目進行查詢，主要包括（樓棟帳目概況、單位繳存明細、業主繳存明細、資金使用記錄、分攤記錄、業主帳面、結息記錄）B、輸入信息：C、輸出信息：D、功能要求： a)進行權限功能控制4.10.3房屋賬面A、功能描述：對房屋的賬目進行查詢，主要包括（繳存明細、使用明細、分攤記錄、單位余額、結息記錄）B、輸入信息；C、輸出信息：D、功能要求： a)進行權限功能控制4.10.4使用查詢A、功能描述：對申請使用資金未審批和已審批的進行查詢。B、輸入信息：C、輸出信息：D、功能要求： a)進行權限功能控制 b)查詢方式能夠按小區、日期、審批未審批狀態進行查詢。4.10.5退伙查詢A、功能描述：對資金退伙記錄進行查詢。B、輸入信息：C、輸出信息：D、功能要求： a)進行權限功能控制4.10.6業主查詢A、功能描述：提供給業主進行維修資金查詢（賬房余額、使用記錄、結算記錄、分攤記錄）B、輸入信息：C、輸出信息：D、功能要求： a)進行權限功能控制4.10.7銀行賬單對賬查詢A、功能描述：提供維修資金的存、取、利息結轉記錄的查詢與打印。B、輸入信息：C、輸出信息：D、功能要求： a)要求查詢能按小區、樓棟、房屋進行賬單查詢。4.11報表統計功能模塊描述：主要用于賬務的統計4.11.1小區賬面統計功能描述：通過選擇時間段（精確到天）和小區進行統計，統計項包括繳存總額、賬面余額、使用金額、利息合計、增益合計。4.11.2分棟賬面統計功能描述：通過選擇時間段（精確到天）和小區下的樓棟進行統計，統計項包括繳存總額、賬面余額、使用金額、利息合計、增益合計。4.12相關打印 業主催繳單、樓棟催繳單、繳存流水賬、個人賬面、樓棟賬面、分攤明細賬、記賬憑證、業主繳存發票

集成的會計系統財務四大基礎模塊ERP系統是分模塊的，在財務會計領域，一般總會有如下的4大模塊：總帳，應收帳款，應付帳款和固定資產。如圖1-1所示，這四個模塊本身是相互集成的（圖中以連接模塊的線條代表模塊間的集成），比如當用戶對應收，應付和資產三個明細分類帳進行操作時，系統會自動更新總分類帳中的數據。圖1-1財務四大基礎模塊這四大基礎模塊可以構成一個獨立的會計軟件–它具有和其他會計軟件一樣的特征：帳務處理和業務處理是分開的。所謂業務處理是指企業日常運作的具體業務，比如根據銷售定單和定單履行情況開出銷售發票；根據采購定單和收貨情況校驗收到的發票；以及所有的庫存收發業務等等。而所謂帳務處理是指財務人員根據原始憑證（包括外部的，如發票，和內部的，如入庫單）編制會計分錄，在系統中記錄下來。對于一般會計軟件而言帳務處理和業務處理是分開的，它們之間是通過單據在企業內部其他部門和財務部門間的傳遞和核對完成的，同時財務人員需要利用專業知識分析業務和編制分錄。同時除了最基礎的借貸，科目和金額以外，財務人員可能還需要手工錄入一些附加信息，以利于日后做一些簡單的匯總分析，這些附加信息是以憑證輸入時的附加字段體現的。圖1-1右下角紅色的粗箭頭代表了這種分開處理的過程。雖然大方向上是一致的，但是不同的軟件之間在功能上還是會有很大的差別的，圖1-1中列舉了一些這四大基礎模塊的功能。模塊外部的紅色箭頭是需要手工輸入的功能，模塊內部的則是系統可以自動完成的功能。事實上有些功能已經體現了ERP業務處理和帳務處理統一的特征，比如圖1-1中的紅圈所示的自動付款功能。集成下的財務會計如果ERP的財務會計模塊僅僅是一般會計軟件的功能延伸和加強，那它不會在最近的10年間對全球企業的財務實踐帶來如此巨大的變革。而ERP本身的集成性，決定了它的財務會計模塊完全融入到了企業整體的流程中，圖1-2描述了在集成環境下的財務會計模塊。圖1-2財務會計和物流的集成在物流領域有四個基本的模塊：銷售，生產，采購和庫存管理，企業物流管理的流程和功能不是本書所要討論的內容，圖1-2中我們大致例舉了一些物流模塊的基本功能（在圖中各模塊內部）。在下面我們要著重介紹的是物流模塊和財務會計的集成關系，本章主要介紹以下7個集成點：銷售開票，銷售發貨，采購收貨，發票校驗，其他收發貨，盤點和估價。銷售開票銷售開票的過程其實是在ERP系統中生成一帳開票憑證（BillingDocuments）。發票，形式發票，紅字發票和貸項憑證都是不同類型的開票憑證。我們通常提到的發票（如增值稅專用發票或普通發票）是根據系統中的開票憑證在金稅系統中套打出來（或直接套打出來）的實物憑證。在下文中如果不特別指明實物發票，那“發票”都是指系統中保存的開票憑證。ERP系統是集成的，而銷售開票又是銷售流程的最后一個環節。因此發票在系統中不是孤立的，它一般是參照先行的其他憑證（如銷售定單或發貨單）建立的，系統會根據一定的規則自動的復制這些先行憑證的信息，從而使得開票的過程盡可能的簡單，也防止了錯誤的產生。發票的結構發票由一個發票抬頭和多條行項目構成。在發票抬頭系統保存了關于整張發票的信息，比如付款方（客戶），開票日期，整張發票的凈金額，幣種，付款條款，國際貿易條件，售達方（有時候付款方和售達方是不同的），價格條款（比如針對整張發票的折扣）。行項目中保存了僅對該行有用的信息，比如商品，數量，該行凈金額，重量和體積，參照憑證的編號（比如，該發票針對的發貨單號），價格條款（比如貨款，運費，折扣，增值稅等等）。可以發現系統中的發票所保存的信息大大超過了實物發票所需要的，在套打實物發票時，系統會根據各國家和企業的規定選取相關的信息，按規定的格式打印出來。開票方式從參照憑證（定單或發貨單）生成發票，系統提供了如下一些可能的方法：只要某些數據吻合，你可以合并多張不同的憑證（銷售定單和/或發貨單）的全部或一部分，開出一張發票。前提條件是：首先，需要從這些參考憑證中復制的發票抬頭數據在這些憑證中都是一致的。其次，拆分開票的條件不成立。比如在處理到期的開票清單時，系統會合并那些具有相同的客戶編號，銷售組織和開票類型的參照憑證，如果上述的前提條件都滿足，系統將開出一張發票。如果你希望在某些情況下發票是分開的，比如希望同一張交貨單上的很多商品按不同的商品組分開開票，那么可以通過定義拆分開票規則來實現。當然你也可以針對每張銷售憑證開一張發票，比如每張發貨單一張發票。在具體執行開票時，系統提供了如下方法：定單或發貨單個別開票。我們可以針對整張定單，個別行項目或行項目的部分數量進行個別開票。手工處理到期開票清單。我們可以使用到期開票清單來處理開票，在這種情況下財務人員不需要針對某張銷售定單或發貨單單獨開票。我們只需要輸入選擇條件，系統會自動挑選那些符合條件的定單或發貨單，生成到期開票清單。經過手工編輯和模擬后就可以實際開票了。后臺自動處理到期開票清單。為了減少處理時間和人力，可以將到期開票清單的處理安排在系統后臺完成，比如每天下午4點由系統自動生成。財務會計過帳當開票這一業務處理在系統中完成后，通過ERP系統的集成功能，在財務會計模塊會自動生成相應的會計分錄。圖1-2中“開票”標簽所指的箭頭就代表了這種自動過帳。但是為了增強靈活性，也可以對于某些類型的開票憑證自動凍結過帳，這樣在流程設計時在正式過帳前可以加入控制點。而當控制完成后，過帳也僅僅是一個按鈕的工作了。對于會計科目，系統是綜合4個數據自動判斷的，它們分別是銷售組織，客戶組，商品組和價格條款。這樣系統可以自動將貨款和增值稅分別計入“產品銷售收入”和“應交稅金-增值稅-銷項”科目中。同樣的，如果價格條款中還有運費和折扣，可以分別計入“產品銷售收入”的二級科目中。此外這種科目確定的機制也使得我們可以根據銷售組織，客戶組和商品組設置二級或三級科目。不過需要指出的是雖然系統提供了這些靈活性，但是在實際實施中我們未必需要這樣做，特別是當我們同時實施了盈利分析模塊時，此類分析將沒有必要通過科目來完成。盈利分析將在第4章中具體介紹。對于金額的確定，系統是根據發票中各價格條款的金額來決定的。定價功能是ERP銷售模塊的一個非常有力也非常有趣的功能。本書不做詳細的介紹。有一點需指出的是我們在實施時，可以根據企業的實際情況和管理要求，決定開票時是直接從銷售定單復制價格呢，還是允許修改或重定價（這種配置是基于發票類別的）。對于定價功能和科目自動確定功能的一個應用是消費稅的計算和過帳，我們可以在銷售定價模板中增加一增一減兩個價格條款，它們的計算規則是貨款的百分比，兩者分別指向“產品銷售稅金和附加-消費稅”和“應交稅金-消費稅”科目，同時消費稅率維護在和商品相關的定價表中。因為消費稅是價內稅，所以我們的實物發票中并不體現，但是財務會計上卻即時地記帳了。這個問題的另一個解決方法是月末定期地運行報表計算消費稅額，并自動批輸入過帳。兩者都是可行的，也都可以自動生成納稅申報表，前者的好處是記錄的實時性，從而有利于盈利分析。折扣和折讓如果銷售已經完成，但是客戶對于產品的質量或者別的方面存在異議，雙方協商以折扣和折讓的方式處理。在系統中可以有如下3種處理方案：第一：用貸項憑證的形式來處理折扣和折讓。貸項憑證在系統中和發票一樣，是一種不同類型的開票憑證。貸項憑證可以參照發票或者貸項憑證申請來創建，而且既可以針對整張發票也可以針對部分行項目，還可以針對行項目中的部分數量。使用貸項憑證申請，我們可以走正規的客戶投訴和扣款流程，保證完善的內部控制。如果我們不準備對實物發票，特別是增值稅發票做任何處理，那么通過配置，可以讓系統自動生成如下會計分錄：借：產品銷售折扣和折讓貸：應收帳款-客戶明細。對于這種處理方法需要注意如下兩點：第一，貸項憑證沒有增值稅發票作為原始憑證，因此在我國是不能減少增值稅銷項額的，因此折扣應該給不含稅價，否則折扣中的增值稅部分就只能由銷售方作為費用多承擔了。但是在實際業務中這往往會使雙方的業務人員夾纏不清，無法理解。第二，正由于貸項憑證沒有發票做原始憑證，在我國的實施中可能會引起企業所得稅上的麻煩。但這種方案的優點是明顯的：它不涉及對原增值稅發票的處理，而眾所周知，這類處理在我國是非常難的。第二：用取消發票并重開來解決折扣和折讓的問題。取消發票在系統中會生成反方向的紅字發票和沖銷會計分錄，業務人員取消原發票后重新開票，并更改價格條款。從實物發票的角度，會有如下兩種情況：1如果對方能夠返還兩聯增值稅發票,我們可以開出紅字發票，其中記帳聯作為減少銷項稅的原始憑證。其他三聯和返還的原發票的兩聯應妥善保管。2如果對方不能返還兩聯中的任何一聯，必須做如下操作：客戶應從當地稅務部門取得退貨或折扣證明單并交給銷售方。銷售方開出紅字發票，其中兩聯作為其減少銷項稅的原始憑證，另兩聯交給客戶。第三仍然用貸項憑證的功能，只是通過配置，讓系統自動生成如下會計分錄：借：產品銷售收入借：應交稅金-增值稅-銷項貸：應收帳款-客戶明細，金額為折扣金額。同時開具實物紅字發票，金額為原發票金額。再根據折扣后金額重開實物發票。將紅字發票和重開發票同時作為貸項憑證的原始憑證。需要注意的是ERP中在很多情況下使用貸項憑證，貸項憑證是直接以后續的調整金額記帳的。但是我國增值稅管理要求對于增值稅發票變更的處理，一般都是先用紅字發票沖銷，隨后在對變更后的金額開具發票。所以在實施中要么仍然使用貸項憑證的方法，只是實物紅字發票和重開發票兩者一起作為貸項憑證的原始憑證，如本節中的第三種方案和下一節中的第二種方案。要么在ERP流程中也使用這種先沖銷，再重開的方式，如本節中的第二種方案和下一節中的第三種方案。不過這兩種方案都避免不了紅字發票難開的問題，這已經不是ERP系統的問題，在實務中企業也會考慮其他的避免方法，比如本節第一種方案和下一節中第一種方案，以避免開紅字發票。退貨對于客戶投訴的另一種解決方法是退貨。在系統中有3種處理方案：第一：標準的退貨流程。首先是建立退貨憑證，退貨憑證可以是針對銷售定單或針對發票。當貨物實際退回時，倉庫參照退貨憑證做入庫處理，系統自動生成會計分錄借：存貨貸：產品銷售成本。如果需要補貨，那么做補貨的發貨處理，系統自動生成會計分錄借：產品銷售成本貸：存貨。這種情況不影響開票和實物發票。第二：如果客戶不要補貨，而要退回貨款，那系統將針對退貨開出貸項憑證，并自動生成如下分錄：借：產品銷售收入借：應交稅金-增值稅-銷項貸：應收帳款-客戶明細，金額為退回部分的售價。同時財務人員開具紅字發票，金額為原發票金額。再根據退貨后余額重開發票。將紅字發票和重開發票同時作為貸項憑證的原始憑證。第三：對于不要求補貨的退貨，我們也可以不建立退貨憑證，而直接取消原發票（對應紅字發票），退貨入庫后，再重新開出發票（對應重開的增值稅發票）。返利返利是指根據客戶或者經銷商在一定期間里的購買量，而定期返還給他們的款項。在銷售模塊，我們需要維護返利協議。在返利協議中，必須指明：<1>誰可以得到返利。<2>返利的標準。<3>協議的有效期。<4>是否需要在會計上記提返利。同時銷售部門需要維護各種產品或產品組的返利比例。返利比例可以是直線的，也可以是坎級的：對于越大的購買量，返利比例也越高。銷售模塊會跟蹤所有和返利相關的開票憑證。根據返利協議計算返利的金額。在協議有效期內可以先定期結算部分返利，在最終結算時，系統會自動扣減累積的部分結算的返利。從財務會計的角度看，返利會有如下影響：<1>根據預提比例，系統可以自動預提返利費用。分錄如下：借：產品銷售收入或銷售費用貸：預提費用<2>當返利協議結算時，系統會自動生成貸項憑證申請（Creditmemorequests），申請批準后，系統會自動生成分錄如下：借：產品銷售收入或銷售費用貸：應收帳款-客戶明細。該筆貸方的金額或者直接和該客戶原先帳戶中的未清發票對清，或者在發生貸方余額時，納入付款流程。同時自動沖銷先前的預提憑證。由于返利和貸項憑證沒有增值稅發票作為原始憑證（以雙方的返利協議結算報告作為原始憑證），在我國的實施中可能會面臨一些麻煩，因此企業有時候會用票面返利的形式處理，所謂票面返利是指返利不記錄在表內科目里，而是在表外另行記錄。返利的金額被用于扣減今后銷售定單的價格而不是直接對清發票或者付款。但是這樣的處理往往在系統配置上較為麻煩，對于今后的分析也不夠清晰。收入的確認從上文的介紹，我們會發現一個問題：ERP標準設置是在開票時確認銷售收入，而在交貨時結轉銷售成本。系統本身是不保證收入和成本配比的，這主要是因為兩者各有支持的原始憑證（發票和出庫單）。對于這個問題我們認為：除非是行業特殊性造成的原因，收入和成本的配比，主要應當從流程的角度通過控制開票和交貨的時機來解決，比較理想的狀態是開票直接指向交貨，交貨后即時開票或者定期（每天或至少月底）開票。我國的增值稅法也要求企業在銷售交貨之后應當及時開具增值稅專用發票。但是，在有些情況下企業由于種種原因無法實現這種流程上的匹配，就需要一些別的功能和手段來實現這種匹配：<1>在期末執行收入確認程序調整收入。當使用這種方法時，開票時，系統不直接確認銷售收入，而是計入“遞延收入”科目：借：應收帳款-客戶明細貸：遞延收入貸：應交稅金-增值稅-銷項（如果是服務業，則沒有稅金行）。當期末執行收入確認程序時，系統根據預先設定的規則確定當期應確認的收入，做分錄如下：借：遞延收入貸：主營業務收入。具體的規則可以是根據實際交貨或確認的服務，也可以是根據期間分配收入（如長期合同的收入）。<2>類似的處理是在交貨時不結轉成本，而是先計入“遞延成本”，當實際開票時將“遞延成本”確認為“產品銷售成本”。<3>對于大型項目來說，收入和成本是通過項目定期的結果分析計算出來的，而不是開票以及成本的原始憑證決定的，兩者之間的差額通過調整“預提”和“存貨”等科目實現。關于項目管理和結果分析我們將在第10章中介紹。其他還有一些方法，比如走寄售流程，或者建立客戶虛擬庫，但是這些方法一方面會增加操作的步驟和復雜程度，另一方面也曲解了業務本身，變成了為了會計處理而改變業務流程，有點得不償失。最后，仍然想重申的是：除非真正源自行業的特殊性，否則應盡量考慮從流程的角度解決這個問題。畢竟實施ERP的目的之一是簡潔流暢清晰的企業運作，舍棄一些模糊混亂帶來的“好處”是值得的。銷售發貨銷售定單的交貨是銷售定單執行的一個環節，通常會先于開票環節。在ERP中交貨是一個多步驟的過程，包括交貨單（交貨申請），揀配，包裝，裝載，裝運和發貨過帳等步驟。其中大多數步驟屬于物流管理的范疇，好的ERP軟件提供了整個交貨過程的全程監控，包括交貨期管理，自動確定裝運點等等功能。從財務會計的角度集成出現在發貨過帳這個步驟，此時系統通過庫存管理模塊的自動記帳功能，生成了會計分錄，更新了總帳。一般我們配置自動記帳功能時，讓系統生成如下分錄：借：產品銷售成本貸：存貨。存貨的計價既可以是標準成本，也可以是移動平均價或個別認定的批次成本。但是對于制造型企業來說，由于實際成本必須在月末才能得到，而發貨是實時的，所以此時一般應使用標準成本，到月末再根據實際成本重估庫存和產品銷售成本。圖1-2中“銷售發貨”標簽指向的箭頭就代表了這種集成。同時可以發現銷售發貨本身是銷售模塊和庫存管理模塊的一個集成點，它是由倉儲部門完成的，實現的又是銷售業務的一個步驟。采購收貨采購定單的收貨是采購定單執行的一個環節，通常會先于發票校驗。和銷售發貨類似，采購收貨本身是采購和儲運部門的共同職責，同時系統通過自動記帳功能，生成會計憑證。一般手工或簡單會計軟件的記帳，要求收貨要等到收到發票以后再入帳，如果月末發票未到就暫估入帳。這樣做是為了方便會計工作，但是一方面這樣容易造成庫存帳實不符，另一方面雖然平時的工作簡化了，但是卻增加了期末的核對工作。ERP系統是一個實時的系統，同時又講究帳實相符和集成。因此它采取了收貨和發票校驗兩個業務都記帳，兩者通過“商品采購”（或稱為“貨或發票未到”）科目對清，同時還能完成三單匹配（指采購定單，收貨和發票校驗）的內部控制機制。關于采購收貨的系統自動帳務處理我們在下一小節發票校驗中一起介紹。發票校驗發票校驗功能充分顯示了ERP系統的高度集成性，圖1-2中是以“發票校驗”標簽指向的箭頭表示的。該功能從采購模塊的采購定單和收貨中獲取信息。當發票校驗完畢并過帳時，數據被自動傳入財務會計模塊。在發票校驗時很重要的一點是參照采購定單和收貨單，這樣系統可以自動檢查發票的內容，單價并計算準確性。當發票過帳時，系統會在供應商的帳戶上創建一條未清項，它會在財務會計的付款業務中被結清。在配置系統時我們還可以規定每個系統操作者能夠處理的最大發票金額。輸入發票輸入發票時可以有三種選擇：<1>參照采購定單。此時我們只需要輸入采購定單號。系統會自動建議發票的數量，金額，稅率和付款條款（指到期日和現金折扣比率）。因為實際收到的發票可能和這些缺省值有差異，所以缺省值是可以更改的。當我們輸入發票時系統會通知我們這些差異。我們可以設置對于單條發票行的差異的容差。如果差異小于容差，它們將被系統接受。如果它們大于容差，我們將收到系統的警告信息，通知我們檢查該發票，但是仍然可以過帳。如果容差的上限被超出了，這張發票仍可過帳，但是對它的付款將被凍結。只有當財務會計通過另外一個操作釋放這張發票后，這張被凍結的發票才可以被付款。當我們過帳發票時，系統將自動生成會計憑證。<2>參照采購收貨單。此時應付帳款會計輸入收貨單號，系統查找并建議相應的數據。每筆收貨單都將被這樣結算。當然我們也可以輸入采購定單號，系統會幫助查找此采購定單相關的收貨單。<3>不做參照。最后也可以不參照任何憑證輸入發票，這時可以手工輸入發票項，分別計入總帳，存貨或固定資產。財務會計過帳采購收貨和發票校驗完成后都會在系統中自動生成會計憑證，科目可以在系統配置時預先設定。自動記帳的科目和金額的處理受到存貨計價方法和收貨與收發票的先后次序等因素影響。具體規則如下：ERP系統有兩種典型的存貨計價方法：標準成本和移動平均價。如果發票晚于收貨，根據存貨計價方法的不同自動記帳的科目和金額會有所不同：如果是標準成本法，價差將計入“發票價差”科目。價差包括收貨時標準成本和采購定單價格的差異，也包括發票校驗時采購定單價格和發票價格的差異。如果是移動平均價，收貨時直接按采購定單價格計入存貨價值。收發票時的價差，如果庫存充足則直接更新庫存價值，如果庫存低于發票數量，則按比例一部分更新“庫存”價值，一部分計入“發票價差”科目。如果發票早于收貨，那么收發票時按發票金額計入“商品采購”科目，如果采用標準成本法，收貨時價差計入“發票價差”科目。如果采用移動平均價，收貨時按發票金額更新“庫存”價值。這些規則聽起來有點復雜，但主要是因為各種情況的排列組合比較多，所以只要看看下面的具體例子就很好理解了。例一標準成本法/先收貨標準成本:1.2元/件 庫存數量:100件采購定單:1.3元/件 數量:100件收貨 : 數量:100件發票: 1.24元/件 數量:100件這種情況下，系統自動記帳如表1-1。表1-1“標準成本法/先收貨”的自動記帳科目收貨發票校驗存貨120+發票價差10+6-商品采購130-130+應付帳款-供應商明細124-此時，該物料數量，金額和成本的變化如表1-2: 表1-2物料數量，金額和成本變化數量金額標準成本開始時100件120元1.2元/件收貨后200件240元1.2元/件收發票后200件240元1.2元/件例二移動平均法/先收貨/庫存充足初始移動平均價: 1.2元/件 庫存數量:100件采購定單: 1.3元/件 數量:100件收貨 : 數量:100件發票: 1.24元/件 數量:100件這種情況下，系統自動記帳如表1-3。表1-3“移動平均法/先收貨/庫存充足”的自動記帳科目收貨發票校驗存貨130+6-商品采購130-130+應付帳款-供應商明細124-此時，該物料數量，金額和成本的變化如表1-4: 表1-4物料數量，金額和成本變化數量金額移動平均價開始時100件120元1.20元/件收貨后200件250元1.25元/件收發票后200件244元1.22元/件例三移動平均法/先收貨/庫存不足初始移動平均價： 1.2元/件 庫存數量:100件采購定單: 1.3元/件 數量:100件收貨 : 數量:100件領用: 數量:120件發票: 1.4元/件 數量:100件這種情況下，系統自動記帳如表1-5。表1-5“移動平均法/先收貨/庫存不足”的自動記帳科目收貨發票校驗存貨130+8+發票價差2+商品采購130-130+應付帳款-供應商明細140-此時，該物料數量，金額和成本的變化如表1-6: 表1-6物料數量，金額和成本變化數量金額移動平均價開始時100件120元1.20元/件收貨后200件250元1.25元/件領用后80件100元1.25元/件收發票后80件108元1.35元/件例四移動平均法/先收發票初始移動平均價: 1.2元/件 庫存數量:100件采購定單: 1.3元/件 數量:100件發票: 1.24元/件 數量:100件收貨 : 數量:100件這種情況下，系統自動記帳如表1-7。表1-7“移動平均法/先收發票”的自動記帳科目發票校驗收貨存貨124+商品采購124+124-應付帳款-供應商明細124-此時，該物料數量，金額和成本的變化如表1-8: 表1-8物料數量，金額和成本變化數量金額移動平均價開始時100件120元1.20元/件收發票后100件120元1.20元/件收貨后200件244元1.22元/件增值稅上文的例子為清晰起見，都沒有考慮增值稅。實際在輸入發票時，如果是增值稅專用發票，我們也輸入稅碼（包含了稅率的一個參數）和稅額。系統會自動檢查含稅價，稅率和稅額是否正確。如果存在差異，系統會提示一個警告信息，但是我們仍然可以將其過帳。如果是不含稅的發票（比如運輸發票和農產品收購），系統可以自動計算稅額。如果發票的每行稅碼不同，系統會分行處理。當發票過帳時，增值稅會自動計入“應交稅金-增值稅-進項”科目中。收貨成本計劃內的收貨成本包括以下類型：運費，關稅，保險費，包裝費等等。對于每種類型，我們可以決定成本是固定的，基于數量的還是收貨貨款的一定百分比。計劃內的收貨成本可以在采購定單的每一行項中輸入。當收貨時這些成本被計入庫存，對方科目是一個特殊的清帳科目（比如：“商品采購-運費”）。當采用移動平均價時分錄如下：借：存貨貸：商品采購-貨款貸：商品采購-運費。在發票校驗時，我們可以列出某張采購定單，收貨單或供應商的所有收貨成本，從中選擇出正確的收貨成本的發票。系統生成分錄如下：借：商品采購-運費貸：應付帳款-供應商明細。計劃內收貨成本也會在采購定單歷史報表中即時顯示。計劃外的收貨成本也可以用發票校驗輸入。系統自動將它們根據各行項目的金額分配下去。如果需要，我們也可以手工分配這些成本。計劃外的收貨成本直接計入庫存，分錄如下：借：存貨貸：應付帳款-供應商明細。其他收發貨實際上上文提到的銷售發貨和采購收貨只是庫存移動的兩種移動類型。庫存移動是指引起庫存變化的業務。主要包括：收貨。指從供應商或生產定單接收庫存并過帳。收貨導致倉庫存貨的增加。發貨。指存貨的領用，消耗或交運至客戶并過帳。發貨導致倉庫存貨的減少。移庫。指存貨從一個庫存地點轉移到另一個庫存地點。移庫既可以是在同一個工廠，也可以是跨工廠的（工廠是ERP中決定存貨估價，MRP等的重要組織結構）。轉換。是一類特殊的存貨變化的總稱。它和存貨是否發生物理上的移動無關。比如：將存貨從一種物料代碼轉換成另一種；將存貨從質檢貨狀態釋放；將存貨從寄售商品轉換成自有庫存。系統使用“移動類型”來分類管理庫存移動的各種不同的種類。在ERP系統中使用物料憑證來管理和記錄所有的庫存移動，物料憑證中包含了移動類型，工廠，庫存地點，物料編碼，數量，批次等等信息。系統通過物料憑證來追蹤和證明庫存移動，同時物料憑證打印出來就是我們通常所說的出入庫單。同時物料憑證的輸入也不是孤立的，系統通常會根據情況自動建議收發貨的數量，地點等等，比如根據采購定單收貨，根據生產定單領用原材料。可以說庫存管理是ERP物流的中心環節之一，它連接了采購，生產和銷售等各個環節。ERP的庫存管理講究的是實時地記錄和反映現有的庫存情況：收發貨及時記錄進系統，系統自動更新庫存的當前狀況，既可以以各種報表的形式提供給庫存管理者即時的信息，又通過集成直接參與其他的功能中，如MRP，銷售的可用性檢查等等。從財務會計的角度來看，庫存移動既反映了庫存數量的變換，同時還代表了價值的轉移。因此大部分的庫存移動需要在財務會計上進行反映。上文中我們已經介紹過銷售發貨和采購收貨，倉管人員只負責存貨數量的記錄，而不需關心其價值。系統根據一定的規則來決定存貨的價值，同時根據自動科目確定自動生成財務會計憑證（參見上文采購收貨的財務會計過帳）。會計憑證和物料憑證在系統中是相互勾稽的，而且能直接從任何一張中進入另一張的顯示。庫存移動的自動科目確定是一個智能化較高的功能，系統配置也較復雜，但是簡單地說，系統是根據<1>移動類型<2>各行的性質（如是庫存行還是對方行）<3>物料主數據<4>工廠等信息決定會計分錄中每一行的科目。這里我們再介紹兩種重要的移動類型：<1>原材料生產領用，系統自動記帳如下：借：生產成本-原材料貸：原材料。原材料的估價方式可以是標準成本或移動平均價。<2>產成品入庫，系統自動記帳如下：借：產成品貸：生產成本-生產