前言：中文期刊網精心挑選了會議方案格式范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
會議方案格式范文1
劉姝（1993—），女，漢族，四川成都人，四川農業大學經濟管理學院財務管理2011級本科生。
郭明亮（1990—），男，漢族，福建福州人，西南財經大學中國金融研究中心金融學碩士研究生。
摘 要：我國當前支撐高房價的主要動力有財政動力、投資性購房、土地資源有限及地價上漲。國研中心“383”改革方案對于土地制度提出在現有土地權屬基礎上，賦予農民集體土地處置權、抵押權和轉讓權?？煽闯觥?83”改革方案正好瞄準了房價上漲的核心頑癥，也許將給長期炙熱虛高的房價一劑退燒藥，切實做到藏富于民，讓利于民。
關鍵詞：房價；“383”改革方案；土地制度
一、“383”改革方案中有關制度解讀
2013年10月28日，各大媒體都在醒目位置刊登了國務院發展研究中心為十八屆三中全會提交的“383改革方案”。印象最深之處，就是關于土地及房地產政策改革，也許將給多年來一直屢調不下的炙熱虛高的房價，起到釜底抽薪的效果?！?83”改革方案中提出，將在現有土地權屬基礎上，賦予農民集體土地處置、抵押和轉讓的權力。允許農村集體土地與國有土地平等進入非農用地市場，進而形成權利平等、規則統一的公開交易平臺，建立統一土地市場下的地價體系。同時，完善土地租賃、轉讓、抵押二級市場，“小產權房”補繳出讓金后進入市場[1]。
當前支撐高房價的動力主要有，一方面是土地財政動力推高供應方價格，另一方面是投資性購房增值效應推高了購買方價格，其次是土地資源有限及地價上漲相互作用促使房價上漲，三者合力形成高房價長期高燒不退?！?83”改革方案正好瞄準了這一久病的核心頑癥，很有可能讓長期滾燙虛高的房價退燒?！?83”改革方案，可行性是可以肯定的，但能否有效執行卻存在不確定性。畢竟，方案雖好，貴在執行。如果執行到位，房價必然應聲回落；若是執行不到位，改革可能再次流于形式?！?83”方案解決房價問題主要是通過土地所有權的改革，大多數人也都意識到房價的高低是不能僅單純的從房價數字上去比較，房子建在土地上，地價問題理應被更大程度地公開討論。
二、制度與房價關系研究分析
夏正亞（2013）指出土地在房價調控中起了舉足輕重的作用[2]。張燕君等（2012）則認為只有改革“土地財政”，建立穩定的財產稅體系，更替主要依賴“賣地”獲取一次性獲利的布局，才能從根本上切斷地方政府與“高地份-高房價”的紐帶[3]。而莊天君（2006）提出土地私有化才是房地產市場的出路[4]。近年來，房地產業蓬蓬勃勃，有實力的資本家買地皮開發樓盤賺大錢，貼身褲兜里藏著小錢的人瘋搶著的買上一兩套，時機成熟倒賣之后小賺一把。然而絕大多數的老百姓無可奈何望房興嘆。
然而，溫鐵軍（2009）則認為土地私有將會帶來許多社會問題[5]。一方面，經營農業本來就利潤甚微的小農會在地方權利與資本結盟的強勢介入下大批失去土地。另一方面，喪失了在農村生存的根基之后，農民又無法完全在城市立足，最終結果可能是城市中貧民窟的數量與農村社會穩定的沖突同步加劇，大規模社會動蕩將難以回避。因此，目前中國農村形成的這種基本制度，是經過長期實踐檢驗的、大體上符合中國基本國情的制度。
關于土地制度改革，我們要從兩個方面去分析。首先是正面意義，2013年美國農業人口比重下降到1.5%-2%，雖然人口比重在下降，但高科技技術引導下的美國農民不但可以負擔全國人民的日常所需，還可以出口高質量高產出的糧食。而中國在2010年末農業人口比重為45.29%，相比之下，中國的大多數農民早就該被解放出來了。土地流轉政策一經實施，就可以進行農場大規模經營化，降低成本，提高利潤，促進糧食生產，從而為農民謀福祉。土地流轉以后，土地承包權就是私人財產。一方面可以防范鄉村惡霸的豪奪，另一方面地權上更加公平。土地流轉以后，很多農民就可以把鄉下的土地賣掉，在城里買房子，大大支撐了城鎮的房地產市場，又可以縮小城鄉差距。土地公有，農民就不愛惜土地；干部可以奪土地，私賣土地；農民就被束縛于土地。因此，從長遠看，土地流轉將利大于弊，是中國工業化進程中必須完成的改革，是中國減小貧富差距，走向未來的必經之路。
三、結論與建議
在中國的經濟發展過程中有很多問題尚待解決，其中必然面臨一個城市化過程中的住房問題。住房問題關系的是民生、社會穩定問題，同時也直接關系經濟質量與GDP。政府從宏觀調控的角度來看，應該是順乎民意，給農民以土地權，還農民土地權。農民有了土地所有權，作為經濟主體參與住房供應市場，房價必將大副度下調，房價下調居民住房可以解決，商業成本下降，大量有效的房產需求必將導致經濟的另一個起飛。而如今高房價像一條大蟒蛇把GDP把社會公平全部纏死。所以在我看來，繼續完善，才能讓長期炙熱的房價退燒。以下是一些建議：
（一）亟待解決
部分地方政府以城鎮化之名行房地產開發之實，其意在賣地收入。國家行政學院經濟學部教授許正中說過，有的地方政府已經準備進行“一房四吃”：“一吃”土地出讓金，“二吃”轉讓住房所得20%的個人所得稅，“三吃”房地產稅，“四吃”遺產稅。十八屆三中全會公報指出“要完善城鎮化健康發展體制機制”，看來要實現偉大的中國夢，政策必須要列為首要解決的民生問題。
（二）改革“土地財政”
土地財政無可厚非的是許多地方政府的核心財政依賴。值得關注的是，在許多城市，土地出讓金甚至已經成為地方政府最大的收入來源，大量地方政府利用土地財政推高房價已是不爭的事實，很多網友紛紛感嘆“土地財政不破，高房價不止！”在這一點上，幾年前，國土資源部的領導就曾承認過，在一些地方確實出現了政府過分依賴土地收入的問題。在上面提到過，三分之二的購房費用都被地方政府和房地產商“吃”掉了。這還只是“四吃”中的“一吃”。早前就有政協委員披露，我國現階段涉及的房地產稅種有12項之多，涉及房地產的收費多達50項，這62項稅費占到購房費用的30%～40%。
（三）政府要切實做到讓利于民
轉讓住房所得20%的個人所得稅，其實也被全部轉移到了買家的房款中，本來高居不下的房價就在不斷升溫，再加上沉重的個稅，老百姓也只有繼續勒緊褲腰帶，當一輩子房奴。假使某天遺產稅再一實行，含辛茹苦供了一輩子的商品房在讓子女繼承時又要交一筆不少的遺產稅。另外很多專家呼吁實施房產稅，讓房產回歸居住的功能，出發點是好，但一定要配合地方政府的土地政策，如果，房價始終不降，房產稅又來雪上加霜，老百姓的買房壓力更是苦不堪言。許多地方政府之所以對城鎮化建設幾極為熱衷，是以為他們關心的是賣地的錢，而這又使城鎮化的規劃、決策被房地產綁架。這種以圈地建房造城為特征的疾風驟雨式的“城鎮化”運動，會給中國經濟，社會發展帶來許多隱憂，影響經濟的健康發展。的紅利誰先得？全面深化改革就是為了讓老百姓享受更多的改革紅利。期待新一輪體制改革能有效破解地方政府的土地財政依賴癥，并切實把房地產行業的稅費負擔“簡政”、“放權”，最大程度的讓利于民。（作者單位：1.四川農業大學經濟管理學院；2. 西南財經大學中國金融研究中心）
參考文獻
會議方案格式范文2
在縣城附近建設標準化學校，用于接收至今沒有通路、通電、通廣播電視的貧困山區義務教育階段中小學生，為他們提供與城里孩子同等的教育條件。海南自2007年起實施的“教育扶貧移民工程”改變了山里娃的命運。
據海南省教育廳廳長胡光輝介紹，海南省轄18個市縣，11個是貧困縣，教育發展長期處于比較落后的水平，尤其是基礎教育水平低、質量差，薄弱學校比重偏大，優質資源稀缺，義務教育均衡發展任務艱巨。
為促進義務教育均衡發展，海南大力實施“教育扶貧移民工程”，截至目前，海南省財政投入14億元，建設了24所思源學校，改擴建教育扶貧移民學校14所，新增優質學位4.57萬個。數萬名大山深處的少數民族貧困孩子得以走出大山，到縣城接受優質教育。
記者在王榆芳就學的屯昌縣思源學?？吹?，這是一所全新的現代化校園，擁有綠草如茵的花壇、標準化的籃球場、明艷的塑膠跑道、一流的教學設備。學校接收的學生90%以上來自貧困、少數民族家庭。
更讓貧困孩子和家長笑逐顏開的是學校強大的軟實力。思源學校建設改變了過去只重硬件投入的教育扶貧方式。海南省政府教育總督學石秀慧說，思源學校招聘的校長均為市縣級以上優秀校長，綜合素質較高，具有豐富的辦學經驗和先進的教育理念，事業心強，工作投入，加上一批年富力強經驗豐富的學科骨干教師和一批充滿活力的年輕“特崗教師”，各思源學校構建了一支素質優良的教師隊伍。
現代化的教學設施、優秀的師資力量，為山里娃們帶來了全新的教學理念和優質的教學課程?！八荚磳W校真好，可以免費學鋼琴，還有各種各樣的興趣班，繪畫課、書法課、舞蹈課，大家可以憑興趣選擇?！蓖跤芊夹ζ饋砗軤N爛，她說今后要上思源高中，繼續學鋼琴。
黎族小姑娘王玉寶告訴記者，在她們以前就讀的山里小學，往往一個老師要教很多門課程，音樂、美術課則讓他們自習。
由省、市縣財政和香港言愛基金共同投入建設的一期10所思源學校經過三年的順利運行，教育教學成果顯著：學校教學樓下，展示著孩子們精美的美術、繪畫作品；籃球、排球場上，山里娃揮汗如雨；學業成績也大幅度提高，上學期末，第一批10所思源學校中，有7所平均分高于所在市縣平均分，9所成為省級規范化學校。
會議方案格式范文3
關鍵詞：OpenMeetings；視頻會議；Red5；OpenLaszlo
中圖分類號：TP37文獻標識碼：A文章編號：1009-3044(2011)12-2909-03
The Research of Video Conference System on OpenMeetings
PENG Ling-hua, ZHAO Rui
(Guizhou University, School of Computer Science and Information, Guiyang 550025, China)
Abstract: This article describes environment and overall design of network video conferencing system based on open source framework OpenMeetings. OpenMeetings is a multi-language customizable video-conferencing and collaboration systems. It supports audio, video, each participant can share the desktop. It also contains a whiteboard, the whiteboard can import images in various formats and make presentations. System architecture is mainly server-side development using Java, using Spring and Hibernate frameworks, streaming media servers running on Red5. Client using OpenLaszlo development environment running in the Flash player.
Key words: OpenMeetings; video conference; Red5; OpenLaszlo
隨著網絡的普及和視頻交流的廣泛需求，軟件視頻會議的應用越來越廣泛，但傳統的客戶端方式的軟件系統也給客戶的視頻會議應用帶來了諸多障礙：下載和安裝客戶端軟件時的各種繁瑣流程、瀏覽器對各種插件的校驗與排斥、各類防火墻防病毒軟件的嚴格檢查。據統計，有超過50%以上的用戶因為諸如此類的原因而放棄了軟件視頻會議客戶端的安裝。視頻會議的Web化是幾年來軟件視頻會議在技術上、應用上不斷發展之后的一個必然選擇，與傳統的C/S模式的軟件視頻會議相比，無論是在靈巧性、易用性方面，還是在易嵌入、易整合、易擴展等方面，Web視頻會議都表現出其強大、高柔韌度的特征。
而開源框架的OpenMeetings正是基于Web化并且客戶端采用純FLASH呈現的視頻會議系統。OpenMeetings最大特點是視頻會議客戶端不需要下載安裝，OpenMeetings系統將客戶端做成swf形式，通過網頁瀏覽的方式自動加載，免去用戶下載安裝的步驟，所有支持flash的瀏覽器都可以使用OpenMeetings進行視頻會議。OpenMeetings另一大特點在于其強大的跨平臺能力，從FireFox、Chrome、傲游到IE，從Linux、Mac、Unix到Windows全系列，而隨著Flash對各類新型操作系統和智能終端的不斷兼容，OpenMeetings視頻會議所支持的設備、瀏覽器、操作系統也在不斷擴大，相比而言，基于客戶端方式的視頻會議系統想做到這一點是異常困難的。
1 OpenMeetings系統簡介
OpenMeetings是基于Flash的多語言可定制的開源EPL（Eclipse Public License）視頻會議軟件，通過RTMP和HTTP協議傳送視頻數據。
OpenMeetings的主要采用的開發語言是Java和LZX（Laszlo XML-based language，一種基于XML和JavaScript的語言），它的服務器端運行于開源的流媒體Flash服務器 Red5，客戶端是OpenLaszlo的應用，并且運用第三方輔助軟件實現格式轉換處理以及視頻音頻錄制等功能。
OpenMeetings是可以從選擇操作系統（Linux）到數據庫（MySQL）到流媒體服務器（Red5）到輔助軟件（OpenOffice、FFMpeg等）到開發環境（OpenLaszlo、Eclipse）等完全開源的系統。
2 運行環境介紹
2.1 流媒體服務器Red5
Red5的主要功能和Macromedia公司收費的FMS（Flash Media Server）類似，提供基于Flash的流媒體服務的一款基于Java的開源流媒體服務器，可開發Web音視頻應用程序（比如，視頻聊天室、視頻會議系統、播客系統、音視頻留言等等）的最方便最快捷的解決方案。它由Java語言編寫，使用RTMP作為流媒體傳輸協議，可與FMS完全兼容。
OpenMeetings的服務器端處理均是在Red5服務器中運行處理，Red5主要支持把音頻（MP3）和視頻（FLV）轉換成播放流，實時錄制客戶端播放流（只支持FLV），共享對象，實時視頻播放、Remoting遠處調用等。
2.2 客戶端OpenLaszlo
OpenLaszlo是一個與Flex并駕齊驅的主流的開源RIA（Rich Internet Applications）構建平臺，使用Macromedia Flash 作為部署載體。OpenLaszlo 依賴 JavaScript 來表達邏輯，并提供了傳統 Flash 開發方式無法比擬的一些優點，包括高級的 UI 約束系統、面向對象的設計方法學以及內置的對 Web 服務和各種風格的遠程過程調用（Remote Procedure Call，RPC）的支持。
OpenLaszlo應用程序開發使用的是基于XML的LZX語言，它可以被編譯成DHMTL,SWF等格式。
OpenMeetings中所有前臺操作都是通過它編譯生成flash，然后客戶端操作產生事件再傳遞到后臺服務端處理的，所以它在相當于我們常見網頁界面，只不過它是flash形式展示的。
2.3 開源辦公軟件OpenOffice
是一套開源的跨平臺的辦公室軟件套件，能在 Windows、Linux、MacOS X (X11)、和 Solaris 等操作系統上執行。
它主要是用來處理OpenMeetings中演示文檔時需要將各類格式的文檔轉換成PDF，它可將MS Word，Excel，PowerPoint，文本文件txt，MS Office 2007在內的多種格式，并且能夠將其導出為PDF文件，由于它能廣泛支持MS Office，而且免費，所以用它來進行轉換處理是非常合適。
2.4 圖像處理ImageMagick
ImageMagick是一套功能強大、穩定而且免費的工具集和開發包，可以用來讀、寫和處理超過89種基本格式的圖片文件，包括流行的TIFF, JPEG, GIF, PNG, PDF以及PhotoCD等格式。利用ImageMagick，可以根據web應用程序的需要動態生成圖片, 還可以對一個（或一組）圖片進行改變大小、旋轉、銳化、減色或增加特效等操作，并將操作的結果以相同格式或其它格式保存。對圖片的操作，即可以通過命令行進行，也可以用C/C++、Perl、Java、PHP、Python或Ruby編程來完成。同時ImageMagick提供了一個高質量的2D工具包，部分支持SVG。現在，ImageMagic的主要精力集中在性能、減少bug以及提供穩定的API和ABI上。
OpenMeetings中通過它處理白板中的圖像操作以及生成等工作。
2.5Flash轉換工具SWFTools
SWFTools是一種為Adobe Flash文件（SWF文件）工作的實用工具集。該工具集包括用于閱讀或者合并SWF文件，，或者將（如圖像，聲音文件，視頻或源代碼）等文件轉換成swf文件的程序。
它在OpenMeetings中是非常重要的，因為其中許多上傳的文件或者系統運行中的文件都需要通過它來創建或者格式轉換成swf文件，以便前臺可以訪問或者使用。
2.6 視頻處理FFmpeg
FFmpeg是一個開源免費跨平臺的視頻和音頻流方案，屬于自由軟件，采用LGPL或GPL許可證（依據你選擇的組件）。它提供了錄制、轉換以及流化音視頻的完整解決方案。它包含了非常先進的音頻/視頻編解碼庫libavcodec，為了保證高可移植性和編解碼質量，libavcodec里很多codec都是從頭開發的。
OpenMeetings中通過它來實現錄制視頻并后期重組處理。
2.7 音頻處理SoX
SoX是一個跨平臺（Windows，Linux操作系統，MacOS X系統等）的命令行實用工具，可以轉換各種格式音頻文件的計算機在為其他格式。它也可以應用各種效果，將這些聲音文件作為外放，SoX可以播放和錄制大多數平臺上的音頻文件。
OpenMeetings中會議錄制時將會用到音頻處理，并將音頻單獨拆分出來外放。
3 OpenMeetings的系統架構
3.1 服務器端框架
OpenMeetings服務器端是Java開發的，采用了Spring和Hibernate框架。
Spring 是一個開源框架，是為了解決企業應用程序開發復雜性而創建的?？蚣艿闹饕獌瀯葜痪褪瞧浞謱蛹軜?，分層架構允許您選擇使用哪一個組件，同時為 J2EE 應用程序開發提供集成的框架。
Hibernate是一個開放源代碼的對象關系映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫。 Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序使用，也可以在Servlet/JSP的Web應用中使用。
3.2 系統模型
圖1的模型中，OpenMeetings的后臺是一系列的service組成的，這些service由Java語言編寫，這些service的實現類大都在包org.openmeetings.app.remote中，該包封裝了大部分前后臺交互的類。如文件服務、用戶服務、會議服務、流服務等等。
這些service作為接口供前臺調用，它們分別處理不同的功能請求。例如：
UserService：用戶注冊、登錄、注銷、修改用戶信息等。
StreamService：視頻音頻錄制，格式轉換，處理視頻流，音頻流。
ConferenceService：會議設置，會議管理，可根據需要設置不同功能的會議室。
OrganizationService：組織管理，可添加修改組織，并和用戶進行關聯。
LanguageService：語言編輯管理，可編輯修改按鈕名稱，注釋，菜單名等。
ErrorService：各種消息提示處理，如注冊成功彈出框提示，錯誤提示。
FileService：文件上傳，文件管理，文件格式轉換。
3.2 技術體系層次及數據庫設計
3.2.1 技術體系層次
前臺的瀏覽器頁面請求是由OpenLaszlo編寫lzx文件，編譯完成后是一個Flash的形式（swf文件）。前后臺的交互大部分通過RPC（Remote Procedure Call）遠程調用實現，即OpenLaszlo程序遠程調用后臺的Java類，也有部分回調。
前后臺的交互也有少部分是通過http協議完成的，比如圖片的上傳和現實，文檔的上傳等等。這一部分與傳統的B/S架構是類似，后臺是Java語言編寫的servlet，這些servlet位于包org.openmeetings.servlet。
servlet和service接口處理邏輯請求時通過hibernate訪問數據庫并獲得數據，并向前臺返回請求結果。
用戶操作時，上傳的文件或者圖片會通過外部擴展攻擊SWFTools來轉換成swf然后供前臺展示。視頻音頻錄制后會通過調用外部命令FFmpeg和SoX來實現視頻音頻的格式轉換和整合，它們將生成一個無聲的視頻，并對應的生成一個音頻，以供只需視頻或者只需音頻的不同需求。
數據庫服器可采用多種應用于多種數據庫，如sqlserver、mysql、ocracle，postgresql，只需在數據庫配置文件中修改對應的數據庫驅動，并裝上對應的包即可。
3.2.2 數據庫設計
1）語言和提示信息設計
fieldlanguagesvalues為存放所對應的語言的實際內容，它根據語言表fieldlanguage的language_id來區分語言的種類，fieldvalues表是fieldlanguagesvalues表的一個每個所需顯示的語言對應，例如在fieldlanguagesvalues表中同一個fieldvalues_id表示他們屬于同一個表示值，但是不同的fieldlanguagesvalues_id表示不同的語言（language_id）下的值是不同的，這樣程序中查詢所對應語言的時候只需根據fieldvalues_id即可查到它所在不同語言下對
2）用戶、組織、房間數據庫設計
用戶表（users）通過關聯表organisation_users和組織表（organisation）關聯，該關聯表表示每個用戶表所對應的組織，單個用戶可以對應多個組織。
組織表與房間表（rooms）通過關聯表rooms_organisation表相關聯。它負責記錄每個房間和組織的對應關系，這樣可以按房間類別和用戶所在的組織是否屬于該房間來控制用戶是否有權限進入該房間參與會議或者訪談。房間類別表roomtypes（上圖未列出）來表示各個房間的類別，通過roomtypes_id來進行關聯。
會議邀請表（invitations）為當用戶需要預定某些用戶參與預約的會議時用到，關鍵的記錄了開會的房間和有哪個用戶發起，并記錄了參與的用戶等信息。
用戶權限根據用戶表中的level_id來控制，1為管理員，2為主持人，3為普通用戶。將來擴充的話可根據用戶表所關聯的user_level表（上圖未列出）來增加或者修改用戶權限類別。
3.2 代碼實例
一個登錄的調用實例：
代碼1：（checkLoginData.lzx）
this.parent.errormess.setAttribute('text','');
this.parent.loginUser.doCall();
代碼1意思是當登錄按鈕有點擊事件時執行的兩句代碼，handler是當某個事件觸發時即執行。
this.parent.loginUser.doCall();調用loginUser類。
代碼2：（checkLoginData.lzx）
return parent.parent.username.getText();
代碼2中netRemoteCallHib name="loginUser" funcname="xmlcrm.loginUser" 指明了loginUser遠程調用指向的函數名為xmlcrm.loginUser。而后面帶上的內則是該函數調用所帶去的參數。
代碼3：（xmlcrm.service.xml）
class="org.openmeetings.app.remote.MainService">
由于lzx可以遠程調用service中的接口，所以我們在WEB-INF\red5-services文件夾下找到xmlcrm.service.xml，其中看到xmlcrm.service對應于org.openmeetings.app.remote.MainService，所以我們可以在MainService找到函數loginUser，這個就是前臺遠程調用的函數了。
后面再通過hibernate訪問數據庫，比較用戶數據的正確性以判斷是否允許登錄。
參考文獻：
[1] /documentation.
[2] Openmeetings /p/openmeetings/wiki.
會議方案格式范文4
格式內容：
1、標題。由"會議名稱+會議紀要"構成。
2、導言。介紹會議召開的基本情況，如時間、地點，參加人，討論的問題。
3、會議的成果及議定的事項，應逐項列出。
會議方案格式范文5
1、認真把好處置項目的審查關。自從確定專門機構、專職審查人員以來，建立健全了各項規章制度，經過兩年多的努力和完善，我辦的資產處置審查工作基本上達到了程序化、規范化、制度化，上半年共審查、批復項目xx個，其中審查上報總公司項目x個。
2、做好資產處置審查委員會日常事務工作。為使處置審查工作程序更加規范化，我們在審查程序上嚴格做到規范化，即按照辦事處制定的《中國東方資產管理公司長春辦事處資產處置審查委員會工作規則》要求的內容，從審查經營部門上報方案內容、格式、時間，反饋初審意見，到安排例會時間、通知上會、準備例會相關資料、會議記錄、投票內容、會議紀要、下達批復文件、上報處置方案等等，力求處置審查工作程序的規范化。上半年共組織召開了評審會xx次。
3、加強處置項目的后續跟蹤管理工作。為及時掌握已批復項目的處置執行情況和存在的問題，我們每季度對已批復的處置項目進行一次后續跟蹤調查，寫出檢查報告，及時了解處置項目及管理中存在的問題，以便采取措施，加強管理。
4、加強終結項目的規范化管理工作。針對以往終結項目中存在的沒有項目終結報告或報告不規范，該闡述的問題在報告中沒有，有些業務人員甚至把處置方案下載一份作為項目終結報告這一問題，我們認為，項目終結報告是對該項目處置全過程客觀、具體、真實、全面的一個反映和總結，尤其對于有些項目，在處置方案執行過程中存在很多變數，一定要在報告中認真總結和反映出來，于是我們制定了“關于項目終結報告的內容和格式”，規范了項目終結報告，并要求經營部門定期報送項目終結報告，移交檔案材料。加強了終結項目的管理，使我們的終結項目真正能夠畫上一個圓滿的句號。
會議方案格式范文6
公文基本格式要求
結合日常公文處理實際，提出一些基本要求，請認真研讀執行。
一、公文寫作
1.方向要正確。撰寫公文必須要符合黨的路線、方針、政策和國家的法律、法規及本企業的制度、規定，并能客觀、完整、準確地體現本單位、部門所要表達的意圖。
2.主題要突出。起草公文要開門見山，簡明準確，要合理安排正文結構，做到層次、條理清楚，要確保請示件一事一文，不可一文多事。
3.表達要深入。尤其請示件，一定要內容完整、有深度。例，對于涉及到經費方面的請示項目，在明確理由的同時，還應拿出依據，測算經費，并提出合理方案，或擬定幾種方案，闡明利弊，供領導決策借鑒，從而增強文件的前瞻性和批辦效果。
4.文題要對應。目前上報的請示中，文不對題的現象依然存在。例，某已開工工程需申請費用，標題卻寫“關于××工程的請示”。
5.用語要得體、規范。具體應注意以下幾點：
(1)文句嚴謹，周密、準確，不生歧義，沒有漏洞、失當之處。
(2)簡明，精煉，去浮辭，忌冗長空泛。
(3)文理通順，符合語法、邏輯規律。
(4)格調鄭重、嚴肅、客觀，不主觀褒貶、肆意渲染，不矯操造作、虛構加工，體現公文的權威性。
(5)平實自然，通俗易懂，忌堆砌詞藻，濫用辭格。
(6)要使用規范化公文書面詞語，現重點例舉以下幾種常用詞進行說明。
稱謂詞，第一人稱用“我”、“本”，第二人稱用“貴”、“你”，第三人稱用“該”。
領敘詞，一般有根據、依據、按照、遵照、接、頃接、近接。作為下文依據的詞有悉、收悉、敬悉、欣悉、驚悉、恭悉、獲悉、謹悉等。表示目的的詞有“為”、“為了”。表示理由的詞有“由于”、“因為”、“茲因”、“鑒于”。
承轉詞常用的有“據此”、“為此”、“故此”、“有鑒于此”、“基于上述”、“綜上所述”、“由此可見”、“總之”、“總而言之”。
時態詞不能用“明年”、“后年”等不準確的詞，而應使用具體化的年、月、日。此外常用的時態詞有茲、現、將、值此、時值、按時、準時、屆時、在即、立即、當即、先期、逾期、片刻、曾經、暫、暫行等。
結尾詞，一般有此復、特此批復、特此函告、特此報告、 為盼、為要。還有致意性結尾詞，如謝謝合作，謹致謝意，順致誠摯問候等。
公文語言要符合發文機關職權、符合文體特點、符合行文關系，下行文要明確肯定，平行文、上行文要用語謙和，分寸適宜。
“請示”要求理由充分，必要性、可行性闡述清楚，在結尾處不能含糊，如“請領導考慮”、“上述意見不知妥否，請上級酌定”就含糊其詞，而應當明確請求批示，例如，“妥否，請批示?！钡染捅容^明確。
6.字句要正確。避免病句、錯字、標點亂用等文字性錯誤，減少語句前后缺乏邏輯性、關聯詞使用不恰當、標題不準確、不確切等表達上的錯誤。
7.引文要準確。常見的錯誤有：引用某個相關文件名稱時，公文文號置前，標題置后，或者引文文號中的六角號“〔〕”用“”代替，正確格式應為“《標題》(文號)”;引用會議紀要內容時，專門強調某個領導提出某某事項，不符合行文規定。正確的表達應該是會議強調某某事項，不出現個人姓名;專業術語、計量單位和數字用法不符合相關規定等錯誤。
二、文種使用
公文種類主要有命令(令)、決定、公告、通告、通知、通報、議案、報告、請示、批復、意見、函、會議紀要等13種。
1.不能漏寫文種。
例：“關于××的方案”、“關于××的辦法”，為不完整正式公文，“方案”、“辦法”不能作為文種，應為 “關于印發××方案的通知”。
2.不能自編文種，行文時必須在上述13個文種中選擇適當的文種，避免出現“說明”、“建議”、“要求”等自編文種的現象。
3.正確選擇文種。要依據發文機關的職權選擇，上行文多采用“請示”或“報告”，必要時也可使用“意見”;平行文用“函”，指在同一系統內部平級單位之間或不相隸屬的任何級別的單位之間;下行文使用的文種有“通知”、“通報”和“批復”等。
要注意幾個易出錯文種的正確使用：
“請示”和“報告”，“請示”需上級批復，而“報告”則是向上級匯報，不須批復?！罢埵尽北仨毷且晃囊皇?。
“通知”和“通報”，“通知”具有執行性，主要用于批轉下級機關行文，轉發公文，印發本機關公文;通報具有教育性，如批評、表揚及情況通報等。
“決定”和“決議”， 這兩個文種都屬于下行文，具有決策性，但決議是黨的機關文種之一，而且是會議通過的，在題注中要注明是哪次什么會議什么時間通過的。
三、公文格式
規范的公文包括眉首，正文和版記三個部分。
1.眉首。一般包括公文份數序號、秘密等級與期限、緊急程度、發文機關標識、發文字號、簽發人6個部分。上行文必須要注明簽發人姓名。
2.正文。一般包括公文標題、主送機關、正文及成文時間，有時還有附件。
(1)標題。準確簡要地概括公文的主要內容，要文字簡明。文種中已表達過的內容標題不再重復，如，不能說“關于申請××的請示”，“申請”二字是多余的。標題中除必要時使用書名號外，一般不用標點符號。要正確使用介詞，要么用“關于”，要么用“對”，不能出現“關于對”。標題的排列要均稱，不能將一個詞拆分成兩行。轉發的公文，如通知的通知的通知，可省略中間層次，但在正文中須敘述完整。
(2)主送機關?！罢埵尽辈荒芏囝^主送。
(3)成文時間。成文時間以負責人簽發的日期為準，聯合行文以最后簽發機關負責人的簽發日期為準。
3.版記。版記部分包括主題詞、印發機關、印刷份數和發文時間。
(1)主題詞：主題詞應主要選擇名詞、動名詞和名詞性詞組，有些公文標注的主題詞是將標題簡單割裂，有的甚至出現介詞“關于”、動詞“調整”等等，對于揭示公文主題內容、便于檢索毫無意義，選詞數量應不多于6個，排列順序為類別詞、類屬詞，最后必須加上文種。
(2)版記最后要標注印發機關、成文時間和打印份數。4.其他格式
遵循“參照標準，力求美觀”的原則，對常出現的格式及其他細節方面的問題作如下統一規范:
(1)文號、正文(除標題外)、版記(除主題詞、詞素外)及上行文中的“簽發人”3個字都采用仿宋GB2312三號字，頁碼采用仿體四號阿拉伯數字;上行文的簽發人姓名為楷體三號;標題用宋體小二加粗;“主題詞”3個字為黑體三號，主題詞詞素為宋體小三，各詞之間空一全角漢字。
(2)正文統一用1.5倍行距。
(3)一般標題上與紅色反線空兩行三號字距離，下與正文空一行。
(4)附件與正文空一行，附件名稱不加標點符號，如需回行，則回行后第一字與名稱首字對齊。正確格式為：
附件: 1.××××××××××××××××××××××
2.××××××××××××××××××××××
(5)有附件的文件，正文中一定要按以上格式標明，并與后附標題一致。
(6)成文日期中的“”從特殊符號里引用，并與正文字體相同。
(7)正文層次序號依次為：“一、(一)1.(1)”或“一、1.(1)”
(8)單獨發文落款處只寫日期，不寫發文單位。
(9)用印要求橫向居成文日期中間，縱向上不壓正文，下壓日期，騎年蓋月。印章所在頁必須有正文，不能在空白頁上打上“此頁無正文”之后再加蓋印章，必要時可調整行間距或標題與紅色反線距離。
(10)版記應置于文件最后一頁，亦即偶數頁。
(11)要雙面打印紙質文件，以備歸檔。在OA系統電子版公文制作時，要按紙質文件要求排版。
(12)“妥否，請批示”并不是請示中必用的固定格式，如以“請公司批復”收尾，再加“妥否，請批示”，則屬多余。
(13)請示文件應在成文日期下隔一行標明聯系人及電話，報告因不必署聯系人。
(14)在轉發、印發某項內容的行文處理時，被轉發的內容是公文的正文，而不能作為附件處理，故無需標注“附件”一詞。
