在前面的文章中，作者已經(jīng)獨自完成了工具選擇和工具的使用，并借助工具完成了商品維護、倉庫管理、供應(yīng)商管理功能，這篇文章，一起來看看是如何做進出庫功能的。

一、前情回顧

上一篇結(jié)束的時候，我已經(jīng)完成了“商品維護”的功能。之后，我用相同的方式完成了倉庫管理和供應(yīng)商管理的功能，這兩個功能均為單模型的增刪改查，所以，我就不做重復(fù)的描述了，給大家看看做好以后的樣子。

我在倉庫中錄入了兩條數(shù)據(jù)，一個倉庫叫陳列庫，一個叫備貨庫。說簡單一點，商品到了超市，我會先讓入備貨庫，當我需要擺到貨架上時，會做一個移庫，將商品從備貨庫移動到陳列庫。

在供應(yīng)商信息中，我也錄入了兩條，這兩條記錄各位就不用在意了，純屬瞎編的，只是為了讓我做數(shù)據(jù)的時候有一個供應(yīng)商可以選擇。

做了這些，基礎(chǔ)數(shù)據(jù)也就差不多了，接下來，按照順序，我得先做進貨入庫的功能了，有了庫存才可以做后續(xù)的功能。（其實我這里所說的順序，只是業(yè)務(wù)上的邏輯順序，實際開發(fā)的時候，不同的模塊完全可以同步進行）

二、進貨入庫需求描述

進貨入庫場景，就是我管理的小超市到貨以后，我將這些商品庫存增加到備貨庫的過程。由于這個場景不屬于高頻場景，所以我打算做的簡陋一點，就直接用一個主子結(jié)構(gòu)的表單作為入庫單的操作界面。

不過，之所以這么設(shè)計，也是因為我還想嘗試一下使用模板頁面，之前都是用模板頁面制作單模型的增刪改查，這一次我打算使用模板頁面制作主子結(jié)構(gòu)的表單增刪改查。

還有一點值得注意，由于我做的是進貨入庫的場景，所以這次并非是簡單的數(shù)據(jù)新增和編輯，還涉及到根據(jù)入庫單新建庫存數(shù)據(jù)，因此會使用到邏輯服務(wù)的功能，也正好看看邏輯服務(wù)到底好不好用。

三、實體設(shè)計

我還是直接擺出我做的實體設(shè)計然后解釋一下我的想法

每次入庫，對應(yīng)一個“入庫單”數(shù)據(jù)，而每次入庫，又會有多個商品明細，所以我增加了“入庫單明細”這個實體。如果你仔細看會發(fā)現(xiàn)一個問題，我在“入庫單”和“入庫單明細”上都增加了“倉庫”這個字段。這是因為有的用戶認為不同倉庫的入庫需要分別錄在不同的入庫單上，但也有用戶認為，多個倉庫的入庫信息完全可以錄入到一個入庫單上，為了滿足這兩種情況，我在實體設(shè)計的時候，就在“入庫單”和“入庫單明細”上都增加了“倉庫”字段，方便我根據(jù)不同的客戶進行調(diào)整。

另外一個關(guān)鍵的店就是“庫存”實體，有不少場景簡單的進銷存系統(tǒng)會將庫存直接作為商品模型上的一個字段，這么做其實就默認了用戶只會根據(jù)商品進行庫存的查詢。

但實際上，用戶根據(jù)什么維度查看庫存是沒法給出結(jié)論的，在查詢商品庫存時，用戶可能忽略倉庫，看到商品總庫存；但是進行盤點時，用戶希望看到的肯定是每個倉庫有商品多少個。

在一些需要進行倉庫精細化管理的場景中，商品不同的有效期、批次號以及放在不同的倉庫、庫區(qū)或者貨位，都是要分開查看的。

