Мобильный клиент 1С для прорабов: с 3 дней до 4 часов

Мобильный клиент 1С для прорабов: с 3 дней до 4 часов

Предыстория: хаос в полевой отчётности строительной компании

Строительная компания «СтройГрупп» (название изменено по просьбе клиента) работает в сегменте гражданского строительства — жилые комплексы, коммерческая недвижимость, инфраструктурные объекты. На момент начала проекта у компании одновременно велись работы на 7 объектах, каждый из которых курировал собственный прораб или бригадир. Итого — 12 специалистов, рассредоточенных по разным районам города и области.

Проблема, с которой обратился финансовый директор, звучала просто: «Мы три дня не можем закрыть неделю». Каждый понедельник офис превращался в хаос: бухгалтеры обрывали телефоны прорабов, прорабы присылали фотографии рукописных накладных в WhatsApp, кладовщики вручную переносили данные в Excel, а потом всё это собиралось в 1С:ERP руками двух операторов. Погрешность в данных достигала 15–20%, а сроки закрытия отчётного периода срывались системно.

Задача была поставлена чётко: дать прорабам инструмент, который они смогут освоить за один день, и сократить время консолидации данных до нескольких часов. Решение — мобильный клиент на базе платформы 1С с кастомной конфигурацией под нужды строительного учёта.

Аудит текущих процессов: где теряется время

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

  • Прораб на объекте тратил в среднем 2,5 часа в день на бумажную документацию: журналы прихода материалов, акты выполненных работ, табели рабочего времени.
  • Передача данных в офис занимала от 4 до 18 часов — в зависимости от того, насколько оперативно прораб мог сфотографировать документы и отправить их.
  • Ручной ввод в 1С операторами занимал 6–8 часов на каждый объект еженедельно.
  • Сверка и исправление ошибок — ещё 4–6 часов, потому что рукописные данные читались неверно, а номенклатура материалов не совпадала со справочником 1С.

Суммарно цикл от «прораб принял материалы на объекте» до «данные отражены в задачах по 1С:ERP» составлял от 2 до 3 рабочих дней. При этом финансовая служба не могла оперативно отслеживать расход бюджета по объектам и реагировать на перерасход.

Ключевые болевые точки

  1. Отсутствие единого справочника номенклатуры у прорабов — они называли материалы «как привыкли».
  2. Нет контроля остатков на объектах в реальном времени.
  3. Табели рабочего времени заполнялись «задним числом» — с потерей точности.
  4. Акты выполненных работ согласовывались по цепочке бумажных подписей.
  5. Нет фотофиксации поставок — споры с поставщиками не имели доказательной базы.

Архитектура решения: что было разработано

Команда разработчиков приняла решение строить мобильное приложение на базе 1С:Предприятие Mobile Platform — это позволило использовать уже имеющуюся лицензионную базу и обеспечить бесшовную интеграцию с центральной базой 1С:ERP. Альтернативы в виде сторонних мобильных приложений с API-интеграцией рассматривались, но были отклонены из-за рисков синхронизации справочников и необходимости поддерживать два независимых продукта.

Модули мобильного приложения

  • Приёмка материалов — прораб сканирует QR-код или штрихкод на накладной, выбирает позиции из справочника с поиском, указывает количество и фотографирует сопроводительные документы.
  • Списание материалов в работу — выбор объекта, вида работ, статьи затрат; автоматическая проверка остатков на складе объекта.
  • Табель рабочего времени — ежедневное заполнение по бригадам с возможностью отметить неявки, сверхурочные, работу в выходные.
  • Фотоотчёт по этапам — привязка фотографий к конкретным этапам работ и позициям сметы.
  • Согласование актов — электронное согласование КС-2 и КС-3 с уведомлениями в приложении.
  • Дашборд прораба — остатки материалов, план/факт по бюджету, статус согласования документов.

Техническая реализация: код и конфигурация

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

Обмен данными: обработчик синхронизации

