Introduction

This document introduces the administration of the beCPG software and is meant to beCPG administrators.

• Open beCPG Admin console to initialize the PLM
• Click on "Initialize the repository"

Group management

The group management interface is accessible by beCPG>beCPG administration menu on the upper headband. Then, on the left headband, click on « Groups ».

Groups can be prioritized. For example, the « R&D users » and « R&D leaders» are part of the « R&D group ».

beCPG groups are:

The « System Managers» group has the write permission in the system folder.

License management

Licenses in beCPG are administered via groups. To assign a license to a user, simply add the user to one of the following groups:

In the case of the use of beCPG enterprise, it is mandatory that each user belongs to one of the license groups.

Licenses are defined as following :

Concurrent license license shareable between multiple users, but used by only one user at a time, so a user can use the software once other users has stopped using it (voluntary logout or end of session).

Write license: create and modify products, formulation, generate reports, product approval, use of workflows to manage products, project management.

Read/Supplier license: read products, documents and projects, collaboration (blog, wiki pages, forums, lists of data), document management, supplier license.

Users management

Create a user

The users management interface is accessible through beCPG>beCPG administration menu on the upper headband. There, on the left headband, click on « Users ».

Creation of a new user can be done by clicking on the « New User » button.

The interface enables to enter user informations (name, account, email and so one) and groups he belongs to.

Edit/modify a user : add a new group:

1. write a few letters of the user name you are looking for in the text field,
2. click on "Research",
3. select a user by clicking on his name.

Modify a permission:

1. on the upper right of your screen : click on "Edit User" ,
2. in : "About User" : Search for the groups by writting the first letters of the group in the text field (you can see all the group in becpg> administration > groups> Browse) : click on Search,
3. select the group by clicking on "Add"
4. save Changes

Go back to beCPG > administration beCPG > Click on "Reload" properties permissions.

Initialization of sites

Site set up

As part of the new 2.2.3 version, beCPG now integrates 4 sites by default which enable to automatically classify and organize entities.

Descriptions of the 4 standard sites:

1. "Products in development": site for entities in simulation and refused (e.g. used by the R&D team, it is also possible to restrict only the access of the site to R&D team members).
2. "Validated Products": site where validated entities are saved (active recipes, referenced suppliers ...)
3. "Archived Products": site where entities whose status is "archived": obsolete products, non referenced, old recipes. (usually access is limited to R&D members/ Quality)
4. "Supplier portal": job site which groups together all referencing projects plus the creation of new raw materials.

The sites have different common characteristics:

• Absence of dashboard to facilitate quick access to entities,
• State: private.
• It is possible to change their name.

Codification of the name:

1. Site "Products in development", default name: "simulation", type: product
2. Site "Validated Products", default name: "valid", type: product
3. Site "Archived Products", default name: "archived", type: product
4. Site "Supplier Portal", default name: "supplier-portal", type: project

Ranking rules

Ranking rules are by default not active . To activate them:

Table of default ranking rules:

Site creation

Sites are collaborative spaces in which a team or a service can work on the same data/products in a dedicated space. For example:

• R&D site;
• fresh products R&D site;
• frozen products R&D site;
• Purchases;
• Quality;
• Plant A;
• ...

To create a new site, click on Sites> Create site (on the upper headband).

Once the site has been created, it is possible to administrate the members of the site thanks to the site’s « Members » tab. In that tab, you can indicate groups and/or users who get access to the site.

To add a new group or a new user to a site, click on the icon which is surrounded in red as per the screenshot below:

Select the « Members » tab or the « Groups » tab to add people or groups respectively. Write the first letters of the users or groups names to find them.

Then, assign rights to users or groups by chosing a statute :

• Consumer (can consult content);
• Contributor (can add and modify his own documents);
• Collaborator (can add and edit his documents and others’ documents) ;
• Manager (can invite people).
• Version manager (can merge branch/version to this site and consult content);

Rights matrix is available at:

