July 7

我现在有个弄不确定的地方，schedule blend，在Bin列上的这个，这个放在这其实是为用这个Bin的值对吧，是为了多个搅拌业务合用一个Bin?

是哪一页上的Bin列，RigBoard？还是Bulk Plant Board?

搅拌业务应该用搅拌申请更恰当，但是这种关键的概念还是用英文比较好Blend Request。

Bin是一个容器， 它是装载搅拌好的水泥的成品，然后会用掉，清空，再装下一个水泥。申请是一个队列，它不是合用。

在Bin 列上的Schedule Blend的目的是我们可以从Program创建Blend Request。在Pref/Blend/Disp 列上Schedule Blend是从Callsheet开始创建Blend Request。

在RigBoard的Bin列，它针对的是Rig Bin, 所以它针对不只是一个Bin，也可能是多个Bin。从plan文档的截图上你可以看到这部分是改过的， 是罗列了每个Bin，要求输入Amount。

在Bulk Plant Borad的Bin列，它针对的是Bulk Plant Bin, 它只是一个Bin。从plan文档的截图上你可以看到这部分是没改动的，是下拉框。

详细重读了下部分Eservice原来的代码，新任务的schedule Blend其实是新建productHaulLoad,但建立ProductHualLoad就得建立ProdductHual，在test blend 不选的情况下,只不过这ProductHaul里的内容大部分是空的，

你说反了，应该是"在test blend 选的情况下, ProductHaul里的内容大部分是空的，"，而且与之关联的Schedule数据都没有创建

是的，原来两个是绑在一起的，现在要完全分开。

只有Estimated Load Time是赋值了。这样我们在reschedule blend和cancel blend的菜单中，可以只有一级子菜单，我感觉product haul那级菜单作用不大。当然要是和上面统一是最好，有两级。

如果有ProductHaul就是两级，如果没有就是一级。

你在概念上和菜单标题上稍微有没理顺。在Rig Bin的菜单中，我们的菜单应该改成Schedule Product Haul，而不是Schedule Blend。因为这里创建的都是运到现场的。

只是我们reschedule blend下的第一级菜单是否就不用有点击后弹出：reschedule product haul的这个操作了，感觉这个就是要操作也只是就能改一项内容就是Estimated Load Time，应该和现有页面也不太一样，只保留第二级菜单的reschedule blend就行了。

cancel blend 按感觉原来的逻辑应该就是对的。

还有个问题，就是producthaulload里面的producthualid是0的因为是选了blend test后product haul就不创建了，那上次你说的以后blend test就是一个标记了那这块的后台逻辑变不变呢。如果后台逻辑变了的话，只是把这标记存入product hual，这块估计后端都得添加新的处理方法了。如果后台逻辑不变的话，那直接调用原来的方法，只需要很小的改动，甚至不改就能通过。

blend test是Blend Request(ProductHaulLoad)的属性，它应该没有后台逻辑。它原来是前台控制界面来实现没有Product Haul数据输入。

你现在想的有点多，我让你只做Pref/Blend/Disp 列上Schedule Blend是从Callsheet开始创建Blend Request这一部分。不要去改原来的功能和逻辑。通过做这一部分，你会对这些关系更清楚一些。

JULY 19

Questions

如果一次拉完是不是就直接把product haul和product haul load两条记录修改，一次没有拉完，那是不是要创建新的product haul和product haul load是拉走的部分,而没有拉完的这部分product haul和product hual load还继续保留。

另外domain model里的 shipingload sheet和unload sheet这两个部分和haul blend暂时没有什么关系。

是不是说一个haul blend要programid 和call sheet number都是有值的。

Answers

ProductHaul和ProductHaulLoad最初根据需求设计时认为是一体的，也就是说ProdcutHaulLoad创建了，它就必须被拉走，它一定有一个ProductHaul存在，所以ProductHaul和ProductHaulLoad是组合关系。这从命名上可以看得出来。