// Процедура синхронизации документов приёмки материалов
// Вызывается при восстановлении интернет-соединения
Процедура СинхронизироватьДокументыПриёмки(ИдентификаторУстройства) Экспорт

	Запрос = Новый Запрос;
	Запрос.Текст =
		"ВЫБРАТЬ
		|		ПриёмкаМатериаловМобильный.Ссылка КАК Ссылка,
		|		ПриёмкаМатериаловМобильный.Дата КАК Дата,
		|		ПриёмкаМатериаловМобильный.Объект КАК Объект,
		|		ПриёмкаМатериаловМобильный.СтатусСинхронизации КАК Статус
		|ИЗ
		|		Документ.ПриёмкаМатериаловМобильный КАК ПриёмкаМатериаловМобильный
		|ГДЕ
		|		ПриёмкаМатериаловМобильный.ИдентификаторУстройства = &ИдентификаторУстройства
		|		И ПриёмкаМатериаловМобильный.СтатусСинхронизации = &СтатусОжидает";

	Запрос.УстановитьПараметр("ИдентификаторУстройства", ИдентификаторУстройства);
	Запрос.УстановитьПараметр("СтатусОжидает", Перечисления.СтатусыСинхронизации.ОжидаетОтправки);

	РезультатЗапроса = Запрос.Выполнить();
	Выборка = РезультатЗапроса.Выбрать();

	МассивОшибок = Новый Массив;

	Пока Выборка.Следующий() Цикл

		Попытка
			// Создаём документ поступления в основной базе
			СоздатьПоступлениеМатериаловВОсновнойБазе(Выборка.Ссылка);

			// Обновляем статус синхронизации
			Объект = Выборка.Ссылка.ПолучитьОбъект();
			Объект.СтатусСинхронизации = Перечисления.СтатусыСинхронизации.Синхронизирован;
			Объект.ДатаСинхронизации = ТекущаяДатаСеанса();
			Объект.Записать(РежимЗаписиДокумента.Запись);

		Исключение
			// Фиксируем ошибку, продолжаем обработку остальных документов
			ЗаписьОшибки = Новый Структура("Документ, ТекстОшибки",
				Выборка.Ссылка,
				ОписаниеОшибки());
			МассивОшибок.Добавить(ЗаписьОшибки);
		КонецПопытки;

	КонецЦикла;

	// Уведомляем диспетчера об ошибках синхронизации
	Если МассивОшибок.Количество() > 0 Тогда
		ОтправитьУведомлениеОбОшибкахСинхронизации(МассивОшибок);
	КонецЕсли;

КонецПроцедуры

Автоматическое создание поступления в основной базе

// Создание документа «Поступление товаров и услуг» на основе мобильного документа
Процедура СоздатьПоступлениеМатериаловВОсновнойБазе(МобильныйДокументСсылка) Экспорт

	МобильныйДокумент = МобильныйДокументСсылка.ПолучитьОбъект();

	// Создаём новый документ поступления
	Поступление = Документы.ПоступлениеТоваровУслуг.СоздатьДокумент();
	Поступление.Дата = МобильныйДокумент.Дата;
	Поступление.Организация = МобильныйДокумент.Организация;
	Поступление.Контрагент = МобильныйДокумент.Поставщик;
	Поступление.Склад = МобильныйДокумент.СкладОбъекта;
	Поступление.КомментарийПрораба = МобильныйДокумент.Комментарий;
	Поступление.МобильныйДокументИсточник = МобильныйДокументСсылка;

	// Переносим табличную часть
	Для Каждого СтрокаМобильного Из МобильныйДокумент.Материалы Цикл

		НоваяСтрока = Поступление.Товары.Добавить();
		НоваяСтрока.Номенклатура = СтрокаМобильного.Номенклатура;
		НоваяСтрока.Количество = СтрокаМобильного.Количество;
		НоваяСтрока.ЕдиницаИзмерения = СтрокаМобильного.ЕдиницаИзмерения;
		НоваяСтрока.Цена = ПолучитьЦенуНоменклатуры(СтрокаМобильного.Номенклатура, МобильныйДокумент.Дата);
		НоваяСтрока.Сумма = НоваяСтрока.Количество * НоваяСтрока.Цена;
		НоваяСтрока.СтатьяЗатрат = ОпределитьСтатьюЗатрат(СтрокаМобильного.Номенклатура, МобильныйДокумент.Объект);

	КонецЦикла;

	// Записываем без проведения — бухгалтер проверяет и проводит
	Поступление.Записать(РежимЗаписиДокумента.Запись);

	// Сохраняем ссылку на созданный документ в мобильном документе
	МобильныйДокумент.СозданныйДокументОсновнойБазы = Поступление.Ссылка;
	МобильныйДокумент.Записать(РежимЗаписиДокумента.Запись);

	// Отправляем уведомление бухгалтеру
	ОтправитьУведомлениеБухгалтеру(
		"Новое поступление от прораба: " + МобильныйДокумент.Прораб + 
		" Объект: " + МобильныйДокумент.Объект,
		Поступление.Ссылка);

КонецПроцедуры

Функция определения статьи затрат по номенклатуре и объекту