http://docs.alfresco.com/5.0/references/permissions\_share\_components.html

Rights management in sites is easier than the rights management in the repository :

• It’s not possible to have a group as collaborator on a folder and not on another folder.

• If a group is collaborator in a site, he’s collaborator on all the contents.

• If you want to create a site where the group A is collaborator on the folder A and the group B is collaborator on the folder B, it’s not possible. Thus, you should create two sites, one for the group A and another for the group B.

Permissions in the repository

It’s possible to define permissions on a content (for example, a folder or a document). For that purpose, place the cursor on the folder or the document line and click on « More » and then on « Manage permissions ».

A permission is defined by:

• A group of users or a user (to search a group or a user, write the first letters of its name);

• A role: > Consumer: can consult content; > Editor: can edit content; > Contributor: can add and edit his documents; > Collaborator: can add and edit his documents and other users documents; > * Manager: can delete content of other user, add rules etc.

Rights matrix details:

https://docs.alfresco.com/content-services/latest/using/permissions/

A folder can inherit permissions defined on its parent folder.

Fields permissions

beCPG restricts access to certain fields of the model per group of users. For this purpose, go to Repository> System> Security rules and create a new entity. This entity corresponds to a group of permissions applied to a beCPG node type. Once the entity is created, edit its properties and choose the node type for which the permission is activated :

Here, permissions are created on the node type « Packaging ». To define the rights on properties, click on the « Permissions » list:

Add new permissions to the data list by clicking on « New row »:

Rules are as follow:

• If a group has the « Read » permission on a field, others don’t access the field ;
• If a group has the « Read and write » permission on a field, others have the « Read » permission on the field ;
• By default, a field is accessible in reading and writing mode.

Once all rules have been defined, go to « Administration beCPG » and execute « Reload properties permissions » by clicking on the corresponding button.

Permission on fields: Confidentiality & security rules

Security rules help to manage system rights when they are defined. They apply to all of PLM. You can however define product by product rules with the "Security" aspect. These rules of confidentiality take precedence and are directly associated with the product.

Functioning :

• Create a security rule
• Identify the rule as a local permission rule by validating the field
• Configure your rules (e.g. visibility right for the Composition list)
• Add the Security Aspect (sec:securityAspect) on the target entity
• Add the rule with the local permissions to the product with the field: "Security rule"

Application of the rules :

• Formulation of the product

Example of using the security aspect : Allow or not the visibility of the composition of a semi-finished product by users. They will be able to use the semi-finished but the composition of the latter will not be visible (the composition will not unfold, impossible to carry out a "duplication of children"). Only authorized persons will be able to read and modify the composition of the semi-finished product.

Permissions on reports

It’s possible to define rights on technical sheets so that their consultation and/or their edition is rigorously managed.

For that purpose :

1. Go to: Repository> System> Reports> Product reports;
2. Select the folder corresponding to the type of products of which you want to manage the technical sheets (finished product, raw material …);
3. Place the cursor on the line corresponding to the concerned technical sheet and click on « More » and then on « Manage permissions »;
4. If the default configuration doesn’t suit you, which means that you don’t want everybody to have the right to consult the technical sheet as a « Consumer », click on « Inherit permissions ». Thus, the logo turns from « Check » sign to « No entry » sign so that you can administrate your own rights.
5. Click on « Add a user/group » to give rights only to some users or groups on this technical sheet. Once the user or the group selected, give it a rôle (consumer, collaborator etc.);
6. Click on « Save »;
7. Finally, place the cursor on the line corresponding to the technical sheet and click on « More » and then on « Update permissions ».

Permissions on projects

beCPG enables to define rights on projects:

• Either on folders which specifically contain projects. For that purpose, consult the documentation concerning the permissions on folders, available at:

ADDRESS

• Either on individual projects. For this matter:

• Go to the folder containing the project in question;

