Overview

What is an entity? #

In a general sense an entity is any singular, identifiable and separate object. In One ERP entities are used to model and manage business data and are defined by: (1) an unique name, (2) a set of properties and (3) a set of relationships with other entities. Examples of entities: product, customer, invoice etc.

Conceptually, an entity is like a database table, and the properties correspond to the table columns. Creating an entity record (or, simply a record) in One ERP is like adding a row in a database table. There are three types of entities: read-only system, writable system, and custom. When developing applications in One ERP you will be working with custom entities. System entities are used by One ERP to handle internal operations such as metadata, security and workflows. System entities cannot be unpublished.

In this article #

Entity metadata #

The metadata for a One ERP instance contains the definitions for the structure of the entities. For each entity the metadata contains information about the entity, its properties and its relationships.

To view the metadata for an entity click the Develop app, and then click on the Customization sets menu. In the page that opens, under the Search section, enter in the Entity field the name of the entity. Click the Search button.

Best practice #

An entity name should be a singular noun.

Properties #

A property is identified by a name and has a type. The type describes what kind of data can be stored. There are two types of properties: system and custom. System properties are handled automatically by One ERP for managing entity record identity, entity record ownership and date/time of the create and update operations.

The system properties are:

System properties are created automatically and cannot be deleted or changed.

Custom properties can be created at will with the following limitations on their name:

1. Property names are case sensitive and unique
2. The property name cannot start with a number or with the “id_”
3. The property name can contain only ascii letters ([a-zA-Z]), numbers and the character “_”

Property types #

The following property types are available in One ERP:

Relationships #

A relationship is identified by a name and has a type, property name, foreign entity and a foreign property name. The type describes how the data is related. There are two types of relationships: system and custom. System relationships are handled automatically by One ERP for managing entity record identity, entity record ownership.

To simply descriptions we will describe relationships as sentences with the following structure:

define relationshipName of type between left-side entity and right-side entity

From hereon we will call the rel

Relationship notation

relationshipName = localEntity type to foreignEntity on property and foreignProperty

The structure of a relationship:

In One ERP there are four types of relationships: One-To-Many and Many-To-One, Parent-Child and Child-Parent, Many-To-Many, One-To-One. Many-To-Many and One-To-One are implemented but cannot be used and are reserved for future use.

The system relationships are:

System relationships are created automatically and cannot be deleted or changed.

Custom relationships can be created at will with the following limitations on their Name:

1. Relationship names are case sensitive and globally unique
2. The relationship name cannot start with a number
3. The relationship name can contain only ASCII letters ([a-zA-Z]), numbers and the character “_”

and the following limitations on their Type:

1. Only one relationship of the same Type  same Foreign entity  and same Property name can be created, regardless of Name.

One-To-Many (1:n) and Many-To-One (n:1) #

When creating a One-To-Many relationship between two entities the following will happen: 

1. The relationship will be created on the entity corresponding to the “Many” part;
2. A reversed relationship (Many-To-One) will be created on the entity corresponding to the “One” part;
3. A property that holds the key, of the entity corresponding to the “One” part, will be created on the entity corresponding to the “Many” part.

The previous is valid also when creating a Many-To-One relationship.

This type of relationship can be created multiple times between the same entities or with the same entity on both parts. In this case the relationships must be distinguished by different Names and must be on different Property names.

Example of Many-To-One relationship

Let’s create another 2 entites called purchase_invoice and supplier. The entity purchase_invoice will have a Many-To-One (n:1) relationship with the supplier entity.

The purchase_invoice has the next properies:

• date of type: datetime
• number of type: string
• terms of type: string

The supplier entity has the next properties:

• name of type: string
• address of type: string

The n:1 relationship between purchase_invoice and supplier will be called purchase_invoice_supplier.

Best practice #

The user can choose what kind of relationship he wants to create One-To-Many or Many-To-One. It is recomanded that after he has chosen one of this relationships, to create the same type of relationship everywhere in the project.

Parent-Child (p:c) and Child-Parent (c:p) #

From structural point of view this types of relationships are identical with One-To-Many and Many-To-One relationships. The difference resides in the fact that they are managed in the same life cycle and not separately. This means that child entities are not saved or updated separately but within parent entity. 

Example of Parent-Child relationship #

Here we defined another entity called purchase_invoice_item. The entity purchase_invoice , that we created in the last example, will be in a Parent-Child (p:c) relationship with this new entity.

The purchase_invoice_item has the next properties:

• quantity of type: decimal
• unit_price of type: decimal
• amount of type: decimal

The p:c relationship between purchase_invoice and purchase_invoice_item will be named purchase_invoice_purchase_invoice_item.

If we make changes to one of the purchase_invoice_item of a purchase_invoice, to save those changes we will have to save the purchase_invoice that contained that item.

Best practice #

Between Parent-Child and Child-Parent relationships the user is adviced to create the Parent-Child relationship so that the relationship will be named having at the beginning the parent entity name and the character “_” followed by the child entity name.

Many-To-Many (n:n) #

This kind of relationship creates into the database a table with the primary keys of the both entities.

Warning #

Many-To-One relationship creates the necessary table into the database, but right now it is not accessible through the entity service and it is reserved for future versions of this service.

One-To-One (1:1) #

In One-To-One relationship a record coresponding to the table of one of the two entities is associated with one and only one record of the other entity.

Warning #

Right now the One-To-One relationship doesn’t affect the database and it is reserved for future versions of the entity service.

Lifecycle of entity records #

Understanding the life cycle of entity records is very important.

All properties and relationships are updated in the same time. In contrast with database table you cannot update only one single property for an entity. 

When designing the data model you must take in account all the life cycle events of a entity not just the structure.

Creating #

Reading #

Updating #

Deleting #

Entity ownership #