Производственный учет + управленческий учет для мебельного производства

[juramebel]

Наша компания занимается производством мебели как по проектным подрядам, так и по индивидуальным заказам.

Проект автоматизации начался случайно. Искали ПО для управления цеховыми операциями. Все что есть на рынке либо дорого, либо сложно, либо не возможно кастомизировать и т.д. Случайная находка Тотума стала просто открытием. На нем изначально был реализовано только управление техоперациями. До Тотума также использовались совместно 1с УНФ для управленческого учета, Планфикс в качестве CRM, Базис-Склад для оперативного снабжения материалами и комплектующими. Постепенно все блоки были реализованы в Тотуме, и от остального ПО отказались.
Проект вел и продолжает вести один человек. Я отвечаю за подготовку производства и ПО. С программированием был связан только в школьном возрасте, немного изучая турбопаскаль. За время работы в разных компаниях сталкивался с необходимостью автоматизации каких-то аспектов, и в разное время выполнял для этих нужд небольшие локальные проекты на ПланФиксе и ElmaBPM.
Это чтобы был понятен мой достаточно дилетантский уровень. Проект начался в ноябре, выполняется в основном в свободное от основных обязанностей время. Иногда с большими перерывами (последний блок – снабжения, сделан после перерыва примерно в 2 месяца).

Из плюсов, которые отметили для себя:

• очень быстрый старт. Можно начать с основной проблемы, автоматизировать ее прям сегодня, и постепенно докручивать в процессе работы. Разработка и использование становятся непрерывным одним процессом.
• привычный табличный вариант работы с данными
• разбивка поведения на простые понятные коды облегчает работу непрограммисту
• просто отличная документация и очень лояльная и грамотная поддержка. Допускаю, что это благодаря небольшой команде. И с ростом (который искренне желаю) ситуация не ухудшиться.

Из субъективных минусов:

• не очень понятная мне система нотификации. Из-за этого практически ее не используем. Просто не доходят руки все это настроить. И даже если ее настроить сделать какие то оповещение наружу задача для непрограммиста сложная. Из-за этого использование, например, комментариев, как средства коммуникации в команде невозможно.

Улучшения по нотификациям: #145 (comment)

• какая то неочевидная для меня последовательность обновления таблиц через recalculate, когда их несколько и влияют друг на друга. Не всегда могу спрогнозировать результат.
• коды, влияющие на поведение, могут быть абсолютно в разных полях. Если надолго выпасть из процесса, то логика становится непрозрачной. Возможно это связано с невыработанных мной неких правил хорошего тона разработки на Тотуме. Будет здорово, если их смогут сформулировать разработчики.

В настоящий момент работают следующие блоки:

Блок продажи:

• Сделки – ведение контрагентов, прохождение по статусам. Каждая сделка должна иметь текущие шаги. Их отсутствие или просрочка сразу видна на общем обзоре сделок.
• Договоры – «основная линия» блока продаж. На договор завязаны поступления денег, заказы на производство, мотивации менеджеров, агентские выплаты и т.д. Сразу из карточки договора менеджер по производству может создать заказ на производство, или занести потребности на комплектующие, которые не будут проходить через цех и т.д.

Блок производства. Основной функционал:

• Заказы на производство – «основная линия» блока производства. К заказам привязаны техкарты, спецификации на комплектующие, задачи, сроки отгрузки и т.д. Из карточки заказа можно создать связанные техкарты, загрузить спецификацию из внешней конструкторской программы ( через обработчик по типу этого (Импорт данных из эксель в простую таблицу #32)), списать комплектующие. В разделе спецификации видно состояние по каждой позиции – дефицит, заказана ли она, есть ли кол-во чтобы ее выдать и т.д.
• Техкарты – служат для фиксации операций. В нашем случае чаще всего выполняются с однородным материалом (и получается полуфабрикат). Или являются техкартами сборки (и получается готовое изделие или промежуточный полуфабрикат).
• Пакетные крои – предназначены для объединения в пакет кроя одного материала для оптимизации загрузки и отходности.

Блок задач.

Предназначен для фиксации и управления любых задач как себе, так и коллеге. Работает по типу шагов в сделке. Задача должна иметь шаги с конкретными датами, и они не должны быть просрочены.

Блок цех.

Предназначен для отображения операций, доступных для выполнения в цеху, а также для фиксации их выполнения. Максимально упрощен для использования.

Блок финансы. Основные подразделы:

• Счета и кассы – отображают остатки по всем счетам, а также дефициты исходя из плана оплат на дату.
• Счета на оплату – фиксируют план платежей. Связаны с блоком снабжения.
• Операции финансы - таблица фиксирует все движения по счетам. Для того, чтобы не пересчитывать все операции несет запись об остатке.
• План поступлений – прогноз поступлений из договоров по предоплатам и доплатам.
• Раздел отчетов – самым интересным был раздел отчетов для данного блока. Пока он включает в себя Анализ ДДС по статьям, Деньги на дату по счетам и Анализ плана финансы. Последний позволяет прогнозировать кассовые разрывы и состояние финансов исходя из всех известных планируемых выплат и поступлений.

Блок снабжения. Самый свежий блок. Основные разделы:

• Справочник номенклатуры – содержит записи номенклатуры с остатками на складах, данными об основном поставщике, типе пополнения и т.д. В настоящий момент около 16 000 позиций.
• Документы движения номенклатуры – все документы, оформляющие движения – накладные, списания, перемещения и т.п. Связаны с заявками на снабжение, заказами на производство, договорами с покупателями.
• Потребности на заказы сводная – обработка анализирует все потребности текущих заказов исходя из остатков на складах и уже оформленных заявок на снабжение. Сразу из нее можно создать заявку на снабжение, используя рекомендуемое кол-во, либо скорректировав его.
• Заявки на снабжение – фиксируют заказы поставщикам. Связываются со счетами на оплату.

[ttm-alexeypolunin]

Спасибо огромное за описание вашей системы, особенно за скриншоты! Мы по ним видим, что принципы, которые мы закладывали в систему реализовываются не только в наших собственных проектах — я искренне радуюсь.

Про мутные моменты и что мы с ними собираемся делать:

Из субъективных минусов:

Нотификации

Объективно получилось достаточно сложно и надо упростить добавив функцию notificationSend: которая сама все куда надо расставит. Еще руки не доходят сделать хорошую инструкцию по отправке нотификаций в Telegram. У самого Тотума нативные нотификации на десктопах будут как только мы запакуем все в Electron для десктопного приложения.

Последовательность обновления таблиц через recalculate, когда их несколько и влияют друг на друга.

Да, сам сталкивался. Что думаем делать:

• сделаем раздел учебного курса по чтению отладки
• сделаем еще один вид отладки, который будет показывать что вычисляется, пересчитывается и какие действия вызываются

Коды, влияющие на поведение, могут быть абсолютно в разных полях. Если надолго выпасть из процесса, то логика становится непрозрачной.

• сделаем режим, в котором можно будет запустить действие и посмотреть отладку без изменения в базе — это должно пофиксить выпадание если некоторое время не занимался проектом. Можно будет ткнуть, получить отчет и прям из него обзорно посмотреть коды.
• сделаем поиск по кодам.

По срокам:

Мы на прошлой неделе провели ревизию планов и получилось, что нашими двумя рабскими силами времени уйдет 2 года. Но мы надеемся, что мы сможем ускорится за счет внешнего финансирования.

[ttm-alexeypolunin]

Тотальное упрощение по нотификациям c 3.7.46:

= : notificationSend(users: 5; title: "Заголовок какой-то нотификации"; ntf: "Какая-то нотификация"; eml: "Проверка email нотификации")

• users — одно значение или список id пользователей.

• title — заголовок (для email и списка нотификаций)

• ntf — html нотификации в интерфейсе (сразу активная с момента отправки), будет отправлена если параметр указан

• eml — html email, который если указан, то будет отправлен на указанный в таблице пользователей email пользователя. Отправка будет в стандартном шаблоне Тотума.

• custom — про это будет в документации через некоторое время (можно задать кастомные сендеры, например телеграм бота итп)

[juramebel]

Супер! Спасибо огромное!
Будем пробовать.

[ttm-alexeypolunin]

Выбрать их id через selectList из таблицы users по where: 'roles' = ROLE

[Zaskokin]

Добрый день. А как то можно купить ваше решение?

[juramebel]

Добрый день.
Извините, не видел вопроса.
К сожалению, это вряд ли возможно, по причинам, что подробно тут на форуме описывал Алексей.
У нас разработка происходит непрерывно.
Автоматизировав основные боли, дальше развитие происходит без какого то плана, просто по насущным потребностям.
То есть нет какого то ТЗ, плана развития и т.д.
Я не являюсь программистом и в общем занят основной работой. Просто я глубоко погружен во все процессы и мне из-за этого проще, чем внешнему человеку. И соответственно решение не универсальное, очень узко заточено под наши потребности.
С Тотумом работаю просто в какие то свободные промежутки.
Бывает так, что у нас появилась идея, к примеру, что вот текущих операций может быть несколько в техкарте, а не одна.
И вот уже быстро делается новая версия расчетной в цикле, и пошли отрабатывать новую идею.

На самом деле от этого поста в нашей системе появилось оочень много. Думаю может быть продолжить пост с дополнениями, по особо интересным блокам. Вдруг кто то подчерпнет для себя интересные идеи.

[juramebel]

Буду выкладывать небольшие дополнительные описания дополнительной функциональности.
Прошу админов отметить, если лучше поступить как то по иному (новая тема к примеру).
В первом посте я отметил неудобство, которое представляли для меня оповещения и коммуникации в Тотуме.
К счастью разработчики кардинально упростили функционал оповещений. Теперь с этим проблем нет.
Для получения оповещений всех сотрудников и общения используем связку Тотум + Mattermost.
Связка получилась гибкой и удобной.
В разных частях интерфейса есть кнопки, например, создания чата к договору. Если он уже создан, то кнопка "Открыть чат".
Сами чаты создаются из Тотума по определенному шаблону. И только один раз к одному договору.
Благодаря ушла проблему дублирования чатов, неудобного поиска по ним и т.д.

Также от тотум бота приходят все сообщения, которые необходимо увидеть сотруднику.

Связка работает в обе стороны.
Например, сотрудники отмечаются при приходе на работу через мессенджер, отправляя быстрые команды, занесенные в MM.
В тотуме по получении этих сообщений автоматически ведется журнал учета рабочего времени.

Кроме этого для удобства на некоторых технологических операциях, которые ранее требовали обращаться к стационарному компьютеру, созданы быстрые команды для расчета ряда параметров. Сотрудник вводит данные в мессенджере и Тотум делает необходимые вычисления и присылает ему ответ.

[ttm-alexeypolunin]

С интеграцией чата мне идея очень понравилась. Когда-нибудь мы дойдем до похожей нативной интеграции с Rocket Chat :)

[LostAlly]

Спасибо, что опубликовали свой проект и продолжаете обновлять, даже скрины очень помогают сформировать логику своего приложения более правильно. Успехов и в ожидании дальнейшего развития вашего приложения.

[juramebel]

Сегодня вкратце опишу важный блок для отдела продаж "Расчеты".
Расчеты привязываются к конкретной сделке и позволяют быстро просчитать мебельные изделия для коммерческого предложения клиенту.
Блок большой, остановлюсь только на главных особенностях.
Расчетов к сделке может быть неограниченное кол-во, все они хранятся в отдельной таблице циклов. Признак активный/неактивный влияет на предварительную сумму сделки.
Расчеты могут полностью дублироваться, что позволяет сохранять предложения разных модификаций (разные типы фасадов и т.п.)

В главном окне расчета достаточно много разных ячеек для тонкой настройки (наценки, скидки, дублирование изделий и т.д.). Для того чтобы было удобнее переключаться между разными наборами ячеек (расчет, оформление предложения), сделаны кнопки на пресеты через форматирование таблицы.
Каждая строка таблицы главного окна описывает основные параметры одного изделия - габаритные размеры, кол-во, описание, которое выводится в коммерческое предложение.

Можно вставить уже готовое изделие из другого расчета. Один из расчетов используется в качестве шаблонов кухонных изделий с уже заполненными деталями. Их можно вставить в новый расчет и скорректировать параметры.

В таблице циклов есть несколько расчетных таблиц. Главные из них - детали (содержит данные о всех плитных деталях изделия), комплектующие (фурнитура и крепеж их справочников), допы (что-то, чего нет в справочниках, разовые комплектующие), погонаж и др.

Основная таблица - детали. Геометрические размеры деталей можно привязывать к габаритным размерам изделия из основной таблицы через формулы. Именно в этой таблице я первый раз познакомился с этой функциональностью и она оказалась крайне удобна.
Впоследствии формулы появились практически во всех таблицах, связанных с кол-вом или деньгами.

В детали также заносятся погонажные детали, для которых тотум выполняет раскрой на хлысты (в текстовом формате можно посмотреть этот раскрой).

Для двухмерных деталей раскрой не выполняется, но есть функциональность, частично его заменяющая.
Если материал в базе помечен, как нестандартный (то есть не закупаемый на склад на постоянной основе), тотум рассчитывает его расход по всему расчету, определяет сколько материала останется невостребованным до целого листа и распределяет остатки между изделиями пропорционально расходу этого материала.

Отмечу, что впоследствии для другого блока в тотуме был реализован и полноценный двумерный раскрой. Но в целях расчета менеджера эта функциональность избыточна и сюда его не добавляли.
Комплектующие также могут привязываться к габаритам изделия (например профили метражом, или крепеж исходя из длины).

Для быстрого просмотра всех деталей и комплектующих расчета можно открыть общий отчет. Помогает выявить несостыковки.

Если все ок, можно заполнить описания изделий и распечатать коммерческое предложение.

Этот блок впервые всерьез заставил задуматься о быстродействии.
И заставил переехать на полноценную виртуалку)
Поскольку расчетные таблицы пересчитываются каждый раз, когда вносятся изменения хотя бы в одну ячейку, в крупном расчете работа становилась практически невозможна.
Решение было принято такое.
Добавил кнопку расчет включен/отключен и если расчет отключить, то все формулы везде просто проверяют условие включения. Если оно не выполняется, никакие расчеты не производятся.
Кроме того по неопытности сначала многие формулы сделал не оптимально, много было лишних расчетов. В общем впоследствии удалось скорость существенно поднять. Но все равно при включенных расчетах работать некомфортно.
И думаю и сейчас я не провел работу по оптимизации до конца, но жалобы менеджеров сократились до терпимого уровня) так что пока работы на этот счет остановлены.