• Place the cursor on the line corresponding to the project and click on « More » and then on « Manage permissions »;
• If the default configuration doesn’t suit you, which means that you don’t want everybody to have the right to consult the project as a « Consumer », click on « Inherit permissions ». Thus, the logo turns from « Check » sign to « No entry » sign so that you can administrate your own rights ;
• Click on « Add a user/group » to give rights only to some users or groups on this project. Once the user or the group selected, give it a rôle (consumer, collaborator etc.);
• Click on « Save » ;

N.B : a user or a group of users defined as « Consumer » on a project won’t have the right to add new tasks neither to modify or delete tasks UNLESS they are assigned to these tasks !

Depending of their rights, users won't have the same access. For example, a consumer won't have the right to modify a task if the task is not assigned to him.

However, the user can modified tasks which are assigned to him.

Permissions on change orders

If you want to create a change order, you need to have the right permissions.

There are 2 different permissions :

• beCPG Change orders creators (CreateChangeOrder) : you can create a change order but you can not apply one.
• beCPG Change orders managers (ApplyChangeOrder) : you can apply a change order.

beCPG Change orders managers and the administrator are the only ones able to apply a change order.

How to change users permission: see here

Define rules on folders

Rules can be defined on each folder. By rules is meant :

• Send an e-mail when content is added/deleted/modified in a folder ;
• Set-up a workflow when content is added to a folder ;
• ...

To define a rule:

• Go to the directory containing the folder in which a rule has to be added ;
• Click on « More » and then « Manage rules ».

Two cases are possible:

If no rule is associated to the folder, two actions are possible:

• Create rules : define rule from nothing on the chosen folder ;
• Link to rule set : Reuse an existing set of rules defined for another folder.

If one or more rules are already assciated to the folder, four actions are possible:

• Inherit rules: the folder on which we’re working inherits the rules of its parent folder ;
• New Rule: creates a new rule.
• Run Rules: execute an existing rule ;
• Edit: modify an existing rule ;
• Delete: delete an existing rule ;

Generalities about the creation of a new rule

By clicking on « New rule », a form appears in order to fill:

• The name of the rule (1);
• The descripion of the rule (2);
• The moment when the action generated by the rule must be executed (3);
• The conditions that have to be met (4);

• The action to trigger (5);

• The action to execute (6).

Note: supplementary options are available (7) :

• Disable a rule: desactivate a rule instead of deleting it (because perhaps it could be useful later);

• Apply rules to the subfolders : the rule is called « recursive rule ». In that case, conditions have to be well defined, otherwise the performances could be degraded.

• Run rule in background

Finally, click on « Create » to register the rule.

Example of a new rule creation allowing the deplacement of products, from a folder A to a folder B, when they pass from the state « Simulation » to the state « Validated ».

"More details": http://docs.alfresco.com/4.1/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Fconcepts%2Flibrary-folder-rules.html

Versions management rules

beCPG proposes a rule to manage the number of versions on a document. This rule manages the legacy.

The action of versions management contains the following configurations :

    Version: Minor,Major,Both;
    Number of versions: all if empty;
    Number of days to conserve: all if empty;
    Number of versions per day: all if empty;

In the case of many versions rules (inherited or not) fields are surcharged. Example :

    Rule 1 on the ECM (Both, 5 versions max)
    Rule 2 on the Site A (Minor, empty)
    Rule 3 on the Site A (Major, 5 versions max, 1 version per day)
    Rule 4 on the Site B (Major, empty)

Which gives for a document in the site A:

    All the minor versions
    5 versions max, 1 version per day for the major versions 

Which gives for a document in the site B:

    All the major versions
    5 minor versions Max

The rules application is done when a document is updated or manually. Thus, even if the number maximum of days is 2, if the document is not modified, the versions are preserved. If the rule is modified when the document is updated, the new rule is applied on all the document’s historical versions.

The versions conservation is made in this order:

• Major versions are deleted before the minor versions.
• When a major version is deleted, all its minor versions are also deleted.
• The rules evaluation for the minor versions is made for all the minor versions of each major version.