// Автоматическое определение статьи затрат по правилам распределения
Функция ОпределитьСтатьюЗатрат(Номенклатура, Объект) Экспорт

	Запрос = Новый Запрос;
	Запрос.Текст =
		"ВЫБРАТЬ ПЕРВЫЕ 1
		|		ПравилаРаспределенияЗатрат.СтатьяЗатрат КАК СтатьяЗатрат
		|ИЗ
		|		РегистрСведений.ПравилаРаспределенияЗатрат КАК ПравилаРаспределенияЗатрат
		|ГДЕ
		|		ПравилаРаспределенияЗатрат.Номенклатура = &Номенклатура
		|		И ПравилаРаспределенияЗатрат.Объект = &Объект
		|		И ПравилаРаспределенияЗатрат.Активно = ИСТИНА
		|УПОРЯДОЧИТЬ ПО
		|		ПравилаРаспределенияЗатрат.Приоритет УБЫВ";

	Запрос.УстановитьПараметр("Номенклатура", Номенклатура);
	Запрос.УстановитьПараметр("Объект", Объект);

	Результат = Запрос.Выполнить();

	Если НЕ Результат.Пустой() Тогда
		Выборка = Результат.Выбрать();
		Выборка.Следующий();
		Возврат Выборка.СтатьяЗатрат;
	КонецЕсли;

	// Если правило не найдено — возвращаем статью по умолчанию
	Возврат Справочники.СтатьиЗатрат.НайтиПоКоду("МАТЕРИАЛЫ_ПРОЧИЕ");

КонецФункции

Процесс внедрения: как обучали прорабов

Технически грамотное решение — это только половина успеха. Вторая половина — принятие системы конечными пользователями. Прорабы строительной компании — люди опытные, но далеко не все дружат со смартфонами за пределами звонков и мессенджеров. Средний возраст — 42 года. Несколько человек открыто скептически отнеслись к идее «тыкать в телефон вместо того, чтобы работать».

Этапы обучения

  1. Пилот на двух объектах (2 недели). Выбрали двух наиболее лояльных прорабов — тех, кто сам жаловался на бумажную волокиту. Они работали параллельно: вели и бумажные журналы, и мобильное приложение. Это позволило выявить UX-проблемы без риска для бизнеса.
  2. Доработка по итогам пилота (1 неделя). Главные замечания: кнопки слишком маленькие (добавили крупный режим интерфейса), поиск по номенклатуре работал только по точному совпадению (добавили нечёткий поиск и поиск по синонимам), не было возможности быстро добавить позицию, которой нет в справочнике (добавили форму заявки на добавление номенклатуры).
  3. Групповое обучение (1 день). Все 12 прорабов собрались на базе компании. Обучение строилось на реальных сценариях: «вам привезли кирпич — что делаете», «бригада отработала смену — как заполнить табель». Никаких презентаций — только практика на тестовой базе.
  4. Поддержка в первые две недели. Создали чат в мессенджере с разработчиком и ответственным сотрудником офиса. Время ответа на вопросы — не более 30 минут в рабочее время. За две недели поступило 47 вопросов, большинство — в первые три дня.

Работа со скептиками

Трое прорабов продолжали саботировать систему после группового обучения. Решение оказалось неожиданным: финансовый директор лично приехал на один из объектов и показал прорабу, как выглядят его данные в общем отчёте — и как из-за задержки его объект «висит красным» в сводке. После этого разговора проблема исчезла сама собой. Люди начали понимать, что система не контролирует их, а помогает им же выглядеть хорошо в глазах руководства.

Интеграция с бухгалтерским учётом и ЭДО

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

Реализация: при поступлении входящего ЭДО-документа в центральной базе система автоматически создаёт «задание на приёмку» для соответствующего прораба. Прораб получает push-уведомление, открывает задание, видит список позиций из электронной накладной и проставляет фактически принятое количество. Расхождения автоматически фиксируются и уходят в претензионный отдел.

Параллельно была настроена интеграция с 1С:Бухгалтерией для автоматической выгрузки проводок по принятым и списанным материалам. Бухгалтер получает уже готовые документы, которые нужно только проверить и провести — ручной ввод исключён полностью.

Результаты через 3 месяца после запуска

Через три месяца после полноценного запуска системы команда провела замеры и сравнила с исходными показателями. Результаты превзошли ожидания:

Показатель До внедрения После внедрения Изменение
Время сбора недельных отчётов 2–3 рабочих дня 3–4 часа −92%
Погрешность данных по материалам 15–20% менее 2% −87%
Время прораба на документацию в день 2,5 часа 35 минут −77%
Количество операторов ввода данных 2 штатных сотрудника 0 (функция упразднена) −100%
Споры с поставщиками по количеству 8–12 в месяц 1–2 в месяц −85%
Задержки закрытия отчётного периода каждый месяц 0 за 3 месяца −100%

Отдельно стоит отметить неожиданный эффект: прорабы начали более ответственно относиться к остаткам материалов. Когда человек видит в приложении, что у него на складе объекта осталось цемента на 3 дня работы, он заранее подаёт заявку на поставку — а не звонит в панике в пятницу вечером.

Финансовый эффект

Найдите специалиста для решения этой задачи на koderion.ru