Registration

[Ausm1]

I am attempting to edit a built in template in Filemaker Pro 7 - Template is called "Registration". It's pretty much perfect for what I need it to do except that I need it to track payments tied to contacts and to events. I know this should be fairly easy to set up and I know how to create relationships and set up portals but I am confused by how the relationships are already set up in this template. I would like to be able to:

-track multiple payments for contacts linked to mulitple events

-have payments show up in Contact Registration portal

Right now there are three tables set up - "Contacts", "Events", and "Registrations" and there are multiple ID's which are the linking points, which is what is confusing me.

Could anyone help guide me through this process? I appreciate it. I need to know where to put the payment information and how to link it. Do I need to set up a payment ID in the Registration table? Or create a whole new "payment table"?

I appreciate very much any help and support!

-Melody Oaks

Edited March 17, 2006 by Guest
removed Forum info

[aldipalo]

I'm assuming the payments are related to the events and there could be many events related to contacts. What's the "Registration" table for?

Can you post a copy of the file?

[Ausm1]

Yes, "payments are related to events and there could be many events related to contacts". The "Registrations" table is to register contacts for multiple events. It is set up as a portal in both the "Events" (Registration Event ID) view and the "Contacts" (Registration Contact ID) view. And as a tab in both views as well.

I attached a pdf of both views to this post....

Thank you for your time and support!

-Melody

Workshop_Registration.pdf

Contact_Registrations.pdf

Edited March 20, 2006 by Guest

[Razumovsky]

Hi Melody,

If there is only a single payment per event, you could track it as just a Payments field in the events table.

If there is ever the possibility of more than one payment per event (and a single payment CAN NOT be for more than one event), I would make a payments table with Event ID and Contact ID fileds, enter payments from events, and also display payments in a portal from customer table.

If there is ever the possibility of more than one payment per event (and a single payment CAN be for more than one event), I would make a payments table with Registration ID and Contact ID fields, enter payments from registration table, and also display payments in a portal from customer table.

The deciding factor is if a customer pays by event, or by registration.

-Raz

[aldipalo]

Can you post a copy of the file or show us your relationship graph?

From looking at the pdf's it appears to be pretty straight forward, but you say there are many relationships that are confusing. So, it may be helpful to see what you mean by that.

Al

[Ausm1]

Thank you for your response. This helps clarify some, but I’m still a bit confused, if you could offer just a bit more assistance, I would really appreciate it!

I've posted a pdf of the relationship graph....it's not that there's so many relationships....I'm more confused by the labeling.....like "Event Event ID" and "Event ID", etc. I just don't get how they're connected and how to add in a payment piece to the registration table and have it link to contacts and events.

The Contact pays by registration...meaning there can be multiple Contact registrations for one event.....each event will have multiple registrations and a given contact could have multiple registrations for multiple events. To be more concise, each registration will have one payment for one event for one contact. But each contact and event can have many registrations.

Does this make sense? With this being the case...which suggestion do you think would work best?

When you say “customer table” are you referring to the “Contacts” table already in existence? Or suggesting I make a whole new customer table?

Hope this makes sense! Let me know if it doesn't.

Registration_Relationships.pdf

Edited March 21, 2006 by Guest

[Razumovsky]

Sorry- I meant Contacts.

To be more concise, each registration will have one payment for one event for one contact. But each contact and event can have many registrations.

OK, this makes it easy. Since there is only a single payment per registration, and each contact has only a single registration per event, payment could just be tracked as a field in registration table.

I attached a quick demo- just look at the relational graph.

read through this post here for starters.

Also, run a search for "Join table" (use the quotes) on the forum, and you will find plenty of posts on this topic. In your current model, registration would be the join table. Using your existing graph, if you put a payment field in the registration table, you could put a portal from a Contacts layout displaying payment field from Registrations ContactID table occurence.

-raz

Registration.fp7.zip

Edited March 21, 2006 by Guest
added specific detail

[Ausm1]

Raz,

Thank you for all your help. I think I've mostly got it and seems like it was much simpler than I was making it.

But I'm still having trouble actually making it work. I put a payment field in the Registration table. However, I can't seem to put it on any layout so that I can actually enter information into it......

I'm not totally sure what you mean by:

"if you put a payment field in the registration table, you could put a portal from a Contacts layout displaying payment field from Registrations ContactID table occurence."

Put a portal from a Contacts layout where? And do you mean have the portal display the payment from the "Registration ContactID table?

I'm apologize if I'm being terribly dense. It all seems to make sense until I actually try doing it!

Thank you for all your help and time. I appreciate it very much!

-Melody

[aldipalo]

I believe this will give you an idea of how to set up a portal on your contacts page.

Registration.zip