It begins with the last rule and it goes back to the former one:

• Versions are gathered per day;
• Day surplus versions are deleted;
• Surplus days are deleted;
• The remainder is sorted by date and the maximum number of versions is conserved (the most recent versions are conserved).

Mandatory properties catalog

It’s possible to define mandatory property catalogs for a product. These properties impact the computing of the product advancement score when they are not filled.

The catalog can also be directly downloaded to the instance by going to:

Repository> System> Properties catalog

• id: string, the unique catalog identifier (e.g. "inco");

• label: string, the catalog name displayed (e.g. "EU 1169/2011 (INCO)");

• entityType: table, if this catalog is applied for a specific entity type (e.g. ['bcpg:finishedProduct'] will apply this catalog only on finished products). Optional field;

• fields: table, the list of fields that have to be filled in order to validate the entity (e.g. ["bcpg:legalName", "bcpg:storageConditionsRef"] will create a catalog where the legal name and the packaging conditions must be filled);

• i18nMessages: Object, the mapping of fields and their labels. In the situation where certain fields are overloaded in forms, we need to use the new renamed fields values. e.g. {"bcpg:clients":"business partner", "cm:title": "becpg.forms.field.tradeName"}
  • For bcpg:client we now use the label business partner.
  • For cm:title we use a language key, that language key must be declared in a file that resides in Core(Alfresco).

• locals: table, the languages list for which the catalog is applied. It’s used for the multilingual fields, which must be filled in all languages in common with these indicated in the catalog through this field, and these which are selected in the reports parameters. If this field doesn’t exist, reports languages will be chosen (if there are), otherwise the system language will be the one selected. A language is defined by a 2 letters code according to the ISO-639-1 regulation.

https://fr.wikipedia.org/wiki/Liste\_des\_codes\_ISO\_639-1 Champ optionnel

Concerning the multilingual fields, it’s possible to force a field in a certain language. In that case, the field must be followed by a souligner and the language, for example becpg:legalName_pl forces the filling of the legal name in polish, whatever the language chosen in the catalog or the reports.

See below for some examples of catalogs:

 [
    {
        "id": "incoFinishedProduct",
        "label": "EU 1169/2011 (INCO)",
        "entityType": [
            "bcpg:finishedProduct"
        ],
        "uniqueFields": [
            "bcpg:erpCode",
            "cm:name"
        ],
        "fields": [
            "bcpg:legalName",
            "bcpg:precautionOfUseRef",
            "bcpg:useByDate|bcpg:bestBeforeDate",
            "bcpg:storageConditionsRef",
            "cm:title"
        ]
    },
    {
        "id": "incoRawMaterials",
        "label": "EU1169/2011 (INCO)",
        "entityType": [
            "bcpg:rawMaterial"
        ],
        "uniqueFields": [
            "bcpg:erpCode",
            "cm:name"
        ],
        "fields": [
            "bcpg:legalName"
        ]
    }
]

The backslash at the end of a line allows the property to continue to the next line.

It’s recommended to verify the JSON table validity (without back slash) thanks to a parser before starting the instance - http://json.parser.online.fr/

N.B : You need to clear cache when you update the catalog file.

Easy way to add/delete a field in the catalog:

1. Go to Repository>System>Properties catalog;
2. Put the cursor on "Catalogs" and press "Download";
3. Open the file with a text editor (Atom for example);
4. Add or delete a line;
5. Add or delete a line;
6. Return to the instance and press "More" and then "Import a new version" and choose the file which has just been modified.

beCPG administration console

The beCPG administration console is available through the menu « beCPG » on the upper headband.

This console provides access to system characteristics and system folders

System characteristics

• Lists of value;

• Product hierarchies (family, subfamily);

• Project lists

• Quality lists

• Security lists

Characteristics

The following lists of characteristics are available in the administration:

