mrp1
2018-07-07 10:54:06 0 举报AI智能生成
逻辑梳理
作者其他创作
大纲/内容
目的
控制odm oem分配情况
过度期间将要使用odm定额的情况，未来肯定都是odm/oem比例控制
做法
人工维护的策略表
难点
因为输入是设备 国家 日期（年月日），但是策略是年月，这里需要在策略处记录一个累加的逻辑
策略改成start_date 开始生效日期和end_date 结束生效日期
修改这两个字段，会导致的程序的修改量并不大
对mysql时间的处理和时间字符串的处理
使用字符串的方式来处理
太low
而且字符串不包含格式验证，可能数据有异常也发现不了的
假设
每次都会计算完整的某个月的
存在重复计算月份的时候，上次计算的已用量清0
每周做一次计算
策略表包含的字段有设备，国家，年月，odm份额、oem份额，以及odm数量，基本方针：
优先使用odm数量
如果当月的odm数量为0了，再按照份额分配
侧露表的字段有设备、国家、开始生效日期，结束生效日期，odm份额，oem份额以及odm数量
优先使用odm数量
如果这个区间的odm数量为0了，再按照份额分配
怎么使用策略
计算的时候，会按照天来输入设备、国家、数量信息
需要将已经使用的odm数量和oem数量存在一个字段中
假设在这张策略表里面添加odm_used_num和oem_used_num两个字段
表示该月累计要下发的odm数量和oem数量
表示该段时间内要下发的odm数量和oem数量
如果有那个月已经下发的，默认由资源经理来维护新的odm份额数量。程序不管这一块逻辑
那么每次计算的时候，如果
假设x表示这次分配给odm的数量，y表示这次分配给oem的数量,则需要满足:
(> (- odm_num odm_used_num) 0)
先扣减数量
数量足够扣减
x=num,y=0
odm_used_num+=x
数量还不足够扣减
先扣所能扣的odm
x0=(- odm_num odm_used_num)
剩下的按照份额来分配
根据下面的逻辑求的x1和y
那么x=x0+x1
(<= (- odm_num odm_used_num) 0)
直接按照份额来分配
x+y=num
(x+odm_used_num-odm_num)/(y+oem_used_num)=odm_share/oem_share
x四舍5入取整
y=num-x
odm_used_num+=x
oem_used_num+=y
也就是计算每一天的x,y，最终得到很多的x y值。
在跑完一次mrp之后将odm_used_num和oem_used_num清0
有没有什么需要持久化记录的呢，相当于记录log
x和y值可以记录log
便于后续查找
mrp1
计算逻辑
时间
需求预测给出的是mysql的时间格式，转为"yyyy-MM-dd"
时间区间
每一个策略都有一个时间区间
区域
字段要保证统一，否则容易出错
设备类型
名字
epo策略数据
bom数据
mrp1的具体逻辑
从预测数据开始，【循环】对于每一个设备和区域
预测数据是存db的，这需要mrp1去查
查出具体日期和数量
然后，【循环】对于每一个日期和数量
查db得到设备版本
结束循环：将这所有的数据放到一个list中
提前计算: 可以查出设备，区域、时间区间对应的分配策略
【循环】对于同一个设备、区域、版本和时间区间 分配策略
根据之前循环里面计算得到的odm/oem份额（目前已经省略）
下一步
根据分配策略计算出分配给各个供应商的数量
【循环】对于每一个整机供应商信息查bom表
查到有多种部件
【循环】计算每种部件的分配情况
查出要计算的部件的抽象类型，和单个机型需要的部件数量
查不到要异常处理
根据抽象类型和部件又查出一条部件策略
审计
比如查不到策略
按照部件策略分配
审计
比如部件的供应商和bom的对应不上
数据存储
细到部件级别的平铺数据展示
设备
区域
日期
版本
数量
odm数量
整机厂商列表信息
整机厂商
整机份额
整机固资id
整机数量
部件名称
一个整机需要这个部件的数量
部件厂商列表信息
部件厂商
部件购买数量
部件str Goods id
整机固资id
数据审计
预测数据
作为数据源
area信息要是标准的
odm/oem份额策略
不要有重复的时间区间
也就是对时间的审计
其他的是否审计要不确定
设备版本信息
不要有重复的时间区间
对时间的审计
其他审计，比如各个字段名需要正确
区域要对
epo整机策略和部件策略
不要有重复的时间区间
信息要完善
各个字段格式要满足要求
国家
部件类型
比如说没有硬盘的时候要怎么处理
bom数据
server表
bom 关系表
部件表
需要存的字段
设备
假设都ok
日期
假设都ok
区域
需要提前手动检测需求预测的数据是否准确
待办
版本
如果查不到就说版本不存在
或者有多个这样的
计算odm数量的过程
是按照份额策略来计算的
份额策略这个按了比例，就暂时不审计数据了
策略不存在就报错
查找整机列表策略的过程
审计比例和要是1
这个在同步的时候虽然做了审计，但是这里也还可以继续审计
子主题
找不到报错
找到的条数》1 报错
根据odm厂商+前面的信息查找bom的server表的过程
找不到报错
不会找到多条，因为有联合索引？
整机固资id不存在，报错
整机数量计算要整数化
查找bom表的部件的过程
内存、cpu、L6和硬盘都要存在，任何一个没找到，都报错
查到vendor-list,里面的PartPurchaseid必须是数字
必须要能在part表里面查到抽象类型，抽象类型查不到报错
根据部件和抽象类型，在部件策略表里面能找到一条唯一的策略，否则报错
处理单个部件的过程
部件数量是正整数
查到vendor-list,里面的PartPurchaseid必须是数字
根据部件和抽象类型，在部件策略表里面能找到一条唯一的策略，否则报错
必须要能在part表里面查到抽象类型，抽象类型查不到报错
部件厂商和整机厂商数据一样
处理部件厂商的过程
在bom server表和bom_关系表联合去找这个数据，找不到报错
EPOGoodsId
补充计算epo份额
小于50，就只分配给一个供应商
小于5，就只分配一个部件供应商
做成接口
输入
输出
如果有错误，就返回审计数据
如果没有错误，就返回mrp1的计算数据
最后一个逻辑的确定
shame
居然多写了一层循环，导致了重复计算的问题
改变
以前面BOM的vendor为准
现在是找到了另外一个字段strBarndVendor
这个才是和epo策略表中某个字段对应的那个字段
然后根据抽象类型在策略表去找对应的策略，发现了一个分配列表
要审计这个列表是否和外层的一摸一样
不一样则给出审计数据
一样就过滤出对应的厂商，算下份额看对不对
子主题
按理说这几个应该都会找到同一个抽象类型，因为他们必须用同一条策略。
这确实是一样的，如果不一样，那就需要审计出来
如果是这样，那是否一个循环都不需要了？这个数据的分配，反正我是循环计算了
其实只计算一次就够了
为什么循环计算了，数据也还是对的呢？
mrp2
匹配输入
一次一条数据
设备类型
国家
版本
预计到货时间
已经经过特殊的处理
数量
从匹配输入开始
查对应的epo整机份额策略
查到对应的odm供应商，开始建模
先对数量不做限制
查出serverid和对应的部件，以及部件信息，包括部件goodsid
比如L6,部件的物料id是356119
在这里去查库存
查出每一个供应商的库存
这个只有部件
数据已经基本上可用了
看一下每一个供应商大概能达到一个什么水准？
model
分配给厂商的数量>0 <匹配数量
是否考虑小于50就分配给一个厂商的条件
每一个必须满足浮动比例
最大化齐套量
产能约束
？
0 条评论
下一页
