問題一：由於sap中技術搭建bom時維護金工板材數量使用的是板材淨重，與實際生產過程中領用量存在差異，導致產品報工反衝板材時，差異留存在庫存中，需要手工核算調整。
解決方案：新方案通過在系統中錄入鈑金程式單，獲取板材實際用料，並關聯程式單對應的生產訂單，按照生產訂單中，板材淨重換算分配比例，將板材實際用量分配到各生產訂單，並領料過賬。
問題二：對於部分公司，既是我們的**商，又是我們的客戶的情況，列印付款申請單的時候，實施人員讓我做了個彈窗，大概長這個樣子.
大概意思就是：付款的時候注點意哈，這個公司還欠咱錢呢，別那麼實在的把錢都給付了，要賬的時候不好要了。
高併發業務場景下常見的解決方案
由於系統都是連線資料庫的，但是一般最多資料庫每秒只能支撐幾千的並非，如果業務量激增，會導致系統宕機 因此需要從一下幾點入手設計 系統拆分 快取 mq 分庫分表 讀寫分離 搜尋 將乙個系統進行功能拆分，如現在流行的微服務，每個服務連線的資料庫分開，分開部署。這樣可以將壓力進行拆分，緩解因為網路和資料庫...
kafka 訊息重複的場景及解決方案
訊息重複和丟失是kafka中很常見的問題，主要發生在以下三個階段 生產者階段 broke階段 消費者階段 根本原因 生產傳送的訊息沒有收到正確的broke響應，導致生產者重試。生產者發出一條訊息，broke落盤以後因為網路等種種原因傳送端得到乙個傳送失敗的響應或者網 絡中斷，然後生產者收到乙個可恢復...
Redis 擊穿 穿透 雪崩業務場景和解決方案
擊穿 原因給key設定了過期時間 lru lfu 當key過期之後，資料被清理掉了。突然來了一批訪問這個key的。這是請求就會壓到資料庫上 key的過期導致的高併發訪問資料庫，給資料庫造成了壓力 如果過期之後，只有少量請求訪問這個key，達到資料庫不能成為擊穿。只有出現高併發的時候，對資料庫產生影響...