Book Publishing Accounting System:
Evolution 1

Tyler Bletsch, Duke University
January 4, 2026

Introduction and Use Cases

This system will serve the following use cases:

• The system will track books published and provide a means to manually record sales information.
• The system will assist in tracking and disbursing author royalty payments.

Definitions

1. Implementor: Refers to you, the software developer. Items described as “at the implementor's discretion” or similar indicate free choices. However, “free choice” does not mean all choices are of equal merit; your overriding goal must be software quality.
2. Extra credit: Some requirements are left up to the implementor's discretion and are labeled “extra credit”. Naturally, you don't have to do these. Further, you can choose when to do them: you will receive the awarded extra credit points in just the evolution in which the feature first appears. Exact values of extra credit are not given, but as with all credit, will be commensurate with the scope of work anticipated.
3. Publisher: A business entity that agrees to produce and market books for one or more authors. Larger publishers do their own book printing, smaller ones are "Print-On-Demand" (POD) publishers. POD publishers rely on distributors (def 4) to do the actual printing. A POD publisher is the intended audience for this software.
4. Distributor: A wholesale distributor of books. For POD publishers like HP, distributors such as Ingram Spark and Amazon also serve as printers of the physical books.
5. Consumer: The actual end-customers for books. They typically pay the cover price (def 7).
6. Printing cost: The cost to print a given book. This is computed by the distributor based on book length and the printing options selected by the publisher. When a publisher buys books direct from a distributor, this is what they pay.
7. Cover price: The retail price of the book as paid by consumers. This is what bookstores and Amazon will nominally charge.
8. Wholesale price: The price paid by independent bookstores and similar bulk purchasers for the book. Standard practice is for this to be a 55% discount from the cover price (so wholesale = 45% × cover_price), but this is not a requirement.
9. Publisher revenue: The money paid to the publisher by the distributor. This is generally wholesale price minus the printing cost (possibly adjusted by some fees).
10. Author royalty: The money paid from the publisher to the author based on sales (or, more precisely, publisher revenue). Each book has a negotiated author royalty rate, expressed as a percentage, often 50%. The author royalty is publisher_revenue × author_royalty_rate.
11. Unique: Requirements may describe a given field (or combination of fields) as unique. This means that there may be at most one record with that value (or combination of values). Attempts to violate uniqueness should generate an error, unless otherwise specified in the requirements.
12. International Standard Book Number (ISBN): A standardized number that uniquely identifies a printed book. A separate ISBN is assigned for each variation of a book (i.e., separate editions, formats, or translations of a book all are numbered separately). May be an original 10-digit ISBN (often called "ISBN 10") or a more modern 13-digit one ("ISBN 13"). An ISBN 10 can be algorithmically converted to an ISBN 13 starting with 978, but a newer ISBN 13 starting with 979 is not backwards compatible. ISBNs have dash separators placed in different ways depending on subtle details, therefore, dash separators should be ignored when using the ISBN as a lookup. See Wikipedia for details.
13. External database: A third-party service that provides an API for looking up facts about a book, e.g. via its ISBN. The system may make use of one or more external databases to ascertain facts about books to be sold without having the user input every detail. Examples include Open Library and Google Books, but there are many more. Some are paid services; it is not necessary to use a paid service, but you are allowed to (on your own dime).
14. Monetary value: An amount of money specified in United States Dollars (USD), e.g., $15.99. No fractional cents permitted unless otherwise specified.
15. Book: A book published by HP. Defined by fields:
    • Title: The title of the book. Short text field, required. May be acquired from external database.
    • Author(s): The author(s) of the book. Short text field, required. If a book has multiple authors, the user will indicate this inside the field (e.g. "author1, author2"). May be acquired from external database. This field should be stored with whitespace normalized (def 17).
    • ISBN 13: The 13-digit ISBN number for the book. Required, unique. May be acquired from external database.
    • ISBN 10: The legacy 10-digit ISBN number for the book, if present. Optional, unique if present. May be acquired from external database.
    • Publication month/year: The month and year the book was published. Required. May be acquired from external database.
    • Author royalty rate: The percentage of publisher revenue passed along to the author as a royalty based on sales. Required. Defaults to 50%.
