Configuration and Customization

Warka is one product that runs any company. Nothing about a specific company is hardcoded into the application: the company identity, chart of accounts, branding of the public careers page, users, roles, and master data are all configuration. This document explains every layer at which Warka can be tailored, from a one-line company name to writing new modules.

Layers, from least to most effort:

1. Provisioning configuration (company identity): set once at deploy time.
2. In-app configuration (settings, master data, roles): done by administrators in the browser, no code.
3. ERPNext-native customization (custom fields, forms, workflows, print formats), which needs no code and is powerful.
4. Code extension (new endpoints, modules, hooks): for developers. See Extending and Customizing.

1. Provisioning configuration: making it "your company"

When Warka is deployed, one configuration file defines which company this instance is for. The setup routine reads these values and provisions the company, its chart of accounts, and its defaults automatically.

These live in the deploy kit's .env file. On first deployment they are written into the site configuration, and the setup routine (cyber_zeb_erp.setup_defaults.complete_setup_wizard) uses them to run the real ERPNext setup wizard programmatically. The result is a fully provisioned company: a Company record, a standard chart of accounts, cost centers, warehouses, a fiscal year, and every wizard fixture, with no manual clicking.

Because the values are resolved in the order explicit argument, then site config, then a generic default, the exact same deploy command provisions "Acme Corporation in Kenya" or "Zemen Trading in Ethiopia" with no code change. The company abbreviation, when not given, is derived from the initials of the company name (for example, Zemen Bank Ethiopia becomes ZBE).

The abbreviation appears in ledger account names such as Cash - ACME. Pick a short, stable code; changing it later means renaming accounts.

Running or re-running setup manually

If you need to provision a company by hand (for example on a site created outside the deploy kit), set the values in the site config and run:

bench --site your-site.example.com set-config company_name "Acme Corporation"
bench --site your-site.example.com set-config country "Kenya"
bench --site your-site.example.com set-config currency "KES"
bench --site your-site.example.com set-config time_zone "Africa/Nairobi"
bench --site your-site.example.com execute cyber_zeb_erp.setup_defaults.complete_setup_wizard

The command is a no-op if the company is already set up, so it is safe to run again.

2. In-app configuration (no code)

Most day-to-day tailoring happens in the browser, done by administrators.

Company and finance

• Company details: name, logo, website, addresses, tax IDs.
• Chart of accounts: keep the standard chart or add company-specific accounts, tax accounts, and cost centers.
• Fiscal year: match your financial year if it is not January to December.
• Currencies and price lists: transact in multiple currencies; maintain selling and buying price lists.
• Payment modes: cash, bank transfer, mobile money, and the accounts they post to.

HR and payroll

• Departments, designations, leave types, shift types, holiday lists.
• Salary components and structures: build earnings and deductions and combine them into salary structures, then assign per employee.
• Expense claim types and their accounts.

Users and roles

Create users and assign roles to control who sees and does what. See Security and RBAC for the full role model.

Self-healing defaults

Warka ships an idempotent routine (cyber_zeb_erp.setup_defaults.ensure_operational_defaults) that runs on every update. It guarantees the operational master data every module needs actually exists: a current fiscal year, item groups, units of measure, selling and buying price lists, customer, supplier, and territory groups, genders, core HR masters, a company bank account and default, a tax account, a holiday list, expense-claim and salary-component accounts, and a default salary structure. If any of these is missing or was deleted, it is recreated. This is why a form never dead-ends on a missing default, and why a company can safely start from a minimal setup and grow into the full configuration.

3. Careers page branding

The public careers page at /careers belongs to the customer company, not to Warka. It renders the company's own identity, pulled live from the Company record:

• Company name as the site name and in the page copy.
• Logo (the company logo you upload), shown in the header.
• Website, linked from the header.
• Headline, tagline, and an "about working here" section, editable by HR.

HR edits the careers copy from inside the ERP (the Recruitment section of HR, or directly on the Company record's Careers Page fields). The changes are served to the public page through a guest-safe endpoint (cyber_zeb_erp.careers.get_site_settings). Warka appears only as a small "Powered by Warka" attribution in the footer, the same way a hosted product credits its platform.

This means a candidate applying to Acme Corporation sees Acme's brand throughout, and their application lands in Acme's recruitment pipeline. See Careers and Recruitment.

4. ERPNext-native customization (no code)

Warka is built on ERPNext, so the full ERPNext customization surface is available to administrators without writing code. This is a large and mature toolset:

• Custom fields: add fields to any form (for example, a project code on invoices or a national ID on employees).
• Customize Form: reorder fields, hide fields, make fields mandatory, change labels, and set defaults per doctype.
• Workflows: define approval chains with states and transitions (for example, a purchase order that needs manager then director approval above a threshold).
• Print formats: design branded invoices, payslips, and purchase orders.
• Naming series: control document numbering (for example, INV-2026-#####).
• Notifications: email or system alerts on document events.
• Roles and permissions: define custom roles and fine-grained permissions per doctype and field.

Warka already uses this mechanism itself: it adds national-identity and residence fields to Employee records and careers-copy fields to the Company record, all via the custom-field system, applied automatically on every update so they are reproducible on any site.

5. Code extension (for developers)

When configuration is not enough, developers can extend Warka: add new API endpoints, build new frontend modules, add document hooks, and integrate external systems. The patterns for doing this cleanly are documented in Extending and Customizing.

Rebranding note: Warka is the product

Warka is the name of the ERP product, the way Oracle or Workday name theirs. The internal application (the dashboard your employees log into) carries the Warka brand. What is customer-specific is your company inside Warka and your public careers page, both of which show your identity. If you have a white-label agreement with Cyber-Zeb, discuss product-level rebranding with them directly; it is not a self-service setting.

Summary