倉庫管理和SAP系統如何使用

簡單來講SAP系統提供的倉庫管理功能有：收、發、轉、盤點四大項。其中，‘收’就是收貨入庫，除系統標準的收貨、退貨外，還可以依實際需要增設超交收貨、折補收貨、免費收貨等；

創新互聯專注為客戶提供全方位的互聯網綜合服務，包含不限于做網站、成都網站制作、呼圖壁網絡推廣、成都微信小程序、呼圖壁網絡營銷、呼圖壁企業策劃、呼圖壁品牌公關、搜索引擎seo、人物專訪、企業宣傳片、企業代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創新互聯為所有大學生創業者提供呼圖壁建站搭建服務，24小時服務熱線：028-86922220，官方網址：www.cdcxhl.com

登錄

選擇所需要管理的部門

選擇收、發、轉、盤

檢查

確認

退出

可以根據如下倉庫管理指導學習：百度文庫-ERP系統

拓展資料：

儲存原則

1.存儲規定

a）防火、防水、防壓、防潮；

b）定點、定位、定容、定量；

c）先進先出

2.物料存儲要分門別類，按“先進先出”原則堆放物料，填寫《物料標識卡》等標識，尾數應貼上“尾數標簽”或做好尾數標識，并有相應的臺賬、卡賬以供查詢；

3.對因有批次規定、色別規定等特殊原因而不能混放的同一物料應分開擺放；

4.物料儲存要盡量做到“上小下大，上輕下重，不超安全高度”

料不得直接置于地上，必要時加墊板、紙皮或置于容器內，予以保護存放；

5.任何物料不得堆放在倉庫通道上，以免影響物料的收發

倉庫管理-百度百科

分布式理論基礎之BASE原則

BASE理論是由eBay架構師提出的，是對CAP中一致性和可用性權衡的結果，其來源于對大規?；ヂ摼W分布式系統實踐的總結，是基于CAP定律逐步演化而來。其核心思想是： 即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。

BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性) 三個短語的縮寫。

參考文章：

分布式系列文章——從ACID到CAP/BASE

分布式理論(二) - BASE理論

分布式系統一致性高可用的解決方案總結

本文基于對redis、zookpeer、rocketmq、elasticsearch學習總結，對于分布式系統學習，一定繞不開一個點，那就是CAP定理。什么是CAP定理，我這里簡單的復制摘抄一下百度上的文案。

CAP原則又稱CAP定理，指的是在一個分布式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。

說明一下上面的三個要素各代表的含義：

CAP定理說明上述的三個要素不能兼顧，最多只能滿足其中的兩個要素，在分布式系統中，一般都是保證分區容錯性，而在一致性和可用性之間做取舍。因此存在CP、AP兩種分布式集群的實現。

CP集群，即滿足一致性和分區容錯性，如zookpeer

AP集群，即滿足可用性和分區容錯性，如redis-cluster

下面，針對與上述的CP和AP問題，我們展開話題。

對于分布式系統，學習了解多了之后，發現其內在的解決方案基本上都是一樣的，所謂萬變不離其中。總結一下大體在于以下幾步：

數據分片，很多分布式系統尤其是中間件服務，一般都會涉及高并發，數據量大的問題，如redis-cluster、recketmq，以及被大家熟知的Elasticsearch。針對于大數據量高并發的問題，若不做處理，服務器的性能將會成為服務的瓶頸，解決的方案之一便是數據分片，將大數據量在集群中按照一定的規則分片，使數據按照一定的規則分布集群的不同服務器上，以減輕單個服務器的壓力，保證服務集群的可用性。

redis-cluster的數據分片是通過redis-cluster的哈希槽來實現的，redis-cluster有16384個哈希槽，這個數量是固定的，根據集群中服務器的數量可以手動的調配每個服務上存放的hash槽的數量，哈希槽之間是相互獨立的，因此對集群的擴展提供了便利。

rocketmq的分片和topic緊密相關，在使用rocketmq中，無論是消息的生產者還是消費者都需要注冊訂閱一個topic。在rocketmq集群中，集群中的broker保存這個topic下數據的一部分，也就是topic的其中一個數據分片。當然，rocketmq不僅將一個topic下的數據分片到多個broker上，而且，一個broker上的topic數據還可以被分為多個queue，這是因為rocketmq中，一個queue只能被一個consumer消費，若是consumer的數量多于queue的數量，沒有綁定queue的consumer將不能消費數據。

