Comment 2 for bug 2007322

I need more coffee to follow the main thought thread, but fwiw we've been running the fix for that bug in production since our upgrade in January. We do have one library that has a system-level orderer but uses decentralized funds, so I felt *sure* that you were wrong but upon investigation found that no, you're right. :) So marking this Confirmed. But then I had to wonder why it's not an issue for us, and so here's my thoughts on our use case.

We have a SYSTEM-ACQADMIN perm level that has a VIEW_FUND at system level. So this orderer has access in fund administration to all funds because she's the one who manages the money. However, she only does ordering for one branch. So in her dropdowns, she only really wants to see the funds for the branch she's ordering for.

In cases where there's true centralized ordering, we don't use decentralized funds even if they're ordering for multiple locations. The main reason we came to that standard is because of the Load MARC Order Records interface. You have to set an Ordering Agency in the form, but if you're uploading funds in your holdings data and those funds have multiple owning orgs, you're going to get errors because EG can't match up the Ordering Agency in the form with the owning org in the funds. So with centralized ordering, we set all funds as owned at the system level and then in the fund code it will indicate the branch. The thought process behind where a fund is owned is "who is ordering this?" For decentralized ordering, it's the branch, so they only want to see their own branch's funds. For centralized ordering, the system is ordering, so the funds are owned by the system.