Some of the SolarNexus template variables described in the Available Variables list on the template editor screen are objects containing sub-properties. For example, the salesperson variable is a User object with properties corresponding to the project sales owner's name, phone, email, etc.

This article describes each type of SolarNexus template object and the properties it contains.

To output an object-type variable in a template, use the syntax {{object.property}}. For example, to output the sales owner's full name, write {{salesperson.full_name}}.

Object Reference

• Date
• Milestone
• User
• Solution Element
• Item
• Finance Option
• PV Array
• PV Inverter

Date

Milestone

For milestones, use the name of the name of the milestone before completion as the object's name. So for example, if your scheduled milestone is "Sales Appointment," you would use "sales_appointment" as the object. If you wanted to provide the scheduled start date and time of the Sales Appointment in a paragraph in your template, that could be:

<p>{{sales_appointment.start_at.short_date}} at {{sales_appointment.start_at.time}}</p>

For scheduled milestones only:

User

Solution Element (aka "Services")

The user interface refers to Services, but the associated template variables use the term "solution_elements." Solution_elements is an array of solution_element objects containing all solution elements, regardless of type, ordered by user-specified position. Each solution_element object has:

• type - The top level categories of elements. Its a predefined enumeration of these values: PV System, Storage System, Efficiency Measure, and General Service
• subtype - This is known as the "Service Type" in the SolarNexus UI. It is a set of Admin defined values
• name - This is the user provided name for any "General Element" or "Efficiency Measure" type element. PV and storage element types are auto-named "PV System" and "Storage System"
• description - the short description of the scope of work for this solution element.
• items - items is an array of product items in the solution_element, each with:
  • type (REMOVED)
  • category - This is the Company Catalog's product category
  • sub-category - This is the subcategory within the Company Catalog where the product resides. Note that some Catalog categories do note have subcategories.
  • provider - In case of materials/products, this is the manufacturer. But items can also represent services or labor, so provider covers both.
  • model_name - Product model number, or the name of the service/labor item.
  • quantity
  • img_url - outputs the url for the first image associated with the item (i.e. a product in the Company Catalog can have an image uploaded).
• cost object properties, a solution_element's cost object includes:
  • subtotal
  • adjusted_subtotal
  • preliminary_contract_price
  • unit_price
  • cost_item_groups. Each cost item group object has:
    • sub_total_price
    • name
    • description
    • optional cost_items (if enabled for the group). Each cost item object has:
      • provider
      • model_name
      • variation
      • quantity
      • unit
      • cost
• plus any other properties specific to the element type
• EE element-specific values:
  • electric_savings_annual
  • electric_savings_annual_percent
  • non-electric_savings_annual
  • non-electric_savings_annual_percent

We also provide the following objects that define specific solution elements, or subsets of solution elements:

• Existing ee_measures object variable becomes a subset of solution_elements of type "Efficiency Measure."
• general_solution_elements is subset of solution_elements of type "General Service"
• pv_solution_element object only includes properties of the one and only one PV system element (type = "PV System")
• storage_solution_element object only includes properties of the one and only one storage system element (type = "Storage System")

Object name is solution_element. Also have special specific solution_elements: pv_solution_element and storage_solution_element. There is a collection (solution_elements) that you can loop through. And special solution_element collections that are a subset of elements: ee_measures, and general_solution_elements.

Item

Object is named item, an object within a solution_element. (for item in solution_element.items)

Finance Option

Object is named fin_opt. An analysis can generate an array of up to 3 finance option objects. There is a collection (fin_opts) that you can loop through.

PV Array

Used in the pv_arrays array variable.

PV Inverter

 Used in the pv_inverters array variable

Using Objects in Liquid Directives

Object Indices

The objects in a collection have an index from 0, 1, 2 (first, second, third position)

It’s OK to reference an indexed object in a conditional directive {% %}, but not in a simple evaluation {{ }}. For example, You can do this:

{% assign loan_one.name = fin_opt_loans[0].name %}
loan 1: {{loan_one.name}}

But not this:

loan 1: {{fin_opt_loans[0].name}}

Due to the way the template is parsed during evaluation, you can’t reference a non-existent array index inside {{ }}, even if that is enclosed within an {% if %} that would prevent it from being evaluated. I think it parses all the expressions in {{ }} prior to evaluating the conditionals, and in the process of parsing an expression involving an array, it tries to access the referenced index, which is where it’s failing.

Assigning fin_opt_loans[0] to fin_opt_pre allows it to work because it’s ok to reference object properties inside of {{ }} even if that object might not exist. When initially parsing that expression, it doesn’t check if the object exists.