• Ingredients
• Allergens
• Claims
• Cost
• Nutrients
• Organoleptic characteristics
• Physico-chemical characteristics
• Storage conditions
• Precautions for use
• Geographical origins
• Organic origins
• Trademarks
• Subsidiaries
• Target markets
• Taxes
• Customs codes
• Certifications
• Plants
• Process steps
• Resource parameters
• Notifications
• Labeling templates
• Mentions
• Publication channels

For example, the addition of an allergen will enable users to declare this allergen in a product's allergen list. The same applies to all other characteristics.

Characteristics Claims

Create a claim

• Click on add item
• Complete your claim: Code, Name, legal wording, description, languages, formula...
• Save

Modify an existing claim

• Select the claim to be modified

  To modify an existing claim, select the claim you wish to modify from the list or use the filter search (enter the keyword in the first field then click on filter. To cancel the filter, click on delete).

• Click on the pencil icon at the end of the line.
• Modify your claim
• Save

Notifications

It is possible de generate notifications by e-mail and as often as wanted, for a defined evenment, such as update of documents.

To do so, go to the Notification section.

You can add a notification rule. It will display a form that will ask you :

• Notifications :

  • Groups/persons to notify.
  • Changes rule
  • Related date field. For example, cm:modified for any modification in a document.

• Filters :

  • Of Type: Entity type, like Raw Material, Finished Product,...
  • Folder: allow you to look to applicate your notification only in a certain folder or site.
  • Only changed version: choose if it's only notification about minor or major modifications.
  • Advanced filter : you can add an advanced filter, in JSON format. For example, if you want to be notified for semiFinished prodict that have a certain plant, you should use:

{
    "query": "@cm\\:name:\"Fiche*\"",
    "entityFilter": {
        "entityType": "bcpg:semiFinishedProduct",
        "criteria": {
            "assoc_bcpg_plants_added": "nodeRef" 
        }
   }
}

It's possible to add extra parameters:

{
    "query": "@cm\\:name:\"Fiche*\"",
    "entityFilter": {
        "entityType": "bcpg:semiFinishedProduct",
        "criteria": {
            "assoc_bcpg_plants_added": "nodeRef" 
        }
    },
    "nodeFilter": {
        "criteria": {
            "assoc_bcpg_clients_added": "nodeRef" 
        }
    }
}

• E-mail :

  • Subject: object of the notification e-mail
  • E-mail template: you can choose any built templates.

• Réccurng :

  • Repetition and type. Choose how often you want to send the notification in days/weeks/months/years.
  • Repeat in: choose to repeat a certain day (only usefull for a week type notification)
• Start date: choose when the notification rules will be active.

Once created, you can change your notification rule at anytime.

Note on changes:

Regarding the changes, the date is configured the following way:

• X days before sending date: more than X days before the email is sent

• X days after send date: in more than X days at the time the email is sent

• Since X days: less than X days at the time the email is sent

• In less than X days: Between the time the email was sent and before X days

• X days to date: In exactly X days

Surveys

Since the 3.2.3 version, it's possible to set up surveys and use them in project wizards (for example for the supplier portal referencing project).

To configure surveys, go to the administration characteristics, and choose the Survey questions list:

Here, you can find several fields to complete:

• Label: name of the question / answer
• Parent: used to link answers to questions. A label without any children will be considered as a message the system needs to display.
• Next question: name of the question to open based on the answer

• Response type: there a 4 types of answers:

  • By default (empty) : single choice checkbox. To use for next question usage.
  • List : single choice list.
  • multiChoiceList : mulitple choices lists.
  • checkboxes : mutiple choices checkbox.

• Comment type : use to add or not a comment to the question. There are 4 comment types:

  • none : no comment
  • text : add a free text comment field. To use for short comment.
  • textarea : add a free text area comment field.to use for long comment.
  • file

• Comment label: gives a title to the comment section.

