n8n за етажна собственост: 8 сценария

01Какво ще научиш

• Една схема за всички осем задачи: тригер → данни → преработка → одобрение от човек → действие → запис в дневник.
• Как да опишеш сграда и плащания в две малки таблици в Postgres, с пари в EUR.
• Как да разпознаваш плащане по основание и да не гадаеш, когато не си сигурен.
• Как локален модел сортира заявки по спешност, без текстът да напуска машината.
• Как да направиш PDF отчет и как да хванеш грешките на работните процеси.
• Как да пазиш личните данни на живущите: какво да не събираш и какво да не пращаш.

02Преди да започнеш

• Работещ стек от урока n8n на GX10: n8n, Postgres и Ollama в Docker, достъп до редактора през SSH тунел. Без него тук няма да тръгне нищо.
• Пощенска кутия за изпращане (SMTP данни) — по възможност отделна, не личната ти.
• Примерните данни по-долу са измислени. Не зареждай реални собственици, докато не мине тестът и не прочетеш бележката за GDPR.

  gotenberg:
    image: gotenberg/gotenberg:8.37.0
    restart: unless-stopped

Пусни я с docker compose up -d gotenberg и провери с docker compose ps. Версията и ARM64 са сверени в Docker Hub на 01.10.2026 — при по-късно четене провери актуалния таг.

03Стъпки

1. Основата: две таблици

   Всички сценарии четат от тези две таблици. Защо Postgres, а не електронна таблица? Заявките са по-бързи и по-точни, а n8n не презаписва чужди редове по грешка. Парите са numeric(10,2), никога float — иначе центовете „плуват“.

   sql · Postgresкопирай

   CREATE TABLE units (
     id            serial PRIMARY KEY,
     unit_no       text UNIQUE NOT NULL,
     owner_label   text NOT NULL,
     owner_email   text,
     monthly_fee   numeric(10,2) NOT NULL,
     balance       numeric(10,2) NOT NULL DEFAULT 0,
     active        boolean NOT NULL DEFAULT true
   );
   
   CREATE TABLE payments (
     id        serial PRIMARY KEY,
     unit_id   integer REFERENCES units(id),
     amount    numeric(10,2) NOT NULL,
     paid_on   date NOT NULL,
     reference text,
     matched   boolean NOT NULL DEFAULT false
   );
   
   INSERT INTO units (unit_no, owner_label, owner_email, monthly_fee, balance) VALUES
     ('01', 'Собственик А', 'owner.a@example.com', 12.00, 0),
     ('02', 'Собственик Б', 'owner.b@example.com', 12.00, 24.00),
     ('03', 'Собственик В', 'owner.c@example.com', 12.00, 36.00);

   Пускаш я от Postgres възел с операция Execute Query или с docker compose exec postgres psql. Забележи owner_label: колкото по-малко лични полета пазиш, толкова по-малко рискуваш (виж бележката за GDPR в края на стъпките).

2. Сценарий 1 — месечно известие за такса

   Всеки месец, в първия ден, всеки собственик получава кратко известие със сумата и основанието. Схема: Schedule Trigger → Postgres (активните апартаменти) → Code/Set (текстът) → одобрение → Send Email → ред в дневник.

   sql · Postgres възелкопирай

   SELECT unit_no, owner_label, owner_email, monthly_fee, balance
   FROM units
   WHERE active AND owner_email IS NOT NULL;

   текст · поле „Message“ на Send Emailкопирай

   Здравейте, {{ $json.owner_label }},
   
   Такса за {{ $now.format('MM.yyyy') }} за апартамент {{ $json.unit_no }}: {{ $json.monthly_fee }} EUR.
   Дължима сума към момента: {{ $json.balance }} EUR.
   Основание за превода: АП {{ $json.unit_no }} {{ $now.format('yyyy-MM') }}
   Сметка на сградата: <IBAN-на-сградата>
   
   Домоуправител Пример

   Правило: през първите два месеца пускай процеса към собствена тестова пощенска кутия, а не към собствениците. Изпращането към реални адреси включвай чак след като си видял десет верни известия. Форматът на дата в n8n изразите е по документацията на n8n — провери го с пробно изпълнение.

