Best MERCI approach for Resources like Studios?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
stefanwray's picture

This is a discussion about what is the best approach in MERCI for dealing with Resources that comprise a number of additional Resources, Buckets, and/or Accessories, such as a Studio.

The Open Media Project Handbook section on MERCI defines 3 types of equipment available for checkout:

Resource - Individual items that are unique. Example: Studio A vs. Studio B

Bucket - Items that are identical or so similar that users don't care which one they get. Example: DV Cameras

Accessories - Items that you don't track other than to ensure that if someone takes one or more with other equipment, it is returned. Examples: Batteries, lens cap, usb cable.

For purposes of what equipment is exposed to users via MERCI on a web site, this differentiation is clear.

However, MERCI is also meant to be an inventory tool.

In the definition example above, Studio A is a Resource. Yet Studio A is also comprised of any number of other Resources, Buckets, or Accessories.

At channelAustin we have the Main Studio.

To the external user (i.e. producer who uses MERCI to make a reservation), the Main Studio is a Resource, because the Main Studio is a unique item.

But to the internal user (i.e. staff tracking inventory), the Main Studio is a unique item, yet it contains a number of separate Resources (i.e. TelepPrompter), Buckets (i.e. studio cameras), and Accessories (i.e. variety of cables and connectors).

In Facil -- channelAustin's current inventory database -- the Main Studio is listed as an Equipment Type. Every equipment item (Bucket, Resource, or Accessory) that exists within the Main Studio space (cameras, switcher, monitors, audio board, computers, etc.) all have "MAIN" as the equipment type. This is technically inaccurate but it is the way the Facil database has evolved over time. In fact, "MAIN" is more of a location type, or end-use type, than an equipment type.

Nevertheless, the structure of our implementation of the Facil database has influenced our approach to designing the MERCI database. Until this point, we've been thinking that we would simply transpose our Facil method into MERCI and create a "Main Studio" content_type in MERCI, and add all equipment items that exist within the Main Studio underneath that content_type.

That's now clearly a wrong approach. Main Studio cannot be a content_type because then MERCI would treat it as a bucket. And it's not. It's a singular resource.

We can designate the Main Studio as a resource in MERCI.

The question then is how do we treat the numerous equipment items that comprise the Main Studio, which will never be checked out as separate items but still need to be part of the inventory, and still need to be associated, as a group, with the Main Studio Resource.

It is easy enough to create a content_type of "camera_main_studio" to be used for the 3 HD cameras on the Main Studio floor.

But what is the best practice approach to link or connect these cameras with the Main Studio Resource?

  • Option 1: Facil has a "location" field for each equipment item where we can put a room number value. In MERCI, this could be: field_merci_location or field_merci_room_num. That location value could be a way to group equipment. Using Views we could produce a list of equipment in that room. Only problem is the Main Studio has several rooms, so there would be several values for field_merci_location or field_merci_room_num
  • Option 2: We could create another field to indicate when there is a parent resource. In MERCI, this could be field_merci_resource_parent. The values would either be NULL if no parent, or whatever the parent is; in this example, it's "Main Studio". Similarly, Views could be used to generate a list of items that have "Main Studio" as value.
  • Option 3: I see in DOM's MERCI Master Inventory field list, there is a field called field_merci_child_items. Perhaps this could be a way to designate within a parent Resource a list of the child items (Resources, Buckets, Accessories). This, though, seems like it could be unwieldy with a resource like the Main Studio that has many sub-resources.
  • Option 4: Perhaps instead of adding a merci field of field_merci_whatever, there is a good way to use Taxonomy. I don't have a specific solution in mind.

It'd be great to see a discussion on the merits of these options or other solutions that are even better.

Comments

Invintory v. Checkout

PetePO's picture

Stefan,

I wrote a somewhat detailed reasoning of why I found that MERCI wouldn't work as an inventory system for PCM (who uses Facil in a very similar way to you) on a thread back in the day here.

When we determined the requirements that we had for an inventory system while looking at MERCI it became clear to us that Facil did not serve the inventory functions we needed it to fulfill either.

Makes sense in the fact that we had an accounting inventory system that ran along-side Facil (public facing inventory) which was always more accurate and up-to-date than Facil.

But, to answer your question, I would love to see some development on MERCI as a full inventory system in the future. For now though I believe it's best used as a checkout system for CMCs. Option 3 seems like the quick-and-easy approach but option 4 would have to be the end goal in my mind.

If I'm understanding everything right Option 4 would give the ability to set the variety of best-practice information (ex: depreciation rate, replacement date, service dates etc....) that we found we needed at PCM.

johnthatcherjr's picture

pete. there's a sub-module in merci called merci inventory. this sub module create a content type called merci inventory master. the merci inventory master content type can be customized with any fields that are needed to meet and organizations' needs. the fields on this content type can be 'pushed' to other merci enabled content type.

stefan. a little feedback on the options you present.

* option 1: location field. would the studio be both a bookable resource and location option? would other equipment items in studio be bookable?
* option 2: parent field. would you want all the nodes in the inventory to be available in a drop down list for this reference? additional development would be needed to make this work. 
* option 3: child items field. this a free form text field and likely wouldn't meet your needs. 
* option 4: taxonomy. this might work but depending on how you implement it, you risk a sloppy user interface. 

