[OPEN-ILS-DEV] Basic Org Unit Hierarchy Setup Question

[Jason Etheridge]

> We're just now getting into setting up Evergreen on our test server, and
> after working through the org unit types, then turning our attention to the
> Org Unit Hierarchy (and working off of the examples provided), I notice now
> that the org unit type SYSIDS don't match up with the SYSIDs assigned in the
> org unit hierarchy.

Hi Amy, these two things don't need to have identical SYSID's.  You
can have more org units in the org unit hierarchy than you have for
org unit types, but you need at least one org unit type for each
"depth" of your hierarchy.

So you might, for example, have something like for your hierarchy:

My Consortium (depth 0) -> My Region (depth 1) -> My Branch (depth 2)

Then you'd need at least one type for each depth, maybe:

Consortium
Region
Branch

But you could have multiple types (or "classifications") for each
non-zero depth.  For example:

Consortium
Region or System or School
Outlet or Depot or Mobile or Sorting Station
Department or Section or Sub-Library

These types also have a hierarchy, so when you apply a type to your
org units, you could do something like this:

My Consortium (Consortium) -> My Region (Region) -> My Branch (Outlet)

But not this:

My Consortium (Outlet) -> My Region (Department) -> My Branch (Consortium)

> Will this cause a problem for us down the road?  Should I delete/re-order/whatever I have to do to get these to match up?

Feel free to share with us what you're considering.  A simple library
could get away with a single org unit and org type, and push the brunt
of classification into Copy/Shelving Locations and into Call Numbers.
But org units are useful for defining political, geographical, and/or
functional boundaries between and within libraries.  Different
behavior (circ policies, loan durations, etc) can be associated with
different org units, and with different org unit types.  Org units
that are "children" of parent org units can inherit the behavior of
their ancestors in the hierarchy.  When an item moves between org
units, it's "transiting".

I would recommend at least two org units for anyone expecting to gain
new branches or form consortia.  You can always add more org unit
types later if needed, and a flexible hierarchy gives you more logical
insertion points for new libraries.  So, even if all you have is
Library A, it's useful do something like this to make it easier to
grow later:

My Libraries (Consortium) -> System A (System) -> Library A (Main
Branch) -> Genealogy (Sub Library), Kids (Sub Library)

Then it'd be easy to later insert a Library B into your hierarchy, or
even form ties with an independent System C, etc.

Does this help?

-- 
Jason Etheridge
 | VP, Community Support and Advocacy
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  jason at esilibrary.com
 | web:  http://www.esilibrary.com