Categories
A second level of classification for library members, used to group members within a Member Type
Member Types and Categories — How They Relate
Papyrus Cloud uses a two-level classification system for members. Member Types are the primary grouping; Categories are the secondary grouping within that. The relationship between the two is deliberately flexible:
| Feature | Member Type | Category |
|---|---|---|
| Purpose | Primary classification — drives reports, Privileges, and the promotion routine | Secondary sub-classification — used for finer grouping in reports and member lists |
| Affects borrowing rules | Yes — Quota, No Issue After, Max Fine, Bespeak Days all operate at the type level | No — Categories are informational only and do not affect any lending rules |
| Relationship | Each member has exactly one Member Type | Each member has one Category (or none). Categories are shared across types — the same Category code can appear in multiple Member Types |
| Uniqueness | Type codes are unique per type | Category codes are global — a many-to-many relationship exists between Categories and Member Types |
| Configured here | Parameters → Member Parameters → Member Types | Parameters → Member Parameters → Categories |
The member hierarchy in Papyrus looks like this:
The Categories List
The Categories screen displays all defined categories in a simple table showing the category code and the number of members currently assigned to each. The list can be sorted by the Category column heading.
| Category | Members | |
|---|---|---|
| Delete | (none) | 247 |
| Delete | 00B | 24 |
| Delete | 00M | 23 |
| Delete | 00N | 23 |
| Delete | 0C | 25 |
| Delete | 0L | 26 |
| Delete | 0S | 24 |
| Delete | 1A | 3 |
| Delete | 1G | 2 |
| Delete | 2H | 3 |
| Delete | 7C | 28 |
| Delete | 7L | 29 |
| Delete | 7S | 27 |
| Delete | G8 Green | 0 |
The first row (with a blank category code and 247 members) represents all members who have not been assigned to any category. This is normal — Categories are optional and many libraries do not use them at all.
The Members column shows how many member records are currently assigned to each category. This count is useful when managing your categories — for example, confirming which classes have been fully populated after an import, or identifying empty categories that can be safely deleted.
Adding a Category
To add a new Category, type the category code in the single field at the top of the screen and click Add.
| Field | Description |
|---|---|
| Category | The category code — up to 20 characters. The code is what appears on member records, in reports, and in drop-down lists when assigning a category to a member. It should be meaningful to library staff. There is no separate description field — the code serves as both identifier and label. |
Deleting a Category
Click the Delete link on any row to remove that category. A category can only be deleted if no members are currently assigned to it — the Members count must be 0 before deletion is permitted.
Use Case Examples
The sample library uses Grade 7 as a Member Type (07). Within Grade 7, the school has three classes: 7C (Calder), 7L (Livingstone), and 7S (Stanley). These are defined as categories 7C, 7L, 7S, with 28, 29, and 27 members respectively. A report can then be run for Member Type 07 and sub-totalled by Category to show borrowing by class.
The categories 00B, 00M, 00N with 24, 23, and 23 members suggest a pre-Grade 1 or reception year with three classes (B, M, N). Similarly 0C, 0L, 0S suggest another year group with three classes, showing how the same Category structure scales across the school.
The category G8 Green shows that categories can use longer, descriptive names where the code alone does not convey enough meaning. This might be a Grade 8 house or tutorial group called "Green". With 0 members currently assigned, it is either a new category being prepared for an upcoming intake, or an old one that has been emptied and is ready for deletion.
In a college or higher education library, Member Type could be the year of study (Year 1, Year 2, Year 3) and Category could be the course or programme (e.g. BSc Comp, BA Eng, BCom). Because Categories are not unique to a Member Type, the same course names would appear across all year groups.
The Unassigned Row
The first row in the Categories list always shows a blank Category code with a member count — in the sample library, this is 247 members. This row represents all members who do not currently have a category assigned to them.
This is entirely normal and expected. Many libraries use Member Types extensively but never assign Categories — in that case, all members would appear in this unassigned row. Categories are always optional.
The unassigned row cannot be deleted. It simply reflects the current state of member data. To reduce the count, assign categories to members through Members → Maintain Members or via a bulk member import.
Planning Your Categories
Because Categories are simple codes with no additional settings, the main planning consideration is deciding on a consistent naming convention before members are imported. Here are practical guidelines:
| Guideline | Detail |
|---|---|
| Decide before importing | If member import files include a class or group column, define the matching categories in Papyrus first so the import correctly assigns them. Otherwise members will arrive unassigned. |
| Match your school's naming | Use exactly the same codes your school administration system uses for class groups, so that imports from D6+, Adam, Engage, or Wonde can be matched automatically. |
| Keep codes concise | Short codes are easier to read in drop-down lists and reports. Two to four characters is ideal — 7C is clearer in a column than Grade 7 Calder Class. |
| Year-end housekeeping | At the end of each year, after the promotion routine has run, old class categories will have 0 members. This is a good time to review the list and delete obsolete categories to keep the drop-down lists tidy. |
| Categories are optional | If your library does not need class-level reporting, simply do not assign categories to members. Member Types alone provide sufficient grouping for most purposes. |