some other solutions that might work:

make studio a bookable resource. make the other inventory items in the studio non-bookable items. (user reserve only the studio and you infer usage of the other items equipment items in the studio based on the usage of the studio)
pro: simplified user interface
con: no direct relationship of equipment usage on reservations for the studio and all the item in the studio.

create a merci reservation template (before navigating to the node/add/merci-reservation, they click on a template link that directs them to node/add/merci-reservation populated with all the item in the studio)
pro: direct relationship of equipment usage on reservations for the studio and all the items in the studio.
cons: cluttered user interface (each item in the studio will be visible and available for booking). the user process would need to be modified for this workflow.

finally, a couple of questions to help you figure out the best approach.

  • can user book the studio and equipment in the studio separately?
  • is there reporting that necessitates the studio and the equipment in the studio be reserved together?

Seems that other systems can handle inventory better

PetePO's picture

John. Totally understand that you can configure MERCI/Drupal/etc. to do inventory functions but it seems like more work than is necessary for the intended results.

At PCM we couldn't commit to that level of configuration for functions that were better served using our existing non-checkout based inventory. But every station's needs and resources are different. Don't want to rain on anyone's parade.

Also - I think PCM is still using Facil so take my comments with a grain of salt. Just did about 30-40 hours of work with them tackling this problem like a year ago and haven't worked there for a long time.

-pete

Clarifiying MERCI Issue

stefanwray's picture

Thanks Pete for your thoughts on the utility of MERCI as an inventory system. There may very well be other non-MERCI open source inventory solutions. I don't know of any. We're not exploring those now. Our efforts are aimed at making MERCI work the best for our needs. Our inventory needs are probably rudimentary compared to some of the more complex inventory systems that include what you're talking about: depreciation rate, replacement date, service date, etc.

We need to keep track of: tag number, model, manufacturer, description, serial number, status (available, assigned, repair, etc), owner, location, purchase date, purchase cost, notes.

With the MERCI Inventory Sub Module, as John mentions, we can create all these fields for each equipment record.

John, to answer your questions:

* can user book the studio and equipment in the studio separately?
* is there reporting that necessitates the studio and the equipment in the studio be reserved together?

To the first, when producers want to use the Main Studio, they book the Main Studio. They do not book the equipment that lives permanently in the Studio. They do, however, book microphones separately, because those are kept in the equipment room. And there are some specialty items checked out separately that can be taken into the Studio.

To the second, reporting requirements don't dictate that studio and equipment be reserved together.

A typical use case is for a producer to reserve the Main Studio, along with several Lavalier Mics and several XLR cables.

So, if we have the Main Studio in MERCI as a bookable Resource, the Lavalier Mics as bookable Buckets, and XLR cables as bookable Accessories, then we're good.

This part isn't the issue.

Here's what we want to do:

1) We want to include in MERCI both the bookable and non-bookable equipment items. (i.e. all inventory items)

2) Some of the bookable items will have non-bookable items associated with them. (Like the Main, which is bookable, and all the pieces that make up the Main, which aren't bookable separately, but come with the Main.)

3) We don't need the public end-user (public facing checkout on MERCI) to see all the non-bookable items (i.e. when they book the Main Studio, they just see Main Studio in the list)

4) We don't want the non-bookable items to just simply be floating around in MERCI not connected, or associated, or linked to the parent item. We would like staff to be able to have a view on all gear.

So this is how I arrived at Options 1-4. Regardless of which Option is chosen, I'm thinking that we would use the Views module, in order to generate a specific View of the specific child items of a parent Resource or Bucket.

Regarding OPTION 1: Using the Location Field (Room Number) would be a common value to extract a View. We have a Conference Room. That Conference Room is a Resource. It has a Room number. It is bookable. It also has an overhead projector, a screen, a monitor, furniture, etc. None of those items are bookable. They come with the room.

Staff might want to pull up a list of all equipment in that room. So filtering off a Location Field (with Room Number) seems to make sense on that. (Don't confuse this Location with the other parts of OMP called Location).

Regarding OPTION 2 and 3: Here I'm thinking of establishing a relationship between parent equipment items and child equipment items. And the question is whether it is better to list child items within a field in the parent, or list the parent within fields in the children.

Let's use another example. We have a room called Master Control. By definition, Master Control is a Resource. But it's not-bookable. Nor is anything in Master Control bookable. But we're going to want to include all these specific items in our inventory in MERCI (not right away as the priority is checkout equipment).

Staff would want to have a View on all the equipment (most of it unique items, i.e. Resources) that exists in Master Control. So would it be better to have each of the sub-items that fall under the category of Master Control have a field with something like field_merci_parent_equipment?

Adding a Node Reference that

kreynen's picture

Adding a Node Reference that allows multiple values that is limited by a View of only MERCI buckets or resources gets you part of the way there.

1) We want to include in MERCI both the bookable and non-bookable equipment items. (i.e. all inventory items)

Currently the MERCI Inventory sub module only synchronizes content types that are managed by MERCI. When sreynen originally wrote that as part of the bounty program, we talked about making a generic CCK Field Synchronization module, but ran into challenges that were going to take too long. Unfortunately, I can't remember what those where.

Obviously you could manually add the fields to the non-MERCI content types.