在系统建成和使用过程中获得了反馈，以上假设并不完全成立。ProductHaulLoad实际上是BlendRequest，也就是搅拌申请和物料单，它关注的是一批水泥的生命周期，理想的情况是我们应该对其重新命名，但是由于它已经适用于生产系统，我们只能暂时保留命名，但是我们要清楚概念上的转变。

V2的任务是完善运输流程，并对水泥的生命周期进行进一步的描述。ProductHaul与ProductHaulLoad(BlendRequest)的关系不是直接的组合关系了，变成了多对多的关系，也就是一批水泥可以多次运，而一次运输可以装载不同批次的水泥。所以我们引进了新的概念ShippingLoadSheet，它描述的是一次运输中的一个批次的水泥的运输量和目的地。对应的是Haul Blend界面上的若干个Bin Load Amount。PodLoad是装车单，它是ProductHaul的一部分，它也要明确每个Pod里面运的是什么，所以它会关联到ShippingLoadSheet.

具体到每一种情况，参考文档Blend Request Scenarios with prototype中4和5。

回到programid 和call sheet number是否都有值的问题，答案是不一定。在ProductHaulLoad中，它取决于从Program开始还是CallSheet开始。在Haul Blend的中，我们只关心Call Sheet Number, 从它ShippingLoadSheet 和ProductHaulLoad的关联上，我们至少可以拿 到ProgramId，在建立ShippingLoadSheet的过程中，可以列出源自同一个Program的未来的Callsheet，但是用户也可以不选，因为这个ProdcutHaul可能还是为未来的工程而拖运的，Call Sheet 还没有创建。

目前你需要只关注Blend 列上的Haul Blend的功能，在这个功能里，ProductHaulLoad是从CallSheet开始创建的，它所有信息是完备的。这样有利于你理解Domain Model的进化。完成了这一步，你对新增实体与原来之间的关系会有更深层次的理解，再去做其他两个HaulBlend。次序上听我安排。因为在不破坏原有功能的前提下，实现中逻辑上会有冲突，一次重要的重构会发生，并且需要进行数据转换。这些需要你自己最终想出来，并把它实现出来。

JULY 20

Questions

有个问题就是现在也有hual blend，是需要在这个上面改，还是重新写新的。

现有的HaulBlend里面binSelectList、callSheetList、binList都是固定值，这块有点奇怪啊。

再一个就是你上个邮件说haul blend需要一个条件就是ready,是不是指的是：ProductHaulLoadStatus为这个值[Description("Loaded")]Loaded = 5。

Answers

原有的HaulBlend方法是一个设计原型，不是真正的代码。是需要重写的。

这就涉及到一个开发方法的问题，你可能不是很清楚。当我们进行开发的时候是需要与用户进行沟通的，沟通的最好的工具其实就是用户界面原型， 所以我们要用最小的工作量给用户展示一个可以工作的界面，以此来确认用户对数据、行为的实际需求。然后进行后端的设计和开发。这是一种由前端面向后端推进的方式的开发。这种方式是界面优向。

在此前我们做开发的时候，都是我把最后的模型定义好，元元方生成后端，然后你构建前端。这是因为我们是分析设计优先。

只要你是前后融汇贯通的，这些都不应该是问题。我建议你以通样的方式先调好前端页面，然后再调整前端的Model，为了与之前区分，不要继续使用ProductHaulModel，可以建一个新的HaulBlendModel。前台行为确定了，后面如何链接后台也就更清楚了。

Haul Blend需要的条件是ProductHaulLoad的状态是Ready, 但是Stored状态时也可以，需要弹出一个警告。我在Plan文档中加了一个说明。这些状态都是新加的。我在ShippingLoadSheet中也加了一个BlendTestingStatus属性来保存Haul Blend的时候，这个Blend的测试状态。

July 21

Questions

今天开始了haul blend编码，主要是弹出页面的部分，有几个问题。能弹出来了，数据显示还有些问题，有时间可以帮忙看看有什么不对的地方。

因为定义了HualBlendModel实体变了，view里的子控件都不能用了，都得重新写,这块有什么好的办法吗，暂时没有想出来。

