Layout parts in FilemakerPro 10

A Sub-Summary Part is an entire section of a layout, meaning at the base layer. A Tab Panel sits on top of or inside a Layout Part, so the answer to your first question and second questions are 'no'.

The answer to your third question is a qualified "yes"...you can put a Summary field wherever you like but it's unlikely to function properly / display the correct results unless it's in a Sub-Summary or Grand Summary part.

I'm not sure what you're attempting to do but I will draw your attention to something you may not be aware of, the GetSummary( ) function which you can use in calculations to produce results that might not otherwise be able to be displayed with out a Summary field and Part. And, depending on what you are trying to do, you may find that there are other calculations that will give you the numbers you are looking for in the location. For a portal, you can Count(), Sum(), Average() and perform various other functions on values in the related records being viewed in the portal, e.g. from an Invoice, you can do Sum( InvoiceItems::Amount ) of the related records.

For information on the GetSummary() function, see:

http://www.filemaker.com/help/12/fmp/html/func_ref3.33.47.html

http://fmforums.com/topic/77983-getsummary-to-do-what-it-says-across-tables/

Participants need Continuing Education credits. The layout I have now gives a running total.
What the director wants is a total based on a date range for the fiscal year. If I use date ... date I get a total of all credits not just those in the date range.
Created a layout for the new report but can't seem to get it right there either. Added two global fields to People table, one for start date the other for end date. A new TO based on  g_Start< participatedDate and g_End > participatedDate.
Still get all of the credits going back to 2015.
Might have been farther along if I hadn't wasted time trying to add to a Tab Panel/Portal.

You need to run a script that performs a Find based on the date range in the Table that contains the records for Continuing Credits and NOT try to do this within a portal from another table to the Credits table. Reports, especially those that you want to have sub-summaries for, need to be done in the based table, not a related table. (This is a common mistake)

So, create a script that first asks the user to enter the date range using either a dialog size layout with a Global Date field on it or in a Custom Dialog, and then use that to perform the Find on a layout based on the table you want to summarize. Once you have all the records in that Date range, you can sort them and use a Sub-summary part to display whatever totals you want based on the Sort order...e.g. monthly, type of credit, etc., whatever sub-total break you want to display.

On the report layout - based on the Continuing Ed credit table - you can either display the individual records and the sub-summaries values, or you can leave out the Body Part and ONLY show the sub-summary part with the sub-totals. I would recommend leaving at least a minimal Body Part in for testing purposes and then removing it once you have the sub-summary totals appearing correctly.

I know what I need out but not sure if things are set up correctly. Before I start trying to write a script, I want to be sure I have everything I need and in the right place.
Have I add the new fields in the right places?
People is linked to Registrations on PeopleID.
Registrations is linked to Events on EventID.

I added  the global fields for g_start and g_end and the summary field to People.
 sumCredits field was already in the People Table =sum(People to Registrations to Events::NoOfCredits) and gives the running total.
The summary field =Total of sumCredits
dateParticipated is in Registrations

The ContinuingEd credit table is based on Registration.
Parameters to enter StartDate, EndDate.
Output needed:Persons name, total of hours during the date range.

Based on what you've described, you need to do the Report in the ContinuingEd credit table, not in the People table, though this might not seem intuitive at first. The global fields can be anywhere since they are global. The sumCredits Calculation field in People is fine for displaying the total credits earned by someone, but not for a report that is limited to date range, for that you need to create a layout based on the ContinuingEd table and using the sub-summary part and a Summary field (not calculation) for that is set to the Total of Credits. The steps are:

1. Ask the user for the starting or ending dates via a Custom Dialog with two Input fields based on your Global fields g_start and g_end. Make sure these global fields are date fields so that entries are validated correctly as dates.

2. With the date range captured, Open a new windows or switch to a layout based on the ContinuingEd table

3. Enter Find Mode

4. The ContinuingEd table should have a relationship to the Registration table based on RegistrationID so in Find mode, use Set Field to set the Registration::RegDate field to

g_start & "..." & g_end

Select allOpen in new window

 The RegDate field doesn't have to be on the layout to do this it just has to be accessible via the relationship to Registration.

