總括訂單blanket order是客戶向其**
方發出的採購訂單
，但其中包含一段時間內的多個交貨日期，通常使用談判時的預定**。
大多數情況下，
它用於對消耗性商品有經常性需求的情況。總括訂單通常用於客戶大量購買並已獲得特殊折扣的情況。在總括訂單的基礎上，可以根據需要建立銷售訂單（放貨單）和發票專案，直到合同履行完畢。
有了總括訂單，客戶就不必持有超過必要數量的存貨，避免了頻繁處理採購訂單的管理費用，同時有利於通過數量承諾或**折扣進行折扣定價。
總括訂單是在一段時間內設定乙個固定**的合同。採購方在相互競爭的**方投標中進行選擇，尋找最佳定價，在選擇了最優的**方後，貨物的**是固定的，而且每種產品的數量也提供給了**方，以便根據交貨需求來準備庫存。
**數量是由採購方提供近幾年的全部使用量，或根據定量分析的需要。**方可能會對此「合同」提出**數量的條件。例如，**數量的80%必須在合同結束時購買，時間期限可能是一年或兩年。
如果**方不能按時**合同中的產品，在總括訂單中將收取延遲交貨的費用。由於**方在第一年或約定的期限內已經留有庫存準備交貨，如果採購方不能滿足合同中的條件，如 「一年內必須購買**數量的80%」，合同可能會延期，或者延遲費用可能不會增加，或者採購方不會要求其他費用。
實際情況中，在總括訂單合同結束時，採購方不會按照合同中約定的**數量購買，比如說，80%的需求量傳送給**方。採購方也會允許**方減少銷售合同中的產品數量。**方也必須向採購方說明並告知貨物的庫存數量，以便採購方了解庫存狀況。在採購方向的**方發出採購訂單之前，採購方必須先詢問**方的庫存情況，以避免出現無庫存的問題。
總括訂單對採購方非常有用。簽訂合同最困難的部分是確定產品終端使用者安排的**數量。由於**數量可能很難得到，**方必須知道要保留的庫存數量。乙個簡單的方法是與採購方討論應該保留多少的庫存。例如，他們可能在前6個月只保留
20%的庫存量，這樣**方和採購方就可以回顧這個數量，並適當進行調整。這樣可以減輕**方在合同期內的庫存負擔，如果庫存沒有像預期的那樣快速流動，這可能會在合同結束時對採購方有所幫助。合同可能會年復一年地延長，但每次都可以調整，因為更多相關的**歷史資料將預示著需要減少或增加庫存需求。另外，一些公司可能會利用
mrp系統的**資訊來確定整個產品生命週期的合適的庫存量。
根據美國總務管理局（u.s.general services administration），總括採購協議：
Spring Batch系列總括
最近乙個專案在使用springbatch框架做乙個電子商務平台的批處理。網上資料很有限，尤其是中文資料更是少之又少，官網上的文件也只是講一些入門的基礎知識，大部分高階特性都是一筆帶過，講解的很不徹底，在實際開發中碰到的問題很多。因此，特將自己學習 應用spring batch的過程總結成乙個個小例項...
collections集合的總括。
序言 還有，這份微小型總結肯定是從很多博文中摘取精華拿過來的，因為我還是乙個菜鳥，不能自己寫出自己的見解，還是在學習的路程中，見諒。大神真的很多，學無止境，學的越多，越發現自己的無知，感謝能站在巨人的肩膀上前行。wzy 一 簡述 這是collection總體的乙個關係圖，很龐大，我就挑我們常用的來講...
linux驅動模型分析總括
linux裝置驅動模型在2.4和2.6之間有非常大的變化。感覺最大的變化就是2.6中加入了一些面相物件的方法進行管理裝置驅動，其實在linux中早就使用了該方法。為了有乙個全面的了解，今天特意理清了一下思路，為下一步進入分析打下基礎。linux使用類似uinx方式管理裝置驅動，把裝置當作檔案來看待，...