OK需求分析.docx
- 文档编号:28587932
- 上传时间:2023-07-19
- 格式:DOCX
- 页数:32
- 大小:707.86KB
OK需求分析.docx
《OK需求分析.docx》由会员分享,可在线阅读,更多相关《OK需求分析.docx(32页珍藏版)》请在冰豆网上搜索。
OK需求分析
項目編號:
UFNC-OK
項目名稱:
澳門工藝資訊化專案
文檔編號:
UFNC-OK-B01
澳門工藝有限公司
OK便利店(澳門)有限公司
NC資訊化需求分析報告
甲方簽字確認:
__________________
日期:
__________________
前言
本文檔是依據OK便利店(澳門)有限公司(以下簡稱OK便利店)對財務業務資訊化專案的需求,在參考相關資料的基礎上結合用友軟體股份公司(以下簡稱:
用友公司)多年來在企業資訊化專案上積累的豐富經驗編寫的。
該文檔屬專案調研分析報告。
該報告屬於確定系統建設大方向的文檔初稿,具體實際的細節和內容可能未能一一列出,系統實現的細節在方案測試中會進行增刪和修正,直到通過測試。
文檔使用對象
澳門工藝及OK便利店高層領導;
OK便利店專案組成員;
用友公司內部領域專家和公司高層領導;
用友公司專案管理監督人員。
文檔控制記錄
基本資訊
文檔名
澳門工藝有限公司—OK便利店(澳門)有限公司資訊化需求調研報告
項目名
澳門工藝資訊化專案
作者
姓名
角色
日期
內容
AlanLam
專案經理
2012-11-06
審批
姓名
角色
日期
內容
文檔更新記錄
版本號
更改人
日期
更改原因
1.1
Alan
2012-11-14
修訂採購、銷售業務補充庫存、成本、及MP整體規劃
1.2
Alan
2012-11-30
加入採購、庫存、成本詳細需求分析
1.3
Alan
2012-12-16
整體內容完善
目錄
一、調研活動總結4
1.1.調研目的4
1.2.調研方式4
1.3.調研時間及調研內容4
二、專案背景5
2.1.企業背景5
2.2.專案現狀及本期規劃與目標5
2.2.1.項目現狀5
2.2.2.本期專案規劃6
2.2.3.本期專案目標6
三、現行系統及業務原型描述7
3.1.BO系統功能及處理的業務描述7
3.1.1.BO總體功能概況7
3.2.採購業務描述8
3.2.1.原型業務流程8
3.2.2.用戶需求分析9
3.2.2.1.系統實現流程(用戶需求)9
3.2.2.2.流程及用戶需求詳細描述10
3.2.3.財務處理方式11
3.3.銷售業務描述11
3.3.1.原型業務流程11
3.3.1.1.普通商品銷售11
3.3.1.2.繳費服務12
3.3.1.3.澳門通增值消費業務12
3.3.1.4.泊車卡銷售13
3.3.1.5.银柜收支:
收制服押金,購買店铺低值品13
3.3.1.6.收款公司收款14
3.3.2.用戶需求分析15
3.3.3.財務處理方式17
3.4.庫存管理業務及成本計算18
3.4.1.基本業務流程及分析18
3.4.2.成本計算描述19
3.4.3.用戶需求分析19
3.4.3.1.系統實現流程(用戶需求)19
3.4.3.2.流程及用戶需求詳細描述20
3.4.4.財務處理方式21
3.5.總賬21
3.5.1.用戶需求21
四、MP系統總體規劃23
4.1.MP系統功能描述23
4.1.1.MP總體功能概況23
五、報表的清單24
一、調研活動總結
本次調研是根據OK便利店(澳門)有限公司要求而進行的調研。
調研主要針對OK便利店財務業務系統及統計分析要求;針對OK便利店的財務與供應鏈總體管理現狀和需求進行了調研,重點瞭解了其採購業務、銷售業務、庫存管理業務、材料成本計算、應收應付業務。
1.1.調研目的
瞭解和描述客戶資訊化系統的現狀
瞭解和描述客戶採購業務流程及專案需求
瞭解和描述客戶銷售業務流程及專案需求
瞭解和描述客戶庫存管理業務流程及專案需求
瞭解和描述客戶材料成本計算流程及專案需求;
1.2.調研方式
訪談調研:
顧問現場拜訪主要管理者、關鍵用戶,單獨交流。
實地考察:
顧問到客戶工作現場參觀和瞭解實際發生業務時的操作。
1.3.調研時間及調研內容
1.3.1.訪談調研
時間
具體調研內容
調研顧問
客戶配合人員
2012-11-05上午
對OK便利店資訊化系統現狀及採購、銷售、應收應付、庫存管理實際業務初步調研
Alan
Raymondlung
Raul、Joshua
Celia
2012-11-09下午
對11月5號調研的進行講解和確認
Alan
Raul、Joshua
Celia
2012-11-13
上午
對庫存管理業務、材料成本計算進行調研
Alan
Raul、Celia
2012-11-23
採購業務用戶需求詳細調研
Alan
Raul、Celia
2012-11-30
上午
庫存、存貨用戶需求詳細調研
Alan
Raul、Celia、Raymondlung
二、專案背景
1.
2.
2.1.企業背景
CircleK為世界最規模的連鎖便利店之一,「OK便利店」早於1951年創立於美國德克薩斯州,是一家24小時營業的國際性連鎖便利店,至今分店網路遍佈美國、日本、香港及東南亞多個市場,總數達10,000家,全球每週顧客人次達二千多萬。
OK便利店(澳門)有限公司于2004年成立,第一間分店在2005年3月開張,現在澳門有23間分店;業務更拓展到珠海,有15間分店。
OK便利店(澳門)有限公司引入澳門首個全面性的集體供應鏈及零售管理於一整體的平臺,系統通過資訊中心,連接店鋪電子銷售系統、中央分發中心、財務會計部門、以及採購、營運、管理等支援部門,對應貨物採購、分配配送、店鋪訂貨、貨物接收及陳列,到最終銷售,環環相扣。
令我們對顧客的購物習慣及需求更為熟悉,幫助我們有效地提供顧客所需的產品售賣,使我們「OK便利店」能在澳門建立連鎖便利店的地位。
母公司MacauIndustrialLimitada在澳成立於1949年,目前集團員工總數超過壹仟名。
OK便利店服務宗旨,快捷(Speed),整潔(Tidiness),友善(Friendliness)去服務顧客。
OK便利店在澳門已開業七個年頭,成為市民日常生活的一個常接觸的品牌,為消費者委員會誠信店一員,常與澳門及國際不同商業機構合作;為澳門市民提供日常便利的商品及服務。
2.2.專案現狀及本期規劃與目標
2.2.1.項目現狀
OK便利店(澳門)有限公司的絕大部份業務資料經由香港資訊系統處理,包括銷售、採購、庫存、應收應付、總帳;澳門公司只負責對資料進行手工核對,確認後回饋香港相關人員,再由其錄入資訊系統。
澳門公司所需的報表或業務資料需要經由IT人員在香港資訊系統中抽取並處理才能得出。
2.2.2.本期專案規劃
通過二次開發和用友NC標準產品的結合,把OK便利店(澳門)有限公司日常經營的業務資料從香港資訊系統(以下稱BO系統)中對接過來,在用友系統及二次開發的系統中進行資料處理,入帳等賬務操作。
二次開發的系統定義為MP系統;MP系統的功能包括以下方面:
1、接收BO系統的採購資料,並對資料進行核對和處理。
2、接收BO系統的銷售資料,並對資料進行核對和處理。
3、接收BO系統的庫存資料,並對資料進行核對和處理。
4、接收BO系統成本資料,結合採購、銷售、庫存等資料進行材料成本計算。
5、把處理完畢的資料,根據實際需求導入用友NC系統相應模組和最終把資料處理成GL系統中的財務資料。
2.2.3.本期專案目標
1、開發MP系統,把資料處理系統從香港轉移到澳門
2、實現MP系統到用友NC系統的對接形成GL資料
3、實現系統高度集成,業務資料及財務資料能直接互通
三、現行系統及業務原型描述
3.
3.1.BO系統功能及處理的業務描述
1
2
3
3.1
3.1.1.BO總體功能概況
BO概況描述:
現行BO系統主要功能包括三大部份:
採購、銷售、庫存管理。
三部份資料以每一間店鋪為主體獨立產生相關業務操作記錄;對於採購結算和銷售結算的業務,是根據對各店鋪資料匯總並確認後,再統一進行收付結算。
3.2.採購業務描述
3.2
3.2.1.商品採購原型業務流程
流程描述:
a)由店鋪下達採購訂單,供應商根據訂單向店鋪送貨
b)店鋪收貨後簽署送貨單,並按送貨單內容(送貨單號碼、貨品名稱、數量、供應商名稱)把送貨單錄入BO系統。
c)每天店鋪人員從BO系統匯總送貨單資訊形成採購報告,由專人收集報告並交回公司後臺人員,後臺人員把報告掃描進電腦系統後存放好。
d)BO系統中送貨單與當日的成本資料結合形成應付帳款並在GL生成憑證。
e)供應商提供符合格式的電子月結單,月結單直接導入MP系統並與MP系統中的送貨單進行對賬。
對賬內容有:
日期、供應商、送貨單號、收貨店鋪、貨品、數量和金額。
f)對賬內容完全一致的送貨單可付款結算並生成付款憑證;月結單金額少於送貨單並且其他內容一致的送貨單,按照月結單金額付款結算並生成相應調整憑證。
其他情況一律擱置付款。
3.2.2.用戶需求分析
3.2.2.1.系統實現流程(用戶需求)
3.2.2.2.流程及用戶需求詳細描述
1、採購訂單、送貨單從外部系統導入形成用友採購系統相應的採購訂單和送貨單。
相同的採購訂單和送貨單資料不能重複導入。
2、採購價格表從外部系統導入,並自動匹配對應日期、供應商、存貨的送貨單把價格信息補上。
3、店鋪每天9:
00轉更,未轉更的每半小時發送預警信息到財務部。
4、檢驗BO系統的收貨數量和單據與採購系統中導入的單據進行核對。
5、在採購系統中設置存貨的金額、數量採購上限,當導入的送貨單超過設定上限時會有預警信息傳到AP相關人員。
6、送貨單在採購系統能手工增加和刪除,手工增加單據需由AP主管審批和處理。
手工增加和刪除功能需設置權限控制(備註:
NC系統的單據的所有功能按鈕都能設置權限控制)。
7、送貨單在採購系統審核後會自動生成兩張單據:
一是採購入庫單,入庫單直接進入庫存系統;一是採購發票,發票審核後自動生成應付單據。
8、供應商月結單按指定格式能直接導入。
9、A)採購系統設置自動與供應商月結單對數功能。
用戶手工選擇一定時間範圍內的採購發票和一定狀態下的單據並選擇需要對賬的供應商月結單,然後系統進行自動對賬。
對賬內容包括:
供應商名稱、收貨店鋪、送貨單號、貨品編號、送貨單日期、數量和金額。
B)送貨單設置兩種標識狀態,處理狀態和付款狀態;處理狀態有四個:
未對賬、已處理、未處理和待處理;付款狀態有三個:
部份付款、已付和待付。
C)月結單設置三個狀態,未對賬、待付款和已付款。
D)對賬時按一定範圍和條件篩選出月結單記錄和送貨單單據,對賬以送貨單單號為最小對賬單位,即同一送貨單號的全部內容進行對比,內容符合條件的通過(具體條件見F點),有一項不符合條件的就整張送貨單不通過。
通過的單據系統把送貨單和月結單相應記錄做核銷處理,把兩邊的單據關聯起來。
E)未對賬的送貨單為未對賬、待付款狀態;未對賬的月結單記錄為未對賬狀態。
送貨單狀態標識為單據級標識,月結單的狀態標識為記錄級標識。
F)根據A點對賬內容,月結單和送貨單數據完全對上的,或月結單金額、數量比送貨單金額、數量少且其他對賬內容一致的單據,對賬後送貨單標記為已處理、待付狀態,月結單相同送貨單號的記錄標記為待付款狀態;其他情況的送貨單落入未處理狀態、月結單落入待付款狀態。
G)退貨單的對賬規則基本與F點相同,不同的是按高額退貨,即月結單金額、數量比送貨單金額、數量多且其他對賬內容一致的單據視為對賬成功,送貨單標記為已處理、待付狀態,月結單相同送貨單號的記錄標記為待付款狀態;此時按月結單金額生成紅字應付單。
H)對賬成功的送貨單和月結單記錄會自動核銷,核銷後的月結單記錄才能進行付款操作。
付款按月結單金額生成付款單,生成付款單後,送貨單單據標記已處理、已付狀態或部分付款狀態,月結單相應記錄標記為已付款狀態。
I)未對賬的送貨單為未對賬、待付狀態;未對賬的月結單為未對賬狀態。
J)未處理狀態和待處理狀態的送貨單據經人為判斷單據內容後可手工勾選月結單記錄進行核銷,核銷後,送貨單標識為已處理,月結單相應記錄標識為待付款。
繼後付款操作規則參照G點。
K)對賬時金額能允許一定的容差(例如允許金額相差0.01元),即在容差範圍內也當對賬成功,容差金額需記錄統計。
L)對賬的單據範圍包括:
未對賬和待處理的送貨單與未對賬和待付款的月結單。
10、採購返利、其他收入,當收到供應商的返利時,根據返利單據在系統中錄入紅字的費用發票,然後把發票與相對應產品的入庫單進行結算把返利金額分攤到入庫成本中(可一張發票與多張入庫單進行攤分),同時紅字費用發票生成紅字應付款。
如果不需要攤入成本,則直接在應付系統做紅字應付單。
11、手工調整:
調整有以下四種情況
A)可能由於價格表錯誤,導致送貨單價格錯誤。
錯誤在當月發現,系統提供批量修改功能,能按日期、供應商、店鋪、產品過濾出送貨單,然後把新的價格全部更新;錯誤在下月供應商提供月結單時發現,因為已經結帳和成本計算,因此只能針對錯誤的存貨手工填入一張金額調整單,調整單根據上面提到的條件按每間店鋪先自動列出需要調整的存貨的結存記錄,然後手工填入正確單價,系統根據填入的單價與結存單價自動作補差計算,把差額生成到每間店鋪對應的存貨記錄中,保存調整單完成成本分攤操作。
調整單審核後生成應付單。
B)狀態調整,對賬後落入“未處理”或“待處理”狀態的單據,經過實際業務確認後,可手工修改其狀態變為已處理。
單據的各個狀態可以手工調整。
C)低額付款:
低額付款指供應商提供的月結單與送貨單除金額外所有項目都對上,月結單金額比送貨單金額少,此時OK按低額付款。
下月或以後供應商發現自己錯誤要求OK把餘下金額補付,此時需要補回差額。
因為系統之前的月結單和送貨單已對賬成功,所以這種情況直接從應付系統填入付款單。
付款單和之前送貨單產生的應付單餘額進行核銷。
在年結前供應商不要求補回差額,此時由低額付款產生的餘額系統能自動生成紅字的應付單,把餘額核銷,紅字應付單生成其他收入憑證。
D)小數差異調整:
由於匯率或四捨五入計算等情況使應付款和付款時產生一定小數差異。
對於這種差異,同樣直接在系統中做一張應付單與之前的餘額核銷,核銷后生成損益憑證。
備註:
所有未付款、部份付款、已付款的單據都能在系統中通過核銷明細表查詢出相應的結果。
12、付款通知:
付款後系統自動根據供應商檔案的email地址發送email告知供應商。
3.2.3.低值品、辦公用品採購
低值品、辦公用品的採購是指辦公室裏面文具、辦公設備、家私等物品的採購,該種採購暫不納入採購系統管理,直接用GL進行入數。
3.2.4.財務處理方式
以下的入帳規則只是簡要的描述僅作參考,系統實現時按實際情況再進行配置
序號
業務情況
入帳規則
1
購貨
DR:
材料採購
CR:
應付帳款—供應商
序號
業務情況
入帳規則
2
一般商品入庫
DR:
庫存商品
CR:
材料採購
序號
業務情況
入帳規則
3
777、999等店鋪用品、固定資產入庫
DR:
費用或固定資產
CR:
材料採購
序號
業務情況
入帳規則
付款
DR:
應付帳款—供應商
CR:
現金或銀行
3.3.銷售業務描述
3.3
3.3.1.原型業務流程
3.3.1.1.普通商品銷售
普通商品銷售:
銷售單數據從前臺BO系統導入MP,然後由MP處理輸出銷售日報表;店鋪銷售收入的現金每天經過衛安公司的收款流程在財務系統入帳。
3.3.1.2.繳費服務
繳費服務(電費、水費、中國電信電話費):
繳費資料每天從BO系統匯出發送到代收費公司,因為無法雙邊對數,所以財務以BO資料為准進行入帳。
當系統資料有錯誤,由客戶提出並提供繳費票據,票據確認後手工調整MP系統資料。
3.3.1.3.澳門通增值消費業務
澳門通增值/消費業務:
每天澳門通的增值/消費資料從BO系統中導入MP,澳門通公司也提供當日結帳資料,資料導入MP系統並與BO系統導入的資料進行核對,財務部門對已核對正確資料進行開票並與澳門通公司結算同時生成憑證;有差異的資料系統給出差異清單,查明原因後,手工在MP系統調整資料記錄,使差異資料達到一致後再進行結算。
澳門通提供的數據用於對賬的主要內容有機器號、卡號、邏輯碼、充值金額、押金、消費金額、結算金額,交易時間。
3.3.1.4.泊車卡銷售
泊車卡銷售:
泊車卡是一種寄賣代銷商品,只有在實現銷售後才會與泊車卡公司進行採購結算;當“結存量+銷售量=送貨數量”時才確認為正確,可進行結算;核對有差異時,找出差異並跟進,得出處理結果再進行手工調整,調整正確後再進行結算。
收到貨品時,同樣會進行採購入庫處理,並掛暫估應付。
每月月結時,OK財務人員向供應商提供銷售情況,供應商根據OK提供的資料開出發票,收到發票後財務人員根據發票金額進行付款。
在庫存系統中體現兩個結存量:
1、累計採購入庫數—累計銷售出庫
2、實際結存量
因為實際過程中由於種種原因可能會發生貨物的丟失,但丟失的貨物只有在與貨物供應商終止合作時才一併結算,平時按銷售數進行結算。
3.3.1.5.银柜收支:
收制服押金,購買店铺低值品
銀櫃收入、支出:
有新員工加入時,需要在工作的店鋪交納制服的押金,店鋪收到的押金會放入銀櫃並把押金入機記錄但不會計入銷售收入。
平時,店鋪會購買一些低值品,金額直接從銀櫃支出。
銀櫃收入和支出的商品都不需進入庫存系統。
3.3.1.6.收款公司收款
衛安公司收款:
每天日結時,店鋪人員把店鋪現金(港幣、澳門幣、人民幣)和優惠券分別點算清楚,店長在系統錄入日結單(日結單內容:
港幣、澳門幣、人民幣、优惠券),然後現金放入錢袋;港幣、澳門幣由衛安公司運送到銀行存入;人民幣則交回公司財務部。
衛安公司把錢存入銀行後提供ProcessingReport,財務人員根據report與MP系統的港幣、葡幣、人民幣現金收入金額對比,找出差異再做相應的處理。
現金金額=貨品銷售金額+銀柜收入-電子錢-優惠券-銀柜支出+日結現金差額+存款差額
3.3.2.用戶需求分析
綜合上面的業務,可歸納為三大類的業務流程:
1、普通商品銷售業務流程(包括:
普通商品現金、澳門通、優惠券消費的銷售業務及銀櫃收支業務)
2、服務類業務流程(包括:
水費、電費、電話費代收及澳門通充值業務)
3、收款確認業務(包括:
GF港幣/澳門存款及人民幣、優惠券收款確認)
以上是對業務流程的總括分類及其流程的初步設計,不僅限於上述提到的業務,流程可根據實際情況進行匹配及優化。
流程說明:
1、店面銷售
每天BO系統的銷售數據導入MP系統後分拆成6項數據,分别是貨品銷售數據、服務代收數據、服務費數據、銀柜收入、銀柜支出、澳門通充值數據、澳門通消費數據。
6項數據導入為一張日銷售單,其中銀柜支出和澳門通消費數據以負數項導入,其他數據項為整數導入。
服務類型銷售分兩項數據:
服務代收數據、服務費數據。
此類業務也分兩種,一是交易總金額=服務代收金額+服務費金額,如水、電繳費;二是交易總金額=服務代收金額,如中國電信,手續費是直接向中國電信收取而不是額外向客戶收取。
因此,繳費服務交易總金額=服務代收數據+所有手續費-中國電信手續費。
遵循上述公式,繳費服務交易總金額生成銷售系統的銷售訂單,訂單內容和貨品銷售一樣,但貨品不進入庫存系統核算成本,同樣訂單那會生成發票和應收單據,應收單據確認後生成憑證(憑證內容見入帳規則二)。
另外,服務代收數據會生成對應供應商的應付單據,中國電信則是服務代收數據減去手續費後的金額生成應付。
銀櫃支出和收入數據,有兩種做法,一是得出其淨額後直接生成應收單據,確認後生成憑證;二是分別把支出與收入生成應收單據,分別生成憑證。
第一種做法簡單,但總帳不能統計銀櫃支出和收入的明細;第二種方法單據及操作步驟會多一些,但總帳能直接統計出銀櫃支出和收入的明細。
(憑證內容見入帳規則三)
澳門通數據分為增值(押金按增值業務流程處理)和收費數據。
BO系統中澳門通的數據和澳門通公司提供的交易數據都先導入到MP系統進行對數處理,對數的內容有:
機器號、卡號、邏輯碼、充值金額、押金、消費金額、結算金額,交易時間。
系統根據上述內容自動進行對賬並給出差異列表,對賬成功的記錄人工確認後生成對應單據:
增值、押金記錄生成對像是一般客戶應收單據,消費記錄生成一般客戶收款單據。
如果出現差異由相關人員處理後按上述規則生成對應單據。
對賬正確後,增值、押金和消費的淨額根據實際情況生成應收或應付單據。
最後所有的應收、應付單據生成憑證(憑證內容見入帳規則四)。
手工調整數據項,在上述銷售各環節中都有可能存在需要調整的項目,當發生此類情況時可手工增加相應的調整單據。
調整單具有權限控制。
2、收款確認
每天店長根據銀櫃的澳門幣、港幣、人民幣、優惠券金額錄入日結單,收款公司把錢袋收取後存入銀行並給出存款報告。
日結單和存款報告按幣別分拆成多項數據傳入MP,日結單差異數也作為一數據項傳入MP,日結單中現金項與收款公司存款報告進行對數,對數的內容包括:
店鋪名稱、澳門幣金額、港幣金額、人民幣金額。
日結單的差異數金額、優惠券金額分別生成應收系統的葡幣收款單據;存款報告的數據也分別按幣別生成應收系統的收款單據,若存款報告有差異,則差異部份也生成收款單(日結單金額大於存款報告生成紅字的收款單,反之生成藍字收款單)。
生成收款單後,收款單與銷售應收單進行核銷確認收款。
收款單確認後生成憑證(憑證內容見入帳規則五)。
銷售業務總體說明:
1、總體流程的設計思路是把所有銷售發生的交易先進行掛賬(CashinTransit),然後再把收到的款項和掛賬核銷,從而達到銷售統計及收款確認兩個環節的管理。
2、生成的系統單據,遵循以下公式:
現金金額=貨品銷售金額+銀櫃收入-電子錢-優惠券-銀櫃支出+日結現金差額+存款差額
也就是說,流程圖上應收單據的金額總和與收款單據金額總和是相等的(貨幣匯率全部以1:
1計算)。
備註:
以上的業務流程只根據OK現狀進行分析,對於日後可能增加的業務情況,在系統會保留自定義流程的功能,可根據日後的實際情況進行增加和修改。
3.3.3.財務處理方式
序號
業務情況
入帳規則
1
規則一
商品銷售
DR:
CashinTransit
CR:
銷售收入(貨品)
序號
業務情況
入帳規則
2
規則二
DR:
CashinTransit
CR:
代收款(供應商)
CR:
銷售收入(服務費)
序號
業務情況
入帳規則
3
規則三
銀櫃收入
DR:
CashinTransit
CR:
費用/其它收入
銀櫃支出
DR:
費用/其它收入
CR:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- OK 需求 分析