Your question is not very clear and maybe some images with the options you thought might have been useful. To try to help I'm considering that in your system (Accounts Receivable) you have a list of records (ie, tickets or accounts arranged in a "scrollable" table), and that your question is about the better (from the usability point of view) way to allow the user to apply the following actions to the records:
- Edit
- Delete
- Print Ticket
- Email ticket
- Set as received
- Set as not received
Considering that there may be numerous records that you want to delete, print, or email, it seems to make sense to allow them to select the desired records and perform the one-time action (perhaps through a button, as you yourself suggested). This alternative (as opposed to having the user perform the action for each record) is more efficient, and therefore potentially better for usability. In this case, since the action is immediate (records are simply deleted!), It also makes sense to confirm such interactions before executing them (as well as the Usability error prevention and safety principle).
Editing is something that seems to make more sense to be done individually, because while editing an account the user keeps his context frame in memory (that is, his whole limited consciousness is focused on that account). So it probably makes more sense to put the option that gives access to this function in the registry line.
Maybe this is also worth for the definition of the account as received or not, especially if it is a matter of just toggle ) a graphic field such as a check box . If, on the other hand, the definition is received or does not have important consequences (for example, once an account is marked as not received, to be marked as received it will need to be properly processed with insertion of data into other systems - perhaps a fiscal module?), the principle of security and error prevention applies, in which case it may be better to treat such action as delete, print, and send by email (that is, allowing selection and execution in bulk) ( in bulk ).
It should be easy to see that there are some important "SE's" in the previous paragraphs. The fact is that these "tips" are heuristics (understand how best practice rules) that you can use to build and evaluate your interface yourself. In fact, if you look at similar systems (e-mail records are the most classic example), you will see that these problems are generally treated in ways similar to those I exemplified.
But, it makes a lot of sense for you to test prototypes with your potential users. So, will you be able to understand which design goals are most important to each action (performance, security, memorization?) And thus define properly what to treat as "best" in your problem domain (not the same as the one I used italics in that word in the first paragraph). :)