在PodLoad实体这两个是什么意思：BaseBlendWeight TotalBlendWeight，哪个是界面上显示的那个4pod的值。

界面里的Load Sheet Id 这个和producthaulload实体哪个对应的。

Answers

最大的问题是你没有把问题搞清楚，就把前面的HaulBlend的代码拷贝过来然后在上面改。界面上哪个数据项对应原来ProductHaulLoad中的哪个数据项没有搞清楚。不先做映射，直接写代码，后面会越做越乱。这也是你后面的几个问题的来源。在真实的业务环境中，一个概念有若干种叫法是正常现象，所以你要依据代码中的命名和文档中的名词进行映射对理解。比如界面 上的Category， 简洁，用户这么叫，也明白是什么意思, 在ProductHaulLoad实体中叫做BlendCategory，它命名更准确，否则会产生歧义。

粗心大意的问题一定要改。表单中第一个数据项就错了。文档中是Bulk Plant，你做成了Base Blend。

View里的子控件就是一个子View，哪么对应它自己应该对应的Model。每个子Model对应的应该是不同的实体也就是不同的目的。

在Haul Blend这个界面中，大致分为几块：

1. Header，这部份是从ProductHaulLoad中来，也就是原始的BlendRequest，这个View是原来没有的，是只读的。
2. Shipping amount and destination。这个对应的ShippingLoadSheet，这个是新的，需要建一个新的子View
3. Product Haul, 这部分是以前有的，但是命名上是不规范的，因为Miguel在重构的时候只懂逻辑，并不清楚业务。它叫_NonBlendTest。这个部分是整个可以用的，然后再加上PodLoad子View。

在第一步加HaulBlend功能，我们需要借鉴原有的代码，但是不能影响原有功能，所以需要并行构建新的Model和子View，如果可以直接用，就复制一份，把名字加一个V2的后缀。等到这一路完全跑通，我们会对原来的功能进行重构，用V2代码去替换老版本。

在PodLoad实体这两个是什么意思：BaseBlendWeight TotalBlendWeight，哪个是界面上显示的那个4pod的值？

我把它简化成一个LoadAmount值。在所有涉及LoadAmount的地方，它对应ProductHaulLoad中的TotalBlendWeight。BaseBlendWeight只在Blend Request流程中，在ProductHaul的流程中不存在了。

界面里的Load Sheet Id 就是producthaulload 的ID。ProductHaulLoad是我们的实体命名，它是历史原因造成的，它业务含义现在是BlendRequest，但由于历史原因，它也被称为Load Sheet，Blend Breakdown Sheet，这两个是打印出来的报表的名字。

JULY 25

Question

装车的4个POD，如果一次没有装满，再次Haul Blend的话，这4个POD怎么显示

Answers

如果一次haul没有运输完，就需要第二次运输，第二次haul blend时，这个已经填入的pod就不能修改了，只改另外的值。不过reschedule的时候，就可以改里面的值了。

JULY28

Question

关于haul blend 流程及存储的处理细节

Answers

Schedule Blend创建一个ProductHaulLoad (Blend Request), 状态是Scheduled, 它会流转到BPAVS中进行搅拌，最终达到Store/Ready状态, 这个时候Haul Blend菜单下会显示了出来。

当Haul Blend进行了保存，它根据输入的信息，创建ProductHaul，并根据ProductHaulLoad创建ShippingLoadSheet。如果ProductHaulLoad中的数量一次或多次被 Haul完了，它的状态会变成HaulScheduled，如果只是Haul了部分，它的状态会变成PartialHaulScheduled.

如果是PartialHaulScheduled，这个ProductHaulLoad还会出现在Haul Blend菜单下。

ProductHaulLoad的概念上的真实含义现在是Blend Request，它用来追踪一批水泥的的生命周期。就是我们说的物料单。

水泥的运输是新建的实体ShippingLoadSheet, 它指向ProductHaulLoad，从而获得是什么水泥，它的服务目的信息，目的地。就是我们说的出货单。

ProductHaul的作用是出车单和装车单，它包含司机，车辆的调度信息，及货物具体装在什么地方。