16. Sales record: A record of a sale of a given quantity of a given book in a given timespan. Sales records are provided by a distributor and input manually. Defined by the following fields:
    • Month/year: The month and year of the sales period in question. Input, required.
    • Book: A reference to the book being sold in this record. Input, required.
    • Quantity sold: A non-negative integer number of books. May be zero if the user wishes to make clear a lack of sales in the system. Input, required.
    • Publisher revenue: The non-negative monetary value in USD total received by the publisher for these sales. Input, required.
    • Author royalty: The non-negative monetary value in USD total to be paid to the author for these sales. Input, required. This should default to book_author_royalty_rate × publisher_revenue, but can be overridden.
    • Author paid?: A boolean indicating if the author has been paid by the publisher for these sales.
17. Whitespace normalized: A string transformation wherein whitespace is trimmed from the front and back of a string, and all inner whitespace is transformed to single spaces. Equivalent to the Python:
    

      ' '.join(s.split())

Requirements

1. Server
   1. Your software must have a server that supports an arbitrary number of simultaneous users. A web-based solution is preferred; thick client or mobile options are available with instructor pre-approval only.
   2. During the install/setup process, an administrator user called admin is configured. This is the only user of the system.
   3. A user accessing the system prior to logging in should be able to access nothing but the means to login.
   4. Stored passwords must be kept in a secure manner (i.e., salted and hashed at minimum).
   5. The user may change their own password using the customary two-matching-blinded-inputs approach commonly seen.
   6. A user may log out of the system.
   7. All communication between the clients and server must be encrypted. Tip: For web-based solutions, this means using HTTPS. One easy way to get this working is to use the free Let's Encrypt certificate service and their accompanying certbot tool.
   8. The server must maintain state in a persistent fashion. Tip: For web-based solutions, this just means using a database or similar.
   9. Pagination rule: For all views which show a potentially unbounded number of records, the response time of the interface shall not depend on the quantity of records unless a full listing is explicitly requested by the user.
      Tip: This implies some form of pagination so that only a finite number of records are retrieved at a time. Pagination can be explicit (page 1 of N) or implicit (infinite scrolling with auto-loading). The latter part of the requirement (“unless a full listing is requested”) implies a “show all” button or similar. Other UI solutions are likely also possible. If doing explicit pagination, don't do so excessively (e.g. showing only 10 records at a time).
   10. Consistency rule: A variety of cross-references are made by the system; the system must maintain internal consistency of these references in all cases. For example: if book X has 5 sales records, then each of those sales records should refer to book X.
   11. Assisted selection: A user input is said to be assisted if it is a user-selected reference to an existing record (e.g., a book) where the UI provides a listing, inline search, autocomplete, and/or other means to allow easy and efficient selection. Unless otherwise specified in this document, all selections of an existing record should be assisted. For dates, a date picker UI should be displayed.
   12. HTTP-compliant URLs: Web-based systems should use URLs correctly. This means, among other things, that (1) it should be possible to bookmark a URL for a particular view (e.g. a book detail view, req 2.2) and revisit it to see the same view, (2) GET and other "safe" HTTP operations do not have side effects, (3) transactions with side effects are constrained to POST/PUT/DELETE operations, and (4) the browser's natural back button functions correctly. This is sometimes called being "RESTful" (though that term is often used in relation to web-based APIs rather than user-visible URLs). Formally, this means compliance with RFC 7231.
   13. Home page: Upon login, the user should be taken to the book list view (req 2.1).
2. Book management
   1. Book list: The user will be able to view a table of books with columns for title, author, ISBN 13, ISBN 10, publication month/year, author royalty rate, and total sales to date.
      1. The view should be sortable by any of the displayed fields.
      2. It should be possible to filter this view by a keyword search that covers title, author, and either ISBN.
      3. Users should be able to navigate from this to a detail view for a book (req 2.2).
      4. From this view, it should be possible to begin creation of a new book (req 2.3).
   2. Book detail: The user may view a detail view of a book showing all fields. From there, the user may request to modify (req 2.4) or delete (req 2.5) the book.
      1. Within this view, all sales records should be shown for the book in a manner similar to req 3.1.
      2. Totals should be shown for publisher revenue, unpaid author royalty, paid author royalty, and total author royalty.
      3. It should be possible from this view to create new sales records for this book in a manner similar to req 3.4 (possibly minus the features for rapid input of multiple records). The implementors may achieve this by providing inline UI features or by allowing the user to navigate to an appropriate creation view.
   3. Book creation: The user will be able to add books to the system as follows.
      1. The user will input the title, author(s), ISBN number(s), publication month/year, and author royalty rate (defaulted to 50%). Constraints specified in definition 15 will be enforced.
      2. (Extra credit) External database import: Implementors may elect to also allow books to be added by simply inputting the ISBN number (either ISBN 13 or ISBN 10), then using an external database (def 13) to pull down all relevant fields. The user will then have the ability to modify the fields as needed before saving. If the user aborts before saving, no book is created. In this process, the author royalty rate will default to 50%. The manual book creation process is still needed even if this is implemented, e.g. for books new not yet in the external database.
   4. Book modification: The user may modify a book to change editable fields in a manner similar to creation (req 2.3).
      1. Changes to the author royalty rate must only affect the default royalty computation in future sales records (e.g., in req 3.4). It should not have retroactive effects on past sales records.
   5. Book deletion: The user will be able to delete a book as follows.
      1. A highly visible confirmation dialog must be confirmed first. This dialog should reiterate the title and author(s), and make special note if existing sales records have been recorded for the book. Only upon confirmation will the deletion occur. The effect of deletion on historical records as at the discretion of the implementor: they may be retained or removed, but in any case, the system must make clear what is happening. This operation should be quite rare, likely used only to remove books added in error (e.g. duplicates).
