fill across tables need to fix

In your most recent post above, you show two tables.

In the Main table:

Row 6 (or 7, if there are two header rows) shows a "transfer from his share" amount of 1000.00, and a -1000.00 amount in the Mother column.

Row 9 (or 10) shows a "transfer from his share" amount of 2000.00, and a -1000.00 amount in the Boy1 column.

The second table is named "Mother," so it should show the row containing the first transfer. Unfortunately, you've chosen to NOT include that row in the image of this table.

In your previous post, you show an image of the Boy1 table which includes the transfer transaction in row 9 (or, more likely, 10) of theMain table, and shows an 'empty' row 7, corresponding to the other transfer transaction.

Below these tables is the formula offered by Badunit, which looks at the cell in 'this row' of column F (Mother) of Transactions, or in column G (Boy1) and tests for an entry in that column, If there is an entry there, the formula returns the contents of the cell on 'this row' of column B (Description) of Transactions.

The result, on each summary table, is a single cell, always in column B, that contains a description IF the transaction on this row changes the balance of this person's account, or contains 'nothing' if the transaction on this row does not affect the balance of this persons account.

That cell can now be used, either directly or via a second cell in the same row of an added column, to signal a filter to SHOW or HIDE this row.

Here's an example.

Column B on Mother contains the formula provided by Badunit.

Column B on Boy1 contains the formula provided by Badunit, with H3 replacing G3.

Formulas in both cases are entered in B3 and filled down to the end of the table.

Both tables are filtered on the contents of column B, using the Filter rule displayed in the Filter Inspector.

(The filter has been activated only on Mother.)

Note that this filter requires that every description possible in column B must contain the letter e. The version below removes that restriction by using the LENgth test to check for content in column B and generating a filter value that depends only on whether there is visible content in column B.

In the example, the filter is activated only on the Boy1 table, where it hides row 7.

If activated on Mother, it would hide row 10, where the transfer does not affect the Mother account.

in use, column F, containing the filter values, would be hidden,

Formula in F3 (both tables):

LEN(B3)

Fill down to end of column F.

Filter rule in both tables is as shown in the Inspector.

Regards,

Barry

Formula not copying to new rows automatically:

If Numbers detects a pattern, it will apply the formula to a new row. From what I can tell, it needs 2 consecutive rows to have the formula before it calls it a pattern and automatically copies it. I can only guess that the formula is not in every row or is not the same in every row (other than cell references moving down one row). If it is not that, I don't know.

Transfer Column:

I assume you used a simple formula to copy the date and description to the other tables. Trying to copy some rows and not others might get complicated. I suggest you use filters to hide rows you don't want to see. Use the Organize part of the sidebar on the right to create a filter to show rows that match "column B text is not 'Transfer from His Shares'". Make sure the rest of the formulas in those rows automatically result in zeros or blanks or whatever for the other columns so the row will have no effect on the data in the table. You will not be able to make any manual changes to any formulas in those rows because they will be hidden. Yes, you can unfilter them first but you might forget.

I have no idea why your formula does not copy to the next row. I gave one reason, which is the most likely reason. With the information you provided, I have no other ideas.

It was not clear what transaction(s) you wanted to remove from what tables. The only one highlighted, and it was highlighted in all your screenshots, was "Transfer from his shares" so I assumed that was the one you didn't want. But I think I understand now that it is a multitude of transactions. Sure it can be done that only the transactions for a given person go to their table. It gets complicated fast and it needs to be able to tell which transactions go with which person(s). Then you need a bunch of extra columns to flag/number the rows that go to each person's table. The other tables will use lookup formulas to bring the data over. You probably have not received many responses because it is a lot of work just to create an example for you. There are, however, many previous threads on this kind of operation, but typically for only one table. Those threads are hard to find so I don't blame you for not looking or not finding. I'm not even sure what search terms I would try.

What I would suggest, which is much easier, is you continue copying all transactions to all tables and, in those tables, determine if a specific transaction is for that person or not. For instance, if the debit and credit are both zero, the transaction is not for that person (I assume). Add a new column to the table (column F) with a formula that results in SHOW if you want the row to show or HIDE if you don't. Filter on that column to show only the rows that are SHOW.

The formula might be =IF(LEN(C&D)=0,"HIDE","SHOW")

I say "might" because I am just guessing that the formula in columns C and D turn zeros into null strings, which is why those cells are showing as blanks.

Other than looking at the header row of your main table (Mother, Boy 1, Boy 2, etc), can you think of any other way to tell if a transaction is for a person or not? I was thinking if there was no debit or credit for that person for that transaction (LEN(C) = 0 and LEN(D)=0 in that person's table), that transaction (i.e., row) is not for that person and we can hide it. However, in your latest screenshot, you have selected the transaction "Rent apartment #1..." in the "Mother" table so I assume you are telling us it is not a transaction for "Mother", even though it has a credit value. So I guess my assumption of what makes a transaction applicable to a specific person was incorrect. Which brings me back to the question: is there a way to tell if a transaction goes with a person, other than looking at the header in the main table?