Access Keys:
Skip to content (Access Key - 0)

Application 2.2.3 Tool 5.3 IBFB Workflow

1. IBFB Implementation V1


There are two main functions associated with fieldbook production. Firstly specification or creation of the fieldbook structure and secondly export of fieldbook tables or forms for data capture. These functions should probably be separated in the workflow system - one step to Create Fieldbooks and one to Export Fieldbooks.
The vision is to have a dynamic fieldbook system in which the fieldbook datasets (Study data, Trial Instance data, Field Plot data and Sample data) coexist with other datasets in the study (Weather data, Lab data, Survey data etc.) and users collect subsets of data by trait or instance, building up the complete study data resource over the life of the study. To do this fieldbook 'slices' are exported to appropriate data collection devices at different times and possibly including existing data from the same or form other studies for reference during data collection.
The process of creating fieldbooks involves using a template which specifies all the data annotation factors and labels and the list of variates or traits to be measured as well as the structural relationship (crossed or nested) between factors. These are merged with the specific levels of treatments and sampling units and the specific plot and sampling layout for a particular experiment. The user interface for creating a fieldbook is customized by the template, and we can increase the specificity of the template to simplify this user interface. This, of course will increase the complexity of the user interface required to create the template, but since this is an infrequent task and often done by more skilled personnel, it seems worthwhile making the templates as informative as possible.

2. Generic Template for a Multi-Environment Trial


We can make a trial more informative for the user interface by adding some constraints to the general definition of a Study Template. For example we can insist that the following Factors and Labels are present in a MET Template:
2.1.  A Factor with property Study - this is always assumed to be present anyway. There may be some Study labels present also to define Met context.
2.2.  A Factor with property 'Trial Instance' and scale 'Number' and possibly some labels of this factor to define context of the trial instances. Scale Number simply indicates levels 1,2,3 ...n. Hence only the number of levels need be specified in order to define all levels.
2.3.  A Factor with property 'Germplasm Entry' and scale 'Number' or 'Nested Number' and some labels of this factor with specific properties and scales matching columns in a germplasm list. The scale Nested Number is value which concatenates the level of the nesting factor with the level number of the nested factor to create unique levels for the dataset. (eg. entry 10 in trial 9 will have level 910.)
2.4.  A Factor with property 'Field Plot' and scale 'Nested Number' and some labels of this factor with properties matching design parameters such as REPLICATION and sub-block and with scale Number.

There may be other factors in the template, and we can assume for the sake of interface simplicity, that they too have scale Number. These factors describe two additional features of MET fieldbooks:
2.5.  Treatment factors are factors with properties other than Study, Trial Instance, Germplasm Entry, Field Plot or Sampling Unit and we can assume they have scale 'Number'.
2.6.  Factors with property 'Sampling Unit' and scale 'Nested Number' define one or more sub-sampling schemes for the MET. These are always nested in Field Plots.
Each of the Factors types 3 to 6 could have associated Labels with different scales and methods. There are two types of measurement variables in a MET template, Constants and Variates. Each will be observed at a specific sampling level. For Constants, the possible levels are at the Study level (one value for the whole study) or at the Trial Instance level - one value for each trial instance. The choice is indicated in the Sample Unit column of the template. Similarly Variates will be observed at the Field Plot level or one of the Sampling Unit levels and again the choice is indicated by the appropriate factor name in the Sample Unit column of the template.

3. The Create Fieldbook Interface

A fieldbook could be generated from this template with the following steps:
3.1. Open or create a Study




3.2. Select the option to Create a MET fieldbook - Start the Create Fieldbook Wizard:


A single study may have many datasets we are concerned with creating one for a Field Trial.


3.3. Open Template: Open a MET template



The user might want to view the content of the template:


3.4. Conditions: If there are Study labels fill these single values in a Trial Conditions window or allow users to leave them blank to be filled in when the fieldbook is complted. One of the Condition questions (the last) should ask for the number of Trial Instances (use other terminology as appropriate).