elasticsearch的數據分片在我看來和mysql的分庫分表原理是一樣的，elasticsearch中，每一個索引都相當于mysql的一個表，將一個索引分成多個shard放在不同的節點上，每個shard存儲一部分數據。elasticsearch將數據進行分片，這樣可以支持集群的橫向擴展，同時，多個節點提供服務可以提高系統的效率和吞吐量。

綜上所述，數據分片的一般都有兩個好處，一個是支持集群的橫向擴展，而是提升服務的吞吐量和性能。數據分片解決了以上兩個問題，但是若是集群中一個節點發生宕機，或者因為網絡原因和集群斷開鏈接，那么這部分的數據分片甚至整個集群都會不可用，如何解決這個問題，就需要用到數據備份和主備切換。

數據分片的策略 了解了數據分片之后，需要了解以下數據分片的策略，根據集群提供服務的性質不同，可以采用的數據分片策略也各有不同，下面是我學習后的總結：

說到這里，會發現其實這種分片策略和負載均衡的策略還是挺相似的。

數據備份，舉個例子來說，我有兩臺電腦A、電腦B，A用于工作，B用于游戲，我寫了一篇文章，保存在電腦上電腦上，若是某一天我的電腦A磁盤壞了，那我這篇文章就找不到了，即便我現在還有電腦B，我也沒有辦法在對文章進行編輯。但是若是我在之前，就將文章拷貝了一份放在電腦B上，那么現在，我用電腦B就可以對文件進行編輯修改。

舉這個例子，我的目的就是為了說明數據備份對于集群可用性的意義，例子中，我的兩臺電腦可以認為是集群中兩臺服務器，兩臺服務器一開始提供的服務可能不相同，A電腦提供的就是編輯文章的服務，數據備份的意義就在于，當原本提供服務的服務器宕機損壞，集群中另外的服務器仍然可以根據已經備份的數據提供相同的服務，而不會影響到用戶的工作。

數據備份的目的就是不發生單點問題的措施之一，但是若是數據備份的策略不合適，備份的時機不對，那么備份的數據時效性也是問題。還是從例子出發，這里的文章每次都是我手動從A電腦拷貝到B電腦，這是我的備份策略，若是我選擇每天晚上才拷貝一次，那么若是A電腦在我拷貝之前壞了，當天的文章編輯數據就丟失了，采用手動的方式備份，這種備份方式耗時耗力且不可控，而在分布式集群中，不同的系統采用了不同的備份策略，下面一一來說明。

首先明確一點，在分布式集群中，不可能采用人工手動備份，一定是系統程序按照一定的規則自動備份，就好像我將AB連在一起，寫個程序，讓A電腦自動把文章同步到B電腦。數據備份的方式分為兩種：

這里以redis-cluster和zookeeper舉例。

在redis-cluster中，當一臺新的slave節點加入時，會出發數據同步，需要將主節點的數據同步到從節點。這時根據從節點的狀態有兩種同步方案：完整重同步 和 部分重同步

完整重同步既是將主節點的全部數據都復制給新的slave節點。大致流程為，當一個新的節點加入進來時，發送PSYNC命令給主節點并攜帶slave節點自身的信息（重點是復制偏移量），主節點會根據slave傳過來的信息判斷是完整重同步還是部分重同步，如何判斷與數據同步時的復制緩沖區有關，更細節不展開介紹。

相對于redis-cluster，zookeeper中的數據同步有四種方式，和redis-cluster完整重同步和部分重同步相似的SNAP（全量同步）和DIFF（增量同步），以及zk事務處理相關的TRUNC（僅回滾同步）、TRUNC+DIFF（回滾+增量同步）

當節點已經加入集群，成為集群中的從節點，只要不斷開連接，一般都只需要進行增量同步，不過系統同步的范圍和方式有所差異，大致分為下面六種：

下面還是以具體服務來舉例： redis-cluster中，主從復制采用的是異步復制的方式，master節點在做數據變更之后，會由一個異步線程將數據變更同步給slave節點，這是通過push的方式。當redis2.8之后，slave會周期的獲取最新的數據，加入了pull方式。無論是master還是slave，在進行數據同步時，不會阻塞正常的應用請求。所以redis-cluster的主從復制，是異步備份+最終一致性的備份。