3. Сценарий 2 — разпознаване на плащане

   Много банки пращат имейл при входящ превод. Схема: Email Trigger (IMAP) → Code (сума и основание) → Postgres (търси апартамента) → ако е разпознат: запис в payments и намаляване на balance; ако не: опашка за ръчна проверка при домоуправителя.

   javascript · Code възелкопирай

   const body = $json.text || '';
   
   const amountMatch = body.match(/(\d+[.,]\d{2})\s*(?:EUR|€)/i);
   const amount = amountMatch ? parseFloat(amountMatch[1].replace(',', '.')) : null;
   
   const refMatch = body.match(/АП\s*(\d{1,3})\s+(\d{4}-\d{2})/i);
   const unit_no = refMatch ? refMatch[1].padStart(2, '0') : null;
   const period = refMatch ? refMatch[2] : null;
   
   return [{ json: { amount, unit_no, period, matched: Boolean(amount && unit_no) } }];

   ✅

   Не гадай

   Ако липсва сума или апартамент, процесът не отнема пари от баланса — праща реда в опашка за ръчна проверка. Грешно осчетоводено плащане е по-лошо от неосчетоводено. Регулярният израз по-горе е за измислен формат: твоята банка пише по друг начин, затова го нагоди по реални (скрити) примери. ⚠️ Не сме сверявали формат на конкретна банка.

   Алтернативата, когато имейлът е нестабилен, е да качваш периодично извлечение (CSV) и да го четеш с възела за файлове — логиката за разпознаване е същата.

4. Сценарий 3 — заявки за ремонт и спешност

   Собственикът попълва форма, която праща данни на Webhook. Схема: Webhook → Basic LLM Chain с Ollama Chat Model (оценка на спешността) → Switch → при спешно: веднага известие до домоуправителя; иначе: запис в списък със задачи.

   Промпт за веригата (режим Define below):

   промпт · Basic LLM Chainкопирай

   Ти помагаш на домоуправител. Прочети заявката и върни САМО JSON:
   {"priority": "urgent" | "normal", "category": "вода" | "ток" | "асансьор" | "общи части" | "друго", "reason": "едно изречение"}
   Спешно е, ако има опасност за хора или имущество (теч, искри, дим, блокирал асансьор с човек в него).
   
   Заявка: {{ $json.body.description }}

   Моделът може да сбърка формата, затова добави запасен вариант с думи-ключове:

   javascript · Code възел (запас)копирай

   const keywords = ['теч', 'наводн', 'искр', 'дим', 'газ', 'заседнал', 'пожар'];
   const text = ($json.description || '').toLowerCase();
   const urgent = keywords.some(k => text.includes(k));
   return [{ json: { ...$json, priority: urgent ? 'urgent' : 'normal' } }];

   ⚠️

   Автоматичният отговор не е спешна помощ

   При пожар, газ или опасност за хора се звъни на 112. Известието от процеса е само за домоуправителя. Напиши това и във формата, за да не чака никой отговор от робот.

5. Сценарий 4 — подготовка на общо събрание

   Процесът подготвя, а не решава: събира списъка на собствениците, прави чернова на поканата и чернова на протокола. Схема: ръчен тригер (домоуправителят пуска процеса) → Postgres (адреси) → Basic LLM Chain (чернова от дневния ред) → одобрение → Send Email.

   • Срокът, кворумът и формата на поканата се вземат от закона и от правилника (виж кутията „Законът не е тук“). Сложи ги като променливи в процеса, не като числа в текста.
   • Моделът пише само чернова на български по подаден дневен ред; домоуправителят чете и подписва.
   • Подписването на протокола става по реда, който ти е нужен юридически. Ако ползваш услуга за електронен подпис, свързването ѝ е отделна задача, която не сме сверявали.

