Closed bgsandan closed 1 year ago
@bgsandan I looked at those inconsistencies and I think I must have caught/fixed them previously because I am not seeing them. I will share updated spreadsheets by the end of the day -- please let me know if they are still there or if there are other inconsistencies that you notice!
Also, @rbroth , let me know if I should add a separate column with data types (USD, number, percent, etc).
@bgsandan please close this issue once you've checked that the inconsistencies are gone
@rbroth @andy-bevan - Feel free to 'upgrade' any of these to their own issues if/when appropriate
Having worked through the existing storage of the intervention costings data and looked at pulling it back out in various API routes for accessing and updating the data, I have come across a few things that I think need a little more thought, so I am documenting them here for now:
totals
/values
etc. obviously gets used during import but is not reflected in the final data structure. When returning all fields in a given heading tree e.g. "Start-up scale-up costs" -> "Training", there is no way for the API to indicate which fields are user updatable values e.g. "Number of training sessions" compared to calculated totals "Total training cost" without maintaining an exhaustive list of all possible permutations ofrow_name
row_name
e.g.total_inspections_cost
=annual_factory_inspections
xfactory_inspections_unit_cost
. Should these relationships be stored in the db somewhere and returned to the front-end to parse, should the front-end 'know' these hardcoded somewhere, should it be something else - One for collaboration with the front-end guys hereThere are also a few inconsistencies int the way that the spreadsheet values have been labelled (probably more for @kpitten):