Note that throughout this module the user will be required to specify Factor and Label levels. Factor levels are compulsory since the field book cannot be constructed without knowing at least the number of trial instances, the number of treatments (entries for a single factor trial or treatment combinations for a factorial trial) and the numbers of design Factors (reps, blocks and plots). However other labels may be supplied by the person implementing the trial. Some way of indication the obligatory and optional level specifications is necessary (this is not that difficult since the Factors are obligatory and Labels optional)
The mode of entry for label values depends on the units (scale in the Trait Template). Hence if the scale is 'Number' then all the user need supply is the highest level number, n, and the application will know that the levels are 1,2,3 ... n.
If the scale is DBID (Database Identifier) then the application will allow entry of an integer and a button (or return) should launch a look up of the entity specified as the 'Property' of the label (eg a person, institute, location or germplasm). If the scale is DBCV (Database Controlled Vocabulary) then the application could allow text entry followed by a lookup in the appropriate name table (identified by Property). If both DBID and DBCV are present with the same Property, and Method, then the lookup on one will fill the value of the other (eg look up the label for 'Principal Investigator ID' (Property=Person, Scale=DBID, Method=Principal Investigator) and automatically fill the label for 'Principal Investigator Name' (Property=Person, Scale=DBCV, Method=Principal Investigator).
Other 'Scales' could trigger other kinds of entry such as Scale=Date or Scale=Georeference. Scales in the Template are also known to be Numeric or Character and Continuous of Discrete. Continuous Scales should have maximum and minimum levels stored in the SCALECON table to limit input and discrete scales may have a fixed list of possible levels specified in the SCALEDIS table. IF so these can be presented as a pick list.

3.5. Trial Instances: If there are labels for the Trial Instance factor there are four options for filling them:

  • a.  Table filling: Present a table indexed by level number with these labels as columns and allow the user to fill the cells (according to the data type, the scale and the allowable values) or to leave cells blank to be filled one of the following methods;


This could be done by direct entry or line by line with the ADD button:

  • b.  File Import: Read label values from a file with column headings matching the factor and label names (check the data type, the scale and the allowable values);
  • c.  Layout Import: Read label values from a design layout file as specified in step 7 (check the data type, the scale and the allowable values);
  • d.  Data Entry: Leave label fields blank to be filled in when the fieldbook is completed (check the data type, the scale and the allowable values).

Discussion point: Field design parameters should be recorded under Study or Trial conditions depending on whether the same parameters are used for all instances or not. These design parameters should include all the parameters necessary to generate the design, no of reps, no of plots per block etc and subsets of the treatment levels if the treatment (entry) set differs from instance to instance as in the case on mother-baby trials. These details could be filled by the processes above and then automatically used by the design generation engine in step 8, or they could be recorded in step 8 and stored as conditions at that time.

3.6. Germplasm Entries: Read a germplasm list and count the number of entries. The Germplasm Entry factor will have scale Entry ID, Number or Nested Number. If the Scale is Entry ID, map it to the column ENTRYID in the list, otherwise construct level numbers according to its scale - Number or Nested Number. If there are labels of the Germplasm Entry factor (and there will almost certainly be some) then:

  • a.  Automatically map columns of the germplasm list to labels with Property and Scale as follows:
    List Column Label PROPERTY Label SCALE
    LISTID Germplasm List DBID
    List Name Germplasm List DBCV
    GID Germplasm ID DBID
    DESIG Germplasm ID DBCV
    ENTRYCD Germplasm Entry Code
    SOURCE Seed Source Name
    GRPNAME Cross History Pedigree String
    ENTRYID Germplasm Entry Entry ID
    LREDID Germplasm List Record DBID


  • b.  If labels of factor Germplasm Entry with other combinations of property and scale exist then ask the user for level values by Table Filling (5a) (this table might as well show the completed columns from 6a as well), File Import (5b)or Data Entry (5d);

Discussion point: We may also want to add entries from more than one list. How can we accommodate this? For later versions.
Discussion point: Should the Germplasm Entry factor have two labels by default, one with property ListID and the other with property LRecID which would be filled automatically when a list was imported. (ListID and LrecID uniquely define any list entry). For later versions.
Discussion point: Lists of germplasm often have unresolved entries (with GID 0) indicating that the specific germplasm will be chosen later. These may differ from one trial instance to another as with local checks. This is an example of treatment levels nested within Trial Instance, and it is difficult to handle elegantly. I can think of three approaches:

    • One is to label these entries as Local Checks and record the specific details as Trial Conditions in step 5d.
    • The second is to mark the Germplasm Entry Factor as nested within Trial Instance with scale Nested Number and treat every entry as specific to a trial. The labels of the checks would be completed in the data sheet when the trial was planted. Consistency of entries across trials for analysis could then be established by using one of the labels (Germplasm ID or Germplasm Name) to define factor levels in a cross-site analysis.
    • For later versions: The third is to recognize the unresolved entries as local checks and assign them instance specific Germplasm Entry factor levels (for example concatenate the Trial Instance level with the ENTRYID) effectively creating unique levels for the local checks. The specific details would then be entered in the plot label fields of the Trial instance fieldbook.

3.7. Treatment Factors: If there are any factors in the template with properties other than Study, Trial Instance, Germplasm Entry, Field Plot or Sampling Unit then assume these factors are treatment factors:

  • a.  Assuming they have scale Number or Nested Number, simply ask the user for the number of levels of each treatment factor and construct the level numbers.
  • b.  If they have labels then interrogate the user for levels of each label by Table Filling (5a), File Import (5b) or Data Entry (5d).


Discussion Point: We have a slight problem with nesting here if the treatments are nested within the product of more than one factor since the current template only allows specification of one nesting factor. For later versions

This feature will primarialy be used with RCBD designs. It is not useful with unreplicated designs and most unusual with lattice designs.
Now both the Other Treatment Factor FERTLE in your example and the label FERTAM must appear in the measurements tab in the same way as Entry NO and other labels for the germplasm appear in the measurements tab. Remember of course that there may be more than one 'other treatment' factor eg PLANTINGDATE as well as FERTLE.
Now the randomization is best done as follows:
Create a dummy vector caller TreatNo which has values 1, 2, 3, ... NoofGermplasmEntries x No of FertLE x No of PLANTINGDATE etc, ie 1 to the number of treatment combinations so that TreatNo 1 stands for entry 1, fertle 1 and plantdate 1, TreatNo 2 stands for entry 1, fertle 1, plantdate 2 etc.
The randomize treatNo to all the plots in each rep, and the fill in the measuremetns tab with the corresponding levels of each treatment factor.

3.8.Trial Design: The design for each Trial Instance is represented by the factor with property Field Plot and its labels (rep sub-block etc) as well as vectors of entry and other treatment factors which must match the levels specified in steps 6 and 7. There are two ways to specify the design:

  • a.  Ask for the design type and specify parameters (number of reps, sub-blocks etc., the number of Trial Instances and the number of Germplasm entries is already known). This generates plot numbers for each Trial Instance which map naturally to the factor with property Field Plot and scale Nested Number (trial-plot) as well as a table of entry and treatment numbers mapping the Germplasm Entries and any treatment factor levels to the Field Plots. It also creates vectors of levels for the design parameters (reps, and sub-blocks as appropriate) which should map automatically to labels of the Field Plot factor with property Replication and Block etc. If there are no such labels, check if there are other labels of the Field Plot factor and ask the user if these can be mapped to the design parameters and if not, automatically create labels with the appropriate properties for the design parameters.
    Try this mockup
  • b.  Allow the possibility to read the layout from a file which has a column with the name of the Trial Instance factor containing Trial Instance numbers, columns with the name of the GERMPLASM ENTRY factor and the names of other treatment factors as appropriate. It also has columns with the name of the FIELD PLOT factor and design parameter labels - REPLICATION, INCOMPLETE BLOCK etc. The design for each trial instance is defined by treatment factor levels and design parameter levels in the rows corresponding to the trial instance. (Note this file could also have columns with names of the Trial Instance factor labels and therefore be used to complete step 5 at the same time as the design, see 5c).
  • c.  If there are further labels of the Field Plot factor (not mapped to design parameters) then interrogate the user for levels of each label by Table Filling (5a), File Import (5b) or Data Entry (5d).

Discussion point: Step a. above is easy if the design is the same for each Trial Instance. Step b. allows the input of complex designs which do not have to be the same for each instance, and as long as care is taken with the labeling of entries, they do not even need to have the same set of entries at each site so that a mother-baby trial could be specified in this way. As noted in the discussion point at step 5, the parameters could be specified as Study or Trial constants in steps 4 or 5. The latter case is another way to specify different designs for each instance provided all the parameters are available as labels of Trial Instance. Again specifying subsets of entries for different sites requires care, especially as the Germplasm Entries are undefined at step 5.


3.9. Field Plan: If the template contains labels of the Field Plot Factor with properties Row in Layout and Column in Layout then the user must specify a Field Plan in one of the following ways:

  • a.  Use the following table to ask the user for the field dimension in terms of number of plots in each row and column of the field. Ask the user whether to block replicates by row or column. If by row (column), ask the user whether to allocate plots from the start of each row (column) or serpentine (start to end then end to start). Since the number of plots required by the trial is already known - No of Treatments X No of Reps, the user only needs to supply one of the Field dimensions since (in version 1) we will assume the trial fills the whole field.

The table below should be imbedded in an IBFieldbook wizard page exactly like the Design page of the wizard. Once the Fieldbook is complete there should be a Field Plan Tab with this table in it, and an extra button Field Plan Report

  • b.  Levels for the Row in Layout and Column in Layout labels could be read from the Layout file in step 8b.

As soon as the table is filled with valid values, fill the field space structure with plot numbers by row (column), rep following rep until all plot numbers are assigned to field positions. The View Field Plan button produces a graphic for each trial instance with a spin box to select a particular trial and Next and back buttons to step through the trial instances. The graphic should show a grid of the field with double bold (or coloured) edges outlining reps and single bold (or another colour) outlining sub-blocks. Show entry and treatment labels with a tool tip on each plot. Warn users if reps occupy incomplete rows (columns) (not too serious) or if any sub-blocks occupy more than one row (column) (possibly serious). Allow users to return to step 9a and specify a different field size or filling pattern to correct these problems. Also fill the Row in Layout and Column in layout labels with the row and column numbers where the plots have been allocated.

The Field Plan Report could be an excel book with one sheet for each instance. Each plot could be represented by several rows of cells in a column. Each cell will contain one of the plot labels. By default we could start with two cells on for Plot Number and one for Entry Number, but we could allow the user to select any of the labels of plot or entry which would add extra cells to the plot. Each plot should have solid borders, and each block and rep different border styles or thickness.

Example of a Fiend Plan Report with Plot number, Entry number and Designation as labels.

For later versions. Allow users to specify labels to be added to the view of the field, either by writing labels on the plan or by allowing users to specify colour codes for label values (eg red for high fertilizer plots and green for low).


3.10. Sampling Schemes: For later versions. Frequently data is collected from multiple sub-samples of field plots. This can be handled in two ways. Firstly by specifying multiple variates for a particular trait in the template, each with a different method indicating the sample number, and perhaps one with a method indicating a computation based on the sub-samples (eg average) or secondly by specifying factors in the template which define one or more sampling schemes. In the first case the fieldbook will have parallel columns for each sample record and no further user specification is required here. However, in the second case the fieldbook will have multiple sample rows for each plot and it is common to collect data on separate sheets for traits using different sampling schemes. If there are factors with property Sampling Unit then the application must ask the user to specify the levels of each factor and any associated labels by:
Assuming they have scale Nested Number, simply ask the user for the number of levels of each sampling factor and

  • a.  If they have labels then interrogate the user for levels of each label by Table Filling (5a), File Import (5b) or Data Entry (5d).
  • b.  Sampling factors may have labels indicating random selection of sampling units (scale Random Number) so all the level specification techniques should allow the specification of these random levels. In particular, the Table Filling option should allow the generation of random numbers within specified ranges, without repetition, but repeated plot by plot, instance after instance.


3.11. Trait Specification: There are several steps in specifying traits for the fieldbook:

  • a.  Provide a table of the constants from the template and ask the user to select those to appear in the fieldbook (it would be good to allow the user to specify new ones here, but in a later version). We need a column in this list to indicate whether the constants apply to the whole Study or to each Trail Instance as specified in the template.
  • b.  Provide a table of the variates and allow the user to select those to appear in the fieldbook. (Again the ability to edit the table would be useful in a later version). In this table of variates there needs to be a column indicating the sampling level for the trait, either the name of the Field Plot Factor or the name of one of the Sampling Unit factors as specified in the template.

    3.12. Save Fielbook: Save the datasets defined by the fieldbook into the Study creating Factors, Labels, Levels, Representations, Observation Units, and Variates. There are possibly four datasets: A study dataset, A trial Instance dataset, A field plot dataset and one or more sampling unit datasets.
  • a.  For the study dataset you simply need to set up a vector of Study Constant Variables. Then add the study factors and labels to the FACTOR and LABELS tables, Add the Study Constant variables to the VARIABLES tables, at the STUDY Effect and representation and add on OUNIT to the OUNITS table.
  • b.  For the Trial Instance Dataset, you need to create a table with first column headed by the Trial Instance Factor and rows numbered 1,2, 3 .. to the number of instances. Then add columns for all the Trial Instance Labels with specified values or blanks if they are to be filled in when the trial is implemented. Then follow with columns of the Trial Instance Constants. Then load the trial Instance Factor and labels with levels where known, add the Trial Instance Constants to the VARIATES table update the EFFECTS and Representations and add one OUNIT for each trial instance.
  • c.  For the field plot dataset, the first thing to do is set up a Measurements Table which must be constructed from the design for each trial instance.
    • First find the number of plots in each trial instance. (In version 1 we are assuming each instance has the same design so they will have the same number of plots). The number of plots in trial i (Pi) is the "number of entries in trial i" X "number of other treatment factor combinations in trial i" X "number of replications in trial i". Construct a table where the first column is headed by the Trial Instance Factor, and it has one row for each plot in each trial instance with the number of the instance in column 1 ie P1 1s, P2 2s and so on. You can add columns for each of the Trial Conditions with the appropriate values or blanks if they have not been specified.
    • Next construct unique plot numbers for each Trial Instance. First find k = Log10(Int(Max(P1, P2, ...Pm)))+1 then the plot number for plot j in trial instance i, pij, is i*10**k +j. (This is the meaning of the 'Nested Number' scale). These numbers are entered in the next column of the workspace table under the heading of the Field Plot Factor. Add columns for all the design parameters by linking the plot number (j) to the design table for trial instance i as described in 8a above - using the label names from the template.
    • Add the factors, labels, levels, variates, effects and one OUNIT for each plot in each trial instance.


4. The Export Fieldbook Interface

One reason to separate the Create Fieldbook function from the Export Fieldbook function is that users may wish to export different parts of the fieldbook at different times, for different data collectors and on different media or data collection equipment. With the above Fieldbook specification we could already output treatment keys, field plans and data entry sheets (ordered by plot number or row/column serpentine) for different site, sample and trait subsets using the following steps:

4.1. Field Plans and Plot Labels

  • a. Users will want to export Field Plans in various formats to assist with trial implementation and data collection.
  • b. Users will also need to design plot labels at this time with or without barcoding. For barcodes the unique keys are Crop, UserID, StudyID, Field Plot Level and Sampling Unit level (if relevant). This can be shortened to Crop, UserID, OUnitID for efficient database interaction.

4.2. Treatment Keys

  • a. Users will want to export treatment keys to assist with trial implementation

  • b. Treatment labels are also needed for seed packets etc. These should contain the identification of the treatment level and the plot (or sampling unit) to which it is to be applied. If plots are barcoded, a matching barcode on the treatment label could be used to verify correct application.

4.3. Data Collection Forms

  • a. Specify Variates (traits) to be measured for the current data collection form. Select from the list of all variates in the Study (default all). Variates are linked to different sampling levels (datasets) - Study, Trial Instance, Field Plots or Sampling Schemes. Variates also carry with them specifications of data type (numeric or character) and scale which indicates continuous or discrete as well as allowable ranges or classes for data values. The application can group the variates by sampling level (dataset). The sampling units (rows of the dataset) are indexed by the factors defining the sampling level. For each group request the user to complete the following steps:
  • b. Specify Labels: Allow the user to choose any labels of the factors defining the dataset to be included on the data collection form (for information or data capture). Labels also carry with them specifications of data type (numeric or character) and scale which indicates allowable ranges or classes for data values.
  • c. Specify Subsets: For each dataset indicate levels of the defining factors to be included or excluded for the data collection form.
  • d. Specify existing data: Users may want to include previously collected data in the data collection form. This requires a query interface to get that data from the same or different studies and then merge it by factor level with the data collection records, repeating or aggregating values as appropriate.
  • e. Specify Groups: Indicate factors whose level combinations define groups for which separate forms should be constructed.
  • f. Output Forms: For each group output the data collection forms.

4.4. Prepare Harvest List

If samples are to be taken from the field trial a Harvest list (and labels) may need to be prepared. A menu item - Harvest List should be available once the Fieldbook has been saved in the database. This item should launch a menu page similar to the Advance Nursery menu item in the Nursery manager with the following fields:

  • a. Breeding Method: This should have two items, a Radio Button and a Text Box. The radio Button indicates whether the same breeding method is applied to all selected plots or whether a different method is to be applied to each plot. The Text Box allows the user to select the breeding method for all plots, or the variate which specifies the method for each plot. If there is a variate with property BREEDING METHOD indicating the DBID of the method to be applied on each plot then the default for the button is "Different method for each plot" and the name of the variate is shown in the Text Box. If a breeding method is specified through a Condition then this is the method that should be selected in the Breeding Method Text Box. Otherwise the user should be able to select a method but for field trials the defauld should be SEED INCREASE. If there is no variate with the Property BREEDING METHOD and scale DBID then the user cannot select "Different method for each plot" and a message should be displayed if the user tries.
  • b. Plot Selection: Again there should be two items. A radio button indicating if the same number of samples are taken from all plots or not, and a Text Box with the number of samples per plot or the name of the variate with property PLANTS SELECTED if it exists in the trial. If a PLANTS SELECTED variate exists then the default should be "Different number of samples from each plot" for the radio button and the name of the PLANTS SELECTED variate for the Text box, if not the defaults should be "Select same number of samples from all plots" and the text "1".
  • c. Breeding Location: This should be a text box allowing selection of the breeding location. The default should be the Trial Location if it is specified through a Constant, or the Trial Factor is it is a multi-location trial.
  • d. Breeding Date: This should be a text box allowing selection of a breeding date. The default should be set to the Harvest date of the Trial is it is supplied through a Condition or Constant, or the Harvest date label of Trial Instance if it is available.
  • e. Naming Convention: This should be a pick list of available Naming Conventions. We could start with four different naming conventions. For the moment we could call these: Nursery-Plot, CIMMYT Wheat, CIMMYT Maize, IRRI Rice. The Nursery-Plot convention simply names the advanced lines with the source Nursery name and plot number. The others are all familiar to the developers. The default should run according to the crop, or some configuration parameter.

Harvest List Form with default values for a Trial with a BREEDING METHOD variate (called BMETHOD) specifying a breeding Method ID for each plot and a PLANTS SELECTED variate (called PLANTS HARVESTED) specifying the number of lines or the number of the plant (according to its scale) selected from each plot. (The values could also have been entered in the form by the user).

Harvest List Form with default values for a Trial with a BREEDING METHOD condition with value being the Method ID for single plant selection and a PLANTS SELECTED constant with scale Number and value 3. (The values could also have been entered in the form by the user).

Once this form is filled (which should be by default in most cases) the user should select OK. The a Create List window should appear asking for a list folder and name, and a list description. The List Type should be "Harvest", the list user and date should be easily filled by default. On Ok again, each selected plot should be processed with new germplasm added according to the method and naming convention and the germplasm also added to the new List. In all cases of Trials the methods should be derivative or maintenance (the Crossing Manager will handle generative methods) and the source GID is the GID of the germplasm on the plot being processed.


4.5. Updating Inventory

Once the Harvest List has been produced, a new menu item, "Update Inventory" should be available. This function is actually part of the Seed Inventory Manager application but should be available from the Nursery manager and the Fieldbook. It should open a form with the following fields:

  • a. Harvest List: a text box with the name of the harvest list selected through a search in the List Names table.
  • b. Seed Storage Location: look up LOCATIONS filtered on "Seed Storage Locations"
  • c. Seed Storage Units: look up the scales of the SEED STOCK property (gms, number, packets etc). If there is a Nursery condition, constant or variate with property SEED AMOUNT then the default for this should be the scale of that variate.

The Process Inventory function should then create IMS LOT records for each new seed stock (each record of the harvest list).

The amount of deposit could be supplied by a condition, constant or variate with property SEED AMOUNT. If this is a condition or constant, then its value supplied the deposit value for each entry in the harvest list. This could be user where a fixed amount of seed is saved, say 50gms for each line, or where a fixed unit is saved - say 1 packet. When there is only one sample from each selected plot (as with bulk harvesting), then the amount for each sample could be supplied via a variate with property SEED AMOUNT. If a SEED AMOUNT condition, constant or variate is present and contains a positive value then this is the deposit amount recorded in the TRNQTY field of the deposit TRANSACTION record. If this variate is absent or contains a null value then no deposit transaction record should be created and these must be added later when the quantities are known.

Update Seed Inventory Form with default values for a nursery without a SEED AMOUNT variable

Update Seed Inventory Form with default values for a nursery with a SEED AMOUNT condition or constant having scale gms and value 50

Update Seed Inventory Form with default values for a nursery with a SEED AMOUNT variate having scale gms

The Update Inventory function should then produce a report in a template format with information on each LOT and a column for Quantity which will either be blank or contain the quantities specified by the SEED AMOUNT Variable. This report should go to the seed store manager who will add or verify the quantities and commit them to the inventory. This report should go to the seed store manager who will add or verify the quantities and commit them to the inventory. The List and Supplier names and IDs should be available from the LIST NAME record of the Harvest List.

Template for the Seed Inventory Report:

Again we would not like users to Update the inventory multiple times for a particular Nursery, so we could again add a Condition to the Nursery with Property Inventory and value 'Updated' to indicate that it has been completed.

Adaptavist Theme Builder (3.3.3-conf210) Powered by Atlassian Confluence 2.10.3, the Enterprise Wiki.
Free theme builder license