Glossary of Terms and System Rules

Overview

The terms and concepts used in the Dev & Hold ERP system are specific to the Large-Scale solar industry and the Develop and Hold model specifically. This Glossary defines the Terms and related Rules and Processes used in the software.

Project Management Module

Hierarchy - The system is organized around a hierarchy of Portfolios, Projects, Sites, Milestones and Tasks

Portfolios - are simply a way to classify/organize a group of Projects. They are typically used to isolate Early Stage, Active or Financial Forecast Projects. Projects can be moved between Portfolios at any time

Projects are a collection of Sites. Additional Sites may be added to a Project or removed from a Project and added to another Project at any time. A Project can be opened without a Site. The Sites can be opened later.

Sites must always be initiated with a Project. A Site can be moved to a different Project at any time.

Milestones are used as an outline for the work to be completed on a Site.

1. Milestones can be a Single, Parent or Child Milestone.
2. Parent Milestones can only be a collection of Child Milestones and have no direct Tasks.
3. The Status, Schedule and cost of the Parent Milestone is always derived from the Child Milestones
4. Status is either Not Started, In Process or Complete
5. A Child Milestone cannot have its own Child Milestones. Only one level of Child Milestones.
6. The Status, Schedule and Cost of a Direct or Child Milestones are derived from its related Tasks.
7. A Parent Milestone cannot be a Child of another Milestone; it cannot have a Parent Milestone.

Project Management Plan Templates (PMPT) - are Sites with a structure of Milestones and Tasks. The purpose is to be able to quickly add a Working Site to a Working Project with a company standardized structure already in place.

1. A company can have as many Project Management PlanTemplate Sites as they would like.
2. Whatever is on the Project Management Plan Template Site, Documents, Milestones, Child Milestones, Task, Parent Task, Predecessors, Successors Status, Assigned Outside Partners, Start Date, Duration, End Date, Cost Estimate) will roll into the new Working Site when it is initialized.
3. A Working Site can only be initialized once.
4. Once a Working Site is Initialized, it can only be changed manually by the user, not by Initializing the Working Site again.
5. If the Project Management Plan Template Site is revised, it will have no impact on the preexisting Working Sites.
6. If a Working Site is revised, it will have no impact on the Project Management Plan Template Site.

Catalog Tasks and Milestones

1. Only Tasks and Milestones residing in the Catalog can be added to a Project Management Template Site or a Working Site.The purpose is to control the naming conventions and the use of Tasks and Milestones.
2. Tasks and Milestones in the Catalog are not designated as a Parent or a Child.
3. They only require a name designated by the user.The names can be edited at the Catalog level.
4. Editing the name on a Catalog Task or Milestone does not impact the Project Management PlanTemplate or Working Sites it was used on.

Tasks are where all the work is done. Tasks can be a Single, Parent or Child Task.

1. The only way to add a Task is through a Milestone..All Tasks must relate to a Child Milestone or a Single Milestone.
2. A Task can be moved from one Milestone to another.
3. A Parent Task can only be a collection of Child Tasks.
4. The Status, Schedule and Cost of the Parent Task is derived from its Child Tasks.
5. Status can be Not Started, In Process or Complete..
6. A Parent Task cannot have its own Parent; it cannot be a Child Task.
7. A Child Task can be moved from one Parent Task to another.
8. All Parent or Single Tasks must relate to a Single or Child Milestone.

Predecessors and Successors determine the sequence of work to be completed on the Site.

1. A Predecessor is a Task that needs to be completed before another Task can begin.
2. A Task that has a Predecessor is called a Successor.
3. A Successor Task CANNOT start before the Predecessor Task is Completed. If the user wants to start a Successor Task before the Predecessor Task is completed, the Predecessor/Successor relationship needs to be broken first.
4. A Predecessor is defined in the Task that comes after it, called the Successor. For example, If “Task B” cannot be started until “Task A” is completed, “Task A” is the Predecessor and “Task B" is the Successor. To create this relationship, the user edits the record for “Task B” (the Successor) and defines “Task A" as its Predecessor.
5. A Parent Task can be a Predecessor. A Child Task cannot be a Successor of its Parent Task and a Parent Task cannot be a Predecessor of its Child Task.
6. The system defines the Successor, not the user.
7. A Task can have any number of Predecessors.