3. Sales record management
   1. Sales record listing: A tabular view of sales records with columns for book title, book author, month/year of record, quantity sold, publisher revenue, author royalty, and a visual indicator differing in both color and shape of if the author royalty has yet been paid.
      1. The view should be sortable by any of the displayed fields. The default sort should be descending by record month/year (newest first).
      2. It should be possible to filter this view to a date range.
      3. Users should be able to navigate from this to a detail/modify view for the sales record (req 3.3) or the detail view for the referenced book (req 2.2).
      4. From this view, it should be possible to visit the sales input tool (req 3.4).
   2. Author payments view: A tabular view of sales records with fields similar to req 3.1. However, the view is grouped by and sorted by the author(s) field, then further sorted by descending by record month/year (newest first). For each author, a subtotal of unpaid author royalty payments should be shown.
      1. For each author, next to the unpaid total, a UI element should be provided that, after an additional confirmation dialog, marks all unpaid sales records for an author as paid. In practice, the user will use this view to issue payments to authors and mark them paid in the system.
      2. Users should be able to navigate from this to a detail/modify view for the sales record (req 3.3) or the detail view for the referenced book (req 2.2).
      3. From this view, it should be possible to visit the sales input tool (req 3.4).
   3. Sales record detail/modify view: The user should be able to view all fields associated with this sales record. From here, the user can modify the month/year, book reference, quantity sold, publisher revenue, author royalty (overriding the author royalty rate calculation), or author-paid status. It should also be possible to delete the record; this will require a confirmation dialog.
   4. Sales record input tool: This view will facilitate rapid input of sales records. It is presumed that the user will by copy/pasting from web-based, PDF, CSV, or other records provided by a distributor, a tedious task which your UI should seek to optimize as much as possible.
      1. The user will be inputting multiple records at once from this view. They will input the month/year and book. The selection of book should be assisted, allowing keyword search by title and especially by ISBN 13 or ISBN 10 in any format (i.e., dashes ignored). Books should be rapidly autocompleted in a minimum of clicks/keystrokes. The user will the input quantity sold and publisher revenue. Once publisher revenue is input, the author royalty should be auto-populated as (the book's author royalty rate) × (the publisher revenue). If it is overridden by the user, the number should be shown distinctively to indicate that fact, and if the number is deleted, it should revert to its computed value. The author-paid boolean should default to false.
      2. The user can then navigate to input another record. It should be made efficient for the month/year or book to "drop down" to this next input, as the user is likely inputting multiple sales from one reporting period or multiple sales for one book.
      3. In the above operations, care should be taken to allow for efficient input. For example, additional input fields should simply appear without the need to click "add another". Similarly, standard keyboard shortcuts should be maintained, e.g. using Tab to switch between fields. All inputs should be validated per def 16.
      4. When done, the user can review the input records before clicking a confirmation button to commit them all to the system at once.
4. Documentation
   1. Developer guide: A document shall be provided which orients a new developer to how your system is constructed at a high level, what technologies are in use, how to configure a development/build environment, and how the database schema (or equivalent) is laid out.
   2. Deployment guide: A document shall be provided which describes how to install your software entirely from scratch. It should start by describing the platform prerequisites (e.g., Linux distro, required packages, etc.), then mechanically describe every step to deploying your system to production readiness.
   3. Feature guide: Optional. If an extra credit requirement is pursued, document its design, benefits, and a walkthrough of how to demonstrate it here.