Skip to content

Master-Data List Reports — Customer / Vendor / Employee

Date: 2026-07-01

Problem / motivation

Peachtree exposes flat master-data listings — Customer List / Customer Master File List / Contact List, Vendor List / Vendor Master File List, and Employee List — that print the contact and reference details for every customer, vendor, and employee. We surface this data on landing pages but not as formal, exportable reports. These three reports close the master-data rows on the Peachtree Report Parity tracker with thin wrappers over existing tables. (Prospect List is intentionally skipped — there is no CRM prospect entity.)

In scope

  • customer_list_report(generate_csv) — every client with name, RUC/DV, phone, email, payment terms, and current balance.
  • vendor_list_report(generate_csv) — every supplier with name, RUC/DV, phone, email, and balance.
  • employee_list_report(active_only, generate_csv) — every employee with number, name, national ID, position, department, hire date, base salary, status, and active flag.
  • CSV export via generate_csv. Path.REPORTS.

Out of scope

  • Separate "Master File List" (extra-detail) vs plain "List" variants — one report per entity carrying the useful columns; the frontend/CSV can hide columns. Contact List is folded into Customer List.
  • Prospect List — no prospect entity.

Data model changes

None. Reads clients (+client_balances), suppliers (+supplier_balances), employees. No migration, no new Path/Resource.

What's being implemented

  • Responses — app/graphql/reports/strawberry/master_data/master_data_report_response.py (CustomerListResponse, VendorListResponse, EmployeeListResponse).
  • Repository — app/graphql/reports/repositories/master_data/master_data_report_repository.py (customers, vendors, employees).
  • Service — app/graphql/reports/services/master_data/master_data_report_service.py.
  • Queries — app/graphql/reports/queries/master_data/master_data_report_queries.py.
  • Tests — tests/graphql/reports/test_master_data_reports.py.

GraphQL surface

customerListReport(generateCsv: Boolean! = false): GenericReportPage!
vendorListReport(generateCsv: Boolean! = false): GenericReportPage!
employeeListReport(activeOnly: Boolean! = false, generateCsv: Boolean! = false): GenericReportPage!

type CustomerListReport { clientId: UUID!, name: String!, ruc: String, dv: String, phone: String, email: String, paymentTerms: PaymentTerms, balance: Decimal! }
type VendorListReport { supplierId: UUID!, name: String!, ruc: String, dv: String, phone: String, email: String, balance: Decimal! }
type EmployeeListReport { employeeId: UUID!, employeeNumber: String!, firstName: String!, lastName: String!, nationalId: String, position: String, department: String, hireDate: Date!, baseSalary: Decimal!, status: EmployeeStatus!, isActive: Boolean! }

Frontend contract

  • Three listing reports under Reports; each returns records plus optional csvUrl.
  • employeeListReport(activeOnly: true) filters to is_active employees; default returns all.
  • Balances come from the maintained client_balances / supplier_balances rows (0 if none).

Future additions

  • Split dedicated Contact List (per-contact rows) if multiple contacts per customer get modeled.