Hello, annettermt (Annette?). Welcome to FileMaker.
I think the best way to clean up your database is to clean up your data model first. What do I mean by that?
Your confusion is coming from, I believe, a jumbling of your data entities. (Data what?) Data entities are, put simply, the things about which we want to track data. You've actually done a good job in the initial phases of your design; we just need to clean up your terminology a bit.
When you name your tables in FileMaker, it's usually best to name them according to the "thing" (entity) they're tracking. So, for example, you have a layout (and table) called "Client List". Well, you're not tracking lists of clients in this table; you're tracking the clients themselves. So it would be clearer to call that table "Client" or "Clients" (some prefer singular, others plural).
Another, better example, is the table you've named "Client File practice". Obviously, this is the default name given by FileMaker; you called the file that, so FileMaker simply named the first table the same thing. But it's really tracking client appointments, so renaming the table "Appointments" would make it clearer what you're dealing with.
Then you have Receipts, which is great, provided you are leaving room for more than one receipt per appointment. (Which is probably a good idea.)
Now, you can name your layouts anything you like. For example, if you have a layout that's a list of Client records, by all means, call it Client List. It's just that each record represents a client, not a list.
Now, let's take a look at how we move data around - or not - in your relationships. Here's your current relationships graph:
Not bad at all! You've correctly used an ID for the client (instead of something mutable, like Name - yikes!). You can connect a client to his receipts (which is good), and you can connect a client to his (now renamed) appointments. All very, very good. But we're missing a couple of things.
1) Why do we have the clients' names in both Client and Appointment? One of the basic rules of databases is: DRY. Or, Don't Repeat Yourself. There's no reason to put the client's name data on the appointment, because you can see it on the related Client record through the relationship. So only have one place to put any given piece of data. Otherwise, you risk data inaccuracies because someone changed the data one place, but didn't change it someplace else.
2) There's no good place to attach a receipt back to the appointment that generated the service. So, you have the appointment date duplicated. Again, we have a problem.
So let's see if we can't make this a little easier. Take a look at a quick Rev. 2:
Now we're in a position to create new client records directly from an appointment (as you wanted), but we can also create receipts from there. Pretty cool. And we don't have to worry about redundant data entry.
This could be further modified, depending on your needs.For example, if you can always guarantee that every receipt will have at least one appointment attached, you can do away with the Receipt_Appt table occurrence and just put Receipt where Receipt_Appt is. Reason is, you can still get at the Client data if there's an Appointment record in between. Cool, huh?
Hope that gets you started. I've attached the modified database for your review.
Oh My Goodness Mike,
THANK YOU for all this information! You have cleared up a lot of other questions I had. I really appreciate your help! Excited to get this up and running.
Thank you so much for your time.
You're welcome. Glad it helped. Exciting, isn't it?