所有记录只有状态改变，没有删除。创建新的与已有的数据操作没有关系。

所有这些关系和逻辑，都在DomainModel文档中的图中，如果图描述的不对，或是不清楚，及时和我沟通，我们把它进行完善。

July 29

Question

下拉框的数据如何处理

Answers

如果出现在下拉框中的数据，首先要确认是否是主数据。如果是的话，应该加入到 EServiceReferenceData的数据集中进行缓存

July 30

Question

重构的正确做法

Answers

还是之前说的问题，你不能把原来的类似的实现拷贝过来再改，这会导致你建立不了一个新的概念，因为当前改动涉及到ProductHaul和ProductHaulLoad之间的关系的重大调整，以这种打补丁的做法，代码会让人迷惑。

你可以借鉴参考原来的实现，把可以重用的逻辑加进来，重写新的逻辑。保持自己思维的一个流畅性。

比如：_RescheduleBlendFromRigJobBlend.cshtml 中，构造函数中blendTest的逻辑在新的用例中已经不成立了，可是代码却仍然保留着，当你尝试着把界面行为修改正确，它们不会被调用。你也不敢把它删除。即使你要删除它，你需要小心地一边测试一边删，反到浪费时间。如果你再试图改它，让它有了一点功用，那么情况会变得更糟糕。这种情况对以后的程序员来维护来说就是灾难。

August 1

question

我们用shippingloadsheet关联producthaul和producthaulload的关系后，菜单部分应该就不对了，应该用新关系取得他们的联系，原来的联系是producthaul 的对象 producthaulloads，后面应该用 producthaul的ShippingLoadSheet 做关联吧。

answer

这里在ProductHaul和ProductHaulLoad之间加入了ShippingLoadSheet。如果是从ScheduleProductHaulFromRigJobBlend开始的，它自动是一次性全部拉走，它的HaulAmount是不允许更改为部分的。历史数据中是没有ShippingLoadSheet的数据，需要做一个转换脚本出来，这样你才可以在重构Re-schedule Product Haul From RigJob Blend有数据用来调试第一步。

question

另外ProductHaulLoadStatus后面应该和弹出菜单紧密相连，这块的值不少，这块怎么做详细界定呢，后面haul blend等blend部分的菜单和reschedule product haul 的菜单界定就要靠ProductHaulLoadStatus了。现在blend test也只是一个标记了，那是不是标记为这个的load 不能haul了呢。

answer

reschedule product haul分为两级菜单，你说的是第二级，它还是针对ProductHaulLoad的。只不过我们现在需要从ShipppingLoadSheet中去获得ProductHaulLoadSheet。如果这个ProductHaul是从Haul Blend 调度的，那么ProductHaulLoad的状态就是HaulScheduled，或是PartialHaulScheduled。它只是显示出来而不允许修改。ProductHaulLoadStatus和弹出菜单的基本逻辑不变，只是对新的状态进行一下判定。具体依据看文档中的状态机。BlendTest中变成只是个标志，这部分状态机没有摘出来，需要更新一下文档。但是你只要记住它只是个状态了，不影响你继续开发。想像一下，Stored和Ready状态就重合了，Ready状态就不用了，可以把它去掉。

把各种情况都列一下，什么时候可以第二级是可以修改的，它和以前修改界面都一样，但是保存时要更新shippingLoadSheet.

question

我看schedule product haul的新界面怎么没有load to bin 了呢，那这个load to bin 没有了，那 schedule blend为什么有呢。

answer

schedule product haul是直接运走，它不保存在Bulk Plant Bin中，所以没有Load To Bin，但是它有Unload Bins的部分。

schedule product haul 也得重新建立producthaulmodel的v2版吧，还是在现在的producthaulmodel实体上改，这个和HaulBlendModel 共用子实体。

重新建新的Model V2。这是我们这次重构发现的ProductHaulModel被不同用例反复重用，导致它内部结构混乱，如果改动它可能会使得其它功能直接被破坏，但又发现不了。以后每个用例需要建自已的Model，其中可以包含用到的已经有的子model。