6. Сценарий 5 — напомняния по етапи

   Напомнянията са деликатна работа. Схема: Schedule → Postgres (активни, с дълг) → Code (етап по просрочие) → Switch → одобрение → действие.

   Етап	Просрочие (пример)	Какво прави процесът
   1	до 30 дни	Любезно известие по имейл
   2	30–59 дни	Второ известие със сума и основание
   3	60–89 дни	Чернова на писмо — домоуправителят го преглежда
   4	90 и повече дни	Само известява домоуправителя. Какво следва, решава човек (с юрист).

   javascript · Code възелкопирай

   const due = new Date($json.oldest_unpaid_since);
   const days = Math.floor((Date.now() - due.getTime()) / 86400000);
   let stage = 0;
   if (days >= 90) stage = 4;
   else if (days >= 60) stage = 3;
   else if (days >= 30) stage = 2;
   else if (days >= 1) stage = 1;
   return [{ json: { ...$json, days_overdue: days, stage } }];

   Полето oldest_unpaid_since е дата, която изчисляваш в заявката към Postgres (най-старото начисление без покритие) — таблиците по-горе го нямат, добави си колона или таблица с начисления, ако искаш точно просрочие.

   ✅

   Дълговете са лични данни

   Никога не изпращай информация за дълг на група, в общ чат или на друг собственик. Всяко известие е само до самия длъжник. Сроковете и последствията в таблицата са пример — реалните са по закона и правилника.

7. Сценарий 6 — месечен отчет в PDF

   В края на месеца процесът обобщава приходи, разходи и баланс и праща PDF на домоуправителя (и на съвета, ако е решено). Схема: Schedule → Postgres (обобщение) → Code (HTML таблица) → Convert to File → HTTP Request към Gotenberg → Send Email с прикачения файл.

   HTTP Request възелът: метод POST, адрес http://gotenberg:3000/forms/chromium/convert/html, тяло Form-Data с двоично поле files, а файлът се казва index.html (така изисква Gotenberg). Отговорът е PDF — избери формат на отговора File.

   javascript · Code възел (HTML)копирай

   const rows = $input.all().map(i => i.json);
   const total = rows.reduce((s, r) => s + Number(r.paid), 0).toFixed(2);
   const tr = rows.map(r => `<tr><td>${r.unit_no}</td><td>${Number(r.paid).toFixed(2)} EUR</td></tr>`).join('');
   const html = `<!doctype html><meta charset="utf-8"><h1>Отчет за месеца</h1>
   <table border="1" cellpadding="6"><tr><th>Апартамент</th><th>Платено</th></tr>${tr}</table>
   <p>Общо: ${total} EUR</p>`;
   return [{ json: { html } }];

   В отчета за съвета слагай обобщени числа и номера на апартаменти, а не имена и не подробности за длъжници.

8. Сценарий 7 — нова сграда

   Когато поемеш втора сграда, повтаряш едно и също: записи, таблица и приветствено писмо. Схема: Webhook (форма с данните на сградата) → Postgres (вмъква апартаментите) → Send Email (потвърждение до домоуправителя с контролен списък).

   • Добави в units колона building и филтрирай всички процеси по нея, за да не смесиш две сгради.
   • Папки за документи създавай ръчно или със съхранение по твой избор — конкретна услуга не даваме като рецепта.
   • Този процес е добър пример за подпроцес: останалите сценарии се викат с параметър „сграда“.

9. Сценарий 8 — експорт за счетоводителя

   Вместо да „вграждаш“ процеса в конкретен счетоводен софтуер, започни с най-простото: веднъж месечно процесът пише CSV със събраните плащания и го праща на счетоводителя. Схема: Schedule → Postgres (плащания за месеца) → Convert to File (CSV) → Send Email.

   sql · Postgres възелкопирай

   SELECT u.unit_no, p.paid_on, p.amount, p.reference
   FROM payments p JOIN units u ON u.id = p.unit_id
   WHERE p.matched
     AND date_trunc('month', p.paid_on) = date_trunc('month', current_date - interval '1 month')
   ORDER BY p.paid_on;

   Ако твоят счетоводен софтуер приема импорт или има API, свързването е отделна стъпка — прочети документацията му. ⚠️ Не сме тествали връзка с конкретен продукт.

10. Грешки: кой ще разбере, ако нещо се счупи

    Направи отделен процес с възел Error Trigger и го избери в Settings → Error workflow на всеки работен процес (по документацията на n8n). Той получава име на процеса, текст на грешката и — когато изпълнението е запазено — връзка към него.

    текст · Send Email в процеса за грешкикопирай

    Грешка в процес: {{ $json.workflow.name }}
    Съобщение: {{ $json.execution.error.message }}
    Изпълнение: {{ $json.execution.url }}

    Процесите работят по тригери само след Publish; докато ги редактираш, тестовият адрес на Webhook е /webhook-test/…, а постоянният — /webhook/….

    Копия. Всеки ден — копие на базата на Postgres (pg_dump), всяка седмица — износ на работните процеси (от менюто на n8n или с n8n export:workflow). Пази копията извън машината и пробвай поне веднъж да възстановиш от тях. Ключът за шифроване на n8n пази отделно: без него запазените данни за достъп не се отключват.

