Defining a value of a Field based on the values of Other Fields not using workflow

I have two things (Invoice and Items). Both invoice and Items have the field status.
The status of Items is defined by work flows and can be Approved and Waiting for Approval. All good here.

Invoices can have many Items and the status of Invoices should be defined by the status of all items. If all Item’s Status are Approved, so the invoice should be Approve. If any is Waiting for Approval, the Invoice should be Waiting for Approval.

This is easy to define when creating the Invoice and I can set this value in the workflow, but once the invoice is created, the status of the items can be changed by the users.

Question: how can I change the status of the invoice at this moment?
There can be thousands of invoices that related to that specific Item.
One way of doing it would be to look for every invoice that has that item and then looping through all of them to test the status of all the items they have to define their status. This look madness for the purpose.

Should be easier simply saying that the status of the invoice is always a value that is related to other one.

Is that possible?

1 Like


Title (text)
Status (options set: approved; in progress; not started)
Items (list of items)

Title (text)
Status (options set: approved; in progress; not started)
Invoice (invoice)


Sorry but how can a structure of the Classes and a video about option sets is supposed to help?


My bad.

I meant to suggest a dB structure not classes

From what you kindly laid out it seems that the situation seems more complicated that it should be. Just an impression …

Sorry man, it didn’t help.


An invoice has thousands of items before it can be approved?

An invoice is not approved, that’s what I tried to explain. The status of an invoice has to be defined by the status of all its items.
No user should approve or not an invoice. Just the items.

it can have several items.

Ok noted.

What is the basis by which an invoice changes its status?

I gather that there are two statuses? not approved and approved perhaps?

Are there more?

… in short my question is what is the logic that makes an invoice go from status C … into status B … and then from B to A? (however many statuses it goes through?)

The status of the invoice should change (or not) when the status of one of its items changes.


I will take a stab at building some logic for this.

Status: approved and not approved

The status has the above two possibilities and is applied to both, items and invoices, but the difference is that an item only requires one status, while the invoice requires that all of its items be approved for it to change from not approved to approved.

Given the above I would have the following dB structure:

Title (text)
Status (options set; approved, or approved)
Items (list of all items without regard to their individual status)
Approved items (list of items with status “approved” only)

Title (text)
Status (options set; approved, or approved)

When an invoice is created, it’s items should also be created. All with status “not approved”. The invoice should be populated with all of its items in the field “items”. The other field called “approved items” is empty at this moment … but as users change the status of an item from not approved into approved … that item is moved by a flow into the invoice “approved items”. Each time this happens a check should be made to change the invoice status from “not approved” to “approved” when the count of both list fields is the same. If it is the same then the invoice is changed to “approved “.

Hope this makes sense and sparks an idea of how to … perhaps … build the functionality that you are looking for :grinning:

Best of luck with your project :+1:t2:

No. you don’t create the items when you create the invoices. Items are independent of invoices. The same item can appear in multiple invoices.

When you say: that item is moved by a flow into the invoice “approved items”…

I ask: how??? How you do that? Because if you tell me how to do that it’s done and dusted. Each item can be part of several invoices, not just one.


The concept of adding and removing things from a list of things could help.

Here 3 good instructive YouTube videos that may be worth your while.

Man, thanks. I’m really sorry but it’s not helping.

I know how to add things to a list!


Also … the “stab” I took was just that … a stab with the hopes to spark ideas of how to do things for your app.

It was meant to show that a basis of logic needs to be built for the invoice to go from point B to A.

Of course, it was not meant to be the way to do it for your app, as it is evident that there are different specific aspects of how you want it to work.

If it did not hit the bullseye that was not my intention. :grimacing:

The very best of luck with your project :+1:t2:

This topic was automatically closed after 70 days. New replies are no longer allowed.