itemCost Field on item record

Current situation or problem:

In FOLIO, there isn’t currently an adequate and consistent field to store an item’s monetary value. In every story or feature request for actual cost, one resounding prerequisite is this value existing on the item record. Spokane Public Library has an automated process of billing Actual Costs for items based on an item note value. A similar solution that could be implemented in FOLIO proper, but once again depends on this prerequisite field.

1. The Resource Access SIG has agreed that there is a need for this field in every proposal for Actual Cost.

2. SIGs that have discussed, reviewed, contributed to, and recommended the implementation of the Item Cost field on the Item Record:
   Folio Implementors SIG
   Resource-Access SIG
   App Interaction SIG

3. This may satisfy the needs for topic #91 of the Acquisitions/Resource Management implementers board.

4. As mentioned, I see having this at the item level (rather than Title or Holding) as the most valuable as it enables the granularity needed for some institution. But, perhaps, a hierarchical model (e.g. Effective item cost) that could be inherited from Titles and Holdings would be a benefit.

5. Spokane Public Library currently uses an Item Note called LostCharge (as mentioned above) and has a scripted and fully automated Actual Cost solution to handle the thousands of billing processes per day. This Item Note gets populated with PO Line details during fine creation, but the Item Cost field could *hopefully* be populated during new order item creation instead.

Perspective from Spokane Public Library:

In the month of September 2024, 16,038 billing actions took place in for 8,019 Aged to Lost items. This averages 535 billing actions for 267 Aged to lost items per day during the period (Lost process fee and Lost item fee).

Of the 619,754 items checked out in the first 10 months of 2024, 10.96%, remain unreturned. It’s only because we store the Item Cost value in a note (as a workaround) on each record that we know this values $1,309,270.43. There needs to be an official location for migrated item cost metadata as the first step towards an automated Actual Cost billing solution.

In scope
Put item cost field on the item record.

Out of scope
Populate the Item cost field with any data.
Determining/interacting with currency type.
Any work related to Actual Cost.

Use case(s)

1. Reference this value during the manual adjustment of Actual Cost fines.

2. Eventual implementation of Automated Actual Cost billing as proposed in [UXPROD-5094] Proposal for Automated Actual Cost Billing - FOLIO Jira

3. Some items are purchased at varying prices based on contracts, time of acquisition, donated items, etc. Having this at the item level (rather than Title or Holding) enables the granularity needed for some (if not most) institution.

4. Migrating libraries can import their Item Cost metadata from their previous ILS into this field without the creation of an archival “fake PO” for referencing their entire collection(s). 

5. Circulation staff are not always able to spend time verifying prices, so it is helpful to have the cost on the item and visible in inventory, even if it is not currently based on the invoice cost.

   1. Libraries might want to depreciate/appreciate the item cost over time, which would be possible to do with the item field, leaving the original item price on the POL intact for auditing/archival purposes.

6. This can be queried on for “accounts receivable” or “total value of collection” reporting for Public Libraries (required by Secretary of State in Washington State).

   1. E.g. SUM of itemCost where status.name = “Checked out”
      E.g. SUM of itemCost (for total value)

7. Sometime in the future: During the order creation process, when the item is created, have the Physical unit price from the PO Line details populate the Item Cost field on the item-record(s). Rather than referencing the PO during fine creation, as suggested in UXPROD-2245, the Item Cost will be created at item creation.

Proposed solution/stories

In the JSON, itemCost could live near the purchaseOrderLineIdentifier or simply before materialType.

"purchaseOrderLineIdentifier": "d9aea603-a278-45ac-8c10-01c0a1ee5fe6",
"itemCost": "20.00”
    "materialType":

MM-SIG: Materialized view in FOLIO should live under/in the Acquisitions accordion:

Open

Note that the edit screen does not have the “Acquisition” accordion, but example of how that would look.

Open

Materialized rendering uses system-configured currency symbol configured in Language and localization option(s) in settings:

Open

What should the field accept as a value: Currency.

API interaction with field: Yes, delete/get/put

Links to additional info

https://folio-org.atlassian.net/wiki/spaces/RA/pages/2265788/2023-10-05+Resource+Access+Meeting+Notes

Acquisitions/Resource Management implementers - Acquisitions SIG - FOLIO Wiki