根據(jù)我個人的經(jīng)驗，要滿足精細化倉儲管理，庫存模型需要至少含有倉庫、商品、批次號、有效期、庫位（庫區(qū)根據(jù)庫位可以關(guān)聯(lián)出）、供應(yīng)商這幾個字段。在這次嘗試中，我用了較為簡單的設(shè)計模式，只采用了倉庫、商品、供應(yīng)商這三個字段作為庫存的屬性。

四、功能配置

1、入庫單詳情頁面

由于入庫單詳情由“入庫單”和“入庫單明細”兩個模型組合而成，所以會用到平臺一個叫做“組合模型”的概念。首先，我新建一個組合模型——“入庫單-組合”。新建組合模型操作比較簡單，我將“入庫單”設(shè)置為主模型，“入庫單明細”設(shè)置為子模型，系統(tǒng)會自動根據(jù)關(guān)聯(lián)關(guān)系將兩個模型組合起來。

組合模型創(chuàng)建完畢以后，就需要制作詳情頁面，詳情頁面的制作和單模型幾乎是一樣的，只不過在選擇模型的時候，選擇這次我們創(chuàng)建的組合模型就可以。

使用組合模型做詳情頁面的時候，平臺會自動的將主表字段放在表格區(qū)域，將子表字段放在編輯列表區(qū)域，所以我還是只需要選擇自己需要的字段。

除了簡單的選擇字段，這次我還做了一些個性化設(shè)置，我總結(jié)在下方：

1、由于組合模型本身就定義了兩個模型是根據(jù)入庫單字段關(guān)聯(lián)，所以我們做操作界面的時候，可以在頁面中去掉“入庫單”字段，系統(tǒng)會自動處理兩個模型的關(guān)聯(lián)關(guān)系。

2、這次我打算配置的場景是“一個入庫單只能向一個倉庫入庫”，因此我在子表的“倉庫”字段上設(shè)置了一個“跟隨”屬性，讓子表的“倉庫”跟隨主表的“倉庫”，并且將子表的倉庫設(shè)置為“隱藏”，這樣就可以讓子表上看上去沒有倉庫字段，實際上當主表的倉庫改變時，子表的隱藏字段也跟著改變。

3、由于我偷懶，入庫單的狀態(tài)字段使用的是文本類型，所以我將“入庫單狀態(tài)”這個字段改為隱藏的，并且默認值是“暫存”，這樣就可以實現(xiàn)我所有新增的入庫單狀態(tài)都是“暫存”，且用戶不可編輯也看不見這個字段。

4、由于我的主表上有一個“匯總數(shù)量”字段，這個字段需要匯總所有明細的數(shù)量。所以，我將“匯總數(shù)量”字段設(shè)置為“只讀”，然后給它設(shè)置了一個匯總所有明細數(shù)量的公式，這樣就可以實現(xiàn)明細的數(shù)量改變時，自動更新匯總數(shù)量。

預(yù)覽一下，可以看到詳情頁面的效果

2、入庫單列表頁

入庫單列表頁的配置，和單模型的就真的差不多一樣了，所以我就只截圖說明一下這一次配置的差異。由于這次我要看的入庫單是主子結(jié)構(gòu)的組合模型，所以我配置的是一個上下結(jié)構(gòu)可以聯(lián)動的兩個列表，上面的列表是入庫單信息，選擇某個入庫單信息，會在下面的列表顯示入庫單的明細信息。配置的時候，只需要修改一下頁面結(jié)構(gòu)，就可以改為上下兩個列表，并為每個列表設(shè)置字段。

在將詳情頁與列表頁的按鈕掛接以后，配置到菜單中，一個入庫單的增刪改查就做好了，只給大家截圖展示一下做好的效果，重復(fù)的過程就不多說。

五、邏輯服務(wù)-入庫單審核生成庫存

1、設(shè)計數(shù)據(jù)操作流程

