Make a budget tool

[eak24]

Some background:

At APP (Agua Para el Pueblo, the team that builds the treatment plants), we spend a lot of time looking at the hydraulic design and extracting material quantities. This is both incredibly time consuming and error-prone. With the new system, however, we will easily have access to all the various parameters of each component (ie, the length, ND, and SDR of every pipe). Having this information, we need to present something to the engineers there that they can import into their budgeting system. This would be something along the line of a table with the following columns: "part_id, part_path, part_notes, part_parameters". However we decide to output this data, it should be extremely flexible. Like the flexibility you get with SQL queries.

Implementation Thoughts:

Here's the progression of thoughts:

1. We should be thinking of this problem as constructing "another view" of the data passed to us from the rest of aide.
2. Dataset with custom "views" or "queries" sound like a perfect job for databases!
3. If we load the YAML into SQLite, we might have issues with knowing how to format the dataset as relational... relational-object-mapping is a nightmare. I'm more inclined to go with a noSQL embedded database. Maybe UnQLite?.
4. However this I'm not sure I like the idea of adding a database to our stack - maybe it's a great tool, but it isn't anything if students can't figure out how to use it.
5. Should we instead throw out a detailed CSV that can handle the majority of use cases?

Conclusion: Let's start by making a CSV with the most relevant data. We MIGHT convert this to a database in the future, but at that point, maybe we should convert the whole AIDE system to a DB. But with that, we lose a lot of the portability and flexibility that YAML offers...

Next Steps:

1. Get an example budget from the APP engineers to analyze what info we need to extract from the YAML.
2. Explore the APP accounting tool to see if there is any automated upload tool.
3. If it's too hard to connect with what APP is using (software from 2009), then just make a reasonable looking sheet that can be manually skimmed. Something like this. We shouldn't follow that template exactly - we want all the line items to be on the same sheet. That way they can sort by expense, 'category', etc... Maybe the worksheet with line items isn't too pretty, but we'll be able to get certain 'views' of it with standard excel functions. This will provide a familiar environment for those used to Excel (like the engineers in APP).
4. To clarify, we don't have to go all the way to excel, because that might be hard to customize. We could, however, export the CSV and have a custom Google Sheets document that can import it and already has 'views' built in...

Potential Complications:

• We need to give users enough ability to access this... material acquisition is bound to be different throughout the world, so it is imperative they can edit suppliers, material costs, bulk discount info, etc...
• While we want to give users control, we also want to ensure that the extracted line items remain untouched (at least not touched accidentally) to reduce confusion. And we want to make line items easy to sync. Let's aim for simplicity and good sense from the engineers, here.

Conclusions:

There's a lot to figure out here. So let's do the agile approach and take it one baby step at a time. Within two weeks, the team could aim to have every item in an arbitrarily-nested YAML converted to a single "line item csv". Let's just care about pipes for now. So assume the CSV has columns of: "id, path, notes, sdr, L, nd, quantity, notes". Assume that you start with a YAML that looks like this:

component_a:
  bp:
    id: M48611
    sdr: 26
    L: 3 meter
    nd: 3 inch
    quantity: 34
    notes: Important to order surplus! Remember what happened in SJG?
  component_a_a:
    bp:
      id: M48613
      sdr: 21
      L: 10 meter
      nd: 12 inch
      quantity: 3
      notes: corrugated
    component_a_a_a:
      bp:
        id: M48616
        sdr: 21
        L: 40 meter
        nd: 12 inch
        quantity: 1
        notes: corrugated
  component_a_b:
    bp:
      id: M48234
      sdr: 21
      L: 10 meter
      nd: 12 inch
      quantity: 3
      notes: corrugated

You'd end up with a CSV that looks like:

id,path,sdr,L,nd,quantity,notes
M48611,component_a,26,3 meter,3,34,Important to order surplus! Remember what happened in SJG?
M48613,"component_a, component_a_a",21,10 meter,12,3,corrugated
M48616,"component_a, component_a_a, component_a_a_a",21,40 meter,12,1,corrugated
M48234,"component_a, component_a_b",21,10 meter,12,3,corrugated

[oliver-leung]

Moving to Onshape would allow us to use the already implemented bill of materials application.