elasticsearch的主從復制可以手動設置同步備份或者異步備份，數據備份時不要求強一致性，而是主分片（primary shard）會維護一份需要同步的（replica shard）分片列表，這個分片列表同步完成，則認為數據備份完成，需要注意的是，這里的主從復制不是節點的更新數據，而是分片的更新數據。

rocketmq的主從復制和elasticsearch類似，也可以分為同步備份和異步備份，不同的是rocketetmq的數據備份采用的是pull的方式，從節點會通過HAConnection鏈接主動向主節點發送待拉取數據偏移量，待主節點返回節點更新數據信息，更新從節點數據偏移量，如此重復。

zookeeper的數據備份則是通過ZAB協議，通過消息廣播的方式同步數據到從節點。

當數據備份后，主從節點上就有了相同的數據，為了提升服務的性能，那么可以采用讀寫分離的方式。主節點提供數據寫服務，從節點提供讀服務，可以有效的分擔主節點的服務器壓力?？梢赃M行數據分片的系統，如：redis、rocketmq、elasticsearch，一般都可以配置一主多從、多主多從的集群架構。

讀寫分離之后，主節點提供寫服務，從節點只提供讀服務，因此若是主節點發生宕機，從節點依然可以提供讀服務，但是服務無法更新數據，這時候就要進行主從切換。早起，主從切換可以由人工手動完成，不過隨著技術發展，主從切換已經成為集群的必備功能。想要實現主從切換，必須要解決兩個問題：

解決這個問題，需要額外再引入一個角色，相當于是一個監視者的角色，能夠長期的對主節點進行監視，若是只有一個監視者，可能會發生誤判，所以還需要一套機制去保證當監視者說主節點宕機，那么主節點是真的宕機，否則集群會出現腦裂問題。

以redis為例，在redis的哨兵模式中，這個監視者的角色是一個個哨兵實例，而在redis-cluster架構中，這個監視者的角色是redis實例自己。

在redis哨兵模式中，哨兵集群中的哨兵實例會定期和redis實例進行通信（ping），監視redis實例的在線情況，若是其中一臺哨兵發現redis實例master故障，那么該哨兵會將該master狀態改為主觀下線，并通知其他哨兵，當哨兵集群中達到配置數量的哨兵實例認為該master都為主觀下線狀態，這時會將master修改為客觀下線狀態，并開始觸發后續的故障轉移。

在redis-cluster模式中，集群中的每一個節點都可以和其他節點通訊（ping），當某一個節點A發現主節點B下線了，A會將該主節點B設為疑似下線狀態。集群中的節點會通過互發消息維護信息，當另一個節點C收到A的消息時，會將A對B節點的判斷記錄在C節點的維護信息下，這個信息可以理解為A說C疑似下線了。若是有其他節點發送C的狀態信息，A同樣也會記錄。當某一個節點如C發現記錄的B節點信息中，超過半數的主節點都認為B下線了，那么C就會將B節點狀態修改為已下線狀態，并廣播消息給集群的其他節點，開始后續的故障轉移。

上面就是redis的兩種分布式模式故障檢測的方案。大致可以歸結為，監視節點會和被監視節點進行通訊，感知被監視節點的狀態；監視節點之間也會進行通訊，同步信息。為了防止集群出現腦裂，對于某個主節點的故障判斷會十分的謹慎，需要達到一定數量的監視節點都認為主節點故障時，才會認為主節點真的故障，從而觸發故障轉移。

在rocketmq集群模式中，nameserver扮演著監視者的角色（不同于其他系統，nameserver并不負責集群的主從切換，rocketmq 4.5之前不支持自動主從切換，4.5之后，通過dledger實現自動的故障轉移）。在elasticsearch集群中，elasticsearch實例本身在扮演監視者角色。zookeeper也是實例本身扮演監視者的角色。

故障轉移就是當集群發現集群中的主節點/從節點發生故障之后的處理，從節點比較簡單，直接將從節點下線即可，主節點的故障轉移流程比較復雜，各個系統根據系統的功能和架構有不同的實現方式，共同點是選舉出的主節點一定是集群中數據最新的最完善的節點。

選舉過程大致如下：

首先選舉成功的條件時集群中具有投票權限的超過半數的節點投票一致，通過某一個節點成為主節點。

