* This Release Notes refers to INFLOR Forest – Inventory and Smart Modules, whose names, for some customers, are as follows:

  • IFL
  • ANALYTICS

What’s new on INFLOR Forest – Inventory and Smart Modules?

Check out the newest updates of INFLOR Forest – Inventory and Smart Modules, available in this new Release.

Correctives

[IS-25789] – Correct the behavior of the Flags – Provides Harvest and Used by Harvest.
Reported Scenario
The two flags below need to behave in an integrated manner, so that there are no inconsistencies in the reading of the inventory data by the harvest or in the availability of the inventory for the harvest.
 
Adopted Solution
When the flag Uses for Harvest is checked, the flag makes available will be deselected and locked.
 

Incidents

[IS-25381] – ERROR CREATING PLOTS ON GISAGRI WEB
Reported Scenario
An error occurs in the validation routine of appointments mobile
 
Adopted Solution
The call of the webservice responsible for validating the data was fixed.
 

[IS-25500] – Identification of measured heights in the field for auditing
Reported Scenario
The marks of trees measured for neural networks in the data collector do not match the trees marked as neural networks.
 
Adopted Solution
The mobile system was fixed so that the rule that identifies the neural network trees is identical to the routine that marks the neural network trees for the audit report.
 

Projetos

1. Improvements in the Quality System.

1.1. Free Registration of Locations

The system was modified so that the user can carry out assessments without the dependence on selecting an operation and field at the time of validation. A new screen was enabled in which the user can configure the different types of locations that can be used in the quality process:
 
• Quality model configuration:
In the prescription, the user now has the option of filtering and indicating in the “Solo Use Type” the different places previously registered.
It is no longer mandatory to indicate the operation in the prescription record as it is currently done, in cases where the evaluation is carried out in an operation, the configuration must be carried out in the same way as it is currently.

 
• Quality Programming:
With the inclusion of the type of location in the prescription, the programming screen was also modified so that the user can filter the locations available to perform the measurement by type of location:
As the type of location may be an entity that does not involve automatic programming, as in the Harvesting and Forestry processes and may be unlinked from the SGF records, the user must generate at least one manual programming for this type of location that will be used in the quality app.

With the more comprehensive location registration, the user can now perform more than one measurement for the same location, in these cases there is no duplication rule.
With these changes, we will have three possible scenarios for evaluating quality models:

 
1. 1. Programming by field:
a. The Current system format, where a field is associated with an operation of any module.
2. Schedule by location:
a. The New format, where the user can choose which location will have a quality assessment (according to the location chosen in the prescription of the quality model, described above).
3. Programming by location with field indication:
a. The New format, where the user can choose which location will have a quality assessment and still have to inform the field. In this case, list-type variables must be created for the quality model from the tables and region, project and field.
 
 
• Application changes:
In the quality application, the “Download Operations” screen now also requires OSs created directly in the measurement schedule without the scheduled operation link:

When generating the measurement, the layout was also changed:

When selecting a quality model whose setup is by a location type other than field, the screen will not display the scheduled operation option, region, project, and field.
If the evaluation is made by supplier, for each supplier that will be evaluated, it will be necessary to have at least one service order created.
From this step on, the user will use the quality forms in the same way they are used in current processes.
Current processes will not be modified with this improvement.
Configurations of current processes will not be revised.
Every variable registered as a list type will appear on mobile in the same format as the existing lists, below is an example of how the fields will appear.

  

1.2. Location Programming.

The system has a programming screen which allows you to associate a generated measurement to the programming and this is sent to the mobile, but there are places that may need constant evaluation, which would need to be constantly generating measurements for the same location, in addition the system would only allow a single collection. To solve this limitation, the system was changed to create an association between the location and the schedule.
Once a schedule has been created, the user can now associate a location to that schedule. The schedule would have a start date and an end date. While it is within the established period, every time you download the Quality Schedule (we are not talking about operational OS) the location associated with this schedule and all the quality models of this process are sent, because the system is not able to know which quality model that will be evaluated.

 

1.3. Automating the generation of quality programming (survival).

Through the prescription table, the user can now enable the generation of quality activities schedule. In the case of survival, it is necessary to schedule the evaluation 35 days after planting.
The system will go through the forest register looking for plots that complete the 35 days of planting for the current plan and will generate a survival quality measurement schedule.
This measurement should be associated with a quality schedule and not an operational work order. Once inside the schedule, it should be sent to the mobile which should already present the measurement to the user. Thus, there is no need to create (via mobile) just select to start the collection.
 

1.4. Duplicate Configuration.