• Score: gives a score to questions.
• Mandatory: to use if you want a question to be mandatory or not. A mandatory question should be completed to validate the survey.
• Visible : display by default the question, without any dependencies with next question field. To use for first questions to display or questions that should always be displayed.

Surveys should be added in the concerned entity, and should be added in the entity template to be added by default in all entities using a template:

Depending on this configuration, we can have the following display:

Answers are sorted in the survey list of the entity under referencing.

Products hierarchy

The product hierarchy is configured per type of product :

Add a family : In order to add a family to raw materials, it’s necessary to fill the « Hierarchy of raw materials » list.

Value : grocery

Add a subfamily : In order to add a subfamily to raw materials, it’s necessary to fill the « Hierarchy of raw materials » list.

Value : pasta, rice, semolina Parent : grocery This allows to link the family to the sub family.

Projects list

In the projects lists, there are :

• The steps’ legends (which associate colours to steps) ;
• Projects hierarchy (projects’ families and subfamilies) ;
• Requests status ;
• Requests origins (ex : the service which made the request) ;
• Sponsors (persons or sponsor service of the project) ;
• Evaluation criteria (criteria to evaluate the project, for example, market or feasibility).

Entity templates

Folders

Entities’ templates are configured per entity type (product, client, supplier) in which there are subfolders, for example : images, documents etc. When the model is parameterized, once a user will create a product, the system will initialize the entity’s folder according to the folder model by creating the subfolders.

Data lists

Entity templates allows you to define the characteristics managed on each product (ie : costs, allergens, nutrition facts). Each time you create a new product, it inherits characteristics defined on template.

• From beCPG admin console, open "Entity templates".
• Open folder "Templates of product"
• Open "Finished Product" datalists
• For each datalist, add characteristics you want to manage on every product > Costs, select costs previously created (Cost raw material, Cost packaging, Cost production) > Nutrients, select nutrients previously created (Energy, Fat, Sugar, ...) > * etc...
• Do the same with other templates : semi-finished, raw material, ...
• Now, when you create a new product, it inherits characteristics defined on template.

Note:

The new allergen will be added to new products, but won’t be added to already existing products as long as they are no formulated or as long as the administrator doesn’t click on the « Synchronize the entities » action.

Creation of a new template for raw material (if it is really necessary)

Repository> System> Entity templates> Product templates

1. Make a copy of a raw material template,
2. Change the name of the copy (for exemple : "Fresh fruit Raw Material"),
3. Clic on the "Fresh fruit Raw Material" template,
4. Change the informations in the lists (physico-chemical ...)

Now you have 2 different templates for raw material. When you will create a raw material, you will have to chose the right template.

Creation of a generic raw material

Purpose

You create and use a generic RM because you want to manage independently several "identical" RM which have slight differences (suppliers, origins ...)

You will have te create an entity template call "generic raw material". It will have a composition's list so it will be possible to add in the composition list the "identical RM" The generic raw material will bring together the informations.

For exemple, you have 3 tomatoes with 3 different suppliers and with different quantities of minerals. You will create one unique RM which will synthetize all the informations.

How to create a specific entity's template : "generic RM"

Repository> System> Entity templates> Product templates

1. Make a copy of a raw material template,
2. Change the name of the copy to : « Generic Raw Material »,
3. Clic on the Generic Raw Material template,
4. Add a new list and choose « Composition »,
5. Name this new list "Composition" for example,
6. Save.

How to use this entity template :

1. Go back to your original folder,
2. Create a raw material,
3. Name your raw material,
4. Choose the template : Generic Raw Material,
5. Save.

Now, it is possible to add in the composition list of your raw materials, the similar RM. Formulate,

The various fields : nutrients, allergens ... will be completed automatically using the information you added in the "similar" raw materials. The calculation are the same as for the semi-finished products and the finished products.

Formulation

If BeCPG is not linked to your ERP: It is possible to formulate your recipes with the raw material contained in the generic raw material. You just need to create a different ERP code. For example : ERP code of your generic RM + ERP code of your supplier. It will be easy to tell them appart.