Date Estimates.are used to define the Expected Start Date, Duration and Expected End Date.

1. Original Expected Start Dates can be set as past present or future.
2. The Current Expected Start Date can never be older than today's date. (i.e. If the Original Expected Start Date was for yesterday and the Task was not started , the system will change the Current Expected Start Date to today).
3. All manual changes to Expected Starts Dates, End Dates or Durations will be saved by the system. Changes made by the system to the Current Expected Start Date will not be saved.
4. If all Predecessors are completed or expected to be completed before the Manually Generated Current Expected Start Date of the Successor Task, the System will maintain the Manually Generated Start Date.(e.g.Task B has a Manually Generated Start Date of 12/31/2023 and Task A the Predecessor to Task B is expected to be completed on 12/15/2023. The system will keep the 12/31/2023 Expected Start Date for Task B.
5. When a Task is either Started or Completed, the user will fill in the Actual Start Date or the Actual End Date.
6. If the Task is Started and the Actual Start Date is filled in, the system will use the Current Estimated Duration to predict when the Task will be Completed.
7. When the Duration is over, the system will keep moving the Expected End Date forward by one day until the user puts in an Actual End Date or adjusts the Duration or End Date of the Task.
8. When both the Actual Start Date and the Actual End Date are filled in, the system will calculate the Actual Duration.

Cost Estimates are added to Tasks and summarized to predict the cost and timing of costs on the Site.

1. Cost Estimates can be changed as often as the user requires.
2. When a Vendor Bill Line is assigned to the Purchase Order Line that has been assigned to the task, the amount on the Vendor Bill Line will fill in the Actual Cost.
3. Actual Costs can only be updated by Vendor Bill Line Items, not manually by the User
4. The Actual Cost filled in by the Vendor Bill Line will Supersede all Cost Estimates. .
5. Certain Tasks are defined as Field Distribution Tasks to allow for Inventory tracking. This will be covered in the Inventory section.

Teams/Team Members are used to assign a Project, Site, or Task to a particular Team or Team Member for filtering and security purposes.

1. Teams are added to the system as the user requires
2. Team Members are then added and assigned to a Team.
3. All Team Members must be assigned to a Team
4. Team Members/Teams are assigned to their Projects, Sites, Milestones or specific Tasks.
5. Duplicate Teams and Team Member Names are not allowed.
6. Using Team and Team Members is an optional feature
7. The assignments can change as the User requires.
8. Multiple Team Members can be assigned to a specific Project, Site, Milestone or Task.

Utilities & Utility Programs are used to provide information to the Site. (On Project now).

1. Utilities is just a contact form
2. Programs are for memorializing government and utility programs. The information is not used in future calculations.
3. Programs must always be tied to a utility.

Virtual Data Room Module

Documents - can be added to a Portfolio, Project, Site, Task or to a Purchase Order Line, Purchase Order Receipt, or a Vendor Bill Line. All Documents reside at both their Display Location and in the “Virtual Data Room”.

1. Documents are organized by Document Type. The Document Type is assigned to a Display Location of either Portfolio, Project, Site, Task, Purchase Order Line, Purchase Order Receipt or Vendor Bill Line.
2. A Document Name must always have a Document Type.
3. A typical combination set is: Lease Documents (Document Type)/Payment Schedule (Document Name).
4. Document Type/Name combinations cannot be used more than once on a particular Display Location.It is recommended to not use the combination more than once even on different Display Locations.
5. Documents can only be added from the Display Location, not from the Document Data Room.
6. Each Document can carry unlimited revisions.
7. Document Requirement Templates (Document Templates) are a set of Documents grouped together that can be assigned to a Site Display Location and will populate with the initiated Site.

Outside Partner Communication Module

Outside Partners - are “outside users” the company is sharing data with. The Outside Partners will log into the system and only be able to perform very specific actions.The most common Outside Partners are Financing Institutions, Sub Contractors, Independent Engineers and Purchasers of the Project.

1. The same sharing rights can be given to as many Outside Partners as the user requires.
2. Rights can be shared and taken away.
3. Rights can be shared individually or for an entire Project/Site Combination.
4. Documents shared with an Outside Partner are read only and show only the current version.
5. Task rights shared with an Outside Partner can only recommend a change to a Task that can then be approved by the company.
6. Entire Project/Site combinations will be shared with an Outside Partner as read only.

Purchasing Module - Non Inventory

Vendors section is used for setting up the contact information of various vendors. It also allows the control of Vendor information to be used in the API to the companies accounting software.

1. A pre-setup Vendor Type (Category) table is set up first.
2. The section called Site Owner on a Site is picked from the dropdown showing Vendors categorized as Site Owners.

Item Master used to define all “Items” to be purchased as direct Project Expenses or Inventoried.

1. Items must have discrete names. The name can only be used once.
2. Items can be either Inventory or Non Inventory.
3. Once an Item is set up, the Inventory, Non Inventory designation cannot be changed.
4. Items are always a Unit of Measure of Each.
5. Inventory items will require a Container Unit of Measure at the time of writing a Purchase Order.
6. Use of the Inventory and Non Inventory “Items” will be covered separately

Payment Terms used to populate the Purchase Order and the Vendor Bill. It is also used in cash flow forecasting.

1. A user defined description
2. Requires an active numeric field to be used for cash flow forecasting..
3. When the payment term is applied to a Purchase Order or a Vendor Bill, it will be used to forecast actual cash payments.

Purchasing Non Inventory Items - Purchase Orders

1. Purchase Orders are used to begin the purchasing process.
2. Inventory and Non Inventory Purchase Order Lines can be on the same Purchase Order.
3. When an Item goes through the Purchasing Cycle of Purchase Order, Receipt and Vendor Bill, the Actual Cost of the related task will automatically be updated.
4. Actual Costs can only be updated through the Purchasing Cycle, not manually by the User.
5. All Purchase Order numbers, regardless of Inventory or Non Inventory are sequentially assigned by the system (There is only one sequence of Purchase Orders).
6. A Purchase Order can have as many lines as the user requires.
7. Each Purchase Order Line can only have one Item
8. Only one PO line can be assigned to a unique individual Task in the Project/Site/Task combination.
9. If the User needs another Purchase Order Line for a Task, they must set up another Task.
10. Purchase Order Line information also includes an Expected Delivery Date.
11. The Purchase Order line amount will show up as reference information on the Task.
12. Purchase Order Line Quantities and Price can be edited at any time by the user.
13. Documents can be added at the Purchase Order Line level.The Documents will automatically use the Project/Site/Task information.

Purchase Order Line Receipts (Non Inventory)

1. All Purchase Order Lines need to be received when the Service or Product are delivered.
2. A Purchase Order Line Receipt is required to pay an invoice.
3. A Purchase Order Line can have multiple receipts
4. The total receipts cannot exceed the total of the Purchase Order Line. If for some reason the shipment is for more than the Purchase Order Line, the Purchase Order Line needs to be edited to complete the receipt of Items.
5. Purchase Order Lines can be edited at any time as long as the Purchase Order is still open.
6. When all Items on the Purchase Order Line are received, the Purchase Order Line will be marked closed.
7. When all of the Purchase Order Lines on a Purchase Order are closed, the Purchase Order will be marked closed.
8. Purchase Order Receipts will not affect theTask Costs. Task Costs will only be updated by Vendor Bill Payments.
9. Documents can be added at the Purchase Order Line Receipt Level at any time, even if they are closed. The Documents will automatically use the Project/Site/Task information..

Vendor Bill Payments (Non Inventory)

1. Once a Purchase Order Receipt is entered, the user can then apply a Vendor Bill.
2. Vendor Bills can only be applied to a Purchase Order Receipt.
3. Each Vendor Bill Line can only be used for one Purchase Order Receipt.
4. If the Vendor Bill is for multiple receipts, the user will need to apply the same Vendor Bill to multiple receipts..
5. The amount of the Vendor Bill updates the Actual Cost on the related Task.
6. Documents can be added at the Vendor Bill Line Level. The Documents will automatically use the Project/Site/Task information.

Purchasing Module - Inventory

Purchasing Inventory Items Additional Setup. The Inventory section is more complex than the Non Inventory section and requires additional setup.

1. A Warehouse Record is used to track the location of Inventory Items.
2. Unit of Measure is a way to define how Items are packaged. Items are inventoried as Each.
3. They can come in a Box or on a Palette etc. The number of units in each Unit of Measure is used when issuing a Purchase Order.

Purchase Orders (Inventory)

1. Purchase Orders are used to begin the Purchasing Cycle.
2. Inventory and Non Inventory Purchase Order Lines can be on the same Purchase Order.
3. Inventory Costs are entered on the Purchase Order Line and unlike Non Inventory Purchase Orders, they do not impact a Project/Site/Task combination.
4. When an Inventory Item goes through the Purchasing Cycle of Purchase Order, Receipt and Vendor Bill, the Actual Cost for the Inventory Item will be updated.on a First In First Out (FIFO) (See Inventory Section) basis by the Vendor Bill Line
5. The Purchasing Cycle must always start with a Purchase Order
6. Purchase Order numbers are sequentially assigned by the system. All Purchase Orders follow the same sequence regardless of Inventory and Non Inventory.

Purchase Order Lines (Inventory) -

1. A Purchase Order can have as many lines as the user requires.
2. The user selects the Item to be used on the line. Each line can only have one Item.
3. For an Inventory Item,the line is not assigned to a Project/Site/Task combination.
4. The line updates the Inventory “Forecast Report” as an “Open Purchase Order”. It does not update the Site Costs.
5. The Purchase Order Line will define the number of Items (Each) that go into a Container Type . (i.e if a Purchase Order Line has a Container type of Pallette the user will define how many units are on a palette (50). If the user orders 1,000 palettes, they are ordering 50,000 individual (each) units to Inventory).
6. Purchase Order Line quantities and price can be edited by the user at any time as long as the
7. Purchase Order Line is still open.
8. Documents can be added at the Purchase Order Line Level. There is not a Project/Site/Task.

Vendor Bill Payments (Inventory)

1. Once a Purchase Order Receipt is entered, the user can then apply a Vendor Bill.
2. Vendor Bills can only be applied to a Purchase Order Line Receipt.
3. Each Vendor Bill Line can only be used for one Purchase Order Line Receipt.
4. If the Vendor Bill is for multiple Purchase Order Line Receipts, the user will need to apply the same Vendor Bill to multiple Purchase Order Line Receipts.
5. The Vendor Bill Date and Cost amount will update the Inventory Valuation on a (FIFO) basis.
6. Documents can be added at the Vendor Bill Line Item Level.

Inventory Module

Inventory Tracking

1. Inventory is tracked by Item in Units, Dollars, Warehouse Locations and Date of Transaction. Items will go in and out of Inventory.
2. The balance of Inventory at any point in time is important and will be on an Inventory Forecast Report.

Items going into Inventory.

1. Items can only be placed in Inventory through a Purchase Order line, Purchase Order Line Receipt or Vendor Bill Line or through an Inventory Transfer.. Inventory Transfers are discussed separately.
2. An Inventory Purchase Order Line will add to the Forecast of the Inventory Balance on the Expected Delivery Date of the Purchase Order Line using the Quantity and Cost on the Purchase Order Line.
3. When a Purchase Order Line is Received in full or partially, they will be listed in Inventory as Actual and the remainder of the Purchase Order Line will continue as a Forecasted Item.
4. Until a Vendor Bill has been applied to the Purchase Order Line Receipt, the Inventory will not be available for Transfers or Field Distributions
5. When a Vendor Bill is applied to the Purchase Order Line Receipt, the Inventory Cost will be adjusted for the Cost on the Vendor Bill.
6. All Inventory will be carried on a First In First Out (FIFO) basis. Inventory is tracked transaction by transaction.

Items being pulled from Inventory

1. Inventory can be pulled from Inventory as a Field Distribution or a Transfer. Transfers are discussed separately.
2. Inventory Items are distributed to a Task using a concept of Field Distribution.
3. A Task is set as a Field Distribution Task. When the Task is expected to be completed or is marked as completed, the Inventory Forecast will show the Inventory as Field Distributed.
4. A user can have as many Field Distribution Tasks as they require.
5. The Cost Estimate for the Field Distribution Task includes the Inventory Item required for the Task, the Quantity, the user defined Estimated Cost for the Item.
6. Only one Item can be Field Distributed per Task. If the user wants to Field Distribute more than one Item they will need to use a new Field Distribution Task for each Item.
7. For calculating forecasted Inventory Quantities and Values the Cost of the Item supplied by the user will determine the $ value of each Field Distribution Item unit forecasted to be pulled from Inventory.
8. The value of the Quantity pulled from Inventory will be based on a First in First out (FIFO) basis.

Inventory Transfers.

1. Inventory Transfers are to keep track of Transfers of Inventory from one Warehouse location to another.
2. The transaction is always a two sided transaction and the Transfer from and the Transfer to are always equal in both $ and Units
3. Each Transfer can only go from one Warehouse to another. Multiple Transfers from or Transfers to Warehouse locations are not allowed on the same transaction. The user must complete a separate Transfer.
4. A Transfer cannot cause a negative unit value in a Warehouse.
5. The value of the Transfer is based on the FIFO value of the “Transfer From” Warehouse.
6. When the Transfer is complete, total inventory Units and Value will remain unchanged.
7. Inventory Transfers are not forecasted. They are only an actual transaction.

Structured Finance Module

Financing Stages

1. Only one Financing Stage can be available at any time.
2. Each Financing Stage will be triggered based on either a Task being completed or a Milestone being completed.
3. If two Financing Stages are triggered by the same Milestone or Task, the Order of Funding will decide which Stage gets used first, second etc.
4. There can be unlimited Financing Stages.
5. Once a Financing Stage is set up all or any of the variables can be changed at any time.
6. Financing Template - The user will configure combinations of the Financing Stages to develop a Financing Template.
7. Changing Stages in a financing Template will not affect already assigned Financing Templates.
8. The system applies a Financing Template to a Site as the Site is initialized.
9. Loan Cap Type - is a Loan Cap for a group of Sites using a particular loan Financing Template.
10. Financing Stages with the specific Loan Cap Type will be added together and “Capped” by the amount of the Loan Cap.

Financing Stage Capabilities

1. Financing Stages provide for Step up basis, Value of Expense Factor, LTV Factor, Interest Rate, Loan Cap, Trigger Milestone/Task, Replacement Loans and Funding Order.
2. Step Up % (A) - is a % used to increase the Cost (Basis) of the Site for calculating loan funding. Usually used for Tax Equity Stages. This rate is pulled from the Site Metric section on a Site.
3. Value of Expense Factor % iis a % of the total expected cost of the Project available for funding.
4. Loan Cap Type - is a funding cap on either one Financing Stage or a group of Financing Stages. Loan Cap Types will be defined by the user and have a Loan Cap amount such as $25 Million.
5. Triggers - Task or Milestone that triggers the Financing Stage to be active
6. Replacement stages - The Financing Stage the new Financing Stage replaces if any. (eg. This Construction Stage replaces Development Loan).
7. Order of Funding - If there are multiple Financing Stages open at the same time, the Order of Funding dictates how they are funded (e.g. Financing Stage 4 and Financing Stage 5 are open at the same time. Financing Stage 4 funds completely before Financing Stage 5 is funded. Financing Stage 4 will stay fully funded until a future Financing Stage (Financing Stage 6) replaces it).

Financial Planning Module

Post Construction Projections

1. Once a Project reaches a certain Milestone (Designated by the user as “Placed in Service”), the Project is turned on and generates Site Revenue on a continuous basis.
2. There are also Site Operating Expenses associated with the annual upkeep of the Project.
3. The useful life of each Project is set by the user.
4. The Start Date of the Post Construction Projections each begin at a company defined Milestone designated as “Placed in Service”.
5. Only one Placed in Service Milestone per site.
6. The Actual Start Date of the Projections will be based on the Actual or Estimated End Date of the Placed in Service Milestone..
7. Site Specific Fields are in the Site Metrics & Parcels section. The fields are used as a basis for the Post Construction Projections

Revenue and Operating Expenses Categories

1. Categories designated as either Revenue Type or Expense.Type.
2. Revenue Types will add to the result and Expense Types will subtract from the result.
3. Values in Revenue Types and Expense Types cannot be negative.
4. Revenue & Expense Categories define the Revenues and Expenses associated with the site and are User Defined. Such as LMI Revenue or Lease Expense.
5. A Revenue and Operating Expense Category must always be associated with a Revenue or Expense Type
6. A combination of Revenue and Operating Expense Category and Revenue or Expense Type cannot be duplicated.
7. Revenue & Expense Categories are applied to a Site. (Site Name, Type and Category always go together)

Revenue and Operating Expense Category Fields

1. Category is user denied as belonging to Revenue or Expense.
2. Calculation Basis Fields are defined by the system. (Acres, Annual Production, Cost Basis, Fixed Amount, FMV, kWDC) -
3. Start Date Period After (Placed in Service) Milestone. This field defines the number of years after the Placed in Service Milestone is completed. It defaults to 0 meaning the day after the completed Milestone.
4. Number of Periods is how long the Category will continue. It can use a decimal such as 2.5 years
5. Frequency of Occurrence defines how often the category is used. The default is 1, meaning every year. If it is 10, the expense occurs every ten years starting in year 10
6. The period and dates define the timing of the category (e.g. if the Start Period After Milestone is 0, the Number of Periods is 40 and the Frequency of Recurrence is 1, values will appear in the first year following the Completion date of the Placed in Service Milestone and continue for 40 years) (e.g. if the Start Period After Milestone is 5, the Number of Periods is 20 and the Frequency of Recurrence is 5, values will appear in the 6th year after the Completion date of the Placed in Service Milestone and recur every 5 years until year 20. A total of 4 times).
7. Expenses and Revenue using the Fixed Amount Calculation Basis can be designated as Do not Prorate. This will cause the total fixed amount to be charged to a period even if it is one day.
8. Allocating Revenues and Expenses is based on the percent of the Placed in Service Milestone End Date and the remaining days in the year. A 365 day basis is used.
9. The factors of Site Degradation is applied to the Annual Production every year
10. Forward Curves are applied to Costs and Revenues every year starting in year 1 even if the actual Revenue or Expense is not used until a future period.
11. The system assumes all $ value items are in “Today’s Dollars”.
12. FMV Degradation is applied to the Fair Market Value of the project from day one.

Forward Curve Types

1. Forward Curve Type amounts can go out as far in the future as the user requires.
2. Forward Curve Types are given a name and the fields are expressed as an annual %
3. Forward Curve Types are typically the same % for each year in the Forward Curve Type, but they can vary by year as the user requires.

Actual Revenue and operating Expenses

1. At the end of every year, the current category forecast for that year is rolled into an actual record for analysis purposes.
2. The user will input the actual amount and the record will show the variances.
3. The actual will be used in the project IRR calculator for that period. If the actual is not updated,
4. The IRR projection for that year will be 0
5. The user will then update the Category forecasts as needed.

Project IRR

IRR Calculation

The system uses the standard IRR formula to calculate IRR

Cash Flow IRR Calculations are as follows:

1. Annual Post Placed in Service Cash Flows
2. Less - Total Current Cost Estimate (in year one after Placed In Service only)
3. Plus - FMV times the Site ITC % (ITC amount) (in year one after Placed In Service only)
4. Plus - The Annual Tax Impact of MACRS Depreciation
5. Less - Pre Placed in Service Interest (in year one after Placed In Service only)
6. Less - Allocation of Fees (in year one after Placed In Service only)

Source of IRR Cash Flow Data

1. Annual Post Placed in Service Cash Flows are calculated in a Dashboard report
2. Total Current Cost Estimate is pulled directly from the Site
3. ITC % is defined by the user per Site in the Site Metrics section
4. FMV is calculated on the Site as Step up % times Total Current Cost Estimate
5. MACRS impact is calculated per full year and half year convention.
6. Tax Rates are defined by the user as a Global Systems Option
7. Expected Pre Placed in Service Interest is calculated in a report based on interest from the Financing Stages.
8. When the Project reaches “System Placed in Service” the Expected Interest is no longer calculated and the user will update the Actual Interest in the Site Metrics section
9. Allocation of Fees are input in the Site Metrics section of the Site