網站開發合同范文
時間：2023-04-08 22:45:28
導語：如何才能寫好一篇網站開發合同，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公文云整理的十篇范文，供你借鑒。
篇1
乙方：
鑒于甲方委托乙方開發設計網站，幫助甲方樹立企業形象，擴大宣傳，拓寬銷售渠道，為明確雙方責任，根據雙方協商，簽訂此協議，以期雙方共同遵守。
一.雙方的權利和義務
1.甲方的權利和義務
1-1提供有關企業的材料及圖片，應保證材料完整，圖片清晰；
1-2為了更好的開發站點，甲方應配合乙方的調查工作；
1-3依協議約定時間使用主頁；
1-4按時支付費用；
1-5所有制作內容及開展的業務必須符合國家法律和社會公共利益，特別是公安部的《計算機信息網絡國際聯網安全保護管理辦法》。
2.乙方的權利和義務
2-1按照甲方提供的材料和要求按時完成網站的開發制作；
2-2可以在主頁中注明該網站由乙方制作；
2-3有權依協議收取費用。
二.網頁制作完成及時間
乙方按甲方要求____日后完成網頁制作，但必須在乙方收到甲方較為完整的材料之日算起，驗收后____日內傳至網上。
三.費用金額及付款方式
本協議涉及的總金額為人民幣_________元，協議簽訂時需交納%左右的訂金為_______元，驗收之后支付剩余款項。第二年費用：域名______元，空間_______元。
四.驗收標準和售后服務
1.甲方可以通過任何與因特網進行網絡連接的計算機瀏覽自己的主頁。
2.主頁無文字拼寫及圖片（以甲方提供的材料為標準）錯誤。
3.驗收合格，甲方以書面方式簽收。
4.驗收期限為____日。
5.驗收合格網上后，在維護時間（_____天）內，乙方可免費負責網站的基本內容維護和技術支持，改動較大者須收取一定的制作費用。
6.網站原則上按網站拓撲圖設計，且甲方必須認同乙方設計的框架但可以有較少范圍的改動。
五.爭議解決
本協議于其履行過程中如發生爭議，雙方應本著友好合作的精神協商解決。
六.附則
1．貴公司的LOGO我們不提供設計，網站具體設計依據貴司網站拓撲圖（附后）
2．如乙方收到甲方訂金后，甲方在10天內不提供制作網頁所需的材料，乙方有權取消該網頁制作合同同時乙方不退還訂金。
2.本協議自雙方簽訂后生效，一式兩份，甲乙雙方各執一份；
3.本協議未盡事宜，雙方應在本協議達成的原則基礎上以補充條款的方式明
確，補充條款與本協議具有同等的法律效力:
甲方乙方
代表人簽字：代表人簽字：
篇2
簽訂日期：____________________________
簽訂地點：____________________________
項目名稱：________________________項目
委托方：______________________ （甲方）
承接方：_________科技有限公司？（乙方）
為充分利用Internet商業效用，開展電子商務活動， ____________ （甲方）委托_____________科技有限公司（以下簡稱乙方）設計開發____________工程，雙方本著公平友好的原則，簽訂本合同，以茲信用。
一、合同內容和技術要求
1.合同內容：
合同內容為____________項目。
包括：網站規劃、系統設計文檔、網頁設計、技術培訓與支持。
2.技術要求：
乙方應該采用目前流行和先進的技術設計開發整個____________項目，各項功能的實現程度和性能指標應該達到現階段的先進水平，并具有安全性、規范性、靈活性及可擴展性。
二、合同價款與工期
1.合同價款：
合同總價為 :人民幣____________元整（RMB）。
2.工程工期：
工程開工之日起____________個工作日內，甲乙雙方共同完成____________開發項目。
網站建設完成后的____________個工作日內，在互聯網上試運行，確認系統結構設計完成和內容無誤后。甲方依本合同所規定的原則進行驗收。
工程驗收后，在網絡運行過程中，甲方若有新的需求，甲乙雙方協商解決。
三、甲方責任
1.甲方需對網上內容提出具體要求，若在所規定的時間甲方不能夠及時確認開發設計的內容，所造成的項目進度的延誤，乙方不負任何責任。
2.甲方需要為乙方工作人員了解具體業務提供詳細的文字、圖片等資料。
3.甲方應從合同簽署之日起，按本合同中所規定的付款方式，按時足額向乙方支付相應的費用，如甲方在沒有合理的理由的情況下，延誤或拒絕支付乙方相應費用，乙方有權單方終止合同的履行。
四、乙方責任
1.根據甲方的要求，乙方成立該項目的專門工作隊伍，承擔甲方項目開發與運作。在技術上具有先進性、主流性，各項工作具有規范性。
2.乙方應嚴格按照雙方確定的設計方案完成網站建設工作，并及時如實向甲方通報工程進度。乙方應在項目的進行中提供給甲方有關網站建設的所需資料，及準備工作所需的相關文檔和必要的行業知識指導。
3.在方案實施過程中，甲方提出修改意見，雙方友好協商解決后，對內容進行修改。
五、版權、源代碼及商業機密
1.乙方為甲方開發的網站的原代碼的所有權歸甲方所有。
2.乙方必須為甲方嚴守商業機密，不得將該工程設計和數據轉用于第三方。
3.乙方保留本合同涉及軟件、數據庫的使用權及修改權。
六、技術培訓與售后服務
1.乙方有關人員針對網站建設的相關內容進行簡單技術指導。
2. 工程驗收合格之日起提供售后技術支持與服務，期限為1年。
3. 乙方的工作日內，若甲方的網站出現故障時，甲方需提供給乙方必要的管理授權，乙方確保在獲得甲方管理授權后的24小時內解決問題。
七、工程驗收
1.網站設計開發調試完成后，乙方向甲方提出驗收申請，甲方組織有關人員驗收。若有爭議，雙方友好協商解決。若由于甲方人員不齊或工作安排沖突等原因，使系統驗收不能在3個工作日內完成，應視為驗收合格。
2.驗收過程中，若雙方意見分歧，雙方友好協商解決。
八、付款方式
1.合同簽署之日，甲方向乙方支付網頁開發預付費用，計人民幣____________ 元整（RMB）。
2.項目驗收之日，甲方向乙方支付網頁開發尾款費用，計人民幣____________元整（RMB）。
九、違約責任
1.在合同有效期內，因不可抗力而造成一方不能履行合同規定的責任和義務，不視為____________ 違約。不可抗力系指：戰爭、火災、水災、地震、臺風及其他不可預見并且對其發生和后果不能防止或避免的事故。
2.甲方應按照合同規定及時足額向乙方支付相應的網站開發費用，逾期支付，每遲付一日，違約金為合同總價款的____________%.
3.乙方應保證按照合同規定的進度將系統通過驗收并交付使用，若逾期交付，每遲交付一日的違約金為合同總價款的____________%.如延遲交付超過____________日，甲方有權單方解除合同。
十、合同所涉及的服務及款項（貨幣單位：RMB）
服務內容
數量
金額
備注
首頁__________________________________________
普通頁________________________________________
新聞系統？________________________________
解決方案__________________________________
產品系統？________________________________
應用實例__________________________________
BBS論壇_______________________________________
頁面加鎖功能__________________________________
合計__________________________________________
十一、其他
1.在系統設計開發過程中若系統方案有任何變動，應以備忘錄的形式由雙方的主管人員或授權人員簽字確認。
2.甲方明確承諾對本合同的價款保密。
3.對本合同條款未盡事宜，合同雙方應本著友好合作原則，協商解決。
4.本合同自簽定之日起生效。本合同一式貳份，雙方各持壹份。
甲方：_______________ 乙方：______________
地址：______________ 地址：______________
代表：______________ 代表：______________
電話：______________ 電話：______________
篇3
在明確定位了專業人才培養目標的基礎上，就可以繼續確定專業“課程設置”、“教學實踐”、“課程管理和考評”等相關內容，從而構建一個完善的教學體系。
(一)課程設置
高職電子商務專業課程應根據專業人才培養目標，按照精要、實用的理論教學體系，能力主導的實踐教學體系，全方位滲透的綜合素質養成體系的三大體系進行設置。營銷、管理、網站開發和維護、信息處理等方面都要有所體現，尤其是營銷、管理、信息處理等課程在實踐教學中更要努力引進新內容，保證知識不斷更新，使實踐能力要求始終與社會需要保持一致，實踐效果能滿足企業實際需求。
(二)教學實踐
教學主要由理論教學和實踐教學兩部分構成。理論教學以知識傳授為主，實踐教學以技能、技術培訓為主。由于電子商務很強的應用性，實踐環節也自然地成為教學環節中的重要部分。學校采用的實踐教學方式一方面是實驗室實訓，另一方面是校外實習。要加強實踐教學，除了實驗室實訓和校外實習方式外，還必須搭建相應的實踐環境，把校內實訓企業化，把校外實訓教學化。
校內實訓包括生產性實訓和非生產性實訓。校內生產性實訓可以注冊公司；校內非生產性實訓可以是模擬教學軟件實訓或工作情景仿真（工作室）模擬實訓。電子商務專業實驗教學是通過軟件模擬操作，使學生對電子商務的實務運營有較深刻的認識，以達到電子商務實踐環節要求。模擬實驗需要涵蓋電子商務的典型模式、網絡營銷、網絡貿易、電子合同、物流管理、網上銀行、電子錢包、網上證券、EDI中心、自助建站開發平臺、企業網站創建、企業內部工作等環節的運作，還要具有較強的操作性，與實際緊密聯系，真實地模擬出實際操作的關鍵環節。所謂工作室是在校內實訓基地設置電子商務運營所涉及的所有工作部門的真實的崗位，對各崗位任務進行說明，同時對任務所需的知識和技能進行說明，進行應用全面的專業綜合訓練。由營銷、物流、網站建設等多名相關學科教師共同上課，讓學生充分了解工作過程中的所有工作崗位任務、掌握完成任務所必需的知識和技能，讓學生在每一個工作部門進行輪崗實訓，掌握每一崗位的技能。同時，還要對每一個工作過程進行見習，對實際工作情景進行了解。
校外實訓包括崗位實訓和實習。學生在校學習期間要到校外實訓基地進行短期實訓，并由實訓指導教師或聘用工作單位的一線專業人員進行指導教學。實習是教學的重要環節，時間為一學年。由于電子商務是一個新興的領域，其發展程度和地區的經濟有著密切的聯系，因此實習選擇發達城市為突破口，在省內及發達地區建立實習就業基地，采用訂單實習、頂崗實習、頂崗就業實習、自主實習、創業實習等多種方式，多渠道、多層次、全方位地進行實習工作。實習期間制定實習教學計劃，安排專業教師或實習單位的專業人員進行實習指導。
二、課程管理和考評
嚴肅認真的課程管理才能收到好的教學效果，無論是理論課還是實踐課都應加強管理。課程管理主要包括過程管理和考核方式管理兩個方面。過程管理伴隨整個教學過程，理論課程可以通過布置課后作業的方式管理體現學生學習和鍛煉的過程，實踐環節可以通過讓學生完成實驗報告、實習報告的方式來培養學生理論聯系實際的作風和分析問題、解決問題的能力。考核是檢驗教與學效果的重要手段，應實現最大限度仿真模擬職業行為與標準進行考核；實現對教學與實訓的全過程實施考核；實現學生全員參與考核。
考核手段與方式可以靈活多樣，實現立體化、多元化和網絡化。例如電子商務課可以讓學生提交一個作品，作品可以是一個淘寶網店，也可以是網店中的某個寶貝或店標、公告等的技術技巧的操作示范。這樣更能刺激學生的學習欲望和創業興趣，激勵學生課下去自學、研究。再比如營銷課可以通過讓學生提交調查報告、某產品銷售方案等方式進行考核等。合理的考核方式不僅能準確的評價教與學的實際水平和效果，更能反過來促進教與激勵學。
篇4
一、扶持對象
在我縣注冊登記且進出口統計和納稅均在我縣的企業。
二、扶持內容
（一）鼓勵企業開展各類管理體系認證和產品認證。對出口企業在本年度完成的各類認證并取得認證證書的，按其認證費的50%給予資助，單項資助金額不超過1.5萬元。
（二）鼓勵企業爭創“出口名牌”。對企業在境外注冊商標并在本年度取得相應注冊證書的，按其商標注冊費的50%給予資助，單項資助金額不超過2萬元。
（三）鼓勵企業開拓國際市場。對參加境外各類進出口商品展覽會的企業，每個標準展位補貼攤位費2萬元，每增加一個標準展位，增加補貼1萬元，同一企業同一展會補貼不超過3萬元。
（四）鼓勵企業投保進出口信用保險。對向中國出口信用保險公司投保的，按其實繳保費的20%給予資助，每個企業最高支持標準不超過5萬元。同一企業不重復享受縣級資金扶持。
（五）鼓勵企業境外專利申請。對企業獲得的境外發明專利申請、實用新型專利申請或外觀設計專利申請，按縣政府促進科技創新創業政策予以獎勵。
（六）鼓勵企業應訴進出口公平貿易案件。對出口企業參加商務部、國家（省）各類進出口商會、行業協會統一組織的對進口國的進出口公平貿易案件的應訴及復審費用，給予不超過5萬元的補助。對企業單獨應訴、復審的案件，給予50%的律師費補助，支持金額不超過10萬元。同一企業不重復享受。
（七）鼓勵企業設立境外貿易機構。對經過批準，在國外設立貿易機構并實際運行的中方投資者，給予2萬元的開辦費補助。
三、申報材料要求
符合申報條件的企業須報送以下材料：
（一）縣促進外貿發展若干扶持政策資金申請表（詳見附表）；
（二）營業執照復印件；
（三）對外貿易經營者備案登記證書或外商投資企業批準證書；
（四）相關費用支出憑證復印件并加蓋單位財務章；
（五）根據申報項目類型，其他須提供的材料：
1.申請各類管理體系認證和產品認證資助須提供認證證書復印件、產品認證的檢驗檢測報告復印件、與認證機構簽訂的合同復印件。
2.申請境外商標注冊資助須提供境外商標注冊及標識復印件。
3.申請出口名牌獎勵須提供評審組織部門的認定文件或證書復印件等證明材料。
4.申請境外參展補貼須提供組展方的收費通知或展位費結算明細復印件、出國人員任務批件復印件（因私簽證的提供出國護照及簽證頁復印件）、機票復印件、參展照片。
5.申請進出口信用保險資助須提供項目申報單位與中國出口信用保險公司的合同復印件。
6.申請高新技術產品出口獎勵須提供海關出口證明。
7.申請設備進口獎勵須提供海關報關單、設備進口訂貨合同復印件。
8.申請境外專利申請資助須提供專利證書復印件、項目申報單位與被委托方的合同復印件。
9.申請國際電子商務資助須提供網站首頁復印件及網址、項目申報單位與網站開發制作單位的合同復印件。
10.申請出口基地企業做大出口規模獎勵須提供省級以上出口基地認定文件。
11.申請進出口公平貿易資金支持須提供案件總結材料（內容包括企業概況、案件背景、應訴過程及結果、經驗教訓等）、案件結案材料等。
12.申請設立境外貿易機構補助須提供境外貿易機構批準證書、境外貿易機構注冊文件及資金、設備投入證明復印件（外管或海關等部門出具）等相關材料。
13.申請出口產品研發資助須提供研發項目可行性報告、研發項目的查新報告，高新技術產品證書復印件，近兩年審計報告等相關材料。
篇5
關鍵詞：土地流轉；信息化管理；圖形驗證碼；站內搜索
中圖分類號：TP311.52文獻標識碼：A文章編號：1007-9416（2017）10-0153-01
農民擁有長期穩定的土地承包經營權，運用土地使用權的流轉，加強土地利用率，確保農村產業化經營。農村土地承包與流轉管理平臺，主要提供政策和法律法規宣傳、咨詢，土地供求信息匯總、流轉合同簽證、流轉糾紛調解、登記簿批量打印、經營權證書等一條龍服務，減少農村土地承包和流轉糾紛，規范土地流轉行為，保護供求雙方的合法權益。并通過大力招商引資，引進業主發展現代農業，加快城鎮一體化發展的步伐。
本平臺框架設計為1+3，就是一網三子平臺。一網指的是農村土地承包和流轉綜合服務，在一定程度上它屬于一種網絡門戶，而且根據相關的法律法規和信息公布的條例來看。信息平臺的平臺，合同管理的平臺和土地流轉的平臺，在整體系統分布上都是采用的矩陣式架構。平臺采用B/S技術，基于.NET框架，使用C#語言開發。使用大型數據庫，實現信息的海量存儲，采用三層架構設計，保證系統的可靠性與穩定性。
1系統關鍵技術
1.1B/S結構
B/S我們通常情況下也管它叫做瀏覽器或者是服務器。隨著互聯網的不斷興起，在一定程度上C/S這種結構得到了極大的改善。B/S可以在任何地方不需要安裝任何專門的軟件，就可以直接信息操作，操作既簡單又便捷。而且只需要一臺電腦就可以正常的使用，在一定程度上，客戶端可以通過系統維護的方式，加強了系統的擴展和訪問。
1.2SQLServer2008數據庫管理系統
SQLServer作為微軟的搜索的大型數據庫管理體系，在一定程度上它更方便，人們的使用。同時SQLServer2008作為一個重要的產品版本，在推廣的過程中，經過了不斷的改進和系統的更新，已經成為全世界最為強大的SQLServer版本。
SQLServer2008在微軟的平臺上，可以更好地幫助企業加以管理。通過結構化、半結構化和非結構化的同時，進行一定的內置服務。而且在數據進行搜索和查詢的過程中也會將不同的數據儲存在設備中，保證設備的運行。從數據中心的服務器開始到桌面的計算機和移動設備都在不同的更新著。
1.3訪問安全性處理技術
系統登錄時，會要求用戶輸入一定的用戶名和密碼，這樣的操作程序是為了確保用戶使用過程中的合法性和安全性。如果不是合法的用戶，也無法訪問相應的網址和該頁面，即使用戶知道了某個頁面的地址也無法訪問，所以系統會率先提示用戶要先登陸，取得合法的信息。
1.4圖形驗證碼生成技術
驗證碼的功能一般是防止使用程序惡意注冊、暴力破解或批量發帖而設置的。我們通常所說的驗證碼就是一串隨機性的符號兒生成的一些圖片數字或者是文字。在一定程度上，這些都是可以用肉眼直接識別的。通過輸入相應的網站、信息驗證等驗證成功后才可以安全性的使用。本系統中的用戶登錄頁面中就使用了圖形驗證碼技術。生產一個圖形驗證碼需要三步：（1）隨機產生一個長度為N的字符串，該字符串可以包含數字、字母等。（2）將隨機生成的字符串創建成圖片并顯示。（3）保存驗證碼。
1.5站內全面搜索
通過站內搜索的方式有很多種，網站開發人員和根據搜索的范圍大小進行設置，系統設置的搜索功能主要是根據應用SQL語句中的Like運算符進行模糊查詢。Like運算符用于在確定了字符串是否匹配的同時，模式往往是按照常規字符合通配字符來進行配比的，只需要語字串符相互匹配就可以了。
1.6數據分頁顯示
使用DataList控件綁定數據并實現分頁。DataList控件是一種數據綁定控件，其分頁功能是借助PagedDataSource類實現的，該類封裝了數據控件的分頁屬性。
2平臺總體設計與實現
2.1系統首頁和系統登錄
進入系統首頁后，系統用戶和管理員在登錄系統之后，需要輸入相應的用戶名和密碼。在輸入了相應的密碼和驗證碼的同時，系統用戶在輸入過程中，會將輸入的密碼和密碼數據加以比對。
2.2信息功能實現
從農村土地承包與流轉管理是影響較為深刻的，而且在一定程度上信息的及時和溝通可以加快對于信息過程中的管理。可以方便實現的功能有政策法規、土地百科、農業新聞、法制時空、本站動態等信息的。
2.3合同管理功能實現
農村土地經營權流轉合同書在簽訂的過程中它是包含了土地承包經營權的一種法律文書，在交易雙方進行交易的過程中是為了保障雙方的合法權益的。所以農村土地承包和流轉管理平臺，在一定程度上會提供合同的管理功能，合同的管理可以清晰的分析出每一筆交易的成功信息。這些信息既包括了土地坐落位置、轉讓限制交易方式的權利和義務，以及違約責任驗證單位和各種約定事項。農村土地承包和流轉管理平臺的管理，在一定程度上既包括了合同的管理模板的管理。合同管理主要是對已簽訂的合同進行管理，模板管理提供了簽訂合同所使用的合同模板。
2.4土地流轉功能實現
具有權限的用戶可以土地求購信息，并在“流轉資訊”欄目，符合條件的農戶可根據這些信息與者聯系。
3總體性能指標
系統性能需求主要從系統響應時間、并發數等方面對目標系統進行定義。業務請求響應的平均時間≤4s。系統登錄最長時間≤4s（2000用戶并發時）。最大并發用戶數≥2000
除了上述性能指標之外，還要具備很多功能性要求：可靠性：系統的安裝環境要求是Windows2007以上的版本在一定程度上系統的兼容性非常好，可以通過數據自動保存在系統出現異常時也可以對于數據及時的恢復，確保系統的安全可靠。易用性：平臺在一定程度上界面較為整潔，而且還可以通過人性化的提示，便于用戶可以正確的操作學習系統。
4結語
篇6
關鍵詞：高職；電子商務；創新創業；實踐平臺
中圖分類號：G710 文獻識別碼：A 文章編號：1001-828X（2016）033-000-01
電子商務是當前我國最具發展潛力的行業，電子商務專業則是高職課程體系的重要組成部分。實踐內容單調，實踐課程教學效果不佳，是高職院校高職電子商務實踐教學中存在的普遍性問題。為了解決這些問題，許多高職院校都加強了電子商務創新創業實踐平臺建設。
一、高職電子商務創新創業實踐平臺的作用
我國電子商務出現時間較晚，電子商務對于許多人來說都是一個新事物，高職院校電子商務專業建設至今發展不過數十年的時間。高職電子商務學科是一門對學生實踐能力、創新能力和操作能力要求極強的學科。過去，許多高職院校在電子商務專業教學中都存在著重理論輕實踐的認知錯誤，但是，隨著電子商務產業的不斷發展，高職院校不得不加大了電子商務專業實踐教學投入。不過，即便實踐教學在電子商務專業教學中所占的課時比例不斷增加的情況下，由于缺少在仿真、全真的職業環境中實踐的機會，高職電子商務實踐教學水平并不高，高職電子商務創新創業實踐平臺構建也勢在必行。高職電子商務創新創業實踐平臺不僅是學生進行專業相關技能的操作平臺，還是能模擬企業電子商務實現和經營全過程的操作平臺。高職電子商務創新創業實踐平臺構建的作用和意x在于，它為學生技能操作和鍛煉提供了便利，學生可以通過平臺操作檢驗自己的知識水平，培養和提高自身的綜合素質，為自己將來發展打好基礎。
二、高職電子商務創新創業實踐平臺構建和開發策略
1.高職自主開發策略
所謂高職自主開發模式，即由高職院校自己做主，自行組織師資力量進行電子商務創新創業實踐平臺建設的模式。這種開發模式對高職院校的師資力量、資金基礎等都有較高的要求，對于許多實力較弱、發展時間較短的高職院校來說，這種模式并不是最佳選擇。究其原因，電子商務創新創業實踐平臺涉及范圍較廣，它涉及通信、美工、網站、計算機等方面的工作，高職院校只有在計算機專業技術人才和教師人數眾多、技術水平較高的情況下，才能完成電子商務創新創業實踐平臺自行開發與建設任務。許多高職院校在此類電子商務創新創業實踐平臺構建中，經常將之以科研的形式來進行，那些開發能力較強、人力資源基礎雄厚的高職院校可以嘗試一下這種開發模式。通常來說，高職電子商務創新創業實踐平臺所包含的版塊有有電子商務外包、淘寶創業、網絡營銷服務、電子商務網站開發、網絡廣告策劃與推廣等工作室等，實踐平臺的功能由網上銀行認證支付、網絡交易、網上配送、個人交易、網上商城等，高職院校要注意的是，確保實踐平臺的機能與企業實際工作情景匹配，并確保學生電子商務專業學習與平臺包含內容有一定的關聯。
2.校企合作構建與開發
產學研結合是高職教育發展的必由之路，校企合作則是高職院校培養創新創業人才的重要途徑，校企合作同樣是高職電子商務人才培養的需要。過去，許多高職院校與企業合作的最高表現就是校企攜手搭建校內校外生產實訓基地，為學生實踐實習提供機會。但是，許多高職院校在長時間的嘗試中發現，實訓基地雖然能為學生實習提供機會，但是許多時候，商務電子專業的學生在實訓中使用的電子商務模擬軟件與真實的電子商務交易有明顯出去，學生根本無法掌握電子商務的精髓。于是，電子商務創新創業實踐平臺這種最接近企業實踐的實訓平臺及其建設就逐漸成為校企合作的重點。高職電子商務創新創業實踐平臺校企合作開發模式為：高職院校借助電子商務平臺運營商提供的平臺來運行具體的項目，讓學生通過線下操作和線上運營來了解電子商務的交易法則，熟悉其交易流程，進而激發學生的創業夢。不過在這種模式中，平臺運營商在校企合作中占據主導地位，學校在平臺構建、運作和項目選擇上的選擇權有限。高職院校要想通過這種構建模式提高學生的實踐水平，還需要做出更多的努力。
3.學校與軟件公司合作開發模式
除去與自主開發、與企業合作開發和構建電子商務創新創業實踐平臺外，許多高職院校還借助于軟件公司合作共建電子商務創新創業實踐平臺。這種電子商務實踐平臺構建模式的重點是，軟件公司與學校以合同為基礎，軟件公司為高職院校電子商務實踐平臺建設提供技術人員，學校則要為其提供物力、財力和人力，然后通過雙方合作構建電子商務實踐平臺。這種構建模式使雙方的優勢得以互補，因為有專業的技術團隊做保障，所以它能有效滿足電子商務實踐教學需求。不過，在平臺后續功能增設、拓展上，學校還需要付出更多的時間與軟件公司進行溝通與合作。
參考文獻：
[1]王慧.關于高職電子商務創新創業實踐平臺的構建[J].職教論壇，2011，29：43-44+47.
篇7
隨著網絡的發展，采用通過客戶選擇的旅行社為客戶預約機票以及酒店形式的傳統旅游電子商務，無法適應網絡客戶個性化要求，存在信息封閉以及共享性差的弊端。異構網絡的問題出現在旅游電子商務系統與旅游企業信息系統中，導致它們之間的業務流程對接無法實行，不同旅游企業的封閉式信息系統使企業之間做不到資源共享，用戶在搜索旅游資訊時受到限制，不利于網絡規模效應的產生[1]。因此，尋求有效的網站將各平臺、各語言匯總起來，確保大規模企業信息處理系統同電子商務系統間完成連接。處理該問題的最佳措施是基于XML的WebService技術，其不受平臺和網絡通信的限制，能夠重復使用代碼以及數據，可基于已存在的異構載體建立相通的技術層，有效處理旅游企業信息系統同旅游電子商務系統間的信息集成問題。因此本文設計并構建了基于Web技術的旅游網站，將中小旅游企業的商品統一起來，并建立一個大型的旅游網站，提高旅游網站的服務質量。
1Web技術的旅游網站開發與實現
1.1系統架構
基于Web技術的旅游網站架構如圖1所示。從中能夠看出，該旅游網站主要包括旅行社管理信息系統（TIS）以及旅游電子商務系統（TEC）。該架構結構中，在UDDI注冊中心采用Internet對供應商（旅行社）進行搜索和發掘，可以通過TEC系統的Web服務來實現，并迅速地統一為各供應商TIS提供Web服務；網絡客戶在預約旅游行程時就可通過瀏覽器進入TEC系統。充分發揮Web服務的有關技術[2]，有利于此結構對旅行社管理信息系統以及旅游電子商務系統進行統一重組，為不同的供應商（旅行社）帶來利益。
1.2Web服務提供方TIS的設計
旅行社信息系統（TIS）是Web服務供應方，其在確保旅行社內部營業能夠順利進行的同時，還要具備把Web服務注冊到UDDI注冊中心的能力，以及相關的Web服務插口，便于向TEC系統發送線路商品和對TEC訂單申請的接納。
1）供應商管理板塊是對旅行社供應商（含有供應交通、餐飲、景點服務的商家以及其他協作的旅行社）的有關數據信息進行處理。
2）系統管理板塊是指系統監管者在全體旅行社信息系統中維持系統客戶權責的操控、數據報備、系統數據設定等。
3）Web服務板塊有兩大性能，分別為：為了方便對其業務有合作想法的商業合伙人在UDDI注冊中心搜索企業的有關內容，將旅行社企業的相關情況在UDDI注冊中心做登記[3]；管理客戶（調整其Web服務的申請方）身份驗證服務、商品（旅游線路）發表服務和線路預約服務。
1.3TIS的Web服務設計
Web服務供應方的UML用例圖用圖2來描述，其通過可視化的形式對系統性能要求進行解釋，包含兩種關聯，分別為基于一般程序的“角色”（即與系統交叉的其他實物）關聯和系統中事例間的關聯。觀察圖2得出，TIS的Web服務板塊實現的前提是UDDI注冊性能的建立[4]，將身份檢驗服務、產品發表服務、線路預約解決服務提供給Web服務申請人。在微軟的UDDI.NETSDK基礎上實施UDDI注冊，對UDDI注冊中心信息的類以及相應的UDDI程序員規范1.0的API進行發表與優化。
1.4Web服務請求方（TEC系統）的設計
1.4.1TEC的功能模塊
旅游電子商務系統（TEC）能為網絡客戶預約在線線路。身為Web服務的申請人，各旅行社提供的旅游服務是其線上販賣的商品（旅游線路），也就是說，旅行社企業系統提供的Web服務被其在UDDI注冊中心發掘，在網絡客戶預約旅游線路的過程中，通過后臺與有關旅行社進行B2B貿易。將TEC的性能板塊分成以下幾點：
1）商品（旅游線路）管理板塊體現的是商品的管理性能，提供Web服務插口以便系統在UDDI注冊中心對有關的Web服務實施發掘，且根據Web服務插口與有關的TIS系統實施交叉，得到TIS系統供應的商品情況，并在商品數據庫中變更其商品情況。
2）訂單管理板塊管理網絡客戶的訂單，將訂單申請送達到有協作關系的旅行社系統（TIS）提供的Web服務接口。
3）系統處理板塊表現為在系統后臺系統監管者對全體TEC實施管理監管[5]。可將TEC系統的Web服務設計和Web服務客戶端設計劃分成兩類，包括UDDI搜索性能以及Web服務統一，其目的分別為搜索隱藏的合伙人，調整Web服務供應方提供的Web服務。
1.4.2TEC系統的Web服務設計
Web服務請求方法TEC的UML用例圖用圖3描述，分析圖3可得，Web服務客戶端包括：UDDI檢索性能，可檢索到潛在的合作伙伴；實施Web服務的集成，以及完成對Web服務提供方提供的Web服務的調用。本文采用微軟的UDDI.NETSDK開發實現UDDI搜索，Web服務申請方在UDDI注冊中心搜索的適用范圍可劃分成四類：FindBusiness類封裝了find_business函數的調用[6]，能夠對旅游相關的商業實體信息實施定位；FindTModel類封裝find_tModel函數的調用；FindService類封裝find_service函數的調用，實現相關服務的定位；FindBinding類封裝find_binding函數的調用，實現相關綁定信息的定位。
.Net編程中，TEC系統的UDDI搜索是在上述每類事例構建的基礎上，采用調整事例的有關手段完成。詳細的操作如下：從旅行社獲得BusinessKey，通過捆綁的tModelKey以及BindingTemplateKey獲得旅行社提供的Web服務的進入接入點和進入的描述內容。發掘搜索到的隱藏旅行社的系統，對其系統接口模式進行研究，此旅行社的信息系統就被Web服務客戶端承襲，商品（旅游路線）信息和訂單申請的獲得分別在旅行社系統以及旅行社系統提供的Web服務接口，旅行社與旅游電子商務網址間完成了B2B貿易。
TEC系統在客戶端TEC的編碼中引進已構建的Web服務類，并構建Web服務類的事例，將Web服務同調整類實例的方法做連通。
1.5系統功能設計
本文設計的基于Web技術的旅游網站涵蓋不同的旅行路線、旅行產品信息、用戶基本信息的接收和處理，其流程圖用圖4描述。
本文設計的旅游網站包括客戶端和管理端。客戶端主要包含6個職能：客戶注冊登錄、修改資料和密碼、訂單下達、查看訂單及查看信息資料[7]。管理端可以實現后臺的運營管理，包括修改密碼、會員管理、商品管理、訂單管理和路線管理5大職能。
1.5.1數據庫設計
本文設計的基于Web技術的旅游網站屬于小型的Web系統，由Tomcat以及MySQL聯合建立的數據庫能在JAVA程序中進行編程，可提升網站的安全指數。該數據庫設計包括用戶、管理員、旅游線路及旅游商品的E？R圖，分別如圖5和圖6所示。
基于Web技術的旅游網站的數據表包括管理員表、用戶表、商品表、旅游線路表、線路訂單表和商品訂單表6種。管理員需要的數據保存在管理表中；用戶的個人信息如用戶名、電話等存放在用戶表中；旅游產品信息如商品名稱、價格、商品編碼等都記錄在商品表中；旅行線路表包括線路的設定、線路名稱價格等信息；線路訂單表反應了用戶選擇的旅游線路；商品訂單表反應用戶選擇的商品。旅游線路數據圖用表1描述。
1.5.2前臺訂單處理模塊
基于Web技術的旅游網站的前臺訂單處理與前臺框架互不聯系，所以業務處理需單獨建立新模塊。前臺訂單處理主要解決客戶查看推出的旅游線路，線上下訂單、查看訂單等一系列活動，具體包括下達訂單處理流程、查詢線路及商品信息、增加旅行線路、查看合同列表及合同提交界面。下達訂單處理流程向用戶推薦線路[8]、時間等選項，客戶選擇完畢后將信息傳輸至文件ftime.jsp和etime.jsp中。查看線路和商品信息模塊還可了解路線情況。在添加線路訂單模塊下，從Orderservlet.java系統中可得到session對象、登錄信息等，得到數據狀態后可得到訂單信息。如果客戶在訂單處理模塊下沒有下單會出現NULL，同時回到前臺顯示框；若客戶下達旅行線路訂單后系統自動建立一個以Vector為對象的訂單，則客戶的訂單信息將出現在訂單列表中。訂單列表子模塊中如果存在訂單，則在session中有顯示；反之，則無。查看訂單列表只能是登錄的客戶，所以在訂單列表中還需添加兩個表單用來清空和提交訂單[9]，來驗證用戶是否登錄。用戶的登錄信息完成后，網站自動將信息保存在數據庫中，訂單處理模塊流程如圖7所示。
2實驗結果與分析
2.1測試方法
對于旅游網站性能的測試技術主要有黑盒以及白盒測試，白盒測試需要內部算法的具體數據，主要是一些對程序編程很熟練的程序員進行單元測試。黑盒測試對系統的要求不高，只需要通過窮舉技術對網站未來可能發生的情況進行測試，不需要依靠網站實現方式及邏輯結構進行分析。因此，本文依靠黑盒測試方法，按照使用步驟對輸入的數據進行實驗，對本文設計的基于Web技術的旅游網站的功能以及性質實施測試。
2.2功能測試
功能測試是檢驗系統各項指標是否正常，這要求工作人員對系統各項的性能指標非常了解，才能寫出正確的功能測試用例。基于功能測試用例，檢測本文設計的旅游網站不同功能的運行結果，如表2所示。能夠看出，本文旅游網站的各項功能運行正常，滿足用戶的需求。
2.3性能測試
性能測試利用自動化技術對不同狀態下系統的性能進行測試，如正常值、峰值或異常狀態。性能測試分為負載測試和壓力測試。負載測試主要測試在負載慢慢加強時本文旅游網站能否支撐整體的運行，以尋找網站的最大負載壓力[10]，便于對網站進行升級。壓力測試對大型網站來說非常重要，超出了網站的瓶頸或極點時會導致系統崩潰，測試壓力的極值使網站的運行得到提升。本文設計的旅游網站對簡單申請以及復雜申請的響應結果如圖9和圖10所示。
分析圖9可得，申請響應時間組成了兩邊下降的閉合曲線，本文設計的旅游網站在開始以及結束時刻的申請響應時間較低，隨著用戶數量的不斷提升，旅游網站的響應時間呈現降低趨勢，總體響應時間具有較高的穩定性，響應時間集中在200ms以內，能夠確保旅游網站的正常運行，并且具有較高的運行效率。
分析圖10可得，復雜申請的檢測結果同簡單申請的檢測結果相同，說明本文設計的旅游網站的處理能力較強，具有較強的承壓能力。
3結語
篇8
一、充分認識國際國內市場開拓工作的重要性
當前，國際金融危機還在發展和蔓延，世界經濟短期內難以復蘇，外部需求持續低迷，我縣經濟形勢依然嚴峻。大力開拓國際市場，深入開發國內市場，堅持國際與國內市場相互結合、相互促進，是應對國際金融危機沖擊的迫切需要，是貫徹落實省委、縣政府“標本兼治，保穩促調”方針的重要舉措。各鄉鎮、縣級機關各部門、各有關企業要進一步統一思想，充分認識開拓國際國內市場、搶抓訂單的重要意義，切實把抓好國際國內市場開拓工作擺在更加突出的位置。
二、加大企業參展扶持力度，提高參展成效
鼓勵企業參加國內外展會和專業性展會。企業參加縣政府組團，展位統一設計裝修，展示吉區域品牌或產業特色的專業性展會，給予企業展位費30%的補貼（主要用于展位布置）。每個企業當年境內參展補貼最高不超過20萬元。企業參加亞洲、中東地區境外展，每個展位由原來補貼0.8萬元調整為1.2萬元。每個企業當年境外參展補貼限額從20萬元提高到30萬元。《工業經濟三十條政策》第二十二條的其他條款不變。
三、加快建設境內外營銷網絡
推動一批有品牌優勢和市場基礎的企業到境內外設立地區銷售總部、專賣店，鼓勵通過并購獲得國際銷售網絡。對我縣企業在境外新開設的專賣店，縣財政給予當年度租用場地等費用一定比例的資助。對企業赴境外收購品牌或并購、參股，投資額在300萬美元以上的項目給予補助人民幣20萬元。行業協會、組展單位組織同一行業企業赴地級市以上政府所在地的專業市場進行統一銷售的，組織10個以上企業且面積在2000平方米以上的，給予整體補助10萬元；組織20個以上企業且面積在5000平方米以上的，給予整體補助20萬元。省級以上品牌企業在國內地級市以上政府所在地以專賣、連鎖形式構建終端市場營銷網絡且單個營業用房（統一形象設計）面積在100平方米以上，經認定，10個以上的一次性獎勵20萬元；20個以上的一次性獎勵50萬元，50個以上的一次性獎勵80萬元。對國內營業面積在1000平方米以上的直銷點，一次性補助10萬元，500平方米以上的一次性補助5萬元。
四、借助電子商務等手段開拓國際國內市場
積極開展電子商務應用培訓，引導和幫助企業借助阿里巴巴、網盛生意寶、環球資源網等電子商務平臺獲取商務信息和出口訂單。對于年度確定為大企業（集團）培育對象和成長型中小企業，企業當年度利用境內外知名商務網絡平臺開展貿易活動，對首次的網站開發費用、網絡服務費，給予50%的補助，累加補助額最高不超過1萬元。
五、千方百計加大對企業開拓市場的服務力度
加大開拓國際國內市場的政策扶持。縣經貿委、外經貿局、工商、質量技術監督、海關、檢驗檢疫等部門要加大對企業開拓市場的服務力度，幫助企業及時解決實際困難。外匯管理、銀行、保險等部門要加大對企業開拓市場的外匯結算、貿易融資、資金信貸等支持力度，積極開展出口訂單抵押貸款、出口退稅質押融資、出口信保質押融資等信貸業務。加強政策宣傳，組織符合條件的企業積極申報中央和地方的政策扶持項目，指導企業用足用好相關政策。
六、鼓勵企業參加出口信用保險，提高企業開拓國際市場的抗風險能力
支持和引導企業投保出口信用保險，加大對企業投保出口信用保險的保費資助比例。凡企業參加出口信用保險，保費補貼從40%提高到50%，同一企業補助最高限額從30萬元提高到40萬元。
七、著力提高我縣產業和產品核心競爭力
篇9
關鍵詞：電子商務會計；確認方式
隨著社會經濟環境的不斷運動與科學技術的進步，會計也在不斷地演變和發展。特別是電子技術的發展、網絡經濟的出現、電子商務的飛速發展，會計核算手段也從手工操作發展到全面機械化、電子化和網絡化。
一、電子商務會計的概念
關于電子商務會計的概念，學術界探討極少，至今沒有明確的解釋。莊明來教授認為“所謂的電子商務會計，是對電子商務活動的完整的會計反映，包括電子商務的會計確認、計量、記錄與報告。電子商務會計立足于實際運作的電子商務活動，但它又必須有一整套理論框架作為其基礎。它既要對完全電子商務加以核算，也要對不完全電子商務進行核算。”
二、電子商務會計對傳統會計確認的沖擊及其確認方式
會計確認在手工會計中并非新的話題。由于電子商務是一種新的商務模式，在原有經濟業務基礎上，出現了很多新型業務，比如電子商務網站建設、在線采購和銷售商品、在線提供和接受勞務、在線支付或收取款項等。在電子商務時代背景下，電子商務網站的建設成本、新的產品形式―數字化產品的確認、電子商務收入的確認面臨一些難題。本文僅對其中電子原始憑證、數字化商品、網站建設成本等確認的關鍵問題進行探討。
(一)會計電子原始憑證的確認
會計確認即通過會計賬戶要對所發生的經濟業務確認其對應的會計要素，同時，確認各該經濟業務要在何時進入所對應的會計賬戶之中。在將經濟業務轉化為會計賬戶之際，首先涉及的是各該項經濟業務的真實性認定。
1.會計電子原始憑證對傳統會計確認方式的沖擊
會計憑證是記錄經濟業務、明確經濟責任，作為記賬依據、審計依據、稅務稽查的書面證明。會計主體發生任何一項經濟業務，完成該項經濟業務的有關人員應及時填制或取得會計憑證，在會計憑證中詳細記錄該項經濟業務的內容，為明確經濟責任，記錄人員要在會計憑證上簽名或蓋章，審核人員對會計憑證進行審核并簽章，經審核無誤的會計憑證作為記賬的依據。
(1)電子原始憑證的合法性確認
一切企業單位，在辦理各種經濟業務時都必須取得或填制原始憑證。電子商務過程所產生的憑證必然是電子形式的憑證，不再是傳統的紙質憑證，這類憑證由于其是會計處理的數據源，故其確認也就顯得十分重要。《電子簽名法》中的數據電文應當已經包括了電子的原始憑證，因而電子簽名的會計原始憑證合法性自然應當被承認。但是我國會計法律、法規中并未提及電子原始會計憑證，這就給電子原始憑證的合法性確認帶來困難。
(2)電子原始憑證的真實性確認
隨著信息新技術的發展，傳統的手書簽名已被新的數字認證手段代替。在電子商務環境下，電子數據的確認標記應當是電子簽名，對于電子原始憑證中的電子簽名，由于其處于肉眼看不到的網絡之中，數據的認定遠比手工會計中的紙質數據認定困難。
2.會計電子原始憑證確認策略
由于《會計法》是指導會計工作的主要法律規范，因此我國應當盡快修訂《會計法》，確認電子原始憑證的合法性；盡快研究電子發票等重要的會計原始憑證，并以法律、法規的形式確認其合法、有效性。
在會計工作中及時采用數字簽名和加密技術相結合的最新方法。實踐證明通過技術手段對電子數據的確認，是目前行之有效的方法。主要的一種技術手段考慮到了我國的傳統印章使用的習慣與高科技技術的融合，就是采用電子印章。
(二)數字化產品的會計確認
數字化產品指的是以電子數據形式存在的一種產品，包括實體商品的電子形式，如計算機軟件、多媒體產品、專業數據庫以及電子出版物等。
1.數字化產品對傳統會計確認方式的沖擊
首先，數字化產品是一種技術性資產，在一個以生產和經營數字化產品為主的企業，銷售數字產品是其主營業務收入的主要來源，開發的目的是通過出售而取得收益，數字產品能夠給企業帶來經濟收益。企業在數字產品的開發上是排斥他人的，為了自己的數字化產品能夠占領市場，企業通常會花費大量的財力、物力、人力，以其能夠具有優勢以區別其他企業的產品，其研究開發支出可以合理、可靠計量。
其次，用于出售的數字化產品不應當作為存貨確認。從特征上看，數字化產品與傳統的存貨在功能上具有類似之處。數字化產品在企業中發揮的作用與物質產品制造企業生產和銷售有形產品一樣。但從另一方面看，又不具備存貨的特點，因為存貨是指企業在日常活動中持有以備出售的產成品或商品、處在生產過程中的在產品、在生產過程或提供勞務過程中耗用的材料和物料等三類有形資產。而數字化產品是無形的，數字化產品不需有形倉庫保存，一次性開發或再次開發成功后就可以投入銷售，而且可以不斷復制再銷售；可以說產品的生產過程是虛擬的，它的成本構成和收益大小也具有不確定性。
再次，用于出售的數字化產品不應當作為無形資產確認。雖然數字化產品符合無形資產的部分特征，但是企業持有無形資產的目的不是為了出售而是為了生產經營，即利用無形資產來生產商品、提供勞務、出租他人或為了企業經營管理服務，雖然傳統無形資產也可以通過銷售實現收益，但這并不是它獲取超額收益的主要方式。數字化產品的開發目的主要是為了獲得出售收入。
2.數字化產品的會計確認設想
劉良惠學者認為“數字化產品既不同于有形產品，又有別于傳統會計中的無形資產，但它又確實是能夠給企業帶來未來經濟利益的經濟資源，是企業擁有或控制的一項資源，應該確認為一項資產。根據其特殊性，應該單獨設立‘數字資產’項目，將數字化產品確認為‘數字資產’。至此，資產這一會計要素就應分為有形資產、無形資產和數字資產三大類，有形資產又分為流動資產和長期資產兩類。”對增設“數字資產”項目，筆者非常贊同，但對于哪些應確認為“數字資產”，則有不同的觀點。本文提出建議：
(1)增設“研究開發支出―網站開發成本”
在資產項下增設“研究開發支出―數字商品開發成本”。數字化產品研究開發過程的支出，首先作為該項目確認。
(2)確認為無形資產的條件
外購并自用的數字化產品的取得成本應當于取得時確認為一項無形資產。研究開發階段支出(除硬件設備外)于研究開發成功時，如果數字化產品為企業自用，并預期能夠產生收入，應作為無形資產確認，并按預期使用期限攤銷。研究開發結束，申請專利權的有關費用，仍作為無形資產確認。
(3)增設“數字資產”
在資產項下增設“數字資產”。如果數字化產品用于出售，則應于數字化產品研究開發完畢時確認為“數字資產”，并按預期可使用期限結轉成本。開發成功出售交付他人時，作為收入實現確認。
外購的數字化產品，于采購完畢時作為該項目確認，并按預期可使用期限結轉成本。出售交付他人時，作為收入實現確認。
(4)確認為固定資產
為數字化產品服務的硬件產品，確認為固定資產
(5)確認為費用
在外購或開發數字化產品之前的計劃、調研階段支出，應當確認為費用，計入當期損益。研究開發失敗，不準備繼續研究開發的，其已發生的支出，也確認為費用。
(三)電子商務收入的確認
對于電子商務的銷售收入，無論是在線實現商品銷售收入，或是在線實現服務收入，都面臨著確認問題，即何時將所確認的經濟業務進入會計賬戶。
1.電子商務收入對傳統會計確認方式的沖擊
存在電子商務收入的確認難題在于，電子商務尤其是數字化產品的電子商務是新生事物，時間較短，會計規范滯后。如我國會計準則和制度中并未涉及電子商務的內容。
確認難題之一，在線銷售數字化產品收入究竟是銷售商品的收入還是使用費收入。當有形商品可轉化為數字商品時，網絡使得銷售收入和使用費收入之間的區別變得不確定。當有形商品被數字化并通過電子商務網絡進行電子化傳送，買方出售的僅是商品的使用權，而自已仍然保留所有權，在這種情況下銷售收入似可視為使用費。但有些數字化商品如電子版圖書僅僅是實物的代替品，這些支付也可以看作是銷售收入。但有些人則認為，由于版權仍為轉讓者所有，故支付應當視為費用。由于受讓者有權為了運作而在其業務范圍內復制多份拷貝，故在大多數情況下，所得又可視作商品銷售收入。
確認難題之二，數字化產品的收入與費用如何實現配比。對于電子商務時代，數字化產品的前期研究開發費用過大，而陸續的生產成本很小，這一原則的適用性變得有些牽強。技術高速發展所帶來受益期的不確定性，以及技術進步所造成意想不到的淘汰，都使得收入和費用配比這一原則賴以存在的基礎變得不確定。這種變化，致使在電子商務環境下的成本費用的期間分割及配比假定顯得缺乏一種嚴謹實在的基礎，表現出某種隨意性和人為性。
確認難題之三，在線銷售數字化產品何時確認收入實現。2006年2月財政部的《企業會計準則第14號―收入》中規定銷售商品收入予以確認同時滿足五個條件，(1)企業已將商品所有權上的主要風險和報酬轉移給購貨方；(2)企業既沒有保留通常與所有權相聯系的繼續管理權，也沒有對己售出的商品實施有效控制；(3)收入的金額能夠可靠計量；(4)相關經濟利益很可能流入企業；(5)相關的、己發生的或將發生的成本能夠可靠計量。這些規定對于傳統交易的規定非常明晰，但沒有涉及電子交易。
2.電子商務收入的確認策略
針對以上難題，會計理論界應當進行深入討論，以指導會計實踐。目前對上述收入的處理，會計實務界處理很隨意，多是根據自身判斷處理。因此，我國應當盡快將電子商務的收入，尤其是數字商品的收入處理納入會計規范，以保證企業會計信息真正具有可比性。
首先，對于第一難題，在線銷售數字化產品(包括實體產品的電子形式)其收入應當確定為銷售商品的收入。原因在于，銷售傳統商品時，也僅是商品本身的使用權和所有權轉移，其商品商標品牌的所有權和生產該商品的權利并未隨之轉移。電子形式銷售數字化產品，具有與銷售傳統商品同樣的特征，客戶支付費用即可得到所購數字化產品的使用權和所有權，客戶可以對所購數字化產品進行處置(包括復制多份拷貝，但也有產品不允許復制)，符合上述收入確認條件。
其次，對于難題二，數字化產品銷售可以相對配比。對于傳統商品銷售，其收入與支出也并不可能實現全部合理、準確配比，只是按照會計法規操作，實現比較準確、合理的配比。在電子商務時代，對于外購數字化產品再銷售，其外購的金額與銷售所實現的收入很容易實現配比。對于自創數字化產品用于銷售的配比，可以以法律的形式規范，其前期研究開發過程為數字化產品生產過程，其發生費用即為生產產品的成本，作為研究開發支出(類似傳統企業的生產成本，也可以擴展生產成本的內容，因為數字化產品生產情況較特殊，應增加研究開發成本)確認。并預測數字化產品的收益期限，定期攤銷進入成本，實現收入、支出相對配比。
再次，對于難題三，交付商品時確認收入實現。收入確認的基本原則是實現原則和配比原則。現代電子商務環境下，傳統的購銷合同、服務合同、原始憑證已基本消失，傳統中會計核算的簽字、蓋章、復核、出入倉庫等控制制度和措施已大大減弱。取而代之的證明交易已發生或者貨款已收到的是電子原始憑證，如電子發貨單、收貨單、電子發票、電子銀行支付憑證等，為確保其真實，電子原始憑證需要電子簽名。證明經濟業務發生的憑證形式只是由紙質變為電子，其內容、性質、作用并未改變，因而完全可以根據電子憑證確認收入實現。比如開出發貨單，交付商品時確認為收入實現。
結語
電子商務給會計理論的沖擊是全方位的。會計環境的急劇變化動搖了會計假設；信息用戶對會計信息的新需求對會計信息質量、會計確認的范圍、標準和計量的方法帶來了挑戰。電。本文對這些內容作了初步性的分析研究，但不夠深入、透徹，有待進一步的努力。
參考文獻：
[1]許永彬.電子商務會計[M].上海：立信會計出版社，2000.283.
[2]張乃榮.電子商務環境下會計的全方位創新[J].會計之友，2004.12：79-80.
[3]莊明來.電子商務會計研究[M].北京：中國財政經濟出版社，2004.280.
[4]劉瀟瀟.論會計與電子商務[J].市場周刊，2005.2：116-117.
篇10
隨著國家信息化的高速進展，復雜信息系統逐漸占據了市場的主流，由于信息系統的復雜化，傳統的軟件需求分析不能很好地對復雜信息系統進行管理，需求工程的概念應運而生。需求工程是隨著計算機的發展而發展的，隨著軟件系統規模的擴大，需求工程與定義在整個軟件開發與維護過程中越來越重要，直接關系到軟件的成功與否。本文主要介紹了軟件需求的概念、內容，需求工程的概念、需求開發、需求管理以及需求工程各階段的具體實現，而且還以醫療保險管理信息系統項目為例，詳細說明了網站開發項目的需求實現過程。
關鍵詞：
信息系統；需求工程；需求管理
用戶定義的“需求”對開發人員來說是一個較高層次的產品概念，而開發人員所說的“需求”對用戶來說又像是詳細設計。對于軟件需求，可以從以下幾個觀點來看：從用戶角度出發的觀點指明從系統外部能夠發現系統具有的滿足于用戶的特點、功能及屬性等。從開發人員角度出發的觀點指明必須實現何種目的的規格說明。他描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。
綜合用戶和開發人員雙方的觀點
1、用戶解決問題或達到目標所需的條件或能力。2、系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具有的條件或能力。3、一種反映上述所描述的條件或能力的文檔說明。它強調了不但需求中包含目標而且還要包含實現用戶目標所需要滿足的條件或能力，同時必須以規范文檔的形式表述。需求工程的概念：需求工程包括創建和維護系統需求文檔所必需的一切活動的過程，包括需求開發和需求管理兩大工作。一個小的項目要做到需求過程的完全規范化，隨著開發工作的進行和用戶需求的不斷變更，其工作量已經相當驚人。實例——醫療保險管理信息系統需求管理的實現。基本的醫療保險制度是社會保險制度的重要組成部分，關系到百姓的切實利益，而且涉及面廣、金額大、業務量大、政策性強，因此，在實施管理系統時必須要可靠、高效、穩妥，最好一步到位實現信息化管理。
一、業務需求
通過與客戶的反復溝通，以與客戶開座談會、與用戶進行訪談，與客戶的領導進行溝通，得到本醫療保險管理信息系統所涉及到的基本業務有：1、參保人員社會保險基金的征繳；2、參保人員醫療費用的審核、結算；3、參保人員的自然狀況，健康狀況的動態記錄、修改及管理；4、參保人員30年有關醫療保險信息的保存與管理；5、參保人員醫療保險卡制作、發行與管理；6、經常大規模的信息查詢與統計；7、特別情況的管理及處理。
二、功能需求
面對如此復雜的系統，技術人員通過與客戶的領導和相關人員反復溝通，首先確定了一些技術要點和優先要實現的目標。也就是確定了本醫療保險管理信息系統的功能需求：1、通過醫保信息系統的建設，使客戶醫保工作從基金收繳、支付到賬務往來管理、統計分析基本實現計算機化；2、將各經辦機構的工作人員集中在控制中心，開展業務工作，行使管理職能；3、建立參保人口的醫療保險個人信息數據庫，并將涵蓋其它險種所需的基本信息；4、在醫療機構與醫保中心之間通過數據接口實現計算機費用結算工作；5、在銀行與醫保中心之間通過數據接口實現計算機自動轉賬；6、通過與定點醫療機構、定點藥店等相關部門建立網絡連接，實現門診處方的計算機系統事前審核（PCS），改善醫療保險監控手段，為合理控制醫療費用增長，減少醫療資源浪費提供支持，進而保障醫療保險基金高效運行；7、通過業務數據，對基本醫療保險基金的收入和支出進行動態監控和分析預測，對政策執行情況進行評估，達到決策科學化，進而保障醫療保險基金長期運行；8、并通過本次醫保信息系統的建設，為客戶社會保險信息系統（養老、醫療、工傷、生育、失業五險合一）的建設作好準備。
三、涉及部門
為了適應社會保障體系信息系統一體化建設的需要，以及醫保業務的變化，還有醫療保險險種的擴充（如企業補充醫療保險、公務員醫療補助、大額醫療費用互助保險、商業醫療保險等），在數據結構的設計中采用了冗余化和分段處理的思想，使得系統數據不僅滿足醫療保險，同時滿足社會保險各險種的需要。分段處理的設計，可以使不同的險種業務構件處理對應區段的醫保業務。為了保證這些要求的實現，主要涉及到了一下部門：勞動行政主管部門、醫保中心、定點醫療機構（定點醫院和定點藥店）、參保單位、參保職工、財政部門、經辦銀行等單位。1、勞動行政主管部門：制定醫療保險登記管理、基金征繳管理、基金監督檢查等政策細則；會同衛生部門、財政部門等有關部門制定醫療保險藥品目錄、診療目錄、醫療服務設施標準及相應的管理辦法；對醫療保險基金實行全面的監督管理等。2、醫保中心：負責醫療保險登記管理、變更登記管理、注銷登記管理；負責醫療保險基金的繳費申報核定工作；負責管理統籌基金收支；負責完成參保職工的特殊醫療費用的報銷；負責定期與定點醫療機構進行費用結算；負責監督檢查醫保政策在各定點醫療機構的執行情況。3、定點醫院：向參保患者提供醫療服務；按醫保政策與參保患者進行結算；向社會保險事業管理局提供詳細的醫療數據；按政策與社會保險事業管理局結算醫療費用。4、參保單位：管理本單位參保職工的基本資料；向社會保險事業管理局辦理參保登記、變更登記；按時進行醫療保險費的繳費申報；代扣代繳本單位職工個人應繳納的醫療保險費；按時繳納基本醫療保險費；定期代表單位職工到醫保中心辦理報銷業務。5、參保職工：按月繳納個人應繳納的醫療保險費；持醫療保險IC卡到各定點醫療機構就醫或購藥。6、銀行：負責醫保個人賬戶和統籌基金賬戶的建立；給醫療機構、藥店撥付資金；受社會保險事業管理局委托，強制收繳繳費單位的醫療保險費等。
四、結論
在軟件項目的開發過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發，維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能、優化性能、提高用戶友好性的要求。在軟件項目管理過程中，項目經理經常面對用戶的需求變更。如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發人員的士氣將越來越低落，將直接導致項目成本增加、質量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。在開發實踐中，首先應該不斷地探索需求，分析需求，實現需求，響應需求的變更。在需求開發的整個過程中，應該從本質開始，邊捕獲、邊分析、邊實現，通過不斷的迭代交付來響應需求變化，以需求基線來保證開發的節奏，通過對變更的管理來更好地響應變化。總而言之，需求管理是整個開發生命周期中的重中之重。在將來的發展中，需求管理將起到至關重要的作用。
參考文獻：
[1]崔立元,羅燕京,李剛.基于企事業模型的軟件需求工程方法[J].計算機工程與應用,2002(7).
[2]別春麗.對開發與管理軟件需求的探討[J].中國金融電腦,2001(10).
[3]苗炬.基于RUP的軟件需求分析[J].計算機與網絡,2003(3).
