On one hand, it reads like you don't want to create a table because of Runtime but that may be the best answer. On the other hand, it seems you're suggesting a table of document prefixes. Perhaps break your document number into fields, one field for each portion, and string it together in forms and reports. However, without a table of prefixes, anyone can make a typo and create HE instead of HR, which means you'll lose track of documents.
As for the number, it introduces the issue of how to create it. One way is a table of numbers that are flagged as having been used thus not available, but that requires maintenance on the table. If that process fails, you can end up with non-continuous document numbers, which should not be an issue but it is often perceived to be.
Another is to get the DMax of the number field, which raises another issue. If this is a multi-user db and 2 people begin a record on the same category, both can have the same next number, which would be bad for data if the fields are not properly indexed so as to prevent dupes. If they are, the last one to commit the record gets an error message.
Another approach is to assign the number only when the record is saved, which means they don't know the number until it's all done. IMO, that should not matter.
I actually built and marketed a document and record db long ago. This db even made a linkage between documents and records, which did things like prevent document obsoletion if there were associated records that had not also been obsoleted.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.