11. Внедряване на фази и канали за връзка

    Не пускай осемте сценария наведнъж. Всяка фаза трябва да носи полза, преди да започне следващата:

    Фаза	Срок (ориентир)	Какво пускаш
    1 · Основа	1–2 седмици	Стекът, таблиците, сценарий 1 към тестова кутия, процес за грешки, копия
    2 · Пари	3–4 седмици	Сценарий 2 (плащания) с ръчна опашка; сценарий 8 (експорт)
    3 · Връзка с живущите	5–6 седмици	Сценарий 3 (заявки) и сценарий 5 (напомняния) с одобрение от човек
    4 · Документи	2–3 месеца	Сценарий 4 (събрание), сценарий 6 (отчет), сценарий 7 (нова сграда)

    Канали. Започни с имейл: той оставя следа и не изисква отделен акаунт. Чат ботове и SMS са възможни като допълнителни канали през HTTP Request към API на доставчика, но всеки носи свои условия, разходи и нужда от съгласие на живущия за този канал. Дръж за всеки собственик един предпочитан канал в таблицата и не дублирай съобщенията. ⚠️ Конкретни доставчици на чат и SMS не сме сверявали.

12. Бележка за защита на личните данни (GDPR)

    Имената, имейлите и дълговете на живущите са лични данни. Това не е правен съвет — за решения към конкретна сграда питай юрист или длъжностно лице по защита на данните. Практическият минимум:

    • Събирай по-малко. Нужни са апартамент, етикет на собственика и един адрес за връзка. Не пази ЕГН, лични карти и снимки „за всеки случай“.
    • Една цел на процес. Данните за такси не се ползват за реклама и не се споделят с трети лица без основание.
    • Никакви дългове в общи канали. Известието е само до засегнатия собственик.
    • Срок за съхранение. Реши колко пазиш старите плащания и заявки и чисти по график; в n8n сложи и срок за историята на изпълненията.
    • Достъп. Редакторът на n8n е само за домоуправителя (собственически акаунт с 2FA); копията на базата се пазят шифровано или на защитено място.
    • Локалният модел помага: текстът на заявките не отива при външен доставчик на модели. Външният имейл доставчик обаче вижда съобщенията — избери го внимателно.
    • Човек в цикъла. Нищо с последствия за живущ (известие за дълг, писмо) не тръгва без одобрение.

04Проверка

• Таблиците units и payments съществуват и в тях има три измислени апартамента.
• Сценарий 1 праща известие към твоя тестова кутия със верните суми в EUR.
• Сценарий 2 разпознава примерно известие и праща неразпознато в опашка за ръчна проверка.
• Сценарий 3 връща приоритет и причина, а при неясен отговор на модела работи запасният вариант.
• Сценарий 5 няма етап без одобрение от човек през пилотния период.
• Сценарий 6 дава PDF през Gotenberg; Gotenberg няма публикуван порт.
• Всеки работен процес има избран процес за грешки.
• Има ежедневно копие на базата и седмичен износ на процесите; възстановяването е пробвано веднъж.
• Прочел си бележката за GDPR и не си заредил реални данни, преди да е минал тестът.

Тест

05Какво следва

06Източници

1. n8n: Error Trigger — процес за грешки и полетата, които получава.
2. n8n: Schedule Trigger · Webhook · Email Trigger (IMAP) 🌐 глобален
3. n8n: Postgres · Send Email · HTTP Request · Convert to File
4. n8n: Basic LLM Chain 🔒 локално — верига с локален модел през Ollama.
5. Gotenberg: HTML към PDF 🔒 локално — маршрут /forms/chromium/convert/html, файл index.html.
6. n8n в Docker Hub · Gotenberg в Docker Hub — тагове и архитектури (arm64).
7. PostgreSQL: числови типове — защо парите са numeric.
8. n8n: копия и възстановяване — n8n export:workflow --backup и защо ключът за шифроване е нужен при възстановяване.