3.6 批量维护来源准则/查看来源准则

3.6.1   业务方案描述

  1. 可以通过一个集成的界面,随时更新、查询各供应商的当月基准比例、当月累计下单比例、当月实际执行比例。

  2. 具有按照主管、采购员、采购分类等多种纬度供货比例批量下载功能,直接导出至EXECL,以方便下月来源准则的制定。

  3. 维护来源准则界面:新增表单,是一个可以修改比例的界面,也可以批量下载查询结果。仅能够修改当月来源准则比例,不允许修改过期月份的来源准则。

  4. 查询来源准则界面:是”维护来源准则”界面的一个辅助功能,仅用于查询来源准则,不能够修改,可以批量下载查询结果。

  5. 导出来源准则程序:当用户在” 维护来源准则界面”或”
    查询来源准则界面”界面上的”导出至Excel”键后,自动执行该程序,程序的输出结果是界面上显示的结果。

3.6.2   业务方案逻辑控制


1.
支持:批量下载来源准则、临时修改来源准则。仅能够修改当月来源准则比例,不允许修改过期月份的来源准则。

2.
支持多组织:这里的多组织一方面要考虑业务单元,也要考虑库存组织。业务单元org_id取自本职责的profile选项,库存组织orgniazation_id取自当前的mfg_organization_id,进入本表单前一定调用组织选择form选择该OU下的库存组织。

3.
来源准则是库存组织层面的数据,不同的库存组织有不同的来源准则,导入操作要遵从库存组织安全性控制要求。

4.
操作安全规则:按照库存组织、创建人进行安全性控制,不管是前台结果显示,还是后台操作(提交、删除等),都要符合这个安全性控制规则。

5. 需要显示上月比例、当月比例、当月实际下单比例、当月实际执行比例:

1)当月比例%:是指按照查询条件中的”比例月份”为依据,查询出来源准则中与比例月份匹配的记录,比例月份既指本月月份月份,也可以指过期或未来的比例。比例月份记录在来源准则弹性域attrubute1上。

2)当月实际下单比例%:按照查询条件中的”比例月份”为主要统计条件,计算出”比例月份”所在月度各供应商的实际分配比例,计算公式如下:

A- 某供应商的实际下单比例% = (SUM(某供应商当月创建的有效采购订单数量) /  SUM(全部供应商的有效的采购订单数量)) *
100

B- 有效的采购订单数量 = 订单数量 – 订单取消数量

C- 注意计量单位的转换,采购订单上的计量单位可能与物料编码上的计量单位不一致,这种情况下,一定要转化为基本计量单位。

3) 实际下单比例按照%格式显示,四舍五入后保留小数点后2位。

A-  当月实际执行比例%:当月实际交货比例,计算公式如下:

B- 某供应商实际执行比例% = ( SUM(某供应商当月实际交货量) / SUM(所有供应商当月实际交货量)) * 100

a-  当月实际交货量 = SUM(所有接收量) – SUM (所有退货量)

b- 注意计量单位的转换,接收(包括退货)事务处理的计量单位可能与物料编码上的计量单位不一致,这种情况下,一定要转化为基本计量单位。

c- 实际下单比例按照%格式显示,四舍五入后保留小数点后2位。

4)
本月累计下单量:按照查询条件中的”比例月份”为主要统计条件,计算出”比例月份”所在月度供应商的某一物料的累计下单量。

5)
本月累计接收量:是指查询条件中输入的比例月份的该供应商某一物料累计有效接收量,扣除当月累计退货量。

6. 来源准则编码等同于物料编码,来源准则描述同物料描述。

7. 来源准则主窗口:

1)
初始数据排序按照以下规则排序:组织,物料,供货比例(降序排列)。

2)
其后用户可以按照数据表格上所有字段排序。

3)
按照同一个物料、同一个比例月份进行分组,并以不同颜色显示。

8. 更改历史窗口:按照更改历史降序显示。

9. 清楚显示当前行:当光标移到当前行时,当前行颜色突出显示。

3.6.3   业务方案执行控制

  1. 并发程序名称:来源准则导出;

  2. 处理逻辑:当在导入Web界面上按下”执行导入”按钮后,系统会自动调用该并发程序,该程序使用API自动处理来源准则。维护人员可以将本月比例下载为EXCEL格式的文件,修改比例后以此为模板通过另外一个开发”批量导入来源准”WebADI程序生成下月来源准则。

  3. 程序参数:自动从查询条件中获得查询条件。

  4. 运行时点:随时提交。

  5. 导出格式:用HTML格式输出。

3.6 批量维护来源准则/查看来源准则,布布扣,bubuko.com

时间: 2024-10-13 03:10:37

3.6 批量维护来源准则/查看来源准则的相关文章

Linux服务器维护统计连接数查看外部IP

