There is the function Get ( ActivePortalRowNumber ) , but I wouldn't use it for the task you describe. I believe your Class table serves like a "products" table in a more typical invoicing system, correct?
Your system (via script or user action) should enter an ID number for the class into a line item record of the invoice and a looked up value or auto-entered calculation should use a relationship between the ID number field of the Line Item table and the Class table to copy the needed data from the Class table.
I'm also developing a dance studio database for the dance school my daughters go to. If you want to compare notes then just send me a PM through the forum.
I started with the FM11 Invoices Starter Solution and I've modified the heck out of it along the way. The biggest change I made was adding a Season table so that each class belongs to a season. That way when next season comes along they can duplicate their classes database, assign to a new season and modify the classes and prices as needed for the upcoming season. Know what I mean.
Right now my relationship graph looks like a yard sale since I was trying different relationships and I had some learning curve to do since I hadn't used FM much since version 7 developer which I used for my own freelance invoicing as well as 1 client CD-ROM for a Food Packaging regulatory body.
I have actually set up a product - line item relationship that's working fine. This involves user interation to pick the product that you would like to add to the invoice from a line item portal within the invoice layout. The class table operates differently. I would like the product that is related to the class to be added to the customers invoice when their child is added to a class. this means that (from the class layout) when I select a child/student to join a class it will also add this product (and the students name) to the related customers Invoice. I am pretty sure I would need to use the get(activeportalrownumber) function. I'm just not quiet sure how to use it.
I think I see where you're going with this. My situation was simplified because the studio wanted it a certain way which allowed me to make rules that helped uncomplicate that relationships.
For instance, the only thing this database is for is class enrollment and managing classes, students and payments. Nothing else they sell goes through this database. So the products table became the classes table and the invoice table became an "enrollment" table. For each season a student can only have 1 enrollment to which classes are added to via a drop down list of classes in a line item portal row of the enrollment record. So if for example after 1 month of lessons the student decides to add a course then it is added to that same enrollment instead of a new invoice that lists that class.
The way I handle payments is kind of like an invoice system but many of the students pay by the month so I generate a schedule of payments (in a payment table) based on the enrollment's total cost and the number of months they chose to pay. (Typically 8 months, Sept - March). I did have to add some scripting to allow them to do things like ... re-calculate payments if the enrollment costs change and factor in that they may have already made 1 or 2 payments. Stuff like that. This was the priority from the studio owners. In September there is all the the new enrollments. October has a few adjustments. After that its really all about managing the payments for the rest of the season.
If you go to my class layouts you can see a list of students enrolled in the class but I haven't allowed a student to be added to the class via the class table, just from the enrollment table. But now you have me thinking about how I would do that. :) In my solution I would first require the student have an enrollment record for that.
This is certainly a situation where taking to the owners of the studio and figuring out what they wanted simplified things for me. If you want to be able to add something to anything from anywhere its going to get complicated.
There MS Access solution they used last year has half the features that I've built in and they are already happy so I'll go with that for now and let them get used to it. Call it phase 1. After that I'm pretty sure they'll come back to me with more feature requests. Like how to incorporate competition fees into the payment schedules.