dkyo | 27 十二月, 2007 08:45
ERP应用,已从引导期的ERP概念、方法、重要性的介绍转向发展期的选型实施类介绍。但作为系统生存期内占用了很大时间、费用及工作量的系统维护工作,却介绍得很少,这对于全面了解ERP应用是不够的。当ERP应用进入成熟期时,系统维护与发展将成为关注焦点。
ERP维护的具体工作内容包括例行和突发事件的处理;以管理和技术的手段,维护和发展ERP运行环境,如平衡技术先进性/实用风险、目标/成本而进行的IT基础结构(服务器、网络、PC机)的周期更替及日常维护;对应用系统已发现的错误用改正性维护解决,以适应性维护使系统经受住应用环境及流程少量改变,通过完善性维护扩大系统应用的用户与功能,提升系统总体目标;对系统用户不论岗位变换或新人/临时替代人员作定期或专门培训;控制变更,记入标准文档及培训教程;不断积累问题的现象与对策,加速问题的定位与解决;作好日常备份及系统安全;提高运行环境性能和效率等多样性工作。这儿介绍笔者维护ERP系统的几点体会。
1.相信系统 对已常用的流程偶然出错时,不要先去想系统有问题,要注意观察操作或数据有无不寻常处。如果是系统缺陷但可通过固定操作避免,要固定操作流程并注意反复培训。当总经理说“我只看系统作成的报表”,就意味着ERP系统真正被用于管理和控制企业运作,系统的投资回报才容易被认同,维护的价值也充分得到体现。
2.逆向流程 某流程由多个业务动作组成时,每步动作的异常都可能导致一个流程不完整。本次业务要怎样向前推进完成或者向后倒回重来,要形成对策,做到有备无患。
3.勤于积累 不论是主动发现或被动遇上问题,事后都要记录解决过程、方法,以便经验共享并延续。注意及时更新有关文档,我们不仅要记录业务要求的操作过程,也要记录绕过一些系统固有缺陷的途经。执行层用户应当像法规条例那样去执行,不论理解与否都不可简化或异化,即“死步骤,莫发挥”。
4.测试与比较 新出现的异常要判别其复现性(必然性)。可考虑构造测试环境,在正常机器上完全仿照原操作,并将异常与正常的数据作比较,寻找维护操作的方向,并找出用来验证修改正确性的方法。
5.可逆修改 即使找到维护操作的方向,也不可贸然修改,搞不好出现连带负作用,使问题性质变复杂或由局部向更大范围扩散。判断问题涉及的数据及影响范围,以及理解全部流程,都非常重要,否则会引起系统数据混乱和不一致而无法复原。修改数据要留好余地,如最好能有可逆性的修改,改不好也能退回,不会添乱。
6.绕过 这是紧急情况或一时找不出解决头绪时常常采用的方法。如从一个模块向另一模块传数据,有原因不明的丢失,虽是偶发但难以查明原因并解决。这就要有一个检查机制发现这类异常,然后在相应后续模块上补上有关信息。这对今后发现真正的原因并彻底解决问题有帮助。
7.例行检查与操作 这是减少问题紧急程度的有效方法。利用标准功能和一些自开发的实用小程序,主动去应用系统数据中检查。把正常情况下要到今后某一时刻(如月末)才反映出问题的数据(如成本更新、接口异常)提前找出来处理掉。这种不断检查、测试、发现和解决问题的纯洁化过程,是系统更稳定和完善的基石。原则是莫因“善小而不为”,必须及时维护。
8.杂项影响 有时问题异常,百思莫解,结果可能是空间不够、索引要整理、设置不妥或错误改动、某个临时文件已被误删,甚至原样重输入一遍等看似不直接相关的原因。所以多渠道检查有时也有效。
9.预防 要让用户养成有问题立刻报告的习惯,不可随意处理而丢失现场,事后因忘记当时情况而更难查。对于多步骤形成的结果,如有异常,要争取利用平衡关系式,在最后一道采用守球门的方法再计算并检验数据,预防有误差或错误传播。如发票额可由订单经提货发货逐步算出,也可直接算出答案与逐步算出所得结果比较。
10.不能草率承诺 判断客户需求的重要性和紧急程度很重要。客户有时在不经意时可能会指出系统的一个需大力改进的地方,也可能会在正式场合提出一个类似于“我要一敲键就出工资”的无理要求。维护人员不能因声音大小决定取舍,要仔细听,但不能草率承诺。尤其业务未变但流程却因换人随之而变换,这种事常发生,但其结果往往是疲于奔命。对此,要先考虑合理性,再考虑可能性。
转载http://space.itpub.net/94135/viewspace-1030
dkyo | 26 十二月, 2007 10:52
在ERP系统中,自制又采购的物料比较麻烦。
由于我们系统中作业的供应子库是随着计划组进行改变的,另这个更改逻辑分为三个部分,一个是推式采购件,直接取车间供应关系,一个是拉式物料,则取部门设置的弹性域。对于推式制造件,则需取车间关系表,根据物料上的供应子库判断取车间关系表的哪几条对应关系,若有多个情况,则再取总装同部装关系关系表里有记录的,若里面还存在多条,则再取跟单标识打上的。
而自制又采购的物料则比较麻烦,如果自制又采购物料偏采购的,则制造或采购的属性设置为采购,此时对应物料的供应子库需设置为物资仓,该部分物料走推式采购件的变更逻辑,
若自制又采购物料偏制造的,则该物料的供应子库需设置成为车间仓,且该物料的美的制冷计划分类集若设置为采购一般物料的属性,由于该些物料是走制造件的更改逻辑,因此供应子库无法无法准确取得。
dkyo | 29 十一月, 2007 10:16
直接在API导入界面直接导入,下为查询的脚本,只需把该数据粘贴在导入界面:
select vendor_code,
'******库存组织',
SUBINVENTORY_CODE,
decode(sign(transaction_quantity),-1,'k.外租仓入库',1,'k.外租仓出库'),
segment1,
primary_uom_code,
ABS(transaction_quantity),
sysdate
from
(
select substr(clt.segment1,4,12) vendor_code,
'****库存组织',
cio.SUBINVENTORY_CODE,
cit.segment1,
cit.primary_uom_code,
sum(cio.transaction_quantity) transaction_quantity,
sysdate
from apps.mtl_onhand_quantities cio,
apps.mtl_system_items cit,
apps.mtl_item_locations clt
where cit.inventory_item_id = cio.inventory_item_id
and cit.organization_id = cio.organization_id
and cio.locator_id = clt.inventory_location_id(+)
and cio.organization_id = clt.organization_id(+)
and cio.subinventory_code = clt.subinventory_code(+)
and cio.ORGANIZATION_ID=***
and cio.SUBINVENTORY_CODE in('W111物待','W112物租')
group by substr(clt.segment1,4,12),
'****库存组织',
cio.SUBINVENTORY_CODE,
cit.segment1,
cit.primary_uom_code,
sysdate
having sum(cio.transaction_quantity) <>0
)
dkyo | 27 十一月, 2007 14:31
ERP中使用一揽子采购协议,对于手工建立一揽子采购协议是没有什么检查控制,但如果通过API进行批量导入,则对应于一个供应商存在多个地点的情况下,系统会查询该供应商是否已存在一揽子协议,存在的话则提示错误(该查询是不分供应商地点的,系统中包为CUX_PO_AGREEMENT_TEMP_UTL)
SELECT COUNT(*) INTO l_count
FROM po_headers_all
WHERE type_lookup_code = 'BLANKET'
AND closed_code = 'OPEN'
AND approved_flag = 'Y'
AND org_id = p_header_rec.org_id
AND vendor_id = p_header_rec.vendor_id
对于此类问题,只能手工先在系统中为对应的供应商地点新建一个协议,然后再对对应的协议进行导入。
dkyo | 16 十一月, 2007 16:41
步骤:
1:首先将所要修改的物料编码导入临时表内
2:将信息导入工序接口表中(BOM_OP_ROUTINGS_INTERFACE)脚本如下:
insert into BOM_OP_ROUTINGS_INTERFACE
(PROCESS_FLAG
,ASSEMBLY_ITEM_ID
,ORGANIZATION_ID
,transaction_type
,completion_subinventory)
select 1 --1是待定状态
,bor.ASSEMBLY_ITEM_ID --所要更改的物料编码的item_id
,170 --组织id
,'UPDATE' --更新还是新建(CREATE)
,'D231成二' --完工子库
from apps.BOM_OPERATIONAL_ROUTINGS bor
where bor.ORGANIZATION_ID=170
and bor.ALTERNATE_ROUTING_DESIGNATOR is null
and bor.ASSEMBLY_ITEM_ID in
(select msi.INVENTORY_ITEM_ID
from apps.mtl_system_items_b msi
,imp_data.cuxk_temp ct
where msi.organization_id=170
and msi.SEGMENT1=ct.ITEM_CODE
)
dkyo | 13 十一月, 2007 17:34
dkyo | 02 十一月, 2007 09:38
dkyo | 30 十月, 2007 13:56
索引是提高数据查询的最有效方法
索引的管理成本:
1.存储索引的磁盘空间
2.执行数据修改操作(insert、update、delete)产生的索引维护
3.在数据处理时会需额外的回退空间。
建索引之后,数据修改时间会延长。
索引按存储方法分类
B*树索引
B*树索引是最常用的索引,其存储结构类似书的索引结构,有分支和叶两种类型的存储数据块,分支相当于书的大目录,叶块相当于索引到的具体的书页。一般索引及唯一约束索引都使用B*树索引。
位图索引
位图索引储存主要用来节省空间,减少oracle对数据块的访问,它采用位图偏移方式来与表的行ID号对应,采用位图索引一般是重复值太多的表字段。位图索引在实际密集型OLTP(数据事务处理)中用得比较少,因为OLTP会对表进行大量的删除、修改、新建操作,oracle每次进行操作都回对要操作的数据块加锁,所以多人操作容易产生数据块锁等待甚至死锁现象。在OLAP(数据分析处理)中应用位图有优势,因为OLAP中大部分是对数据库德查询操作,而且一般采用数据仓库技术,所以大量数据采用位图索引节省空间比较明显。
索引按功能分类
唯一索引
唯一索引有两个作用,一个是数据约束,一个是数据索引,其中数据约束主要用来保证数据的完整性,唯一索引产生的索引记录中每一条记录都对应一个唯一的rowid
主关键字索引
主关键字索引产生的索引同唯一索引,只不过它是在数据库建立主关键字时系统自动建立的
一般索引
一般索引不产生数据约束作用,其功能主要是对字段建立索引表,
以提高数据查询速度。
索引按索引对象分类
单列索引(表的单个字段的索引)
多列索引(表多个字段的索引)
函数索引(对字段进行函数运算的索引)
建立函数索引的方法:
create index test on table_name(trunc(表列))
应用索引的扫描分类:
INDEX UNIQUE SCAN(按索引的唯一值扫描)
INDEX RANGE SCAN(按索引值范围扫描)
INDEX FAST FULL SCAN(按索引值快速全部扫描)
什么情况下应该建立索引
表的主关键字
自动建立唯一索引
表的字段唯一约束
oracle利用索引来保证数据的完整性
直接条件查询的字段
在sql中用于条件约束的字段
查询中与其它表关联的字段
字段常常建立了外键关系
查询中排序的字段
排序的字段如果通过索引去访问那将大大提高排序速度
查询中统计或分组统计的字段
什么情况下应不建或少建索引
表记录太少
如果一个表记录太少,采用索引去访问记录的话,那首先需访问索引表,再通过索引表访问数据表,一般索引表与数据表不在同一个数据块,这种情况下oracle至少要往返读取数据块两次。而不用索引的情况下
oracle会将所有的数据一次读出,处理速度显然会比用索引快。
经常插入、删除、修改的表
对一些经常处理的业务表应在查询允许的情况下尽量减少索引。
数据重复且分布平均的表字段
加入一个表有10万行记录,有一个字段A只有T和F两种值,且每个值的分布概率大约为50%,那么对这种表A字段建索引一般不会提高数据库的查询速度。
经常和主字段一块查询但主字段索引值比较多的表字段
如果一个表的记录达到100万以上的话,要对其中一个字段建索引可能要花很长的时间,甚至导致服务器数据库死机,因为在建索引的时候oracle要将索引字段所有的内容取出并进行全面排序,数据量大的话可能导致服务器排序内存不足而引用磁盘交换空间进行,这将严重影响服务器数据库德工作。
dkyo | 29 十月, 2007 09:57
公司通过改善它们的生产和物料处理过程大幅提高劳动生产率。
多数提高生产率的努力集中在一个假设之上,即:“在每一个可能的方面消除浪费”。例如,正在等待消耗的物料被视作一种浪费,结果,就产生了“即时生产”(JUST-IN-TIME JIT)。
较之从整体上优化企业的业务流程而言,通过单个公司或营业地点优化企业资源不大可能带来业务流程改善上的突破。人们的思想必须从传统的公司观点转向更高层次的企业观点。
1.需求发现和创建
当一个公司开发一种产品和形成一种产品的概念时,它总是希望建立该产品的客户基础。在一个较高的层次上,这涉及到生产高质量的先头产品并将这些产品转到市场上销售。从公司的运营层次来看,这种信息流还包括广告、促销活动、市场调研以及竞争情报收集等等。
2.传达设计要求
在产品开发过程中,客户将他们的需求和产品需求规范传达给生产商。同时与一些经过选择的供应商共享这些需求信息,以便建立该产品的强大的供应链。设计好产品之后,在发布到制造的过程之前,需要对产品进行广泛的测试。在产品生命周期的早期阶段,发现潜在问题非常重要。
3.传达需求
客户以订单或预测的形式传达他们的需求。这种信息用于计划物料和资源需求以满足需求,同时与合适的供应商共享该信息,以便他们能够计划自己的物料和资源需求。计划过程从父装配件中衍生出组件需求。
4.物料和服务
为了满足客户需要,需要从各种各样的供应商那里采购物料和服务,并经过相应的增值过程之后,将产品交付给客户。同时,还存在少量的反向物料活动,典型的情况如下:
由客户提供原材料
有缺陷的产品必须重新加工
但是在多数情况下,物料是从供应商流向客户。
5.资金
在接收产品和服务之后,客户就开始按固定周期支付产品的费用。因此,资金是从最终产品的客户反向流动,直到到达为产品提供原材料的供应商。为此要建立一套业务流程来管理一个企业中的资金流动,同时满足所有各方的需求。
dkyo | 09 十月, 2007 17:36
先查询出实际的完工数量
select sum(mmt.TRANSACTION_QUANTITY)
from apps.mtl_material_transactions mmt
where mmt.ORGANIZATION_ID=***
and mmt.TRANSACTION_SOURCE_ID=wip_entity_id and mmt.TRANSACTION_TYPE_ID in(17,44) --wip装配件完成及装配件退回
and mmt.SUBINVENTORY_CODE='***'
同时查看mtl_transaction_accounts 表中的财务信息是否正确
select *
from apps.mtl_transaction_accounts mta
where mta.TRANSACTION_ID in
(
select mmt.TRANSACTION_ID
from apps.mtl_material_transactions mmt
where mmt.ORGANIZATION_ID=***
and mmt.TRANSACTION_SOURCE_ID=***--作业id
and mmt.TRANSACTION_TYPE_ID in(17,44)
)
最后更新:
update wip_discrete_jobs
set quantity_completed = 实际完成数量
status_type = 4,
date_completed = sysdate
where wip_entity_id = ***
| « | 五月 2012 | » | ||||
|---|---|---|---|---|---|---|
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||