If BeCPG is linked to your ERP : It won't be possible because your ERP won't tell the RM appart. Only the ERP code of the generic RM will be regonized by your ERP.

Microbiological criteria

Microbiological criteria are defined in the folder below and enable to define microbiological criteria on family of products.

Product specifications

Product specifications enable user to specifiy rules and requirements on ingredients.

For example:

• Salt quantity have to be lower than 2%
• I don't want Frencg eggs
• Specific ingredient labeling rules

To create a produc specification, you must go to Administration beCPG > Product specifications

Product specification creation

Once in the product specifications folder, create the specification ("create" > "Product specification").

Regarding product specifications:

• Properties : to rename your product specification, to define a compatibility criteria, and associate your product specification to another one. For example: create a product specification for France and link it to an anti-doping product specification.

• Documents : to import documents and link them to your product specification.

• Labeling rules : create specific labeling rules.

• Non compatible products : check the list of non compatible products, as specified by the Forbidden ingredients section rules and the compatibility criteria. This section is not displayed by default. If you need it, go to Repository > System > Entity templates > Quality templates > Product specification and click "Add a List". Then, add "Non compatible products" and give your list the same name.

• Forbidden ingredients : create alerts when a product contains something claimed as forbidden here.

Product specifications are refreshed and applied every day at 11 PM. If you want to apply your modification at anytime, you could use the Formulate button.

Associate a product to a product specification:

To assign a specification to a product, edit properties and go to product specification. Then search for your specification in the list and save the properties.

Forbidden ingredients

Forbidden ingredients are used in beCPG to raise alerts if a forbidden ingredient is used in the composition.

To define forbidden ingredients, go to Repository> Quality> Product specifications. Press « Create » and select « Folder ».

A form appears in order to name the product specification. Fill it and press « Save ». Go to « Forbidden ingredients » list and press « Add ». Now, you can complete the information related to one or more forbidden ingredients:

• Requirement level : if the ingredient is authorized, forbidden or if it’s a simple information related to the product ;
• Message : a free text field which will pop up in the composition when the alert is raised;
• Maximum value : maximum threshold authorized for the ingredient ;
• GMO : if the GMOs are forbidden or not ;
• Forbidden ionization: if the ionization is forbidden or not ;
• ingredients : many can be selected ;
• Geographical origins : it can be forbidden to use certain ingredients from certain countries ;
• Required geographical origins ;
• Biological origins: some raw materials ingredients can be forbidden.

Press « Save » to save the form.

In order to use this specification, go to product properties (Properties> Edit properties) and then to Formulation> Product specification and choose the specification by clicking on the dropdown list.

If an ingredient, specified as « Forbidden » in the product specification, is added to a product recipe, by going to the product composition and by pressing the advancement logo, an alert will appear.

Non compatible products

WARNING : make sure the Non-compatible section is displayed.

Once your forbidden ingredients are set, it could seem very difficult to know exactly which raw materials are concerned. That is why "Non compatible products" is available on your product specification.

First, you have to choose the entities to consider. To do so, go to Properties and fill the field "Compatibility Criteria".

You can choose any Entities (Finished product, Raw material,...) and as much as wanted.

On the example above, 2 forbidden ingredient rules were created: the first to forbid any raw material containing water, the second to forbid any raw material containing wheat.

To activate the rule, you have to go to "Properties" and clic on the "Applicate" icon. ( )

This is how we could generate the previous list in the "Incompatible Products" section, with every raw materials which are concerned with at least one of our rules in our example.

Of course, this section take into count others prohibitions, like geography origin.

TIPS : As this list includes a "Details of requirement" column with the chosen message, it's very important to set one in order to know precisely why one product is incompatible. It's highly recommanded also to make one rule for each prohibition, so as to make one message per prohibition. Indeed, in our previous example, we had the No water rule and No wheat rule, with their own message. If we had a single rule with both prohibition, we had only the possibility to have a single message for them both. So, the message would be less specific and less precise, as any product which contains at least water OR wheat would have shown the same message.

