Phoenix Books

BookERP is meant to hold more than one publishing house. Phoenix Books is the pilot. Before it, titles, print quantities, and the warehouse count lived in Excel, and the warehouse count was one cell. Quotations, challans, and the cash book were other files, or paper. Accounts retyped them at month end.

Whoever saved the stock cell last replaced the number. A lower count might be a sale, a transfer, or a typing error, and the file cannot say which. The title on a bill can drift from the title that was printed. A fiscal year running Shrawan to Ashadh, with VAT split out of the total, stays in order only if nobody inserts a row. Another house would need its own copy of the workbook. The spreadsheet also had no seat for the person outside the house who admits an organization and turns its areas on.

Each house is an organization inside one application and one database. Sign-in binds you to that house. An operator outside the house admits organizations and decides which areas are on.

Staff enter the work, the writers, and the edition. The edition gets a short code, which can be printed as a QR on the cover and open a public page. They plan a print run: how many copies, the cost of each, and the date on both calendars. Receiving those copies is a stock line. Sales, moves between warehouses, and corrections are lines too. The screen shows what is on hand, what an order is holding, and what is still free.

An order can set copies aside. The invoice closes the sale, and accounts works from that invoice. A correction is a new line that reverses the posted one. Bill numbers follow the fiscal year, and a second print is marked as a copy. At the counter, the day sits on a shift, and a return points back at the original sale.

Stock, sales, and accounts share that one application. Separate programs for each job can wait. The cost is that a bad release takes the catalog and the counter down together. Paper, machines, and press jobs stay their own list. Copies land in the warehouse when the print run is received. Passing bills to the tax office is a step a person runs. India GST is not included, and a credit note covers the whole invoice.

One Next.js site covers the public book page and the office screens, so the short code on a cover reads the same title staff just saved. FastAPI is the service behind that site. Catalog, warehouse, print runs, sales, the counter, and accounts share one release, so a bill and its stock line are saved together. MongoDB holds those records, and each document belongs to one house. Staff sign in with email and password. The session knows which house they are in. WeasyPrint turns invoices, receipts, and challans into PDFs. The edition's short code is printed as a QR. Uploaded photos stay on the application's own disk.

The operator can see houses and which areas are switched on, apart from the house's own books. What shipped is the finished-book path: the title, the print run, stock lines, sales papers, counter shifts, invoices, and the accounts, including the trial balance, ledger, profit and loss, balance sheet, and VAT. An issued bill stays as it was issued.

There is no counted before-and-after. The press list is still separate from finished copies. The change is the record itself: lines and bills, where the house used to keep cells and loose paper.