Производственный учёт у нас в 1С:КА, и строили мы его дважды. Первый раз — на типовой давальческой схеме в КА 2.4, второй — в собственном расширении, когда обновление до 2.5 первую схему сломало.
Сейчас сдельную оплату раскройщикам и швеям мы начисляем двумя кликами, а перед этим часа два сверяем остатки. На КА 1.1 то же самое занимало у бухгалтера два дня.
Здесь — история решений: почему мы выбрали КА, как использовали давальческую схему для собственного производства и зачем затем написали расширение.
Содержание · 8 разделов
С чего всё начиналось
Мы шьём полным циклом: кроим, шьём в своём цехе и силами надомниц, принимаем, храним и отгружаем. На пике в цехе работают 10–15 швей и примерно столько же — на дому.
На КА 1.1 мы работали примерно с 2009 года, после Excel. Производство в системе почти не жило: учётчик вёл сменные задания на бумаге и сводил их в Excel, а перед расчётом зарплаты бухгалтер ещё два дня сверял остатки. Это была самая ручная часть нашего учёта.
От учёта мне нужно было немного, но быстро: кто и что раскроил и сшил, куда ушли материалы, что сейчас на руках у цеха и надомниц и сколько кому начислить.
Вариантов было несколько, и почти все отпали:
- 1С:ERP, раньше УПП. При выборе решения я оценивал их внедрение как слишком затратное для наших задач на том этапе.
- Другие конфигурации 1С. Смотрели — функционала не хватало.
- Связка из нескольких баз. Я видел у коллег, что бывает, когда обмены приходится править постоянно, и повторять не хотел.
- Типовой производственный учёт в самой КА. Он не давал нам нужной детализации заданий, движения кроя и расчёта по принятой продукции.
Оставалось строить оперативный учёт внутри КА самим. При этом система обязана была работать без сбоев, спокойно переживать обновления и выдерживать нагрузку — и обновления в итоге стали самым интересным местом этой истории.
Первый заход: давальческая схема, которую я сам считал кривой
В начале 2019 года мы перешли на КА 2.4. Первую версию оперативного учёта собрали на механизме переработки давальческого сырья.
Идея была такая. Переработчиком в нашей схеме выступают цех и надомная сеть, а давальцем — отдельная управленческая организация, заведённая в базе для учёта производственных операций. Использовали документы от заказа давальца до отчёта давальцу.
Да, это криво, и я понимал это с самого начала. Но учёт и контроль хотя бы в таком виде лучше, чем никакого, и заметно дешевле, чем ERP под наш масштаб.
И схема заработала. Уже на 2.4 ручной учётчик стал не нужен. Уязвимость была в другом: решение целиком опиралось на типовые документы, операции и проводки, которые разработчик конфигурации мог изменить.
Что сломалось: обновление, которое поставило вопрос ребром
В 2021 году появилась КА 2.5. Когда мы проверили переход на тестовом стенде, изменения типовых механизмов нарушили нашу схему — от документов до проводок.
Спасло нас старое правило: крупные обновления сначала идут на стенд и только после проверки — в рабочую базу. Рабочая база не пострадала, а у нас появилось время подумать. Переход на 2.5 мы отложили на полгода.
Выбор был простой и неприятный.
- Переписать схему под новый механизм. Работы там был бы непочатый край, а при следующей крупной переделке мы оказались бы в той же точке.
- Написать свой оперативный контур в расширении — ровно под наши задачи, с меньшей зависимостью от типовой давальческой схемы.
По предварительной оценке деньги и трудозатраты выходили почти равными. Я выбрал собственный контур: рассчитывал меньше зависеть от переделок типового механизма.
В первый раз мы опирались на готовый типовой механизм. Ко второму заходу решили вынести оперативный учёт в отдельные документы и регистры расширения.
Второй заход: своё расширение
Код расширения написал подрядчик 1С, а на мне были постановка, проектирование и приёмка. Техническое задание я строил вокруг регистров: из чего брать данные и какой результат ждать на выходе. Потом около месяца сам гонял решение на стенде в роли альфа-тестера. Полгода отсрочки как раз и ушли на разработку и отладку.
Из первой попытки мы вынесли правило: собственный оперативный учёт держим в своих документах и регистрах, а итоги передаём в регламентированный контур отдельно. Это уменьшает зависимость от типовой схемы, но связи с объектами основной конфигурации остаются.
Для людей поменялось главное: данные теперь попадают в учёт в момент операции. В цехе висит сенсорный экран со сканером: сотрудник сканирует свою карточку и видит свои задания, отмечает «Раскроено» или «Пошито», печатает этикетку на пачку. Кладовщик с ТСД собирает крой и материалы для надомниц под конкретное задание и принимает готовое. А на вкладке «Проблемы» видно, где не хватило материала, кто выпустил брак и кто отменил раскрой из-за кривой спецификации.
Надомные исполнители работают по договорам ГПХ. Оплачиваем работу после приёмки, а выработку, начисления исполнителям и налоги отражаем в учётной системе.
В нашем процессе сдельное начисление связано с приёмкой: учитываем изделия, которые ОТК принял на склад. Перед расчётом сверяем, что числится за цехом и надомницами; на сверку уходит около двух часов, затем начисление выполняется двумя кликами.
Сопровождение осталось. Если при обновлении меняется типовой объект, на который ссылается расширение, нужна правка и проверка. Поэтому крупные обновления сначала проходят на тестовом стенде.
Цифры
- Около 2 часов сверки, затем 2 клика на начисление сдельной оплаты. На КА 1.1 бухгалтер тратил на эту работу 2 дня.
- Без ручного учётчика — с перехода на КА 2.4.
- 10–15 швей в цехе на пике и примерно столько же надомниц.
- Полгода — на столько отложили переход на 2.5 и за это время написали и отладили расширение.
- Около месяца — моё собственное тестирование на стенде перед запуском.
В каких границах это работает
- Это оперативный учёт, а не ERP. Задания, этапы, незавершённое производство, сдельная оплата — всё, что нам нужно, решено. Остальное, что умеет ERP, мы не повторяли.
- Масштаб. Решение подобрано под наши задачи небольшого производства. Для другого набора процессов нужно заново оценивать типовые возможности, доработки и ERP.
- Дисциплина. Учёт верен ровно настолько, насколько верно люди отмечают операции. Поэтому сверку незавершённого производства перед начислением мы не пропускаем.
- Печать с ТСД. Акт приёмки для надомницы пока печатаем с компьютера: вывести лист А4 со всеми реквизитами прямо с терминала оказалось слишком трудоёмко.
Что бы я сделал иначе
По большому счёту первую схему я не считаю напрасной работой: она дала нам несколько лет нормального учёта вместо ручного. Со вторым заходом у нас появился собственный оперативный контур и меньше зависимости от типовой давальческой схемы.
Главные уроки для меня — учитывать зависимости от типовых механизмов и проверять крупные обновления до рабочей базы. Тестовый стенд позволил увидеть проблему с нашей схемой и подготовить переход без остановки рабочего учёта.
Что пока не решено
Спецификации. Самое больное место. От ресурсной спецификации зависят и нормы расхода материалов, и цена изделия, а из-за ошибки раскройщику иногда приходится отменять раскрой. Хочется упростить их заполнение, но готового решения я пока не продумал.
Раскладка для простых изделий. Хочу, чтобы к заданию на раскрой сразу печаталась раскладка. Раскройщик раз разложил материал, снял на телефон или ТСД, снимок лёг в спецификацию — и при следующем таком задании он печатается сам. Для наволочек и простыней это имеет смысл; сложные вещи вроде халатов и сумок давно раскладываются в цифре и печатаются на плоттере. Отправлять раскладку на плоттер прямо с рабочего места раскройщика — тоже задача на будущее.