Skip to main content
  • 494 Product updates

Material Allocation App (object-centric) version 1.

Material Allocation App (object-centric) version 1.0.0 (2024-02-22) Understand excess supply and uncovered demand and find inventory reallocation opportunities (General Availability) Our object-centric Material Allocation app for Inventory Management is now in General Availability status. The Material Allocation app uses constraint-based optimization and insights generated with object-centric process mining to identify opportunities for working capital optimization, through moving existing inventory from where it is not needed to where it is needed the most. The calculations take labor or transportation cost into account as well as any additional constraints specific to your business. Use the Bill of Material Explosion and Inventory Projection features to evaluate the impact and feasibility of your proposed re-allocations. The object-centric Material Allocation app is the successor to the case-centric Material Shortages app, which is now deprecated. The Material Allocation app is a premium app, and is subject to an additional licensing fee. Talk to your Celonis account team to arrange this before you download the app. To use the Material Allocation app you’ll need a Celonis license that includes object-centric process mining. The app needs some additional custom object types to enable its use cases, so you’ll need to create a custom Inventory Management perspective to use with the app in place of the supplied perspective. When you request the app in Marketplace we’ll provide a step-by-step guide for you to do this. For the app documentation, see Material Allocation app - object-centric.

Related products:Process Intelligence Graph

Inventory Management Control Center, Master Data Improvement, and Starter Kit (object-centric), version 1.

Inventory Management Control Center, Master Data Improvement, and Starter Kit (object-centric), version 1.4.0 (2024-02-22) Streamlined calculations and enhanced quantity and currency conversion Version 1.2.0 of these apps, released mid-January, was an early release to fix an issue with attribute references exceeding the platform’s character limit. We also streamlined the calculation for purchase and production lead times to reduce nesting, moved calculations for averages earlier in the process so they needn’t be duplicated, and combined some KPIs that were only used once in the Knowledge Model and weren’t used in views. In version 1.3.0, released on 6 February, we updated the Quantity Conversion KPIs with the new QUANTITY_CONVERT PQL operator, and appended the existing Currency Conversion KPIs with enhanced operator syntax. Version 1.4.0 updates the object types, event types, and relationships from the Celonis catalog to be compatible with version 1.1.0 of the catalog. Upgrade the apps to version 1.4.0 to keep them in line with our updates to the Celonis catalog types. If you’ve extended any of the Celonis object types and event types, we’ll apply your extensions to the updated types. If you’ve replaced any of the Celonis object types and event types with custom equivalents, we won’t make any updates to those. If you find you have two exact copies of a relationship, a custom one and a catalog one, delete the custom one in each case. For the upgrade instructions, see Updating the object-centric Inventory Management Starter Kit.

Simpler modeling for relationships for object-centric process mining (2024-02-08)

Simpler modeling for relationships for object-centric process mining (2024-02-08) We've redesigned the Objects and Events user interface to give you more guidance when you're modeling custom object to object relationships and event to object relationships:The list of relationships for an object is now divided into outgoing relationships, where the foreign key or join table is to be implemented on this object, and incoming relationships, where the foreign key or join table is to be implemented on the other object. You can click any relationship to view the implementation details and the location of the transformation. You can also show inactive relationships that the object has for processes that you haven’t enabled yet.When you create a relationship between two object types, we now automatically create the relationship in the other direction as well. If you don't want a bidirectional relationship, you can delete it.We've combined the options for the relationship's cardinality with the choice of where and how to handle the relationship data in your transformations, so it's clearer what to choose and what you'll need to do afterwards. Your choices for the cardinality of a custom relationship are now many to one (m:1), one to many (1:m), many to many (m:n) with the relationship table as a join table on the source object, or many to many (m:n) with a join table on the target object. We've removed the choice of a one to one (1:1) relationship, as the object-centric data model and the underlying database don't enforce uniqueness of a foreign key. Any custom one to one relationships already in your object types will continue to exist. For the modeling documentation, see Modeling objects and events. 

Related products:Process Intelligence Graph

Coupa Extractor (2024-01-12)

Coupa Extractor (2024-01-12) Change of primary keys for revision tables Previously the Extractor was using the “id” column as the default primary key for revision tables, which wasn’t right. We’ve corrected it to use the “revision-record_id” column, which means you can properly link and join the parent and child revision tables through this column.Delta loads of the affected child revision tables will fail following this update, because the primary key of the parent table is added in its child table. To prevent this, enable the option Include metadata changes in the extraction settings, or carry out a full data extraction next time in place of a delta load. After that, your delta loads will work correctly again - although you’ll notice a difference in the records they load, because they’re now based on the corrected primary key column.These tables are affected by the primary key change: purchase_order_revisions (parent) and purchase_order_revision_order_lines (child)invoice_revision_records (parent) and invoice_revision_records_invoice_lines (child)order_revision_records (parent) and order_revision_records_order_lines (child)requisition_revision_records (parent) and requisition_revision_records_requisition_lines (child)revision_records_invoiceheader (nested child table of the object)revision_records_orderheader (nested child table of the object)revision_records_requisitionheader (nested child table of the object)