August 3

Question

haul blend 什么时候会存在某些pod是有值的？

Answers

如果我们选择了existing haul，这个haul 已经是存在，也存在某些pod的值，所以在切换existring haul的值的时候，我们要向服务器取回已经设置的值，并且在pod里面填入，并对有值的设置为disabled。验证pod里的值是否和运走的数值相等的时候，只要考虑当前刚填的值。

August 5

question

ProductHaulLoadStatus 状态的理解

Answers

如果你看状态机的图，这些状态的含义都应该是比较好理解的，而且状态的转换是有严格的顺序的，而且有动作的描述。从你的问题来看，你只是在看代码， 因为你的问题是按代码顺序提出来的。如果状态不按它的转换顺序去理解，是没有意义的。

August 6

question

[TotalBlendWeight],[BaseBlendWeight]是怎么回事

Answers

[TotalBlendWeight]总重量,[BaseBlendWeight]主料重量。在Schedule Blend的时候可以指定总重量，或是主料重量来下定单， 根据输入的一个值，可以算出另一个，所以在ProductHaulLoad中两个值都有。但是装车运的时候，只能用总重量，所以我们把属性的名字改为了LoadAmount。

August 11

Question

从Bin创建schedule blend和haul blend的注意点。

Answers

当我们从Bin上创建product blend的时候，我们还没有确定是哪个program，所以要填写program后，取得call sheet number，然后根据Call sheet number取得井，再根据井取得UnLoad的Bin,也许我们的program还没有定，可能会没有call sheet number,这时候，我们就要直接指定是哪个井，然后根据井取得UnLoad的bin。

August 15

Question

怎么通过program取得call sheet number

Answers

通过rigjob可以得到他们的关系

August 18

Question

cancel product hual应该怎么处理

Answers

把producthual 关联的 ShippingLoadSheet 查找productHualLoad列出来，并且带有checkbox选框，如果这个productHualLoad关联的ShippingLoadSheet 只有一个则可以选择，否则选框的状态为只读，当提交后选中的ShippingLoadSheet 和productHualLoad 和producthaul都删除了。

August 31

Question

关于blend和haul状态都有什么，从原来的是怎样的拆分。

Answers

ProductHaulLoad中的状态分拆，现在有 ProductHaulLoadStatus： 原有的状态，其中有一些状态在拆分后无效，以后再删除。 BlendShippingStatus：这个状态标识本批水泥的送装状态，如果标识为OnLocation了，就不再允许Haul了。 BlendTestingStatus： 这个状态标识一个ShippingLoadSheet的装运状态

它们互不干涉，由不同的功能模块独立管理。在大图中可以看出它们之间有一它的制约关系，我们目前不去管它。但是累积关系还是要处理的。即一个ProductHaulLoad对应的几个ShippingLoadSheet都OnLocation了，且全部运完了，那么ProductHaulLoad 也就OnLocation了。

OCT 1

QUESTION

新的环境部署需要哪些项目支持，其中的坑有哪些，需要什么vs工具和sql server 数据库？

Answer

源码是Git管理，所以我们要现有git账号，在vs中安装git工具插件，基本就能完成了，如果要进一步丰富git工具就再安装vs code然后再安装个git工具。

关于vs工具我感觉高版本更好，单项目中有个sanjelEservice的项目需要vs2017 还需要用管理员角色打开项目，不过我用vs2022也是可以的，只是第一次打开好像有个某些文件版本的迁移，这个是机器自动转的，基本影响不大。最好是两个版本都装最好

sql server 最好是企业版，最低版本是，用个人版限制太多。用到的库有两个 SanjelData 和 eservice6.

需要的项目：eServiceMDM(元元方)/eServiceOnline(面板项目，主项目)/SanjelCommonLibrary(基础库)/SanjelEService（eservice6部分）

其中SanjelCommonLibrary可能会编译不过去，需要缺少common.core，这个需要我们把lib/netstandard2.0下的这个文件放入 lib中。