Let’s imagine a scenario where we have a single place for a nursery, and there is a need to make several collections of the same quality model. Previously, the system would consider duplication as we can only do one collection for the same day for the same quality model. Now there is a setting in the prescription record for the user to indicate whether there can be duplication or not.
The collector was also changed so that this information is treated, thus being able to register two assessments for the same location. And when entering the data, the system understands that this is not a duplicity.
 

1.5. Coordinate capture at individual level

Previously the quality module has 3 levels, location, sample and individual. The system only stores coordinate at the sample level. A change was made so that while the individual data is being captured, the system is monitoring the GPS data and storing them together with each individual. This will be done for Local level variables, if there is only one data collection for level 3 (local) the system can identify where the information was collected.
A cube was created to present this data and it is also plotted on the Analytics map symbolizing the result of the collection.
 

1.6. Non-compliance record.

The system now has a non-conformance email sending mechanism. The email is sent by a certain parameterizable rule that already exists, either through a quantitative or qualitative variable that determines a non-conformity, or a value that results in a non-conformity.
When the email is sent, the system fills in an email template where there can be information such as the field, supplier, images, variable result etc..

 

1.7. Inclusion of Level 1.

In this release was added a feature that allows downloading an OS on mobile allows you to view only the OS of the company to which it belongs, if the user is not an employee of the company. If you are an employee, you will not be able to access N2 assessments (performed by Veracel’s Quality area). This same filter must also be implemented in the data import screen and in the processing screen. On the import screen, if the user is level 1, he will only be able to view the import process of the company to which he belongs, and on the processing screen, he will only be able to view data from his company. Other users will be able to have free consultation as it is today.
Also the level 1 user now has more restricted access as data reversal so that no information is erased.

 

1.8. Optimization, import, validation, and transfer.

The process of sending data from mobile to the SGF has three steps. Import, Validation and Transfer. Just as there is today in forestry, there is a job that monitors the arrival of new data at the hub. A functionality similar to that of forestry was created, which will be monitoring the hub, checking for the arrival of new measurements. Once identified, it will automatically do the 3 processes.
 

1.9. Allow statistical calculations to be performed in the field.

Until this release, the system did not present any statistical results on mobile. From this release, if the function of statistical calculations in mobile is selected, the system will present the result during the collection. No calculated data will be exported or saved. Only available for presentation.
 

1.10. Creating new cubes.

New cubes were added, covering the three measurement scenarios:
 
1. Programming by field:
a. The. Current system format, where a field is associated with an operation of any module.
2. Schedule by location:
a. The. New format, where the user can choose which location will have a quality assessment.
3. Programming by location with field indication:
a. The. New format, where the user can choose which location will have a quality assessment and still have to inform the field.
 
Until then, the “Results Quality” and “Detailed Quality” cubes allow the user to verify the information of the measurements performed, however, they necessarily show the region, project and field data, in addition to other information such as process and regime.
To solve this, two cubes were created, which will have the information of field operations assessments and location assessments, with or without the indicated field.
 
 
Quality Result:
When the quality model is programmed from an OS, the data will be displayed according to the current report.
However, when region, project and field information are measured variables, fields such as “Management”, “Area”, “Mat Gen”, “Cycle” and “Rotation” will not be filled in, as the fields will not be part of the programming and yes informed in the field. Furthermore, if the user in the field does not inform these values, the fields may be empty.
 
 
Quality Result:
When the quality model is programmed from an OS, the data will be displayed according to the current report.
However, when the region, project and field information are measured variables, if the user in the field does not inform these values, the fields may be empty.
 
 

2. Review and improvement of the Inventory System.

2.1. Interface improvements and user experience

As of this release, on the inventory system screens, we have the option to filter more than one region and/or project in a single filter on the processing, programming and projection screens, filter by the SGF key (pk) (previously only there was the option to filter by the inventory key), and we can also download the images of the inventory parcels.
 

2.2. Analytics improvements.

In this release we included in Analytics the fields Responsible for Scheduling and work order in the import screen.
 
 

3. Improvements to the Inventory Mobile.

3.1. Inventory Import Treatment for active and historical fields

In this release, a parameterization was created in the import process, where the user must inform if he is importing data for the active or historical field. This will cause the user to inform the cycle and rotation of the field, if he has selected the history option.
This option will not take into account whether the field is active or historic, since there is only a single field in the base with the key Region, Project, Field, Cycle and Rotation.
 

3.2. GIS x Inventory parcel interfaces

Until this release, the parcel interface routine between the inventory system and GIS applied parcel position validation through overlay. However, this validation only occurred with active fields in the register. The routine was changed so that the parcel is created without overlapping validation, that is, it will be created with the X Y coordinates passed in the data import.
The new routine that validates the plot coordinates validates the overlapping of plots through active fields in the register. As it may happen that there are historical fields, this overlapping validation will no longer occur when it is identified that these are historical fields