開始一輪選舉時，定義為一個紀元，用一個自增的id表示。

候選節點將帶著紀元id，以及自身信息作為投票申請廣播給集群給可投票的節點。

具有投票權限的節點投票只要滿足兩個條件：1.自身在最新紀元沒有給投過票 2.節點發送過來的投票申請時最新紀元的（如何判斷時最新紀元，則是判斷一下節點之前通過申請的紀元id是否小于當前申請的紀元id）。

半數以上的投票節點通過某一個候選節點成為leader節點，則leader產生。

若是一個紀元沒有產生主節點，則候選節點進入隨機的休眠，并且開啟下一個紀元，知道產生leader節點。

在zk集群經過崩潰恢復模式之后，需要保證：1.已經提交的事務不能丟失 2.未被提交的事務不能出現。如何保證以上兩點，zk服務集群中維護了zxid，zxid也可以看作是一個自增的id，集群中每產生一個新事物，zxid就會增加。zxid有64位，前32位維護了集群主節點變更情況，每重新選舉出一個新的主節點則增加，后32位維護在新的主節點集群下事務的id，產生一個新事物則增加。

ZAB的選舉模式有很多種，我主要了解了默認，也是推薦的FastLeaderElection模式，在這個模式下，我會以集群中一臺參與選舉的服務器的視角來模擬選主的過程；

我是一臺zk服務器，我現在很慌，因為我的leader服務器不見了，作為一個有夢想的follower，我也要參加leader的選舉，為了這次選舉我要準備：myid(在集群中標識是這臺服務器的id)，zxid(本臺服務器保存的最新事務id)，logicClock(本臺服務器發起的第幾輪投票)

首先我會自己選自己，這得自信。于是我將自身的選舉信息[myid, zxid]放到自己的收票箱，然后將我的選舉信息還有我的選舉輪次logicClock廣播給其他服務器進行PK

作為一個有原則的服務器，我們的選舉也是有原則的，當我收到別人的選舉信息時，我也會將他和我自己的選舉信息進行PK，PK的原則如下：

經過這一系列的PK，終于選出了我心中的leader服務器，要廣播給其他服務器。

超過半數的服務器都同意某一臺服務器成為leader，選舉結束了。

SAP系統是什么

SAP起源于Systems Application, Products in DATA processing. SAP既是公司名稱,又是其ERP (Enterprise-wide Resource Planning)軟件名稱。

SAP是國際上著名的標準應用軟件公司。SAP總部設在德國南部的沃爾道夫市，公司成立于1972年，1988年成為德國股票上市公司。到1995年底，SAP在世界40多個國家和地區設有代表處和獨立子公司，具有近5000家用戶，成為世界第五大軟件供應商。1995年SAP集團在中國設立了子公司。

SAP的一整套程序是針對所有企業的一種數據和應用集成方法，它將業務和技術進步融入了一個綜合性的高品位的標準系統，即商品化軟件系統。SAP的主打產品R/3是用于分布式客戶機/服務器環境的標準ERP軟件，主要功能模塊包括：銷售和分銷、物料管理、生產計劃、質量管理、工廠維修、人力資源、工業方案、辦公室和通信、項目系統、資產管理、控制、財務會計。R/3適用的服務器平臺是：Novell、Netware、NT Server、OS400、Unix ，適用的數據庫平臺是：IBM DB2、Informix、MS SQL Server、Oracle ，支持的生產經營類型是：按定單生產、批量生產、合同生產、離散型、復雜設計生產、按庫存生產、流程型，其用戶主要分布在航空航天、汽車、化工、消費品、電器設備、電子、食品飲料等行業。

2.2 SAP公司的軟件

R/2和R/3系統是德國SAP公司所提供的MRP II產品。R/2是用于集中式大型機環境的系統，R/3是用于分布式 的客戶機/服務器環境的系統。

2.3 R/2和R/3系統的共同特點如下：

（l）綜合完善功能：系統提供的應用功能有：會計、后勤、人力資源管理、辦公室和通信等。它涉及各種管理業務，覆蓋了管理信息系統中各種功能。

（2）高度集成模塊：系統具有一個高度集成化的結構，表現在它所提供的各種管理業務功能之間都是相互關聯的，各模塊輸入輸出相互銜接，數據高度共享，任何數據的修改都將會引起相關數據自動修改。

