I think this would look better as a one liner:
return isElectronicType ? RequisitionStatus.listRequestOptions() : RequisitionStatus.listOutboundOptions()

We're going to need to rethink all of this as we redesign the API over the next few months.

This seems to be one of the most complicated methods in the system and it's at-best an NPC. This tells me that we did something wrong somewhere along the way and we should use this example as our guiding light to undo some of the complexity.

My first problem is that I never liked the distinction between paper and electronic requests. I know there was a reason for it, but as we went down the path of supporting electronic requests, we never revisited whether this was the best approach for handling that distinction. So this needs to be redesigned to be more intuitive.

Secondly, this method should probably be called getRequisitionStatusCodes() or getRequisitionStatuses() since it doesn't return outbound requisition statuses any longer.

But the fact that this is so complex means we probably messed up somewhere else. This might be caused by the fact that enum might not be the right construct for what we're trying to accomplish.

I think a large part of the problem is that Approval should have been implemented as a separate state machine. This is becoming clear to me because we should be able to apply the approval model to any of our activities: requests, purchase orders, supplier preferences, receipts, etc.

Can we add some additional context for each of these to provide a reason why we are restricting the options? You could potentially find this information in the ticket.