You have at least two tables involved, could it be that you have several more and how are they related to each other?
I would think that you would have at least these tables for managing the book distribution to different locations:
Locations::LocationID = Invoices::LocationID
Invoices::InvoiceID = BooksOrdered::InvoiceID
BooksOrdered::BookID = BookCatalog::BookID
You can then add a payments table (Invoice Payments) and can link it to either Locations, Invoices or both. I depends on whether you need to link a payment to a specific invoice or just to a specific store location. (Each store would be one of your "customers".) It also makes a difference if each payment may need to link to more than one invoice (purchase order in your post) or not. How and to what tables you need to link a payment must be determined before we can discuss how to set up the layout you want.
Thanks for you answer and your patience with me. (You'll probably need more after seeing the examples below.) I have made a copy of the DB to translate to English for easier references. I think... I think I already have those relationships defined (albeit through a longer string), for shipments, invoices and payments. There is no need for invoice specific payments. Just payments towards the overall balance due per customer (or location).
Here are the example that I have:
There is no need for invoice specific payments. Just payments towards the overall balance due per customer (or location).
Yet your bottom chain of Table Occurrences does exactly that by using a join table to link payments to specific shipments...
If you do not need to link payments to specific invoices or shipments, you can easily set up a portal to payments on a bookstore based layout and use a summary field with the running total option to compute a running total of payments. Comparing this to the total amount billed can enable you to compute the balance due.