WARNING : the "Non compatible Products" section is not taking in count prohibtions with no defined Maximum value (%) for a forbidden ingredient only. If you want to forbid every product countaing the ingredient, no matter the proportions, you only have to write "0". To disable an ingredient prohibition without erasing it, you could just empty the Maximum value (%) section.

Labeling rules

Before reading this section, please read labeling rules.

In order to avoid creating rules specific for each product or each product template, it’s possible to define labeling rules, valid in every cases.

To define labeling rules, go to Repository> Quality> Product specifications. Click on « Create » and then, select « Folder ».

A form appears and allows you to mention the product specification. Fill it and press « Save ». Go to the « Labeling rules » list and press « Add ». Now, you can complete information related to the new labeling rule :

• Its internal name ;
• Its legal name ;
• Its formula ;
• Components concerned by this rule ;
• Language ;
• If the rule is active or not ;
• If the calculation is manual or not.

Note : to fill the form properly, please read labeling. Press « Save » to save this new rule.

Thus, when creating a new product and generating its labeling, this rule will be applied automatically (if the entity concerned by the rule is part of the product recipe).

Reports models

Entity reports (example : product technical sheet)

There exists two types of reports for the product sheet:

• System report (always generated by the system, automatically) ;
• User report (chosen by the user when he edits the product). This type of report is an upon request report.

Product reports are defined in Repository> System> Reports> Product reports.

The addition of a new report is made like that :

• Add a folder ;

• Add the file .rptdesign and then edit its metadata :

• The name of the report ;

• The product type (raw material, finished product etc.) to define the product type on which the report can be applied ;
• Tick « System model » to indicate if the report is automatically generated for this type of product. In the case in wich the report isn’t a system report, the user must select it when he edits the product ;
• Tick « Default model » to indicate that the report is the default report for the product, which means that it will be display per default when the user opens the « Reports » list. It’s not possible to have more than one default report for a type of product. Reports which are not default reports are classified in the product « Documents » folder when the report is generated.

• Report extension

To create or modify a BIRT report, please refer to « Product report model modification ».

When a product is created or edited, the system generates a report which is associated to the product.

Extraction reports from a research

These reports are defined in the folder Repository> System> Reports> Export search.

They are BIRT or EXCEL reports which export a research result. They are also used for the projects follow up.

To add a new report :

• Add a folder ;

• In this later, add :

• The BIRT or EXCEL report, filled with its name and its metadata. The name will be displayed on the results page of a research ;

• The file extension must be « xls » for an EXCEL report and « rptdesign » for a BIRT report ;
• Define its permissions on the report folder. People must have the « Reading » permission to be able to see the report in the result of a query.

Solely for the BIRT reports : Definition of the data to be exported to feed the report, which name is ExportSearchQuery.xml. This file defines the attributes of a product which must be exported during the report execution : > product properties (state, name etc.); > product’s links (supplier, clients, etc...); > * product’s characteristics (costs, nutrients, allergens, etc...).

To create or modify a BIRT report, please refer to « Modification of a product report model ».

EXCEL reports are easy to create. In EXCEL, in the first tab, define the principal type to extract as follow :

TYPE    bcpg:finishedProduct                
COLUMNS cm:name bcpg:code   bcpg:erpCode    bcpg:productHierarchy1  bcpg:productHierarchy2
#   Nom Code    Code ERP    Famille Sous famille

On the following tabs, extract the principal type datalists. Example for the composition :

TYPE    bcpg:compoList          
COLUMNS bcpg:erpCode    bcpg:compoListProduct   bcpg:compoListProduct_bcpg:erpCode  bcpg:compoListProduct_bcpg:productHierarchy1
#   Produit Composant   Composant – Code ERP    Composant – Famille

Columns and types attributes are internal names given to fields.