Put 'full' OC Product and Supplier totals onto API - for many new outcomes

Software improvement (Archived)
1

Continuing the discussion from Creating invoice in Producer accounting system for total products provided to Order Cycle:

What is the need / problem ?

The solution we created above is brittle (relying on a script running on the server) and unable to be shared with others. It is a partial solution, but with a few small refinements could enable a lot of things - like the highly sought after bank transaction upload files to streamline payments to producers

Currently it produces a row for each product if the variants are ‘summable’ and separate lines for the variants if not.

It requires an order cycle ID and a supplier ID - so at the moment it is just one supplier from the order cycle.

i have tested it this afternoon [NB. restricted access] and I’m pretty confident that both the taxes and fees are being picked up correctly. It might be missing the shipping fee - but it’s pretty close

So the modifications to deliver a total payment per producer would be

  • run the script for all producers in an order cycle rather than just 1
  • consolidate the rows per producer so there’s just one line each
  • [check the shipping and payment method fees are getting picked up correctly]

AND put it on the API so everyone can just easily get and use it

Who does it impact ?

People wanting to generate bank files

What is the current impact of the problem ?

Mostly the influx of farmers markets using OFN who are concerned about manually making payments

What is the benefit of focusing on this ?

There are many use cases of these potential API endpoints. Moving in this direction can give instance managers a lot more power to provide elegant and customised solutions for users

Potential solutions that will solve the problem ?

  1. Continue the frustrated hack approach
  • Tweak the script
  • Make it available to everyone to install on their servers
  • Maintain it
  1. Put it on the API so we can all easily use it

Selection of a feature candidate

Est. time is that same or less to put on API, and robustness and useability of the solution much higher for everyone

T-shirt size of our selected feature candidate

Small. One day to create a new API endpoint based on the current script.

Metrics to measure if need is satisfied after feature is implemented

Feature owners

@tschumilas @lin_d_hop @Kirsten

Epic/projet where you can follow implementation

Connected wishlist and discovery discussions*

[list precedent discussions]

2

Happy this is layed out. A couple of questions/notes – and you’ve likely thought of this @Kirsten and @maikel - but just documenting them to make sure we move toward agreement.

  1. ensure the per supplier, per OC totals include taxes on products, based on variable tax rates set on the product page by suppliers. So multiple rates & zones, and when tax is included in prices and when it is not included in prices (as in NA)
  2. include enterprise fees added into the OC by the supplier in the supplier’s total (so fees separate from the coordinator’s fees).
  3. include taxes on the enterprise fees - for each supplier.
    Note - right now in OFN taxes on shipping fees are handled at the platform level anyway - so at least in OFN-CAN, our users are not adding these in - since they can’t be selected for different tax zones - so I know this would be out of scope here.

So in the end, my dream come true (and the dream come true for OFN hubs & farmers markets) is a listing of Order cycle name/date, producer/supplier name, total product sales, total taxes on producer sales (incl taxes on fees), total owing (product sales + taxes). Oh - how I would dance a jig that would make my Irish gran smile up at me from her grave!

1 Like
3

Migrated to Put 'full' OC Product and Supplier totals onto API · Issue #134 · openfoodfoundation/wishlist · GitHub