chlorinexxe/billing_app

Purpose and entry point

This is a Python business-management application centered on products, suppliers, customers, billing, and dashboard statistics. app.py is the likely application bootstrap; domain persistence is defined in models.py and database setup in database.py.

Application composition

The codebase is organized as a layered desktop-style UI and service application rather than a web service:

• Application bootstrap: app.py

• Persistence/domain models: models.py, database.py

• Business calculations and statistics: calculations.py, services/stats_service.py

• UI screens and reusable components: ui/dashboard.py, ui/products.py, ui/components/card.py

Persistence and schema evolution

database.py provides the database boundary used by the rest of the application, while models.py represents persistent business entities. Alembic manages schema evolution:

• alembic/env.py

• alembic/versions/39f2eefc5ca6_added_state_in_the_supplier_and_customer.py

The migration indicates supplier and customer records include a persisted state field. UI and services should access storage through the shared database/model layer rather than embedding schema-specific logic.

Product and party management

Product management is exposed through ui/products.py, with product creation/editing likely handled by ui/add_product_dialogue.py. Domain-oriented UI asset modules separate representations or access patterns for core records:

• ui/assets/products.py

• ui/assets/customers.py

• ui/assets/suppliers.py

These areas form the input side of billing: maintain catalog items and the customer/supplier identities used by invoices.

Bill-generation workflow

Invoice generation is a distinct feature module under ui/generate_bill/. ui/generate_bill/page.py likely orchestrates the workflow, composing independently focused sections:

• Supplier selection/details: ui/generate_bill/supplier_section.py

• Customer selection/details: ui/generate_bill/customer_section.py

• Line-item entry: ui/generate_bill/product_table.py

• Amount summary: ui/generate_bill/totals_section.py

ui/generate_bill/bill_service.py is the important boundary between UI state and bill persistence/business actions. It should own bill creation/finalization rather than allowing individual sections to write directly to storage.

Calculation and dashboard flow

Line-item and aggregate financial logic is centralized in calculations.py; the bill totals UI should consume this logic instead of reimplementing arithmetic. Dashboard-facing aggregation is separated into services/stats_service.py, which supplies data to ui/dashboard.py. The primary flow is therefore: persisted products/parties → bill form and line items → calculations and bill service → persisted bill data → statistics service → dashboard cards.

Runtime and external dependencies

The repository is Python-based, with dependencies declared in requirements.txt. Database migrations use Alembic (alembic.ini, alembic/). No external network service, API integration, deployment platform, or web-server boundary is evident from the supplied tree.