Iterative Cost Calculations in Multi-Level Productions

"Hello community,

I’m facing a challenge with my tables in AppSheet and I’m seeking guidance. Currently, I have a table of inputs representing the items I purchase, and a production table indicating the products I manufacture using these inputs. It’s important to note that productions can involve both inputs and other productions, resulting in a multi-level structure.

For example:

  • Level 1 production (bread) using inputs (flour and water).
  • Level 2 production (hot dog) using an input (sausage) and a Level 1 production (bread).
  • I can have productions of “n” levels.

I’ve implemented bots that update the tables using a field called [update], and an action that increments this field each time there is a change in the table. So far, everything works fine. However, I would like these actions to run indefinitely until all necessary iterations for recalculating costs are completed. I don’t want the action to stop after the first iteration; instead, I want it to apply to all related rows where the mentioned production is found.

Any suggestions on how to achieve this effectively?

Thanks in advance for your help!"

That’s an incredible use case! It’s somewhat akin to inserting a row that contains a nested loop structure, where each row’s loop encompasses multiple sub-loops, and this process continues until the cycle is complete, correct? I’m eagerly awaiting a response to this question.

Rifad is exactly that. I am very close to achieving it. Let’s like the post massively so that it is always up and has good visibility. Surely some crack in the community solves it easily.

I’ve been racking my brain over something quite similar in the past. I managed to solve it a while ago using an inner loop, but it halted at the second level because it was static in nature, unlike the dynamic looping you need here. Let’s hope someone can come up with a solution.

1 Like

I’m going to try this way, since if I do everything virtually it will give an error ran out of resources, but I’m not sure it will work

Articles > Physical cost

Inputs > Virtual cost

Production component (Inputs and Productions) > Physical cost

Production > Virtual cost

The costs of the items can be entered manually or through action, however they are physical costs, they are real, you update the costs manually. Any change in the items table would recalculate the cost of the inputs taking as the value of the input (in my case) the maximum value of the related items. Imagine that each item is a version of the input.

Now, the components of the productions are inputs and therefore they are fields related to the inputs and their prices are directly the prices of the inputs. Since the inputs are virtual columns, they need to copy the value and paste them into the components table. I’m thinking aloud. Then, once copied and pasted into the component table, virtual calculations must be made with these costs. On the one hand the production costs (I was thinking they should be virtual) and on the other hand the input costs should be real.

Adding the Related costs should work. I’ll try during the day but surely someone will come with the answer.

Is this one of those cases where an actual looping function is required? You know the one that seemingly is highly requested but has not been implemented Lol.

A wise man was once asked: What is the point of walking towards the horizon if you can never reach it? It is precisely useful for walking.

If there is one thing I will never stop doing in my life, it is walking and giving up. Creativity finds genius at work. I hope that one day we can find the solution to this problem because it would be of great help to many people in the world.

greetings

I hear you. I keep holding on to hope that something is done. I can’t help but think that native looping integration would do wonders rather than the hack work arounds that many of us are implementing to get that kind of functionality. I am thinking overall performance here. Same for storing temporary variables based on a selected row instead of calculating virtual columns on every single row. I think I could eliminate half of all virtual columns if this functionality existed.

1 Like

Things like what you say are really helpful. You will have to make a post for the Features section, it has my like and that of many people. Notify me when you do it

I think I have the solution, I have devised a way. I’m not going to say it until I corroborate it, maybe tomorrow I’ll be publishing the form. I also need people to comment and give ideas in case what I’m thinking doesn’t work and in case someone has already solved it.

I have achieved it after racking my brain. And by the way, I am more than happy because I am also ignorant of programming, however, with the Appsheet tools I have managed to solve a complex problem.

What I did was create a CLONE table of the productions table. Records from the main production table are copied into this table, but with other Row IDs. The necessary information from the productions table is copied from the first to the second in only 3 columns.

I need Row ID of productions to copy into Productions_Clonation because I will refer to it later. A unit cost column in Producciones_Clonation, another with the label.

Every time I create or edit a production, it is automatically cloned to the other table. The productions that are components are references to the productions_clonation table, but nevertheless all productions belong to productions. This makes it not necessary to have a production child component referencing the parent but rather a clone.

Then all calculations can be done and there are no circular references. I know it will help you.