Образец 10 — Акт за установяване състоянието на строежа при спиране на строителството. Заглавна лента с Възложител, Строител, Проектант и Консултант; свободно поле „поради …" с пояснителна легенда за причините; поле „основание" + дата на установяване; осем номерирани многоредови полета за констатациите; петима подписващи (строител, надзор + тех. лица по части, проектанти по части, технически контрол „Конструктивна", възложител). Полетата за надзора и проектантите са с многоредово име. Датата, петте имена и четирите страни (вкл. Проектант) са задължителни при заключване.
Образец 11 — Акт за установяване състоянието на строежа и СМР при продължаване строителството на спрени и замразени строежи. Структура като Образец 10, със шест номерирани констатации (изпълнени СМР, отклонения, налични материали, подлежащи на събаряне/ремонт, допълнителни проекти, други изисквания) и същите петима подписващи.
Образец 12 — Акт за установяване на всички видове СМР, подлежащи на закриване (скрити работи). Заглавна лента без Проектант; свободно поле „по част „…"" в подписващия по надзора; таблица с групирани заглавия „По проект"/„Изпълнено" (наименование на СМР, ед. мярка и количество по проект и изпълнено, оценка) с 1 начален премахваем ред; скица (печата се само при наличие на изображение); фиксирани законови текстове и Забележка; двама подписващи. Проектантът не е задължителен при заключване.
Образец 13 — Акт за установяване на щети, причинени от непреодолима природна сила и други. Заглавна лента без Проектант; дата и описание на непреодолимата сила; две таблици (по изпълнените конструкции/СМР и по материалите/инвентара/съоръженията, по 1 начален премахваем ред); описание на състоянието; добавящ се/премахваем номериран списък ПРЕДПИСВАМЕ; трима подписващи. Датата на непреодолимата сила се запазва при клониране.
Образец 14 — Акт за приемане на конструкцията. Заглавна лента с всички страни; чек-лист на строителните книжа с отметки ☑/☐ и свободен текст към всеки документ + добавящи се/премахваеми „други" редове (при печат всички фиксирани документи се отпечатват с ☑/☐); фиксиран извод по т.1; свободно поле за частични недостатъци по т.2; законово ЗАКЛЮЧЕНИЕ; трима подписващи. Датата, трите имена и всички страни (вкл. Проектант) са задължителни при заключване.
Образец 15 — Констативен акт за установяване годността за приемане на строежа (част, етап от него). Многостраничен и свързан с разрешение за строеж — при създаване се избира разрешение, чиито № / дата / орган се пренасят в т.1; групирани участници А/Б/В/Г (възложители, проектанти, строител с части, консултант + тех. лица), като се отпечатва по един ред на група в „СЪСТАВИЛИ"; блок с разрешение и акт за узаконяване, одобрени проекти и договори; четири констатации УСТАНОВИХМЕ; раздел РЕШИХМЕ с два срока (дати), добавящ се/премахваем списък на неразделните документи а)/б) и упълномощено лице; законови Забележки. Задължителни при заключване са датата, четирите основни участника (А1, Б1, В1, Г) и четирите страни; вторичните участници (А2, Б2, В2.1, В2.2) са по избор, за да е възможно заключване и при един възложител. Сроковете се запазват при клониране.
И шестте акта следват общия жизнен цикъл: чернова → заключване при първи печат → повторен печат / клониране / анулиране, с оптимистично заключване. Клонирането нулира датата на акта, но запазва тялото, таблиците, списъците, чек-листа и събитийните дати (непреодолима сила, срокове). Брандирането се повтаря на всяка страница.
Създаване на задача до избраната задача — при натискане на "Нова задача" в графика, ако има избрана задача, новата задача вече се добавя като съседна — на същото ниво и под същия родител, непосредствено след избраната задача (а ако избраната е коренова — на корен ниво). Новата задача вече не се създава като дъщерна на избраната.
Образец 7 — Акт за приемане на извършените СМР по нива и елементи на строителната конструкция. Достъпен от избора на шаблон при създаване на акт. Съдържа заглавна лента с участниците (Възложител, Консултант, Строител), полета „от ниво … до ниво …", многоредово описание на извършените СМР, винаги видима скица (схеми/чертежи), многоредов блок „Разрешаваме" и трима подписващи (строител, тех. лице „Конструктивна" към надзора, проектант „Конструктивна") + ред за управителя на строителния надзор. Подписващите се попълват предварително от проекта; датата и трите имена са задължителни при заключване.
Образец 8 — Акт за приемане и предаване на бетонни, стоманобетонни или други фундаменти за монтаж на конструкции, машини и съоръжения. Съдържа разширена заглавна лента (вкл. Проектант и огледален ред „Изпълнител на монтажни работи"), номериран списък с документи за съответствие (3 начални реда, добавяне/премахване), фиксиран законов текст за динамичните натоварвания, свободен текст за допустими отклонения а)/б) с препратка към таблица от ПИПСМР, описание на предаването за монтаж и четирима подписващи — като тех. лицата „Конструктивна" и „Геодезия" се печатат заедно под „3.", а проектантът /конструктор/ е „4.". Датата и всичките пет имена (вкл. двете подполета под „3.") са задължителни при заключване.
Образец 9 — Акт за предаване и приемане на машини и съоръжения. Съдържа заглавна лента със самостоятелно поле „Изпълнител монт. работи" и огледален ред „Доставчик на машини и съоръжения", таблица „Машини и съоръжения" с 2 начални реда, всички премахваеми (автоматичен номер по ред, наименование, количество, вид на опаковката, добавяне на още), фиксирани озаглавени полета за състоянието по букви а–з (буквата „ж" се пропуска съгласно образеца) и фиксирана законова Забележка за отделните констативни протоколи. Подписващи: възложител, строител/изпълнител, доставчик, тех. лице „Технологична". Датата и четирите имена са задължителни при заключване.
И трите акта следват общия жизнен цикъл: чернова → заключване при първи печат → повторен печат / клониране / анулиране, с оптимистично заключване. Клонирането нулира датата, но запазва тялото, таблиците и списъците. Брандирането се повтаря на всяка страница (важно при по-дълъг Образец 9).
Образец 5 — Акт за уточняване и съгласуване на строителния терен с работните чертежи и даване на основния репер на строежа. Новият образец е достъпен от избора на шаблон при създаване на акт/протокол. Съдържа:
заглавна лента с участниците (Възложител, Строител, Проектант, Консултант);
основен репер с кота и отстояние, препратка към протокол № 2 (свободен текст);
котите по образеца (изкоп, долен ръб на фундаментите, цокъл, корниз, било и др.);
скица на строежа (качване/поставяне на изображение);
таблица „Котировка" с фиксирани 6 точки и възможност за добавяне на още редове;
трима съставители + ред за управителя на строителния надзор.
Образец 6 — Акт за приемане на земната основа и действителните коти на извършени изкопни работи. Съдържа:
таблица за почвата (група, категория, участък от–до) с три фиксирани реда и добавяне на още;
таблица с действителните коти на терена и изкопа — започва с 2 реда; първите два реда са фиксирани, а всеки допълнително добавен ред може да бъде премахнат с бутон „Премахни";
скица на постройката;
секция за установени различия спрямо инженерно-геоложките проучвания и предписания (списъци с добавяне/премахване на редове);
тримата съставители + ред за управителя на строителния надзор.
И двата образеца следват същия жизнен цикъл като останалите протоколи: запазване на чернова, заключване с печат, повторен печат, клониране (нулира датите, запазва таблиците) и анулиране.
Съответствие на протоколите с официалните образци (PDF):
Образец 2а, Раздел III — точно подреждане по образеца:
Добавено е липсващото поле „проектна кота (проектни коти)" в проверки 1.1 (при ниво изкоп) и 1.2 (на изпълнения провод/съоръжение).
В заглавията на 1.1 и 1.2 е добавено поле за мярка в метри „(… м)" след котата.
Свободните текстови полета вече са на самостоятелни редове по цялата ширина (достигнати нива, „по оси", описание на отклоненията, описание на последващите СМР), както е в образеца.
Заключението в 1.1 („Следователно изпълнените строителни и монтажни работи…") е преоформено като избор а)/б), при който избраният ред се откроява в получер шрифт.
Проверка 1.2 е приведена към пълната структура на образеца: избор а)/б) с два отделни текста — заключение (под а) и отклонения (под б), всеки с пълната пояснителна забележка от образеца, и отделно поле за предвидените мерки по безопасност и здраве.
Образец 3 — Констативен акт:
Премахнато е текстовото поле след „на издадените строителни книжа", което не присъства в образеца.
Премахнат е разделът „Забележки:" в края на документа — официалният образец не съдържа такава секция.
Единни наименования при създаване на документ — картите за нов документ вече показват „Протокол 2а" и „Акт 3" (както във филтъра и таблицата „Актове"), вместо предишните „Образец 2а"/„Образец 3".
Два нови строителни документа към модул „Актове и протоколи" (Наредба № 3/2003):
Образец 2а — Протокол за откриване на строителна площадка и определяне на строителна линия и ниво на строежа за строежи от техническата инфраструктура. Документът е многостраничен и включва трите раздела от образеца: Раздел I (откриване на площадката — разрешения и документи 1.1–1.8, изходни точки, описание на площадката с окомерна скица), Раздел II (определяне на строителна линия и ниво — основни репери и окомерна скица) и Раздел III (констатации при достигане на контролираните нива — две проверки: при ниво изкоп и на изпълнения провод/съоръжение, с избор „отговаря/не отговаря", „съществено/несъществено" и „Разрешавам/Не разрешавам"). Подписващите лица се попълват предварително от данните на проекта (надзор, технически ръководител, възложител, строител, геодезия, инженер-геолог, конструктор), а разрешението за строеж се пренася в т. 1.1.
Образец 3 — Констативен акт за установяване съответствието на строежа с издадените строителни книжа и че подробният устройствен план е приложен по отношение на застрояването. Включва избор „съответства/не съответства", „допуснати/не са допуснати отклонения" и „приложен/не е приложен" ПУП.
И двата документа поддържат пълния жизнен цикъл като останалите протоколи: чернова, заключване с печат, повторен печат, клониране (с нулиране на датите) и анулиране. Видими са директно от бутона за добавяне на нов документ.
„Завърши Фаза" грешеше сградата при една избрана сграда — когато в таблицата „Сгради" е маркирана само една сграда, диалогът за фази не показва раздели (Tabs), затова вътрешният индекс на активния раздел оставаше 0 и при „Потвърди завършване" заявката се изпращаше към първата сграда в проекта, а не към избраната. Така при опит да се завърши фаза за втора сграда (напр. „Сграда Б") системата всъщност се опитваше да завърши фазата на първата (напр. „Сграда А") — която често вече е завършена — и връщаше грешка. Поправено: завършването вече цели сградата, върху която е натиснат бутонът (същия източник, който ползва и предварителният преглед).
Бизнес-грешките се показваха като „An unexpected error occurred" — смислени съобщения с код 400/404 (напр. „Phase is already completed", „Completion date cannot be in the future", „Building phase not found") бяха маскирани от общото съобщение за грешка в production. Сега тези съобщения достигат до потребителя. Допълнително са поправени четири извиквания, които подаваха текст вместо HTTP статус код (което би довело до сървърна грешка при формиране на отговора).
Образец 2 — Протокол за откриване на строителна площадка и определяне на строителна линия и ниво на строежа — добавена е възможност за съставяне на втория задължителен строителен протокол по ЗУТ. Изборът от лентата „Създай нов" вече показва Образец 2 на първа позиция (новият шаблон винаги е първи), последван от Образец 1 и Акт 19. Документът се състои от три раздела (І, ІІ, ІІІ × 4 проверки — изкоп, цокъл, корниз, било), всеки с подписаници, окомерна скица и валидация при заключване.
Изображения на скици — само data:image (PNG/JPEG/WebP). Сървърът отхвърля payload-и, в които скицата е външен URL, javascript: или произволен низ — защита срещу XSS през <img src>. Клиентският компресор гарантира валиден data:image/jpeg;base64,... префикс; крайната проверка живее в shared/acts_obrazec2.js и се прилага и на сървъра.
Строга валидация на templateDataV2 — всяко поле, което се очаква да е низ, отказва обектни/масивни payload-и (включително оператор-инжекционни като { $ne: null }). Над 800 KB на скица или над фиксираните дължини за свободни текстови полета (400 ch / 4000 ch / 10000 ch) се отхвърлят с HTTP 400.
Cross-tenant защита включва и techLead — проверката, че реферираните parties[*].contact принадлежат на компанията на потребителя, вече покрива и техническия ръководител (Образец 2 специфична роля). Това затваря регресия на проверката, въведена във v1.213.0.
Template-specific PUT guard — изпращане на templateData / signatories[] (полета на Образец 1) към ред с Образец 2 (или templateDataV2 към ред с Образец 1) се отхвърля с 400 вместо тихо да повреди записа.
Top-level permit остава синхронизиран с templateDataV2.sectionI.permits["1.1"] — обединената таблица „Актове" и бъдещи сървърни агрегации виждат едно и също разрешение, независимо от шаблона.
Печат при заключване не виждаше заключеното състояние — window.print() се извикваше синхронно след setState, преди React да commit-не новия статус. Преместено в componentDidUpdate, който се задейства след като status === "Completed" е committed и document.title е обновен.
Reprint брояч беше остарял — recordReprint беше fire-and-forget; локалното състояние не виждаше новия reprintCount / printedAt[]. Сега изчаква отговора и обновява protocol в state-а.
„Опресни от Проекта" с празни разрешения оставяше остарели данни — ако проектът няма повече разрешения, slot-ът на разрешение в Образец 2 сега се изчиства, вместо мълчаливо да запази стария номер.
Червени граници след „Копирай от" — копирането на подписаник от друг раздел вече изчиства маркерите за невалидни полета.
window.confirm заменен с MUI Dialog за потвърждение при „Опресни от Проекта" с непазени промени — UX единен с диалога за анулиране и тестируем от Puppeteer.
isLocked() използва константи (STATUS_PROTOCOL_COMPLETED / STATUS_PROTOCOL_CANCELED) вместо литерали — затваря клас от регресии при бъдещо преименуване на статуси.
Помощник isProtocolReadOnly(protocol) в shared/acts.js се ползва от двете страници (Образец 1 и Образец 2).
Преименуван TextField → O2TextField в obrazec_2/fields.jsx за да не засенчва MUI компонента със същото име.
Опростена handleCheckRadio — премахната IIFE-обвивка; today-stamp + mutate работят като една операция.
Подреждане на картите за избор на шаблон — Образец 2 е първа (newest first), след това Образец 1, накрая Акт 19.
Заглавие на раздел ІІІ — премахнато дублиращото се „.1" в префикса (преди „ІІІ.1 — 1.1. Проверка...", сега „ІІІ — 1.1. Проверка...").
i18n — премахнат смесеният ключ "Planned кота" (Latin + Cyrillic); заменен с "Planned elevation". Етикетите за бутоните „Копирай от Раздел I/II" вече минават през t() (ключове Section I → А / Section II → А и т.н.).
Преподредени BG преводи по азбучен ред — поправени са „Image too large…" и „Reference point", които бяха вмъкнати на грешни позиции.
.gitattributes — задава * text=auto eol=lf и фиксира съдържанието на бинарните разширения, за да спре CRLF→LF предупрежденията при коммитване от Windows.
Лента с действия за протокол Образец 1 — преместена от ленти отгоре върху A4 листа към фиксирана позиция вляво от документа, вертикално подредена. Лентата вече не покрива съдържанието по време на редакция. На тесни екрани (под 1100px) се връща горната хоризонтална форма като резервна.
Подсказки (tooltips) на бутоните с неочевидно действие: „Опресни от Проекта", „Анулиране" (чернова и заключен), „Клонирай". Подсказките се показват при задържане на курсора и обясняват какво точно прави бутонът.
Брандиране на печат за протоколи — текстът „brickeros.com" и логото вече се изобразяват в същия шрифт както при печат на Акт 19 (MUI Typography h6, лого с invert филтър). Позицията е анкерирана вътре в лявото поле на А4 листа (6mm от ляво, ротирано -90°) — предишният translateX(-160px) преместваше брандa извън печатаемата зона. Запазено е репликирането на всяка страница чрез position: fixed в @media print, така че при многостранични протоколи брандът се появява на всеки лист.
По-светъл цвят на брандa при печат (Актове и Протоколи) — текстът е с opacity 0.35 (преди 0.7), а логото е сиво воден знак (grayscale(1) + opacity 0.35–0.4). Брандът се чете като ненатрапчив воден знак и не доминира над документа.
Брандиране в една вертикална лента (Протоколи) — „brickeros.com" + логото се изобразяват в обща вертикална ротирана лента в лявото поле; логото е точно под текста. И двете части се репликират на всяка страница на многостранични протоколи.
Кросбраузърно брандиране на всяка страница (Chrome/Firefox/Safari) — заменихме position: fixed (което Firefox често не репликира за всяка страница) и display: table-header-group (което не репликира position: absolute потомци) с експлицитен dual-render: два отделни BrandingStrip елемента с класове .obrazec-branding--page1 и .obrazec-branding--page2. Първият е анкериран вътре в .obrazec-sheet; вторият — вътре в секцията .obrazec-permit-page-break, която има page-break-before: always и физически започва на страница 2. Така всеки бранд DOM елемент попада на собствената си страница без зависимост от семантика на репликиране — работи в Chrome, Firefox и Safari. Логото е ограничено по широчина (max-width: 132px при height: 20px, съобразено с SVG aspect 184:28) за да не излиза извън печатаемата зона.
Заглавната таблица на Образец 1 без вътрешен код — полетата Възложител, Строител, Проектант, Консултант вече се изобразяват без водещия числов код от ClientsSuppliersContacts (например „10010 ЖЕКО ТОНЕВ / +359898918720" → „ЖЕКО ТОНЕВ / +359898918720"). Изтриването става както при автоматичното попълване на нов протокол (сървърен модел), така и при показване на съществуващи протоколи (клиентски рендер) — споделеният хелпер stripContactDisplayCode в shared/acts.js стандартизира поведението.
„brickeros.com" не се появяваше на втора страница при печат на протокол — transform: rotate(-90deg) беше приложен директно върху елемента с position: fixed. Chrome третира трансформиран фиксиран елемент като нов containing block и не го репликира на следващите страници. Поправено чрез разделяне: външният елемент с position: fixed (без transform) се репликира, а вътрешен child носи ротацията.
Заданието project_recalculate_costs се зацикляше за определени проекти — withTransaction пренаписваше callback-а при всеки TransientTransactionError, причинен от $lookup агрегации, работещи вътре в multi-document транзакция на single-node replica set. Логовете показваха стотици повторни извиквания на projectTasksCalculateItemsCost без „finished" запис. Поправено — изтрита е withTransaction обвивката от Agenda handler-а; разходните стойности са производни (eventual consistency е приемлива), а решението следва вече установения patern за recomputeActualDates (изнесен извън транзакция в Card E на спецификацията за дати).
Бутоните в лентата на протокола не се показваха — protocol_toolbar.jsx извикваше HOC withTranslation с грешен подпис (withTranslation(Component) вместо withTranslation()(Component)), което караше React да рендерира функция вместо компонент и да премахне цялата лента с предупреждение „Functions are not valid as a React child".
Бутонът „Печат" не отваряше диалога — във версия 1.213.0 печатът се извикваше след await axios.post за одитен запис; браузърът отхвърляше window.print() извън потребителския жест. Поправено — диалогът се отваря синхронно от клика, одитният запис се изпраща във фон.
Бутонът „Запиши и Печат" не отваряше диалога — два проблема: (1) печатът се чакаше през componentDidUpdate след два await-а (запис + заключване); (2) валидацията на задължителните полета прекъсваше функцията преди печат, така че при празна чернова бутонът изглеждаше, че не прави нищо. Поправено — window.print() се извиква синхронно при клика, преди валидацията и мрежовите заявки. Печатният диалог се отваря винаги; записът/заключването се извършват само ако валидацията премине.
Печатът на Акт 19 беше празен след посещение на страница с протокол — глобалното правило body * { visibility: hidden } от print_protocols.css се прилагаше върху всяка страница, въпреки че Актовете нямат .obrazec-print-root обвивка. Поправено със скоп body:has(.obrazec-print-root) — правилото вече се активира само на страници с протокол.
Строителни протоколи — Образец 1 (Протокол за предаване и приемане на одобрения проект и разрешение за строеж) — добавена е възможност за автоматично издаване на официалния български строителен протокол по Образец 1:
Единен изглед на актове и протоколи — таблицата в раздел „Актове" вече показва както съществуващите Акт 19, така и новите протоколи. Колоната „Шаблон" разграничава типа документ; ценовите колони за протоколи показват „—".
Постоянен филтър по шаблон — падащо меню (Всички / Акт 19 / Образец 1) в лентата с инструменти; настройката се запомня за потребителя.
Избор на шаблон при създаване — от страницата „Създай нов акт" се избира между две карти: „Образец 1" и „Акт 19". Съществуващият процес за Акт 19 остава непроменен.
Поток за създаване на протокол — избор на проект → избор на разрешение за строеж (автоматично попълнено, селектор при няколко разрешения, инлайн добавяне при липса) → отваряне на WYSIWYG A4 редактор.
WYSIWYG A4 редактор — целият протокол се редактира директно върху симулиран A4 лист (бяла страница на сив фон, със сянка). Всички полета (страни, разрешение, части на проекта, бележки, дата, подписващи) са инлайн редактируеми.
Жизнен цикъл с lock-on-first-print — „Запази Чернова" може да се извлика по всяко време. „Печат" заключва протокола; след заключване редакцията е забранена и единствените позволени действия са „Печат" (повторно отпечатване), „Клонирай" или „Анулирай".
Клониране и анулиране — заключен или анулиран протокол може да бъде клониран; клонът автоматично актуализира страните и разрешението от текущите данни на проекта. Анулирани протоколи остават в таблицата с етикет „Анулиран".
Оптимистично заключване — едновременна редакция от двама потребители е защитена чрез сравнение на access.updated времеви маркер; при конфликт данните се презареждат автоматично с известие.
Печат през браузъра — използва window.print() + @media print CSS за A4 portrait; заглавието на файла е ProjectName-Образец-1-YYYY-MM-DD.
Подписващи (свободен текст) — компонентът CHandSignature получи нов freeText режим: вместо избор от потребителски речник, се въвеждат име и длъжност свободно. Полетата за подпис и дата остават празни за полагане с химикалка.
Предупреждение за бележки — ако текстът в полето „Забележка" надвишава височината на една A4 страница, се показва предупреждение в червено.
Нови полета на проект:
Проектант (designer) — опционална референция към контакт от ClientsSuppliersContacts; задължителна само при заключване на протокол.
Разрешения за строеж (permits) — списък от множество разрешения с номер, дата, орган и описание; управление с „Добави" / „Премахни" от формата за проект.
Нова MongoDB колекция acts_protocols (отделна от acts); поддържа множество шаблони (Образец 1..17) чрез поле template.
Нови REST endpoints под /api/p/act-protocols/ (create, get, update, lock, print, cancel, clone) с роли OWNER/ADMIN/MANAGER/SITE_MANAGER за писане.
Разширен GET /api/p/acts — обединява резултати от двете колекции в едно подредено представяне, без да нарушава съществуващи консуматори.
E2E API тестове — 17 тестови групи покриват CRUD, валидация, оптимистично заключване, многопотребителски достъп, контрол на роли, обединено извличане и клониране.
Английски преводи — добавени 22 ключа за протоколни функции в shared/locales/en_us/translation.json.
Подобрено управление на датите на задачите — всяка задача вече има ясно разграничени планирани и фактически дати, които се изчисляват автоматично от извършената работа:
Планирана начална дата и планирана крайна дата — задават се ръчно при създаване и редакция на задачата. Системата вече блокира запис, при който крайната дата е преди началната (грешката се показва веднага във формата).
Фактическа начална дата — изчислява се автоматично като най-ранната от: дата на първата свързана покупка на материал, дата на първия отчетен работен час или дата на първата услуга, отнесена към задачата. При ръчно превключване на статус към „В процес" датата се записва автоматично, ако още не е попълнена.
Фактическа крайна дата на листова задача — попълва се при маркиране на статус „Завършена"; изчиства се при отваряне обратно на задачата; за вече завършени задачи може да бъде коригирана ръчно (ретроактивна корекция).
Назад-датирани събития автоматично преизчисляват фактическата начална дата — при добавяне на по-стара покупка или работен час датата се „издърпва" към по-ранна стойност, за да отрази реалния старт на работата.
Замразяване при завършена задача — изтриването на доказателство (покупка/час/услуга) не премахва фактическата начална дата на вече завършена задача (запазва се историческата информация).
Автоматично агрегиране за контейнери и проекти:
Контейнер: фактическата начална дата = минималната от собствените доказателства и фактическите начални дати на дъщерните задачи; фактическата крайна дата = максималната от дъщерните фактически крайни дати (и автоматично се изчиства, когато никое дете няма крайна дата).
Каскадно завършване на контейнер вече стъпало фактическата крайна дата на всички дъщерни листови задачи едновременно; при отваряне на контейнера обратно тези дати се изчистват.
На ниво проект — нови обобщени стойности Планирано начало/край и Фактическо начало/край се показват в детайла на проекта.
Подобрена Gantt диаграма:
Динамично котвиране на лентите — не започнала задача показва планираните дати; задача „В процес" започва от фактическата начална дата и завършва на планираната крайна дата; завършена задача завършва на фактическата крайна дата.
Визуализация на закъснение — задачи, чиято планирана крайна дата е минала и не са завършени, се рендират с диагонална червена щриховка. Планираната дата не се удължава автоматично — отклонението остава видимо.
Прозрачност в редакционната форма — диалогът за редакция на задача показва и четирите дати; фактическата начална дата винаги е само за четене с подсказка („Изчислява се от първата покупка, работен час или услуга"); фактическата крайна дата е редактируема само за завършени листови задачи (за контейнери винаги е само за четене).
Доказателствата за дата (покупки/работни часове/услуги) се агрегират чрез фонов процес project_tasks_recalculate, който вече покрива и трите източника едновременно.
Двуфакторна автентикация (2FA) за администратори — акаунтите с роля Администратор вече изискват задължителна двуфакторна автентикация при всеки вход:
Настройка чрез QR код, съвместим с Google Authenticator, Authy и всяко TOTP приложение.
При активиране се генерират 10 резервни кода за еднократна употреба — пазете ги на сигурно място.
При изгубен достъп до приложението може да влезете с резервен код вместо с TOTP код.
Заключване на редактирането на складовия каталог — нови настройки в Фирмени настройки → Политика на складовия каталог, достъпни за Собственик и Администратор:
Дефиниции на артикули: когато е активирана, никой потребител (включително администратори) не може да създава или редактира дефиниции. Псевдонимите остават редактируеми; деактивирането/активирането на артикули е винаги разрешено.
Главни групи: когато е активирана, създаването на нови главни групи е блокирано; редактирането отваря формата само за четене; деактивирането е разрешено.
Групи артикули: когато е активирана, създаването на нови групи артикули е блокирано; редактирането отваря формата само за четене; деактивирането е разрешено.
Присвояването на групи към артикули е блокирано, когато кое да е от заключванията за групи е активно.
В лентата с инструменти на съответния модул се показва индикатор „Редактирането е заключено".
При отваряне формата е само за четене с информационно съобщение.
По-бързо зареждане на интерфейса — CSS, шрифтове и икони се компресират и кешират по-ефективно; при обновяване на версията браузърът презарежда само променените файлове.
Намалено повторно рендиране при промяна на потребителски настройки.
По-надеждно зареждане на данни при бавна мрежа — при таймаут или мрежова грешка таблиците вече показват ясно съобщение и бутон „Опитай отново" вместо празен списък.
Падащите менюта вече не остават „заключени" след мрежова грешка — следваща навигация автоматично презарежда данните.
Запазването на потребителски настройки сигнализира за неуспех вместо тихо да пропадне.
Увеличен таймаут на заявките до 10 секунди и автоматичен повторен опит при кратки прекъсвания на връзката.
Ускорено зареждане на „Артикулни дефиниции" за компании с голям брой артикули.
Библиотека с рецепти — нова секция в „Продажби → Настройки" за управление на шаблони за задачи:
Йерархия до 3 нива (контейнер → под-контейнер → листова рецепта).
За всяка рецепта: наименование, код, мерна единица, продължителност (дни), ориентировъчна цена за единица, описание.
Под-елементи (Materials & Services) към листовите рецепти — избор от съществуващи артикулни дефиниции с автоматично попълване на наименование и мерна единица; ръчно въвеждане на количество и единична цена.
Автоматично изчислена цена на рецептата от сумата на под-елементите (количество × единична цена).
Скриване/възстановяване на рецепти без изтриване (запазва исторически връзки).
Импорт на рецепта в проектен план — нов бутон „Импортирай рецепта" в лентата с инструменти на задачите:
Избор на рецепта от дърво с всички налични шаблони.
Двустъпков диалог: преглед на йерархията → редакция на количества, цени, дати и наименования преди създаване.
Каскадно изчисление на дати — всяка следваща задача започва когато завършва предходната; ръчно задаване на дата не измества съседните задачи.
Автоматично генериране на код от първите три съгласни на наименованието (латиница и кирилица); добавя числов суфикс при дублиране.
Проверка на дълбочина — задачи, които биха надвишили максималната дълбочина (3 нива), се маркират в червено; бутонът „Импортирай" е деактивиран до отстраняване на нарушенията.
Чекбокс за включване/изключване на отделни задачи; изключването на контейнер автоматично изключва всичките му деца.
Достъп: роли Собственик и Администратор.
Автоматично управление на фактически дати на задачите:
Фактическа начална дата на листова задача се попълва при първата свързана покупка на материал; за контейнер — минималната от дъщерните задачи.
Фактическа крайна дата се попълва при маркиране на статус „Завършена"; за контейнер — максималната от дъщерните задачи.
Полетата се попълват само ако са празни — не се презаписват при повторно събитие.
Йерархия на задачите — задачите вече могат да се организират в дърво от контейнери и листови задачи:
Контейнер: групираща задача (до 2 нива дълбочина), без мерна единица; датите и разходите се агрегират автоматично от подзадачите; процентът на завършване е само за четене и се изчислява автоматично.
Листова задача: конкретна работа с количество, единична цена и ръчно въвеждан процент на завършване.
Бюджет с опция за ръчно задаване (Override) — и за двата вида задачи:
По подразбиране: контейнерите събират бюджета от подзадачите; листовите изчисляват количество × цена.
С отметка „Замяна на автоматично изчисления бюджет": задаване на фиксиран бюджет независимо от количеството/подзадачите.
Колони „Бюджет" и „Бюджет на деца" в таблицата на задачите — заменят предишните отделни колони за контейнери и листови задачи.
Индикатор за превишен бюджет (↘) — червен индикатор в колона „Бюджет" при контейнери/листови задачи, чийто ръчен бюджет е по-малък от сумата на подзадачите.
Зависимости между задачи — всяка задача може да зависи от предходни задачи; Gantt диаграмата визуализира зависимостите чрез стрелки; плъзгане за създаване на нова зависимост директно в Gantt.
Каскадна промяна на статус — при маркиране на контейнер като „Завършен" се предлага автоматично завършване на всички подзадачи с диалог за потвърждение.
Йерархичен изглед на таблицата (Drill-down) — превключване между „Йерархичен изглед" и „Плосък изглед".
Контейнери в актове — контейнерите могат да се добавят като позиции в актове; бюджетната стойност идва от estimatedTotalCost.
Обновен отчет Отчет за фирмата. Артикули за многократна употреба използваемост по групи за период. Показва обща стойност, стойност извън склад и процент на използваемост. Информацията е групирана по артикулни групи.
Уголемени формите за добавяне на артикули към Фактури Покупки. Филтрите за артикулите не се записват, тъй като потребителите въвеждат обикновоно различен артикул с всяка фактура.
Филтрите на страницата за артикулни дефиниции се записват.
При въвеждане на нов Клиент/Доставчик системата проверява за дублиране и предупреждава потребителя. За фирми проверката е по ЕИК, за физически лица по телефонен номер.
Възможност за скриване на колони от таблицата Дефиниции на артикули