服务器上的一些统计数据: 1)统计80端口连接数 netstat -nat|grep -i "80"|wc -l 1 2)统计httpd协议连接数 ps -ef|grep httpd|wc -l 1 3).统计已连接上的,状态为“established' netstat -na|grep ESTABLISHED|wc -l 2 4).查出哪个IP地址连接最多,将其封了. netstat -na|grep ESTABLISHED|awk '{print $5}'|awk -F: '{pr

[原创]用“人话”解释不精确线搜索中的Armijo-Goldstein准则及Wolfe-Powell准则

[原创]用“人话”解释不精确线搜索中的Armijo-Goldstein准则及Wolfe-Powell准则 转载请注明出处:http://www.codelast.com/ line search(一维搜索,或线搜索)是最优化(Optimization)算法中的一个基础步骤/算法.它可以分为精确的一维搜索以及不精确的一维搜索两大类.在本文中,我想用“人话”解释一下不精确的一维搜索的两大准则:Armijo-Goldstein准则 & Wolfe-Powell准则.之所以这样说,是因为我读到的所有最优

最大最小准则(悲观准则)

所谓决策,简单地说就是做决定的意思,详细地说,就是为确定未来某个行动的目标,根据自己的经验,在占有一定信息的基础上,借助于科学的方法和工具,对需要决定的问题的诸因素进行分析.计算和评价,并从两个以上的可行方案中,选择一个最优方案的分析判断过程. 根据决策结局的多少,可以将决策分为确定型决策(每个方案只有一个结局)和不确定型决策(每个方案有多个结局). 由于不确定型决策问题所面临的几个自然状态是不确定,是完全随机的,使不确定型决策始终伴随着一定的盲目性.决策者的经验和性格常常在决策中起主导作用.决

Armijo-Goldstein准则与Wolfe-Powell准则

Armijo-Goldstein准则与Wolfe-Powell准则是不精确的一维搜索的两大准则. 之所以要遵循这些准则是为了能使算法收敛(求最优解).即要使我们的不精确的一维搜索的步长满足一定的规则,使之后的求最优解的过程不至于因为步长过大或者过小而不收敛. Armijo-Goldstein准则 Armijo-Goldstein准则的核心思想有两个:①目标函数值应该有足够的下降:②一维搜索的步长α不应该太小. 我们来看看Armijo-Goldstein准则的数学表达式: 其中, 0<ρ<12

Oracle以及SDE维护常用命令-查看表空间等

之前现场反馈一个数据更新的问题,查看感觉是因为表空间满了导致的(错误在之前的博客随笔中写过),因此远程对服务器进行查看.个人平常都是通过Oracle客户端的Entreprise Manager Console进行查看的,但是发现服务器上只安装了Oracle服务端并且不能正常进行网页登录查看. 因此到网上查了一下查看Oracle表空间使用情况的查询语句,通过PLSQL进行查询查看,在这里记录一下,另外附几个常用的Oracle以及SDE命令. 查看表空间的使用情况(解决此次问题使用) select

3.5 供货比例(来源准则)控制

3.5.1   供货比例 可以通过ERP系统启用<供货比例(来源补充)规则>自动进行物料采购订单的供应商分配. 1)    在运行<MRP物料需求计划>之后,物料的独立需求计划数量,会根据供货比例按照供应商进行分配. 2)    对于总需求数量较小又不是整数的情况下,考虑到供应商供货的可行性,对于采购员无法完全根据分配比例的数量下达订单给供应商的,可以通过ERP系统采购订单的最小订单数量来处理. 2. 可以通过<供货比例>来保存各时期供货比例的历史,历史比例不能够修改,

IO负载高的来源定位 IO系列

http://elf8848.iteye.com/category/281637 前言: 在一般运维工作中经常会遇到这么一个场景,服务器的IO负载很高(iostat中的util),但是无法快速的定位到IO负载的来源进程和来源文件导致无法进行相应的策略来解决问题. 这个现象在MySQL上更为常见,在5.6(performance_schema提供io instrument)之前,我们通常只能猜到是MySQL导致的高IO,但是没法定位具体是哪个文件带来的负载. 例如是ibdata的刷写?还是冷门ib

IO负载高的来源定位

前言: 在一般运维工作中经常会遇到这么一个场景,服务器的IO负载很高(iostat中的util),但是无法快速的定位到IO负载的来源进程和来源文件导致无法进行相应的策略来解决问题. 这个现象在MySQL上更为常见,在5.6(performance_schema提供io instrument)之前,我们通常只能猜到是MySQL导致的高IO,但是没法定位具体是哪个文件带来的负载. 例如是ibdata的刷写?还是冷门ibd的随机读取? 本文就将介绍一个比较简单的定位IO高负载的流程. 工具准备: io

iotop,pt-ioprofile : mysql IO负载高的来源定位

http://www.cnblogs.com/cenalulu/archive/2013/04/12/3016714.html 前言: 在一般运维工作中经常会遇到这么一个场景,服务器的IO负载很高(iostat中的util),但是无法快速的定位到IO负载的来源进程和来源文件导致无法进行相应的策略来解决问题. 这个现象在MySQL上更为常见,在5.6(performance_schema提供io instrument)之前,我们通常只能猜到是MySQL导致的高IO,但是没法定位具体是哪个文件带来的