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