Order Management Object-centric Event Log in OCEL 2.0 Standard

General Description This process describes the management of customer orders within a company, comprising both the registration and payment of incoming orders, as well as the process of packing and shipping these orders. For these tasks, our company deploys staff in their sales, warehousing, and shipment departments. This is an artificial event log according to the OCEL 2.0 Standard simulated using CPN-Tools. Both the CPN and the SQLite can be downloaded. The simulation is an extension of the order management log in the former OCEL standard. Process Overview At our company, customers place orders (place order) for different products in varying amounts. Each product type has a price and a weight. In the current market situation, there is an inflation that irregularly leads to an increase of prices. These price rises have a negative impact on customers’ purchasing power, i.e., on order volumes. When a customer places an order, this order is assigned to an employee of our company’s sales department. To foster customer satisfaction, our company has a single-face-to-customer policy. This means that per customer there is one primary sales representative who ought to render all services related to that customer. If that first representative is unavailable, a second sales representative should take care of the order. Should this employee be also unavailable, the order has to be managed by another employee. The tasks of sales employees comprise the registration (confirm order) as well as payment processing (payment reminder, pay order). In parallel to this, the shipment of goods is prepared. For this, the stock of our company is checked by an employee of the warehousing department for the availability of the ordered items. If necessary, the warehouser reorders the item (item out of stock, reorder item). Items ready for shipment are collected (pick item) for the placement into packages that are addressed to single customers. Here, it may happen that a package content relates to multiple orders, and order volumes are distributed over multiple packages. After all items allocated to a package have been picked, the package is compiled by a warehousing employee (create package). Later on, this package is picked up by a shipment employee for transport (send package). According to another policy, a warehousing employee should provide assistance to the shipment employee in loading the package. However, oftentimes shippers act contrary to that policy and load packages alone or together with a second shipment employee. Finally, the package is shipped. Deliveries may fail repeatedly (failed delivery) until successful delivery (package delivered). The figure below depicts the process in a simplified manner, using an informal process notation to describe the control-flow and the involved object types. A formal description is given along with the artifacts in the next section. Further information can be found at: https://www.ocel-standard.org/event-logs/simulations/order-management/ General Properties An overview of log properties is given below. Property Value Event Types 11 Object Types 6 Events 21008 Objects 10840 Control-Flow Behavior The behavior of the log is described by a respective object-centric Petri net. Also, individual object types exhibit behavior that can be described by simpler Petri nets. See below. orders customers items employees packages products Full object-centric Petri net Object Relationships The company pursues the "one-face-to-the-customer" policy, in which every customer has a dedicated sales representative as well as a deputy (secondary representative). These relationships are described in the log. Source Object Type Target Object Type Qualifier employees customers primarySalesRep employees customers secondarySalesRep Additionally, object-to-object relations can emerge at executions of specific activities: Activity Source Object Type Target Object Type Qualifier create package package employee packed by send package package employee forwarded by send package package employee shipped by Simulation Model The CPN used to create this event log can also be downloaded.To obtain simulated data, extract the linked ZIP file and play out the CPN therein, e.g., by using CPN Tools. The play-out produces CSV files according to the schema of OCEL2.0. The provided jupyter notebook can be used to convert these files to an SQLite dump. For a technical documentation of the simulation model, please open the attached CPN with CPN Tools and see the annotations therein. Acknowledgements Funded under the Excellence Strategy of the Federal Government and the Länder. We also thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.

通用描述
本流程描述了企业内部的客户订单管理工作，涵盖客户订单的登记与付款处理，以及订单的包装与发货流程。本公司为此在销售、仓储与发货部门配备了专职人员。本数据集是依据OCEL 2.0标准（OCEL 2.0）、使用CPN工具（CPN-Tools）模拟生成的人工事件日志。CPN模型与SQLite数据库文件均可下载。本次仿真为此前OCEL标准中订单管理日志的扩展版本。

