The Expense form should just write the Expense name, and if you want to store the total as well, have another entry for it.
Then under the Expense view, add a form for adding Expenses payments as I noted here.
Basically I could manage all the tables, but I still have problems creating the “splittings”.
If I add an expense of 1000 to one event, paid by say 3 people, how can I make it so that one by one, for all 3 people, I can enter how much each person paid and the sum of these will spend 1000.
The goal is to see in the Expenses Payments table, one below the other, the 3 people, their individual payments, which amounts to 1000.
I can’t manage the rows in the Expense Payments table then.
I’m not sure what your setup is now. You have the Expenses inside Events setup correct. You can just have that exact same setup with Expenses as a parent table, and Payments as a child table.
I could manage the followings:
I think you are getting stuck on the fact that you are attempting to add multiple users to the expence at the same time with your checklist. I think what @ThinhDinh is saying is that in the same way you first add an event followed by adding an expense, you would then select your expense and add each user separately to the expense, and write the users to a separate expense-user table. Do the same thing you did going from event to expense, but going from expenses to user.
A choice component is only going to give you a comma delimited list of selected users in the expense take, which you found isn’t getting you very far.
There’s lots of other approaches, but I think you need to get away from the way you are currently trying to do it.
You could have separate columns for user and expense share in the expense table, but you are working with an unknown dynamic number of users, so that complicates things. From a database standpoint, it’s better in the long term to write those users to their own rows in their own table with keys that link each row to their respective event and expense. Think one-to-many. Anytime you have one-to-many, the many should be in a separate table.
Yes, it may not be as smooth of an experience compare to what you want, but I think @ThinhDinh offered some suggestions considering the use of inline form containers. Read through those again.
The alternate keeping your intended flow would probably require involving the use of JSON and building an API call to add multiple user rows into their own table in one fell swoop.
2 Likes
Thanks Jeff for your thoughts, too.
I finally got it what @ThinhDinh wrote me, and I could build up the tables and relations. Apart from the fact that I shouldn’t try to build up the whole event-expense-expense payment-separation process, I can’t manage the splitting or separation part.
Yes, maybe it could be a solution to store the individual payments in the Users’ Table (I don’t know). At this point I just would like to have a workaround for that kind of challenge. 
So, I understand it’s not a good solution to use to choice component but the inline list.
In that case how can I assure that only the “Paid Participants” can be selected and their payments are equal to “Paid Amount”?
Any suggestions for that?
But anyway, thank you all for your help so far! 
So do you not want to build the suggested data structure anymore? I don’t see how else you would be able to store that, perhaps JSON, but that’s even more complex to setup.
You can just add a “total amount” to the expense level, and then use a multiple relation + rollup to get the “paid amount” from the payments table. Calculate the outstanding amount live. Display that somewhere on the form to submit a new payment, and don’t allow the payment amount to exceeed the outstanding amount (there’s the ability to limit in the number entry).
1 Like
I do want to build it!
I started from scratch again, so far so good
I was just watching this JSON-thing as well, maybe I start using it too.
Thank you for your support!
1 Like
Please always let us know if you need anything.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.