5. Perform Find
(To prevent the standard records not found dialog from running, I always put a GetErrorCapture [On] before performing a Find followed by

GetErrorCapture [On]
Perform Find [ ]
If [ Get(FoundCount) = 0 ]
Close Window [ ]  {or us Go to Layout[ ] }
Show Custom Dialog [ "No records found in that range. ]

Select allOpen in new window

6. You now have a Found Set of ContinuingEd credits based on the Date range you're looking for. The key to getting the report to display Credits per user for the date range is the Sort Order because Sub-Summary parts display the sub-total based on a "break" field which in this case would be the person. So, sort your records by PeopleID. If you want them alphabetically, sort by Name first and THEN by People ID.

Since you have a relationship from ContinuingEd to Registration to People, you should be able to specify People::NameLast, People::NameFirst in the Sort order. You can also include People::PeopleID but I try to always use the closest iteration of a field, so if PeopleID exists in ContinuingEd (which it probably should), then use ContinuingEd::PeopleID in the Sort Order, otherwise use Registration::PeopleID

7. Finally, in order to display this properly, you need to have a Sub-Summary part on your layout "when sorted by ContinuingEd::PeopleID". Make sure that the following fields are included IN the Sub-Summary Part (not the Body Part):

People::NameFirst
People::NameLast
ContinuingEd::SumCredits

The last is a Summary (not calculation) field that will display the sub-total Sum of ContinuingEd::Credits for each person because you have sorted the ContinuingEd records by PeopleID, the "break" field. This very same Summary field can also be placed in a Leading or Trailing Grand Summary Part to display the Total of all records in the Current Found Set (meaning for the date range you specified in the Find)

The Continuing Ed table is a Table Occurence of the Registrations Table.
Can I skip step 4. ?
The Summary field (summaryCredits) is in People. Is it ok there or should it be in ContinuingEd/Registrations?

The Report layout should probably be based on the Registrations Table then. You can't skip Step 4 but you would instead use the Registration::Date field for your Find (not sure that you need a separate TO for ContinuingEd if it's the same as Registration unless you need it for separate relationship from somewhere else).

The Summary field needs to be in the Table that the Report is based on, in this case Registrations. If you are summarizing records via a relationship from People then you would use a Calculation field to Sum() the related records, but this is a report based in Registration and is summarizing the Found Set of records within the date range, sorted by the individual's Name and ID.

On your Report layout, I would leave the Body Part on at first and have it display a couple of fields from Registration such as Date, EventName and Credits. Once you have the Sub-Summary  part and Summary field working correctly, you can delete the Body Part and just leave the Sub-Summary part to display the Person's name and summarized number of credits. Note that if the records are NOT sorted by the Sort Field specified by the Sub-Summary part Sort Order, Summary field values in the Sub-Summary part will not display.

I was using the TO for a relationship between the People and Registrations. I was trying to get the records that had a "dateAttended" between the start and end globals.
Should I keep it or just do away with this TO all together.
relationships.gif

I originally directed you to create the Report on a Layout based on the ContinuingEd table because your use of the word "table" seemed to indicate that it was a separate table related to Registration rather than just a TO of Registrations.

Your original idea of summarizing via a relationship may still work and would require the Separate "CE CreditHours" TO that you have created along with the date range globals in the relationship. The records from this relationship do not need to appear on any layout, you just need a calculation field to get the Sum( CE CreditHours::CreditHours ).

For the report, which can be based in People, capture and set the dates with a Dialog as per my instructions above and then perform a Find using the Calculation field above and   >0  because the Sum() field will only be >0 if there are Reg records within the range. Then create your report in People to include Sum() field. You may also want to include Merge fields in the Header that show the date range fields.

And, a Pro tip, your "CE CreditHours" says what you are using it for for this report but it's better to name TOs based on what table they are based on and what they do rather than what you are currently using them for as they may have other uses down the road. Assuming you already have a primary "Registrations" TO that uses just PeopleID, I would suggest naming this one "Registrations_DateRange"

Have to change hats might not be back to this till Friday.
I do feel like I am headed in the right direction, or maybe just not the wrong direction.

I am back.
 Instead of using my original plan I am going to try working with the relationships that already exist.
People is related to Registrations on PeopleID
Registrations is related to Events on EventID
Relevant fields
People Table has the globals g_StartDateTraining, g_EndDateTrtaining, and g_Level(not significant now, but will be in future)
Calculated field:  sumCredits =sum(People to Registrations to Events::NoOfCredits)
Summary field: SummaryCredits=Total of sumCredits
Registrations Table has DateParticipated
Events Table has NoOfCredits
Inside a TabPanel under the main People layout I have added the three global fields and a  Go to Report button( script not working yet, doesn't leave the layout).
Do I have all the parts/fields I need?
The report layout named CE Credits is based on the People Table.
Merge fields in the header contain level, start and end dates.
The one sub-summary part contains NameLF_c, sumCredits, and SummaryCredits fields
The body contains the DateParticipated field

You will need two relationships from People to Registrations, both of which I believe you have.

1) Based only on PeopleID so that you see ALL their registrations and credits

2) Based on PeopleID as well as including the start and end date ranges.

Each People record will likely need two sumCredits Calculation fields, one based on each relationship so that you can see both the overall number Regs and Credits someone has as well as the date restricted sum of credits for the report.

On the report itself, unless you have a need for sub-totals of some kind within the report - and you haven't indicated any need for this - then you probably don't need a Sub-Summary part. The Body part with the person's name and the sumCredits_DateRange field should be sufficient. If you want a grand Total of all credits, then add a Leading or Trailing Grand Summary and a Summary field basd on sumCredits_DateRange.

I assume changing the TO CE Credit Hours's name to RegistrationsCredits will solve number 2. See image
The field SumCredits gives a total of all credits in a different layout so should be ok in the report.
Do I use an IF statement to calculate the value for  the second SumCreditByDate field?
relationships.gif

Had to drop the globals. Couldn't get them to do what I wanted.
The pipeline worked. And then a Find based on a date range. Need to do some cleanup but am glad this is finished.
One more question. If you create a relationship between Table A and Table B, shouldn't a layout based on A be able to reference fields in B and vice versa?

In general yes, and in fact you can reference fields multiple steps away as long as there are valid relationships between the records in each table. For example,  if you have four related tables,

Student   <- StudentID ->    Registration   <- ClassID ->   Class   <- FacultyID _>   Faculty

You should be able to pull information across all the tables. A layout based on the Student table might have a portal in it to Registration (which is essentially a Join table between Student and Class). If you then have a Portal on that layout to the Registration table, you should be able to display in that Portal the Class Name, Time and Location from the related Class records, along with the Instructor's name from Faculty associated with each class.

Thank you. I thought there were links but when trying to put fields on layout got " not related" will have to look at again.

Thanks again for help with my project. Present to the director tomorrow.