Open a Workbench

Documents

• Store and categorise your documents.
• Use the powerful search and filter to find what you need, when you need it.

Manage Bank Accounts

• Link multiple banks and multiple companies
• Download and manage bank statements
• Import bank statements into BookStage
• Auto allocate transations linked to TurboCASH books
• Load bank statements into TurboCASH books

Architecture

An Electron app is a desktop application built using web technologies like HTML, CSS, and JavaScript, but packaged to run natively on Windows, macOS, and Linux. Electron combines Chromium (for rendering the interface) and Node.js (for backend logic), allowing developers to write cross-platform apps with a single codebase. Popular apps like Visual Studio Code, Slack, and Discord are built with Electron because it makes it easy to deliver rich, modern interfaces while still accessing native system features.

Features

• Leverage twenty years of TurboCASH developement, or build your own scaffold
• Built on the legacy of a million lines of Delphi Code
• Cross-platform: Write once, run anywhere on Windows, macOS, and Linux.
• Web entagled, work easily with our servers. MPC servers
• open source, easy to fork, permissive Apache licence, ready to modify with CODEX
• Use TurboCASH or link to your own accounting system

Core Architecture

• Main Process
  Runs in Node.js. It controls the app lifecycle (launch, quit, menus, notifications, file system access). Think of it as the “backend” of the desktop app.
• Renderer Process
  Runs in Chromium. Each window (or tab-like view) is a separate renderer process. This is where the UI lives, built with HTML, CSS, and JavaScript. It behaves like a web page but has access to native APIs through Electron.
• IPC (Inter‑Process Communication)
  Since the main and renderer processes are isolated, they communicate via IPC channels. For example, the renderer might request a file read, and the main process executes it using Node.js, then sends the result back.

Key Features

• Cross‑platform: One codebase runs on Windows, macOS, and Linux.
• Native integration: Access to OS features like notifications, menus, tray icons, clipboard, and file system.
• Packaging: Apps are bundled with Electron, so they ship with their own Chromium and Node.js runtime. This makes them heavier than native apps but ensures consistency across platforms.
• Developer workflow: You can use modern web frameworks (React, Vue, Angular) to build the UI, while Node.js handles system-level tasks.

Example Flow

1. User opens the app → Main process starts.
2. Main process creates a BrowserWindow → Renderer process loads your HTML/JS.
3. Renderer displays UI → User clicks a button.
4. Renderer sends IPC message → Main process performs system action (e.g., read/write file).
5. Main process responds → Renderer updates UI.

Connection Profiles

BookStage UI

React renderer
|
v
Electron preload API
window.bookStageAPI
|
v
Electron main process
Connection/profile manager
|
+> Local Firebird server
| localhost:D:\...\books.fdb
|
+> Network Firebird server
| office-server:D:\TurboCASH\Company\books.fdb
|
+> Remote BookStage Gateway
https://client.example.com/api
|
v
Firebird server near the database
Important rule: do not open a Firebird database over a shared folder like:

\\server\share\books.fdb
That is risky. Firebird databases should be accessed through a Firebird server process, even on a LAN.
So the three supported connection types should be:

1. Local Books

host: localhost
database: D:\dev2023\bookstage\books\4-EN-UK-GENERIC\books.fdb
user: SYSDBA
password: masterkey

2. Network Books
host: office-server
database: D:\TurboCASH\Books\ClientA\books.fdb
user: SYSDBA
password: ********

The file lives on the server machine. BookStage connects to Firebird on that machine.

3. Internet Books
Do not expose Firebird directly to the internet if you can avoid it. Better:

BookStage desktop
-> HTTPS API
-> BookStage Gateway service
-> Firebird on same private server/network
That gateway can handle authentication, logging, rate limits, backups, and later sync rules.

For development, create this progression:

Phase 1: Local Firebird
BookStage -> localhost Firebird -> local books.fdb

Phase 2: LAN simulation
BookStage -> 127.0.0.1 or machine name -> Firebird server path

Phase 3: Gateway simulation
BookStage -> local Express API -> Firebird In the app, create a Connection Profiles table in SQLite:

connection_profiles
id
name
type: local | network | gateway
host
port
database_path
api_url
username
encrypted_password
last_opened_at status
Then the first real module should be Open a set of books, with tabs:

Local
Network
Internet / Gateway
Recent

SQLite