Hi,

The Haystack Labs working group has developed the below draft proposal for universal equipment and date related attributes.

Please let us know what you think! Are there any additional related tags that we should try to add in this pass?

Universal equipment attributes

manufacturer: The company that produced the equip.

modelName: A non-unique name identifier to describe the characteristics of an equip that is assigned by the equip manufacturer.

modelNumber: A non-unique number identifier to describe the characteristics of an equip that is assigned by the equip manufacturer.

serialNumber: A unique number identifier to describe an equip that is assigned by the equip manufacturer.

orderNumber: A unique identifier assigned by the vendor that describes how the equip was purchased. This is also referred to as a Purchase Order Number or PO Number.

vendor: The company which the equip was purchased from.

serviceProvider: The company responsible for the active Service Level Agreement (SLA) on the equip.

Date related attributes

manufactureDate: The date that the equip was produced by the manufacturer.

installDate: The date that the equip was installed at the site.

inServiceDate: The date that the equip was put into service.

warrantyEndDate: The date that the manufacturer warranty of the equip expires.

slaEndDate: The date that the active Service Level Agreement (SLA) by the serviceProvider expires.

Thanks!

Rick

Hi Rick,

thanks for sharing. That sounds very good to me. I think it would be ideal now or in the near future to align that with parameters from standards and classification system from the Building Information Modelling (BIM) world.

Having the same naming and tagging across would be great and can ensure interoperability across the different stages of projects.

Best Regards,

Georgios Grigoriou

We based a lot of the above on Real Estate Core's Asset entity. We didn't look at ISO 16739 IFC but here are the relevant sections.

6.4 IfcSharedFacilityElements

• 6.4.4 PropertySets
  • 6.4.4.8 Pset_ManufacturerOccurrence
    • AcquisitionDate
    • BarCode
    • SerialNumber
    • BatchReference
    • AssemblyPlace
  • 6.4.4.9 Pset_ManufacturerTypeInformation
    • GlobalTradeItemNumber
    • ArticleNumber
    • ModelReference
    • ModelLabel
    • Manufacturer
    • ProductionYear
    • AssemblyPlace

Rick,

I am curious to see how the proposed tags will look. Also, here is some feedback that I think your group may find useful.

---

orderNumber: A unique identifier assigned by the vendor that describes how the equip was purchased. This is also referred to as a Purchase Order Number or PO Number.

I'd like to suggest the definition of orderNumber be reevaluated by your group with the following considerations:

There are several types of order numbers that appear in purchasing. Here are some:

• Sales Order Number - (aka SO, issued by vendor to one customer) https://en.wikipedia.org/wiki/Sales_order
• Purchase Order Number (aka PO, issued by customer to one vendor) https://en.wikipedia.org/wiki/Purchase_order
• Work Order Number - (aka WO, issued by vendor typically internally to vendor, but occasionally we have been issued a WO as a subcontractor) https://en.wikipedia.org/wiki/Work_order
• Statement of Work Number - (aka SOW, issued by vendor and sometimes required to be reference by subcontractor/customer) https://en.wikipedia.org/wiki/Statement_of_work

Relationships and other things to consider:

• None of these have to be numerical only. A lot of times companies use alphanumeric and hyphens and underscores in these. Example: Purchase Order Number "PO-3X456" or "589P15156_789"
• Purchase Orders can reference multiple items at one time, yet each item could have its own Sales Order depending on processing times of the vendor. Example: If a customer orders 3 AHUs and 2 are in stock and 1 has to be ordered with a 6 week turn around time, then there could be one Purchase Order with two Sales Orders referencing that Purchase Order.
• Sales Orders can reference multiple Purchase Orders. Example: If a customer orders 2 troffers in the morning on one purchase order (PO#1) and then in the afternoon orders 3 more on another PO (PO#2), occasionally a vendor will put them both on the same Sales Order although this method is typically frowned upon (SO#12A7 referencing PO#1 and PO#2). Most customers prefer the appearance of no more than one of their PO numbers per a vendor SO.
• Multiple Work Orders can be created off of one Sales Order.

---

GlobalTradeItemNumber

The Global Trade Item Number (GTIN) is valuable information and I propose there should be a tag for this for those who want to track it. https://en.wikipedia.org/wiki/Global_Trade_Item_Number

Note that there are differences between part numbers and GTINs. When purchasing, a vendor may create their own Part Number (https://en.wikipedia.org/wiki/Part_number). Example: Vendor "ABC Reseller" buys a product with UPC code 123456789012 from Manufacturer "XYZ Manufacturing" they may label it on their Sales Order as part number "XYZ-123456789012" or something totally unique like "TRO78111234" to differentiate ordering that item from that particular vendor so they can track their purchase price from that vendor and impacts on their sales. Part numbers generally speaking are internal references for vendors and not guaranteed to match the vendor's part number or GTIN. And unlike serial numbers, GTINs are referencing the product group.

Maybe a standard to store bar codes ( https://en.wikipedia.org/wiki/Barcode) and matrix bar codes, aka QR codes, would be beneficial too.

---

Let me know if you have any questions for the purchasing or accounting side of any of these. I've dealt with both and with multiple vendors for equipment for years so I am more than happy to share what I can.

Sherri

Hi Sherri,

Thanks for your feedback!

I would be in favor of modifying this tag proposal based on your great ideas. Also, yesterday the EVSE working group had some recommendations that will need to be applied to this proposal.

If it is okay, we will reach back out again later for feedback once we have a fresh draft proposal, which might be a few weeks from now.

Georgios –

Thanks for your feedback too!

We definitely aspire to be interoperable. Though based on some of the research I have done I am almost certain that the eventual outcome of this proposal won’t map 100% to a single other standard.

Before we transition the proposal from draft to final it would be great to have more feedback on how these draft proposed tags work on real world projects. Also, I am testing these ideas out on a synthetic dataset that I have created. I might come up with some new ideas still too.

Rick

Hi Sherri, All,

Today the Labs Working Group reviewed Sherri's ideas presented earlier in this thread. We would like to thank Sherri again for her feedback.

Here we would like to share how we propose to modify the original proposal in this thread based on Sherri's feedback and some other new discussion.

Split orderNumber into multiple tags

• salesOrderNumber
• purchaseOrderNumber
• workOrderNumber

Introduce two new tags

• invoiceNumber
• globalTradeItemNumber

Do not introduce part number

As Sherri mentioned part number can be ambiguous. Part numbers are often used as internal references by vendors. We feel that part number used in this context is outside the scope of Project Haystack at this time.

Keep several topics open

We agree we should decide on how to address Statement of Work Number and barcodes in this pass. I am particularly interested in QR codes for the work we are doing in the EVSE working group. We will need to discuss these topics more in our next meeting.

Call to action

All - Please let us know any feedback that you have to the proposals within this thread. We would like to submit another redone proposal on these topics by the end of November 2023.

Sherri - Would you please join the next Labs working group meeting on September 28 at 3PM ET to discuss these topics further?

The next Labs working group meeting will be super exciting as we discuss QR codes, barcodes, etc. :-)

We would like to welcome the Project Haystack community to join in on this discussion.

Have a great day!

Thanks,

Rick

Hi Rick,

Thanks for that. Could you please share the invitation with me to join the discussion? email: [email protected]

I also would like to join the Project Haystack Working Labs if applicable. I joined the WG but seems that I haven't received any invite, thanks!

Best Regards, Georgios Grigoriou

Rick,

Sure, I am happy to help however I can on Sept 28th.

Thank you,

Sherri

@Georgios I see your gmail address on the meeting, so you should have it on your calendar. I just forwarded the recurring meeting so it's at the top of your inbox. Let me know if you didn't get it.

Thanks Matt. I got it now.

Best Regards, Georgios Grigoriou

Hi,

The Haystack Labs working group and Sherri Sims have recently developed the below updated draft proposal. This update is intentionally more narrow in scope and we are hoping to incorporate it into Project Haystack soon.

Please provide to us any feedback that you have.

Proposal for Attributes on equip

manufacturer: The company that produced the equip.

modelName: A manufacturer assigned unique, alphanumeric identifier for a product line.

modelNumber: A manufacturer assigned unique, alphanumeric identifier for a product line.

serialNumber: A manufacturer assigned unique, alphanumeric identifier for an equip.

manufactureDate: The date that the equip was produced by the manufacturer.

globalTradeItemNumber: A globally recognized unique, numeric identifier for a product that is established by the international organization called GS1.

Thanks,

Rick

modelName and modelNumber have the same definition?

Hi Ian,

Yes, technically the definitions shown are the same and probably we would agree this could be improved.

What do you think about something like this instead? Or what else might you suggest?

modelName: A manufacturer assigned unique, alphanumeric display name for a product line (e.g., iPhone 12).

modelNumber: A manufacturer assigned unique, alphanumeric identifier for a product line (e.g., MGF43LL/A).

Thanks,

Rick

In my opinion modelNumber should be the default if "Model Name" and "Model Number" are not specifically identified. For example many data plates just state "Model", which I feel should be assumed to be modelNumber.