Telegram-Based Production Tracker Upgrade
Budget / Salary€250–750
TypeFreelance project
LocationRemote
Posted1 hour ago
Printflow V2.3 — Simplified Specification
Version 2.3 · Purpose: Telegram-based production tracking, material control and reporting for one printing / paper-bag manufacturer.
1. Principles
• PostgreSQL is the system of record. The LLM only extracts and answers; it never writes SQL or changes data directly.
• Every extraction and every operator entry is confirmed by a human with Edit / Approve / Reject before it is saved.
• Never invent missing data. Anything the PO does not state stays blank/UNKNOWN until a person fills it in. Colours stay free text.
• History is append-only: corrections are new events, never silent overwrites.
• No features beyond this document. Simple, deterministic, auditable.
2. Architecture
Telegram (long polling) → ONE LLM → typed Python tools → validation → PostgreSQL (+ event log).
No web UI, no agents, no OCR, no webhooks.
3. Tech
Python 3.12 · PostgreSQL · python-telegram-bot (long polling) · one LLM · PDF text extraction (digital PDFs only) · ReportLab · Docker Compose (app + Postgres).
4. Roles (allow-list of Telegram IDs)
Owner: uploads PDFs, types orders, approves extractions, records deliveries, asks questions, requests reports, assigns operators to stations, corrects operator entries.
Operator: no PDFs, no questions, no reports, no inventory balances. Only the production entry flow for their assigned station. About 6–10 operators; several can share a station.
Stations: printing, laminating, foiling (optional), die cutting, finishing (finishing includes gluing).
Every action is logged with the user's name.
5. Universal confirmation pattern
1. Input arrives (PDF, typed order, operator entry, delivery).
2. LLM extracts to a draft (status PENDING).
3. Bot replies with a readable summary and Edit / Approve / Reject.
4. Approve saves and logs an event. Reject discards and logs. Edit asks which field, takes the new value, redraws the summary.
5. Drafts expire after 7 days.
Customer/supplier matching: MATCH (shown), POSSIBLE MATCH (pick a candidate or New), NO MATCH (button New customer / New supplier, created from extracted details after one more confirm). Never merge silently.
6. Owner flows
Customer PO PDF or typed order → extract customer, quantity, dimensions, lamination type, printing, foiling, handle type, handles per bag (usually 2, sometimes 3), unit price, delivery time, VAT no., and every material the PO states for each station → match customer → confirm → creates one Job per product line (each with its own Job ID, stations and planned materials, all sharing the PO number) and sends one Work Order PDF per job (A4: Job ID, customer, product, quantity, tolerance, order date, due date, specs). A PO with one product creates one job. Source recorded as CUSTOMER_PO or TELEGRAM_TYPED_ORDER. Line value = quantity × unit price; no VAT/discount assumed.
The job's station list and order come from the PO (e.g. plain job: printing → die cutting → finishing; laminated: printing → laminating → die cutting → finishing; foiled: add foiling). The owner can edit stations and planned materials at the confirm step.
Planned handles = bags × handles per bag (calculated by the app, shown for confirmation).
Supplier delivery note / waybill PDF → extract (supplier, VAT, number, date, material lines) → match supplier → confirm → goods-received record that adds to inventory.
Supplier invoice PDF → extract → confirm → stored for reporting only. No matching, payables workflow or payments.
Customer invoice PDF → extract → link to job → confirm → stored for reporting.
Duplicate check on document number + supplier/customer before the buttons appear. One file at a time.
7. Operator production flow
1. Operator sends a Job ID. Bot checks the job exists and includes the operator's station.
2. Bot asks one at a time: Starting quantity? Good quantity? Waste quantity? (whole numbers, sheets or bags as applicable).
3. App checks start = good + waste. On failure: message and re-ask.
4. Materials step (skipped if the station has none): the bot shows the planned materials for this job and station and asks "Is this correct?" with Correct / Edit. Edit changes a quantity or picks a different inventory item from the list allowed for that station. If nothing was planned, the operator types the quantities (flagged for the owner).
5. Summary (job, station, operator, numbers, materials) with Edit / Approve / Reject. Approve saves a production entry.
Version 2.3 · Purpose: Telegram-based production tracking, material control and reporting for one printing / paper-bag manufacturer.
1. Principles
• PostgreSQL is the system of record. The LLM only extracts and answers; it never writes SQL or changes data directly.
• Every extraction and every operator entry is confirmed by a human with Edit / Approve / Reject before it is saved.
• Never invent missing data. Anything the PO does not state stays blank/UNKNOWN until a person fills it in. Colours stay free text.
• History is append-only: corrections are new events, never silent overwrites.
• No features beyond this document. Simple, deterministic, auditable.
2. Architecture
Telegram (long polling) → ONE LLM → typed Python tools → validation → PostgreSQL (+ event log).
No web UI, no agents, no OCR, no webhooks.
3. Tech
Python 3.12 · PostgreSQL · python-telegram-bot (long polling) · one LLM · PDF text extraction (digital PDFs only) · ReportLab · Docker Compose (app + Postgres).
4. Roles (allow-list of Telegram IDs)
Owner: uploads PDFs, types orders, approves extractions, records deliveries, asks questions, requests reports, assigns operators to stations, corrects operator entries.
Operator: no PDFs, no questions, no reports, no inventory balances. Only the production entry flow for their assigned station. About 6–10 operators; several can share a station.
Stations: printing, laminating, foiling (optional), die cutting, finishing (finishing includes gluing).
Every action is logged with the user's name.
5. Universal confirmation pattern
1. Input arrives (PDF, typed order, operator entry, delivery).
2. LLM extracts to a draft (status PENDING).
3. Bot replies with a readable summary and Edit / Approve / Reject.
4. Approve saves and logs an event. Reject discards and logs. Edit asks which field, takes the new value, redraws the summary.
5. Drafts expire after 7 days.
Customer/supplier matching: MATCH (shown), POSSIBLE MATCH (pick a candidate or New), NO MATCH (button New customer / New supplier, created from extracted details after one more confirm). Never merge silently.
6. Owner flows
Customer PO PDF or typed order → extract customer, quantity, dimensions, lamination type, printing, foiling, handle type, handles per bag (usually 2, sometimes 3), unit price, delivery time, VAT no., and every material the PO states for each station → match customer → confirm → creates one Job per product line (each with its own Job ID, stations and planned materials, all sharing the PO number) and sends one Work Order PDF per job (A4: Job ID, customer, product, quantity, tolerance, order date, due date, specs). A PO with one product creates one job. Source recorded as CUSTOMER_PO or TELEGRAM_TYPED_ORDER. Line value = quantity × unit price; no VAT/discount assumed.
The job's station list and order come from the PO (e.g. plain job: printing → die cutting → finishing; laminated: printing → laminating → die cutting → finishing; foiled: add foiling). The owner can edit stations and planned materials at the confirm step.
Planned handles = bags × handles per bag (calculated by the app, shown for confirmation).
Supplier delivery note / waybill PDF → extract (supplier, VAT, number, date, material lines) → match supplier → confirm → goods-received record that adds to inventory.
Supplier invoice PDF → extract → confirm → stored for reporting only. No matching, payables workflow or payments.
Customer invoice PDF → extract → link to job → confirm → stored for reporting.
Duplicate check on document number + supplier/customer before the buttons appear. One file at a time.
7. Operator production flow
1. Operator sends a Job ID. Bot checks the job exists and includes the operator's station.
2. Bot asks one at a time: Starting quantity? Good quantity? Waste quantity? (whole numbers, sheets or bags as applicable).
3. App checks start = good + waste. On failure: message and re-ask.
4. Materials step (skipped if the station has none): the bot shows the planned materials for this job and station and asks "Is this correct?" with Correct / Edit. Edit changes a quantity or picks a different inventory item from the list allowed for that station. If nothing was planned, the operator types the quantities (flagged for the owner).
5. Summary (job, station, operator, numbers, materials) with Edit / Approve / Reject. Approve saves a production entry.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.