Farro Artisan Atölye ERP
A production workshop's whole flow, from sales order to customer ledger
An ERP that brings sales orders, production orders, warehouses, dispatch notes, invoices, collections and the customer ledger into one app. It also includes a bot that reads order messages from WhatsApp with Gemini and turns them into sales orders, plus an order-tracking link for customers.
- Period
- Sep 2026 – Present
- Role
- Farro Artisan Atölye · Software Developer
- Status
- In active development
- Platforms
- Web
Overview
Farro is an ERP that runs a production workshop's daily operations. A customer order is taken, transferred into a production order, stock is received when production completes, the goods ship with a dispatch note, get invoiced and are posted to the customer ledger.
Route distribution planning, consignment sales, sample requests, purchasing, sales and purchase returns, warehouse transfers, stock counts and a waste report all run under the same roof. Customer balances and past invoices can be taken over from the previous accounting system, DİA, through Excel.
Highlights
- Sales order state machine and line-level pricing chain
- Three-step transfer from sales orders to production orders, with recipes and raw material consumption
- Customer ledger with FIFO allocation, statements, aging and credit risk
- Drag-and-drop distribution of orders to driver routes; one click turns a route into dispatch notes
- A bot that takes orders over the WhatsApp Cloud API and interprets messages with Gemini
- Document locks that guard concurrent edits; series-based document numbering
- Company-wide negative stock policy with one shared check on every stock exit
- A live workshop screen and notifications over SignalR
Architecture
Clean Architecture: Domain, Application (MediatR handlers), Persistence (EF Core) and WebUI. Controllers only send requests through ISender; data access goes through IUnitOfWork.
- PresentationASP.NET Core MVCRazorOrtak tablo modülü / Shared grid module
- ApplicationMediatR commands & queriesLedger posterDocument numbering
- PersistenceEF CoreRepository + UnitOfWorkMigrations
- DomainEntitiesBaseEntity (UTC, soft delete)
Engineering notes
- State machines, lock ordering and ledger rules are written in design docs that change together with the code.
- Tests run the real DbContext, repositories and UnitOfWork on in-memory SQLite; no hand-written fake DbContext.
- Every timestamp is UTC; the culture is pinned to tr-TR and machine-read values are always invariant.
Screens
Screenshots coming soon