Assuming the bookshop has these three users of the ledger:
The Owner: He/she would have full access and privileges.
The Accountant: Major changes in the finance structure would be limited to the accountant. But would have full access in introducing new clients or supplier as well as the ledger's reporting tools
The Cashier: He/she would be involve only in entering sales and/or supplier (vendor) data - no privileges beyond such postings.
Once the Admin user is set for a particular dataset,(eg. admin@bookstoredb), he/she can login and set users via HR->Employees. For an employee to have access to the ledger is done by giving the employee a login username and password. Then via the 'access' button at the bottom of the page, specific access is set by activating/deactivating the list of menu items that appear. An access set of one employee can be copied to another by simply renaming the existing employee with the new info, saving "as new" thereafter.
b. Data Structure of Ledger and related Financial Documents
There are some areas here that require planning prior to establishing a SQL-ledger database (or dataset as it is called therein):
Chart of Accounts: The default settings for the dataset is a VAT tax-related British style Chart of Accounts layout. It's quite suitable but one may consider the other offerings by deleting and re-creating the dataset with the new choice. Account items set by these default settings can easily be modified. The account numbering of 5 digits offer a number of advantages, eg. for making adjustments, for reporting. Note: When creating some of the new accounts, one made need to remember to tick the box beside ‘Allow GL Transactions’ so that those new account appears in the dropdown list in GL Transactions.
Stock Codes: For data entry, it is critical to get a good coding structure, as codes are sorted in alphabetical order. For example for a bookshop setup, a 8 character code is suggested wherein the first two characters code for the author, the next four for the book title, one character for it's role (Teacher's or pupil's book) while the last character would define the language (E - English, F - French etc.) Example: RHBK03TE - Ruhi Book03 Teacher's edition in English.
Client/Vendor Codes: A short code will provide an easy lookup for any particular client or vendor (supplier). For example: CBC01 - Continental Board of Counsellors.
Invoice, Credit/Debit Notes: It's recommend to a two or three character code followed by four digits to make follow-up easy in the reporting/review of these documents. For example: INV0001 for the first invoice. This holds true for all other documentation eg. Local Purchase Orders etc. Such numbering preferences can be enforced in the system default settings (eg. enter in 'Sales Invoice numbering' the value '00001') - the same is recommended to be done for the other transaction sets.
Staff Records: SQL-ledger (currently) has a Human Resource module: The Payroll and it is handled under HR. Note: SQL-ledger essentially handles employees as 'Vendors' and as such may be a better alternative and control than with the 'Payroll'. While payments can be handled via AP 'Payment(s)', one should always use 'Add Transaction' under HR to post wage expenses and not vendor invoices. Staff Codes could be created to be easily recalled as opposed to vendors; Example: EMP01 ...EMP100 and vendors VEND01...
Other Considerations - Department/Warehouses etc: A bookshop made have another warehouse or even another outlet. These can handled by creating warehouses and/or departments. Goods (books) then can be posted to a particular warehouse via a supplier's delivery note. Users related to a certain department will be tagged accordingly in the user setup process. There are many other secondary but excellent features in SQL-Ledger that are not listed here.
Organizational Finance Policies and Government law: Such as tax rates and Social Security. Taxes (eg. VAT) with their rates can be modified and set in System -> Defaults. NSSF can have its own liability account.