如果说上述EBS的“表单与查询”的系统设计体现的正是“从业务到技术”，比较容易理解与掌握，那么，所谓“事务处理”则是体现系统“从技术再到业务”的一个典范，相对而言，理解起来要困难很多，原因是无法直接在手工业务模式下找到相对应的处理方式与过程。
以库房接收采购物料为例，假定公司规定必须严格按PO来接收，并且公司为了严格控制库存水平，接收必须小批量、多批次，则库房人员就可能需要针对同一个PO在短时期内开出N多张的“入库单”，工作量很大。为了减少工作量、提高效率，库房人员可能会在供应商每次送货时，仅在找出来的PO纸面单据上只简单地做一个数量标识，最后累积起来汇总开一张“入库单”。但这种“图省事”的做法显然是一种“很不规范”的处理方式，虽可以提高工作效率，却会因为容易带来很多其它管理问题而在实际工作中不被允许。
ORACLE 系统通过提供一个“事务处理”工作界面则很简单地解决了上述难题。如下图9所示采购接收的事务处理工作界面：
类似于“收货时直接在PO纸面单据上简单地做数量标识”，每次供应商送货来时，库存人员只需在系统中查找出对应的PO，简单地输入送货数量并保存，则系统会在后台自动生成“事务处理记录”(等同于是“入库单”)。对于系统来说，这种处理方式技术上实现非常容易，但却大大减少了操作人员的工作量，有效地解决了由于小批量、多批次所带来的效率问题。
ORACLE的各业务模块，大量地采用了上述类似的“事务处理”系统工作方式，不仅保证了系统高度的数据集成性，而且对于系统各业务环节的流程处理也保证了高度的连贯性与集成性。例如OM系统的发货处理、WIP系统的领料与入库处理等等。系统中所提供的事务处理工作界面，有些可能会以“××工作台”（Workbench）来命名之（这取决于不同模块系统设计人员的个人偏好）。
更进一步，系统对于某些“业务流程”类表单，例如“销售订单、发票”等，还在表单界面直接提供一个名曰“活动”（Action）的按钮（Button），该按钮包含丰富的业务处理功能（不仅仅是输入数据），以便用户（User）对表单内容作各种操作处理或获取相关信息。如下图10所示，销售订单界面的“活动”按钮：
此外，ORACLE EBS在某些业务流程单据之间，也提供了类似的事务处理工作界面，以帮助用户方便地实现业务单据的转换和业务流程的衔接。如下图11所示的采购申请PR到采购订单PO的所谓“自动创建”（Autocreate）功能。
对于企业的一个系统用户User（事务处理型用户）来说，掌握了与自己工作相关的表单、表单查询、事务处理，就基本上掌握了EBS的系统使用，系统就不再难懂难用。EBS中的“事务处理”在业务流程表单内部解决了“人与系统”的统一问题，在业务流程表单之间解决了“业务与业务、业务与系统”的统一问题。从“纯技术”的系统实现角度来看，它也没有什么高深莫测的地方。
很奇怪也很遗憾的是，迄今国内主流ERP产品的系统中，还很少看到这种系统实现方式。曾有一网友通过MSN向笔者发问：“EBS的WIP 事务处理界面是否要手工输入item？”看起来这个问题似乎很“幼稚”，但对于很多刚开始接触EBS或过去用惯国内产品的人来说，由于不了解或不习惯EBS的“事务处理”系统实现方式，会不自觉、想当然地将所有EBS的FORM界面都当成具有“实体”作用、通常可以对应纸面单据的“业务表单”来看待，才会发出这样的疑问。