現(xiàn)在還缺一步，也是這次體驗的重頭戲，我需要做一個入庫單審核功能，入庫單審核以后，增加庫存數(shù)據(jù)。首先我設(shè)計了一下入庫單審核邏輯具體的數(shù)據(jù)操作流程，如下圖：

所以，這個邏輯處理是需要有一個傳入?yún)?shù)的，我需要入庫單的ID作為入?yún)?，才可以?zhí)行整個邏輯。下面我們就在邏輯服務(wù)功能中進行邏輯的配置。

2、邏輯服務(wù)配置

首先新建一個空的邏輯服務(wù)，由于整個邏輯需要用到入庫單ID作為入?yún)ⅲ晕以凇叭雲(yún)⒃O(shè)置”中增加一個“記錄標識”類型的參數(shù)，名字可以隨便取，就直接取名為“ID”吧。

出參和全局變量目前不需要設(shè)置，不過還是簡單說一下，邏輯服務(wù)執(zhí)行完畢，需要將什么數(shù)據(jù)返回給調(diào)用的地方，就需要用到“出參設(shè)置”，在整個邏輯中用到的臨時變量，就需要設(shè)置在“全局變量”中，一開始考慮不清楚沒關(guān)系，我一般都是邊做邊想，差什么就到這兒來補什么。

接下來，就開始配置邏輯，根據(jù)之前分析的數(shù)據(jù)處理流程，我們先拖入一個查詢組件，用來查詢出入庫單下面的所有明細。

由于不是使用教程，只是我個人的體驗記錄，所以我就只說說我的設(shè)置，不做所有功能的講解。在這個查詢組件里，我選擇要查詢“入庫單明細”這個模型，查詢條件是“入庫單”這個字段等于入?yún)D。查詢的結(jié)果返回給一個叫做“入庫單明細集合”的變量，注意，這個變量是我在“全局變量”中增加的，是一個集合類型的變量，集合中的元素，我選擇的是入庫單明細模型。

接著，我拖入一個循環(huán)組件，在循環(huán)組件上設(shè)置根據(jù)“入庫單明細集合”進行循環(huán)

在循環(huán)體內(nèi)，我首先做了一個查詢，查的目標是“庫存”模型，我需要查詢和當前正在循環(huán)的“入庫單明細”相同商品，相同倉庫，相同供應(yīng)商的庫存數(shù)據(jù)。

注意，這里的返回值也是我臨時添加的一個叫做“庫存數(shù)據(jù)”的變量，它是一個模型類型的變量，關(guān)聯(lián)的庫存模型。

其實，這個查詢不一定可以查出結(jié)果，因為本次入庫的商品，也許是第一次入庫的，所以經(jīng)過這個查詢組件，“庫存數(shù)據(jù)”這個變量，有可能是空的，也有可能查出了一條數(shù)據(jù)。

接下來，我就拖入了一個分支組件，開始進行分支的設(shè)置了。我分為兩個分支，首先是可以查出庫存數(shù)據(jù)，我在分支條件上是這么設(shè)置的，如下圖

如果可以查出庫存數(shù)據(jù)，我就需要增加這條庫存數(shù)據(jù)的庫存，所以我使用了“單模型保存”組件，修改了庫存的值。

另一條分支是沒有查出庫存數(shù)據(jù)，這時，我需要新增一條庫存數(shù)據(jù)，我同樣也使用單模型保存，為新的庫存數(shù)據(jù)的每個字段都設(shè)置好值

最后，這個分支就可以結(jié)束了。

對每一條入庫單明細都進行這個邏輯的循環(huán)以后，我就別忘了還有最后一步，因為我現(xiàn)在執(zhí)行的是入庫單審核，是需要修改入庫單狀態(tài)的，所以我最后使用“批量更新”組件，根據(jù)入庫單ID更新入庫單的狀態(tài)字段，修改為“已審核”