（3）適應多種行業：系統是一個能夠適用于多種行業應用的軟件，它是通過標準核心軟件與不同行業特點相結合而產生的。應用領域主要是各種制造業，此外，在零售公司、公共設施、銀行、醫院、金融和保險也有應用。

（4）開放應用環境系統是一個開放式軟件系統，它可以運行在所有主要硬件平臺和操作系統之上和不同數據庫，有HP－Unix操作系統，IBM的AS/400操作系統，Windows NT，Oracle數據庫，Informix數據庫等，以及在Sequent和Compaq計算機上同時運行Unix和Windows NT的Server的平臺。

2.4 點評：

R/3的功能涵蓋了企業管理業務的各個方面，這些功能模塊服務于各個不同的企業管理領域。在每個管理領域，R/3又提供進一步細分的單一功能子模塊，例如財務會計模塊包括總賬、應收賬、應付賬、財務控制、金融投資、報表合并、基金管理等子模塊。SAP所提供的是一個有效的標準而又全面的ERP軟件，同時軟件模塊化結構保證了數據單獨處理的特殊方案需求。

目前，排名世界500強的企業，有一半以上使用的是SAP 的軟件產品。因R/3的功能比較豐富，各模塊之的關聯性非常強，所以不僅價格偏高，而且實施難度也高于其他同類軟件。R/3適用于那些管理基礎較好經營規模較大的企業，普通企業選擇R/3時，要充分考慮軟件適用性和價格因素，中小型企業則可選擇SAP Business One，簡稱SBO。介紹如下。

3．SBO介紹

3.1 什么是SBO?

SAP Business One是專為小型企業設計的企業管理信息系統軟件

SAP Business One -- 這套操作簡單但功能強大的解決方案能夠滿足客戶標準的業務需求，它涵蓋財務、物流、銷售自動化以及其他功能。它專為小型企業設計，這些企業需要在IT解決方案中得到相對簡單的，具有特定行業需求的功能。

SAP Business One能夠優化企業的各個方面，從財務會計到制造直到銷售與服務。它還提供真正的創新特性，包括自動物料要求規劃的五步 MRP 向導，以及允許用戶通過一步鼠標點擊操作將不同信息片段鏈接在一起的 DragRelate 工具。

3.2 SBO業務管理

財務 -- 處理所有財務交易，包括總分類帳、科目設置和維護、日記帳分錄、匯兌損益調整、預算定義、成本中心設置、成本分配規則等。

財務功能提供的工具和報告用于管理所有的財務流程，包括:

會計科目表

日記帳分錄

過帳模板

匯率差異

周期性過帳

沖銷事務

資產負債表

定義利潤中心

預算

財務報表模板

定義分配規則

利潤中心和分配規則表

銀行交易 -- 處理所有收付款相關業務，例如現金收款，開具支票，存款，信用卡付款以及銀行對帳。

銀行交易旨在利用以下工具幫您處理所有財務事項:

收款

支票

信用卡管理

付款向導

銀行對帳和核銷

對帳向導

銷售與應收帳款 -- 創建報價，輸入客戶訂單，設置交付日期，更新庫存余額，并管理所有發票和應收帳款。

從報價到開具發票和付款，銷售和經銷功能將幫您利用以下工具和能力完成整個銷售流程:

報價單

訂單

交貨

退貨

應收發票

應收發票和付款

應收貸項憑證

單據打印

自動匯總向導

催款向導

采購/應付帳款 -- 管理和維護供應商合同和交易，例如簽發采購單，更新庫存數量，計算進口商品的到岸成本價值，處理退貨以及紅字發票。

采購功能用于管理和維護您與供應商關系的各個方面。這一功能提供的工具和流程包括:

采購訂單

收貨采購訂單

采購退貨

應付發票

應付貸項憑證

到岸成本

單據打印

客戶關系管理

銷售機會業務伙伴 -- 維護客戶、分銷商和供應商的所有信息 ，包括客戶檔案、相關業務交易，以及帳戶余額，并可管理與該客戶相關的活動日程表。

服務 -- 挖掘服務部門的潛力，對服務部門的運作、服務管理、服務計劃提供支持，跟蹤客戶交流活動和客戶支持。提供的知識庫可幫助技術人員研究或解決問題。