Ok. I think I see the issue... this isn't an Orders endpoint... you aren't sharing data from individual Orders, you're aggregating Orders, from multiple Enterprises, for a given reporting period (to/from date).

I'm on my phone atm, but can look when I'm back on the laptop & provide dfc mappings for the ofn fields you've mentioned.

I would suggest a name like AggregatedSalesData

You probably want to feed in the date range as parameters (either in path or in query).

Wondering how efficient OFN is at builsing this resultset on the fly... do we need to consider indexing/performance? 🤔

As @mkllnk already mentioned...

dfc-b:PostCode is accesible through Enterprise:hasAddress (inherited from Agent, so you might need to look there)

Product/Variant Units are parsed via the measures.rdf SKOS vocabulary. Not sure how that was mapped, but you should be able to yoink the same code as for the Product endpoints.

Price should be passed as a dfc-bPrice object, which is attached to an Offer, which is linked to a CatalogItem (hence why we tend to serve SuppliedProduct with CatalogItem). You'll need to embed the links in the graph, but not the entire object, just @id will do.

Offer also links to SaleSession which will be where you can get the Orders link & determine the quantity sold. I think you'll need to pass all the OrderLines to the object, any aggregation would need to happen after the DFC objects are parsed.

@anansilva - Hope that all makes sense, I'll give you a buzz on Slack.

Further thoughts...

To make the graph hang together, I think we need to start from a User (the INRAE user), affilitate them to all the Enterprises that are willing to share data & walk the graph to OrderLines from there.