這樣，我們的邏輯服務(wù)就做完了。不知道各位有沒有發(fā)現(xiàn)這個平臺的一個特點，這個平臺是真的打算用這些組件配置出任意的復(fù)雜邏輯，循環(huán)、分支、數(shù)據(jù)的操作，集合的操作，變量的操作一應(yīng)俱全，缺點就是要求相對較高，需要用戶能理清楚數(shù)據(jù)邏輯，不過這是缺點，也可以認為是優(yōu)點，因為只有這樣才可以真正的靈活和自由，關(guān)鍵在于用戶是誰。至少對于產(chǎn)品經(jīng)理來說，能夠理清楚系統(tǒng)的數(shù)據(jù)邏輯應(yīng)該是基本要求了，如果數(shù)據(jù)邏輯沒法考慮清楚，那么產(chǎn)品經(jīng)理是不可能真正把握產(chǎn)品的。

回到系統(tǒng)配置的話題，接下來，我們就要將這個邏輯掛在頁面按鈕上了。

3、按鈕掛接邏輯服務(wù)

回到列表頁面，我們需要設(shè)置行按鈕，增加一個“審核”按鈕

然后在審核按鈕上掛上我們剛才做好的邏輯服務(wù)，選擇邏輯服務(wù)以后，我們發(fā)現(xiàn)有一個參數(shù)要傳入，我們選擇“頁面元素-記錄標識”，這樣邏輯服務(wù)就配置好了。

這時，我考慮到一個單據(jù)只能審核一次，所以我為審核按鈕加上了前置條件，這件就只有“暫存”狀態(tài)的單據(jù)可以看見這個按鈕，審核以后，就看不見審核按鈕了。

六、結(jié)語

到這里，入庫單功能就做好了。關(guān)于效果，我就不截圖說明了，因為沒有什么特殊需要說明的地方。這次的嘗試，我體驗了主子結(jié)構(gòu)的詳情頁面的編輯方式和效果，只能說中規(guī)中矩。讓我比較歡喜的，倒是邏輯服務(wù)的功能。邏輯服務(wù)的整個設(shè)計思路就是后端接口的設(shè)計思路，有入?yún)?、邏輯和出參。倘若后面的邏輯都按照這種方式來做，會比市面上的低代碼平臺自由很多。

另外，在我做完邏輯服務(wù)以后，我發(fā)現(xiàn)了一個比較讓我驚喜的功能，我發(fā)現(xiàn)邏輯服務(wù)居然還可以打斷點和調(diào)試。這是我沒想到的，這種功能一般出現(xiàn)在后端開發(fā)的IDE工具中，這種在網(wǎng)頁端的畫布上做邏輯，并且還支持斷點和調(diào)試的工具，真不多見。況且，這也不是真的在寫代碼，而是使用組件組裝業(yè)務(wù)邏輯。之所以我后來才發(fā)現(xiàn)，是因為這個功能太低調(diào)了，不那么顯眼，但使用以后我覺得，真的非常有必要，否則我就得把操作界面都做好以后再調(diào)試我寫的邏輯有沒有問題了。

在我準備結(jié)束文章的時候，我又發(fā)現(xiàn)，邏輯服務(wù)居然還有類似后端開發(fā)的方法封裝，可以在一個邏輯服務(wù)中，調(diào)用另外已經(jīng)寫好的邏輯服務(wù)，這個也是非常有意思的特點，這就表示，只要我好好規(guī)劃，我可以寫出復(fù)用率較高的邏輯，調(diào)試、封裝，這兩個功能的出現(xiàn)給出了一個信號，這個平臺并不打算讓用戶小打小鬧，而是真的在上面開發(fā)正規(guī)的軟件。

在最后，我覺得，這個平臺的產(chǎn)品經(jīng)理得批評一下，這么些讓平臺上限提高的功能，如果是我，我會放在更顯眼的地方，甚至引導(dǎo)用戶去使用，也許，這個平臺的產(chǎn)品經(jīng)理，更多的偏技術(shù)，而忽略了這些小的用戶體驗問題。