Хотел еще пару слов сказать о больших кодах в тотуме.
Создатели изначально обозначают, что внутренний код тотума создан для коротких задач. И писать какие-то достаточно крупные блоки действительно неудобно. Вот, например, кусок кода двумерного раскроя из моего другого блока.

Год назад было чуть больше времени и я немного посмотрел начальные уроки по питону. И понял, что код на нем в данном случае будет короче существенно. И понятнее.
Но.
Во-первых, неудобно не значит невозможно). Да и задачи на такие длинные куски кода возникают достаточно редко.
Во-вторых, все это с лихвой окупается удобством применения тотума каждый день для самых разнообразных задач.
Поэтому в ближайших планах наконец переезд на про версию.

В следующий раз покажу наиболее интересные интерфейсы сотрудников производства.

[ttm-alexeypolunin]

Для var() должен был быть сахар вида

row: select(...) -> $#variable

Тогда все эти вызовы функций var отдельными строками отпадают за ненадобностью:

=: while(condition: ...; action: $code; postaction: $#variable)
	
	code: math`$#variable{def: 0} +  $sel` -> $#variable
         // назначение дефаульта через {...}
             sel: ...

Сразу все в 2 раза короче станет

И есть возможность решать эту задачу без while, тогда тут будет 10 строк на все, через рекурсивный вызов, но практика показала, что у нормальных людей оперативки в башке на это не хватает

PS. Но я не знаю когда это будет. Посмотрим на результат внедрения лицензий и дальше поймем какие у нас возможности :)