Hi @berrycw - welcome to the community! 
Am I missing something or is the Quantities - Material not linked?
Ah this is a great question - and probably points to something we just need to clarify better in the UI perhaps. The word “Material” is used in a few different places, and I think that’s the cause of the confusion…
The TL;DR (summary) is basically this: There are two different ways you can work with “materials” in farmOS v2… 1) tracking actual material assets (including their inventory levels), and/or 2) simply referencing what types of materials were used in quantities.
The former allows for very granular tracking of actual materials, and was introduced as a new feature in v2. The latter was a simple (less granular) way of referencing material types used on Input logs specifically, which was the only option available in v1.
I’ll try to explain the recent history that led to this:
- In farmOS v1, before we had a “Material” asset type, we only had a taxonomy called “Materials”, which allowed you to create a list of the different types of materials you use as inputs, primarily. The “Input” log type had a “Material” field for referencing terms in this vocabulary (as a way to “tag” input logs with the material that was used, essentially).
- In farmOS v2, we added a new “Material” asset type, so you could track ACTUAL materials you are managing, and we renamed the “Materials” taxonomy to “Material type” to better differentiate it and clarify that it was for “types” of materials, not your “actual” materials.
- Notably, Material assets have their own “Material type” field, for specifying what type of material it is (by referencing a term in the “Material types” vocabulary).
- At that time we removed the “Material” term reference field from Input logs, and created a new “Material Quantity” type (alongside the old “Standard Quantity” type), which has a “Material” term reference field. So basically: the field moved from the Input log level to the Material Quantity level. This served two purposes:
- It maintained the ability to reference material types, so that people migrating from v1 to v2 would not lose that valuable information. (The automated migration logic copies data from the log to a new quantity in v2.) This is important for data preservation, but also because not everyone needs to track granular material assets (eg: someone using farmOS for organic certification record keeping only needs to show what type of material was applied - certifiers don’t care about inventory). Different operations use farmOS for different levels of granularity.
- It made it possible for a single Input log to reference multiple Material types (which was possible in v1) AND tie them directly to specific quantities that were used for each (which was not possible in v1).
Here is one of the relevant threads in the issue queue where this was all discussed/decided upon: https://www.drupal.org/project/farm/issues/3196834
Getting back to your use-case specifically…
It sounds like you want to track inventory of your berries via harvest logs. So the way you recorded this (via a Standard quantity on a Harvest log, incrementing the inventory of your Material asset) is the right way to do it! You don’t need to use Material Quantities for this at all, you can just use Standard Quantities.
(To be clear, you could use a Material quantity, but then you would be referencing the Material Type in BOTH the Asset AND the Quantity, which would be redundant.)
The only thing that was confusing is you expected that these quantities would show up under Records > Quantities > Material - and that’s understandable! The labeling is confusing - we should think about ways to make this more clear, if possible. At the very least we can add some help text at the top of the Records > Quantities > Material page to describe exactly what it is a list of, and similarly on the Records > Assets >Material page.
I hope I explained this well enough - and if not maybe someone else will chime in and do a better job. 
Also can an Export CSV function be added to the Inventory tab for Assets?
Great idea! And probably not too difficult… I will add the “feature request” tag to this topic. (See: How things get built... (from ideas to code))
