A note about field names and field labels in iR solutions
There are hundreds of fields in the solution, for names and other needs. A consistent scheme is used throughout iR solutions for naming fields. Often the actual field name is not appropriate as a layout label for a general user. For example, First is a much more appropriate label than NameFirst for the first name of a person, even though NameFirst is the actual field name. Both the field label and the actual field name will be identified in this documentation, if they differ, to enable you to select the appropriate fields when you create merged documents and to better understand how KEYSTONE manages your data. Where appropriate, the field label will be first, followed by the field name in parenthesis.
Child and Family Names and Relationships in KEYSTONE
There are five fields used for recording the name of a child. The first four—First (NameFirst), Nickname (NameNickname), Middle (NameMiddle), and Last (NameLast)—are self-explanatory and should always contain separate data. Sometimes during conversion, Jr. or III is left in the NameLast field. This should be moved to the NameSuffix field and the comma deleted.
Nickname (NameNickname)—which is also presented as First ovr—is considered the nickname of the child or the short or preferred name. If there is no short form then this field can be left blank. Examples of nicknames might be Rich for Richard, but also Robert or Bob for a child named C. Robert Smith. Sometimes foreign students with similar names or hard-to-pronounce names are known by nicknames on campus.
When NameNickname is blank then the common name for a child is assumed to be the NameFirst. There is a calculated field called NameFirst_final that shows the override value if there is one, otherwise it shows the NameFirst. This final field is the one that should be used most often when creating merge documents, as it will always show a useful value, where NameFirst may not.
Name Flow Screens
A help screen, called Name Flow, can be accessed from a button on the Personal screen below the child’s name in ksSTUDENTS.
The Name Flow screen shows the five input name fields, as well as the numerous combinations of those names that are calculated by the solution.
These calculated names are available throughout the solution. Refer to the Name Flow screen when creating merged layouts requiring names.
Family 1 and Family 2 Designations
From the point of view of the child, there may be multiple families (households) to which the child is related. Family 1 is the custodial family, while Family 2 is usually a non-custodial family. These families all have separate records in ptFAMILIES and are linked to the child via the IDFamily1, IDFamily2 key fields. The way the family record is linked to the child’s record is what distinguishes one family from another. Fields exist to handle additional families but generally, schools input information for only two families per child.
When related data from a family record is viewed in ksSTUDENTS, that record is seen as either a Family 1 or Family 2 record. From the point of view of a family, this relationship is not apparent, however. More, the same family can be Family 1 to one child and Family 2 to another child, in the case of separated or divorced families. The specific relationship of a child to a family is stored in the PermRec as further clarification.
On the Parents screen in ksSTUDENTS, there are sub tabs for Family 1 and Family 2.
While the family data can be seen and edited from the student’s record, sometimes it is desirable to navigate to the actual family record in ptFAMILIES. You can navigate to the related records in ptFAMILIES from the KEYSTONE Central Nav screen, or from the Student record > Parents tabs, by clicking the diamond button next to Family 1 or Family 2.
From the record in ptFAMILIES, you can navigate back to the student’s record using the Children tab.
Parent A and Parent B Designations
Each ptFAMILIES record can list two adults—one in the A section and one in the B section of the record. For each adult there are fields for Prefix, First, Middle, Last, Suffix, Relation (relationship to the child), and Nationality. These actual fields are Pa_first, Pb_first, Pa_last, Pb_last, etc. and refer to the A and B adults. Again, A and B may not necessarily be the father and mother.
Field names relating to the parents as a household, rather than as separate people, generally begin with a P_. This includes address information, home phone and the couple prefix. Examples are Zip (P_zip), Home Phone (P_phone_H), and Prefix (P_prefix).
There are special calculation fields in ptSTUDENTS that show the related family information based on a relationship. These fields exist to make it easier to find merge fields when creating letters. These fields are prefixed with the relationship type P1 or P2 and then the field name. For example, the ptSTUDENTS field P1a_first displays the data in the Pa_first field of the P1 Family record for that child. The P2a_first field shows the data in the Pa_first field of the of the P2 Family record for that child. For this reason in ptFAMILIES there is no such thing as P1 or P2.
These special fields in ptSTUDENTS will indicate the family type—P1a_relation, Parents_full, P2_full_ovr, Label_P2, etc. Most fields on the family screens in ksSTUDENTS are the related fields and have blue text to indicate that they are related, meaning that the data can be viewed and edited but that it resides in the ptFAMILIES record. The Relation fields are an exception and are explained further on.
Father and Mother Designations
With the possibility of divorced or separated parents, the father or the mother may be in the Family 1 or Family 2 record. A given woman may be the mother of one child and the stepmother of another. There are relation fields in ksSTUDENTS that make this connection—P1a_relation, P1b_relation,P2a_relation, P2b_relation. The relationship, therefore, is relevant only from the child’s perspective.
Making a list of the biological father’s name and mother’s name can be difficult if considering only one family record. To handle this, the solution has fields for Father_first, Father_last, Father_full, Mother_first, Mother_last, and Mother_full, as well as Father_phone_H, Mother_phone_H, Father_phone_W, and Mother_phone_W. These biological parent name fields are calculations created automatically by the solution, but are available only if the relationship has been entered in the Relation field in the student’s records.
Home and work phone numbers for mom and dad can also be confusing. If the Relation fields are correctly set in ksSTUDENTS, then the calculated mother/father phone fields will be correct whether these two people live together or not. If not, then the phones associated with P1a, P1b, P2a and P2b could be anyone. If users follow the suggestions for data entry detailed in this documentation, the correct phone number will generally appear with the correct person on most standard solution lists.
KEYSTONE allows for flexibility in working with household names, but there can be problems when converting from a database that had specific fields for mother’s name and father’s name. This difficulty can be compounded if the source database had parent data in every sibling record. It is important to review your data and make any necessary adjustments.
Parent Name Flow
There are text calculations or concatenations in ptFAMILIES that make the parent name information easier to work with. In ptFAMILIES there is a help screen called P Name Flow that can be accessed by clicking the P Name Flow button on the Overview screen.
The Parent Name Flow screen shows that the couple prefix is connected to the first and last name of the Pa person to produce the P_full field. Examples would be Mr. and Mrs. Robert R. Jones, Dr. and Mrs. John Kennedy, or Ms. Alice Baxter.
Depending on the custom of a school, this may or may not be the preferred way of addressing a couple. The intention is that this will satisfy the majority of cases. For couples with two professionals who prefer to have both names included, then the P_full_ovr field (yellow) is used. This allows the school to list a couple in any manner needed, using one or two lines, titles or not—for example, Mr. Robert Jones and Ms. Ann Thomas, Reverend Al Scott & Dr. Mary Hart, Jackson Packard and Maria Ortiz.
Merges using parent data therefore should generally use the P_full field. This field uses the override if it has data, or the default calculation if not. At installation, KEYSTONE uses this final field for all parent labels. This can be customized, if needed.
Full Names
Often it is useful to have an additional combination of the parents’ names for lists, labels or merges. The field that links all the different names for the two adults in the household is called Parents_Full. There is no override for this field so, if it does not produce the needed combinations, then it will need to be customized.
The field is constructed to show the Pb name first and then the Pa name. If the last names are the same, then it is not repeated, Mary and John Smith, Mary Smith and John Jones, for example. This may produce inconsistent results if the data is not entered consistently. The calculation attempts to resolve hyphenated spouse names but errors may need to be addressed. Mark Jones and Mary Smith Jones should become Mary Smith and Mark Jones. With customization, this field could be used as the name line in the label layouts instead of P_full.
Salutations
Another useful combination of parent names is used as the salutation for a letter. The default P1 Salutation (P_salutation) field combines the couple’s Prefix and the Last (Pa_last) fields—Mr. and Mrs. Jones, Ms. Sarah Pope, Dr. and Reverend Garcia, for example.
If the couple prefers to have both names present, then the P_salutation_ovr field (yellow) can be used. This can allow the prefix to be always added or always omitted, as preferred by the school or the couple—Mr. Jones and Ms. Smith, Sam and Sarah, or Sam Jones and Sarah Wilde, for example. The resultant P_salutation_final field should normally be used for letter merge.
Name Conventions
There are so many possible family configurations that the solution makes no assumptions about marital status or gender. Either parent, stepparent, or guardian can be the A person in the family record. What is important is that you should adopt a convention and then be consistent. The following guidelines may help:
- If the parents are married, place the father in the A (first) row and the mother in the B (second) row. The wife’s last name can be omitted if it is the same as the husband’s. There will be only a Family 1 record in ptFAMILIES for children of these parents.
- If the parents are divorced or separated, there will usually be two family records. In these cases, it is recommended that the A parent always be the biological parent. Therefore the Family 1 record may have either the father or the mother as the A parent, depending on which adult is the custodial parent. The spouse of that person will be entered as the B adult.
- For same sex couples, any designation that is acceptable can be used. However, it is important to remember that there should be only one biological mother and one biological father designated in the relation fields.
- For single parent households, the parent goes in Pa, regardless of whether the parent is a male or female.
No matter what the family situation is, what is most important is for data entry to be done consistently and for the data entry persons to have a clear understanding among themselves about the nomenclature that will be used. If users wish to run a report that will list biological mothers, for instance, the data must be entered so that biological mothers have been identified in the Relation field.
Address Data
Address data for families is entered separately, with individual fields for P_street, P_city, P_state, P_zip and P_country. These component fields are then combined with a text concatenation field to produce a full address field, called P_address_full. It is important to fill out address data consistently, even with foreign addresses.
In iR solutions, multiple line street addresses are typed into the same field, with a Return to move to the next line. This is different from other systems where there may be a street 1, street 2, street 3, etc. This needs to be noted when converting data from other systems or exporting data to other systems.
These address_full fields can be combined with name_full fields to create single field labels or inserts to merge letters. An example would be P1 Label (Label_P1), which combines P1_full_ final and P1_address_full.
Combination fields are highlighted in gray, indicating that they are calculations. Any errors detected in the label need to be corrected in the original component field or fields. The most common error is the inclusion of a carriage return after the data in a field. This manifests itself as a mysterious blank line in a label. Going back to original data, the return can be located and removed and the label will then be correct.
Directory: Do Not Publish
In ptFAMILIES > Overview tab, in the Contact area, you will find DNP checkboxes where you can mark information Do Not Publish in the Family Directory.
Family IDs
There is a field in ptFAMILIES called IDFAMILY that is the unique ID for a household. In database language this is the Primary Key for the ptFAMILIES database. As explained previously, from the point of view of ksSTUDENTS, each child can have three related family records: Family 1, Family 2, and Family 3. These family records are linked to the child’s record by inserting the IDFAMILY of the proper household record into an ID field in ksSTUDENTS: IDFamily1, IDFamily2, and IDFamily3. These are called Foreign Keys, as explained in the section, KEYS—PRIMARY AND FOREIGN KEYS. If the number entered in the Foreign Key matches an ID number in ptFAMILIES, then the family data are connected to the child and appear on the appropriate family screen in ksSTUDENTS.
Users are not required to type or edit these IDs. When records are created, KEYSTONE automatically assigns a unique FamilyID.
Family Data in the Student Record
The data on the family screens in ksSTUDENTS appear as blue text in white fields. The color indicates that, although the information actually resides in ptFAMILIES, it can be read or edited from this location in ksSTUDENTS. The Family 1 and Family 2 buttons on the sub-tabs in ksSTUDENTS navigate you to that family record in ptFAMILIES.
