First, yes he probably can assign that work.
Getting domain knowledge is a critical skill for any senior developer. So this is what I trained to do to get such info when I designed process improvements back when no processes were computerized.
First, observe the work and take notes. Put all the questions you have aside until you have observed for awhile. Get copies of all forms or paperwork they have. Keep a clean copy and then write questions on another copy. Try to follow the process through. When one person finishes a piece of paper, follow that paper to the next person. Look for who has to approve or sign off. Look for who needs to fill out which fields. Some of your questions should revolve around what happens in the edge cases (such as when an approval is not given).
Look for the laws/regulations (don't forget state laws and regulations if in the US) on the subject in a google search and read them and take notes. Try to compare what the law says with what is really happening. In the US search for GAAP (generally accepted accounting principles). these documents will greatly help with the financial end.
Ask questions about problems in the current system. These are the things you want to show them, your project will fix as well as being as easy to use as the current system or easier.
Put it all together on a flow chart. Talk to their management once you have an idea what is currently happening. They may cooperate more if they see you are not going to bug them for everything. Remind those who don't cooperate that they will have to live with what you build, the time to get what they need is before you build it.
Always start with the lower level people who actually do the job you are automating. They know things the boss does not.
Part of what you are running into may be resistance to change. Do some reading on that and how to handle it. People who have not automated their systems by now are going to be VERY resistant to change.