User Guide
Revised: January, 2006
Revised: Kamloops TSO March 2011
Version 1.1
Genus ‘Life of a Block’ Guide
FILENAME: GENUS Life of a Block.doc
/ User Guide - GENUS‘The Life of a Block’
Document Change Control
Version / Date of Issue / Author(s) / Brief Description of Change1.0 / Jan 30, 2006 / Jill Robinson / Original document
1.1 / March 3, 2011 / Devona Hay / Updated screen captures
Table of Contents
Planning Stage 5
1) Creating a Block in Genus 6
2) Creating a Licence in Genus 8
3) Creating a Cut Permit Under a New Licence 10
4) Create a Mark Under the New Licence or CP 11
5) Moving a Block to a New Licence 13
6) Linking Spatial Data in Genus 15
7) Create SU Layer 18
8) Adding Ecology Data 19
9) Adding Nav_L Spatial Data 20
10) Adding a Nav_P Spatial Data 20
11) FTA Submission 20
Post Harvest 21
12) Results Submissions 21
Life of a Block Activity Checklist 23
Purpose:
This guide reviews the business logic to managing Cut Block data within Genus. It is not intended to explain how the program works and users should refer to the Genus User Guides for that.
Intended Audience:
This is intended for any Field Team Genus users who have already been trained on how to use the program. This guide attempts to answer what to track in the program for Cut Blocks.
Prerequisite:
Technical working knowledge of the Genus program.
Reference:
Best Practice:
Use the Checklist at the back of this guide for tracking cut block data throughout the life of a block in Genus.
Planning Stage
Overview: Block data should be created in Genus as soon as the block is proposed and it should be linked to a tabular record. Blocks should be stored in a Genus planning bucket during the first stage of their life. Blocks may be renamed or moved at this point, but should not be duplicated (i.e. when the block is assigned to a TSL, the block in the planning bucket must be moved rather than a new block being created under the TSL).
A UBI is created for tracking cost. Best Practice is to assign the UBI when you are confident about moving forward with development.
The UBI should only be created under the direction of contract coordinator. (http://www.for.gov.bc.ca/ftp/HBT/gov_internal/!publish/genus/manuals/UBI_Generator.pdf )
Once a UBI is assigned to a block, costs can then be allocated to the UBI. Once there are costs associated with the UBI, blocks should only be flagged for deletion following the deletion process identified in the link below and should be identified to the contract coordinator. Occasionally blocks may be deleted after a UBI is created but this should be an exception not he norm. (http://www.for.gov.bc.ca/ftp/HBT/gov_internal/!publish/genus/manuals/guides/Master_Deletion_Procedure_Process.pdf ).
1) Creating a Block in Genus
Step 1: Right click on the Mark in the appropriate Planning bucket in the Navigation Tree in Cengea Resources to which the planned block will be added. Select “New Cut Block”.
Note: the planning buckets are put in at the TSL level and begin with an “!” (i.e. !KAFinney). The Licence level of the tree is most often used to group the planned blocks by operating areas or some other administrative unit.
The following block naming convention should be used:
Blocks should be named by combining the operating area code in which the block resides with either the last 3 digits of the UBI for that block, or the next available number from a sequential numeric list (if one exists for your field team). Currently only 100MH uses this numeric system, but other field teams may want to consider adopting this instead of using the UBI. There may be a situation where you don’t want to create a UBI for a block at the early stages of planning. Consider this and decide on one convention or the other. The idea is to have unique block names that indicate the general location of the cut block. This name should follow the block for its lifetime, and should not be changed once assigned. If you are unsure what the operating area code is for an operating area, the Operating Area dropdown on the block details screen lists all the operating areas for the TSO and their codes.
Examples: Block in Roche Lake operating area would be named: RO6BE where RO represents Roche Lake and the last 3 digits of the block’s UBI is 6BE
Block in Rayfield operating area in 100 MH would be named: RA1015 where RA represents Rayfield and the 1015 is the next available number from the block number list.
Step 2: Enter the required data (mandatory items are shaded in green), completing the form that appears when you create a new block. If the operating area is not known, then a generic operating area (eg. KX – Kamloops Non Chart ) should be selected as this field is critical for report filtering in Genus.
2) Creating a Licence in Genus
After the block layout has been completed in the field, an FTA (Forest Tenure Administration) application for a licence is necessary. This process is done within the FTA program and then the assigned TSL # will be created in Genus.
Step 1: In the Navigator Tree, click the appropriate Management Unit. Select ‘New Licence’ and a ‘Licence – New Record’ form will appear.
Step 2: Complete the Licence form , with all mandatory fields shaded in green. The ‘Licence ID’ is entered as it is for the approved FTA licence number.
Note: The “Permits Exist w/in Licence?” flag is no longer critical. This will default to being un-checked, but most TSLs do not have CPs and so this must be unchecked except in those cases where there really will be CPs. The next steps on creating CPs and TimberMarks must not be started if this flag is not correctly set!
3) Creating a Cut Permit Under a New Licence
Note: Only required if there is a CP for the sale.
The Cut Permit is created only if the Licence has cutting permits. If there are no CPs for the TSL (as is the case for most of them) then Genus will create a virtual CP automatically when the TimberMark is added. This CP will be named “APR-TimberMark” and can be ignored except for appraisals. If CPs do exist follow the steps below to create them.
Note: if the “Permits Exist w/in Licence?” flag is not set correctly in the TSL as noted above, the creation of the virtual CP will not work, or the option to create a real CP will not be available.
Step 1: Right click on new Licence in the Navigator Tree and select New Cut Permit.
Step 2: Enter the data on the Cut Permit form.
4) Create a Mark Under the New Licence or CP
Step 1: In the case where there are no CPs, right click on new Licence in the Navigator Tree, selecting ‘New Mark’. If a real CP has been created, then right click on the CP and not on the Licence.
Step 2: Complete the new Mark form, using the FTA approved Licence number (without the ‘A’ prefix) as the ‘Mark ID’.
5) Moving a Block to a New Licence
Once the TSL, CP (if applicable) and TimberMark have been created, the Blocks can be moved from the ‘Planning bucket’, rather than creating a duplicate block entry. Do not add a new block where it exists in a planning bucket. The name of the block may change, once it has been moved. The block will be tracked by that block ID in FTA and Results from now on.
To move a block from a planning bucket to the new Licence/CP/TM, open the block form and go to the allocation tab. Then re-assign the block to the new location. This will automatically move the block in the NavTree. Then rename the block as required. Note that the UBI will remain the same, so if any layout costs have been assessed to the block they will still be in the right account.
6) Linking Spatial Data in Genus
At this point the layout of the block should be complete and the spatial data is ready to add or has been added by the GIS staff or contractor. The block needs to be spatially defined first.
Step 1: Open map window by clicking the globe icon at the top left side of the Genus Screen.
Step 2: Make sure you have ‘Test Editing Template’ selected when linking or building spatial data for Block. (Note: for new blocks the ortho photo will not obviously show the block, but it may show other features (roads, creeks, etc.) that will help ensure that the block is coming in correctly).
Note: Double Click on the template to make it active.
Step 4: From the Block Detail tab, click on the “Digitize New” button to build the block boundary from the contractor data, or change the button to “Link Map” and then click to link the spatial data that has already been added.
Once the block is linked or digitized, the Dig flag will be checked and the area should be updated from the spatial.
Note: It is critical for all new blocks that the gross area of the block be allowed to update from the spatial data. FTA submissions do not read the database ha but only read the hectares from the spatial data!
7) Create SU Layer
The Site Plan should be complete at this point and the SUs should be added into Genus if the contractor did not already add it in directly during their contract. Data is added for each productive and non-productive SU (Standard Unit), using a standard naming convention, for consistency. Then the spatial must be added for each SU. This is done the same way as it was for the block.
Note: If the SP was developed outside of Genus there may be a discrepancy between the recorded ha and the spatial ha. This is usually done when the PAS being calculated with site deg worksheets instead of being calculated spatially and then recorded. It is very important that the recorded ha match the spatial ha or else there will be issues with reporting throughout the life of the block as future submissions will always attempt to read the ha from the spatial and will need constant adjustment. The best practice is to fix it up front.
8) Adding Ecology Data
Ecology data is added at this point and linked to the SUs. Use the gross area of the block, for attribute and spatial data rather than the NAR.
9) Adding Nav_L Spatial Data
The TSL needs to be spatially defined for FTA submissions. This is done on the Nav_L (NavTree-Licence) layer in the map window. Once all the blocks have been spatially defined, build a Nav_L layer from them. All the blocks under this TSL need to be copied onto the Nav_L.
Open the Licence and digitize as per other layers.
10) Adding a Nav_P Spatial Data
Note: Only required if there is a CP.
If there are real cutting permits under the TSL, they will also need to be spatially defined for the FTA submission. This data is put on the Nav_P (NavTree-Permit) layer. Once all the blocks have been spatially defined, build a Nav_P layer from them. All the blocks under each CP need to be copied onto the Nav_P.
Open the CP and digitize as per other layers.
11) FTA Submission
Once all the layout data is in for a Block and the Spatial data has been created for each layer (Block, Nav_L and Nav_P if required) the FTA submission can be made. This will create the block in the FTA system.
Make sure the gross area and Merch Area are filled in under the Allocation tab for block. The gross area must agree with the spatial area for the block. All area under the block is included in the gross. This means that there are no external reserves. They will all be included in the tenure, even if they are physically distinct from the rest of the block.
Note: the Merch Area cannot exceed the Gross area, so if amendments are being done, both areas should be synchronized.
The FTA submission can now be made using Genus Exchange. Once the FTA submission has been approved the block should be ready for sale. If the block is not sold for any reason but is moved to a new TSL for resale, then a note should be made in the block comments and the block should be moved to the new TSL so that the UBI will not change and the data will not need to be re-entered under a new block.
Post Harvest
After the block has been harvested, post harvest data is required to prepare the block for the handoff to silviculture.
Please refer to the Harvest Reporting document (\\mitten.dmz\ftp\tka\mof_internal\!publish\genus\sop user guide\genus resources\block module\Harvest_reporting.pdf )
12) Results Submissions
Now that the block harvesting is complete, the Results submissions should be done. The Opening Definition will establish the block in Results. Then the Disturbance will kick on the reforestation commitments. Along with that, there needs to be a Forest Cover submission to mark the block as NSR.
See the exchange submission guides for how the submissions are created and submitted. If all the data is entered as above, the submissions will create correctly.
Step 1: Opening Definition:
The opening definition submits the spatial data for the block boundary and the productive SUs. Each SU must have a standards ID that will be submitted. The stocking details are NOT submitted, rather Results reads the standards that have been approved for the standards ID and assumes that Genus has the same definition. This should be submitted as soon as harvest is complete and the road locations have been adjusted for ABR.
Step 2: Disturbance:
The disturbance submits the spatial data from the silviculture disturbance layer and the harvest dates from the depletion layer. This should be submitted with the opening definition.