流程概述
在本公司，客户可针对不同产品下单（place order）并指定采购数量。每种产品均有对应的定价与重量。当前市场环境下存在通货膨胀，这会不定期推高产品价格，而价格上涨会对客户的购买力——即订单规模——产生负面影响。客户下单后，该订单会被分配至本公司销售部门的一名员工。为提升客户满意度，本公司实行“单一客户对接”政策：每位客户仅配备一名首席销售代表，全权负责与该客户相关的所有服务。若该首席代表无法履职，则由第二名销售代表接手该订单；若第二名代表也无法处理，则需由其他员工负责管理该订单。

销售员工的工作内容包括订单登记（confirm order，即确认订单）与付款流程处理（payment reminder，即付款提醒；pay order，即订单支付）。与此同时，货物的发运筹备工作也同步开展：仓储部门员工会核查公司库存，确认订购商品是否有货。若商品缺货，仓储人员需进行补货（item out of stock，即库存缺货；reorder item，即补货）。待发运的商品需被拣出（pick item，即拣货），装入面向单个客户的包裹中。此时可能出现一个包裹对应多笔订单，或一笔订单的商品被分装至多个包裹的情况。当分配至某一包裹的所有商品均完成拣货后，仓储员工会完成包裹组装（create package，即创建包裹）。随后，发货部门员工会取走该包裹进行运输（send package，即发送包裹）。

根据另一项内部政策，仓储员工应协助发货员工完成包裹装载工作。但实际操作中，发货人员时常违反该规定，独自完成装载，或与第二名发货员工共同完成装载。最终，包裹完成发运。配送过程可能多次失败（failed delivery，即配送失败），直至最终成功送达（package delivered，即包裹送达）。

下图以简化形式展示了该流程，使用非正式流程符号描述了控制流与涉及的对象类型。下一节将结合相关工件给出正式描述。更多信息可访问：https://www.ocel-standard.org/event-logs/simulations/order-management/

通用属性
以下为日志属性概览：
| 属性 | 取值 |
| ---- | ---- |
| 事件类型（Event Types） | 11 |
| 对象类型（Object Types） | 6 |
| 事件总数（Events） | 21008 |
| 对象总数（Objects） | 10840 |

控制流行为
本日志的行为由对应的面向对象Petri网（object-centric Petri net）描述。此外，各独立对象类型的行为可通过更简化的Petri网进行描述，详见下文：订单（orders）、客户（customers）、商品（items）、员工（employees）、包裹（packages）、产品（products）。
完整面向对象Petri网

对象关系
本公司推行“单一客户对接”政策，每位客户均配有一名专属首席销售代表以及一名备用（次级）销售代表，该关系已在日志中进行标注。对象间的基础关联关系如下表所示：
| 源对象类型 | 目标对象类型 | 限定符 |
| ---- | ---- | ---- |
| employees（员工） | customers（客户） | primarySalesRep（首席销售代表） |
| employees（员工） | customers（客户） | secondarySalesRep（备用销售代表） |

此外，在执行特定活动时，还会产生其他对象间关联关系，如下表所示：
| 活动 | 源对象类型 | 目标对象类型 | 限定符 |
| ---- | ---- | ---- | ---- |
| create package（创建包裹） | packages（包裹） | employees（员工） | packed by（打包人） |
| send package（发送包裹） | packages（包裹） | employees（员工） | forwarded by（转寄人） |
| send package（发送包裹） | packages（包裹） | employees（员工） | shipped by（发货人） |

仿真模型
用于生成本事件日志的CPN模型同样可供下载。如需获取仿真数据，请解压所附的压缩包，并通过CPN工具（CPN Tools）运行其中的CPN模型。该运行过程会生成符合OCEL2.0规范的CSV文件。本数据集附带的Jupyter Notebook（Jupyter Notebook）可用于将这些CSV文件转换为SQLite数据库导出文件。如需查看仿真模型的技术文档，请使用CPN工具打开所附的CPN模型，并参考其中的注释内容。

致谢
本研究受联邦政府与各州卓越战略计划资助。我们同时感谢亚历山大·冯·洪堡基金会（Alexander von Humboldt Stiftung, AvH）对本研究的支持。