АО «Янтарь»
Задача.
Перед компанией «Числа» руководство АО «Янтарь» поставило несколько задач:
- В связи с введением ИС Меркурий – системы обязательной электронной ветеринарной сертификации, у АО Янтарь появилась задача автоматизации процессов по работе с электронными ветеринарными сертификатами: гашение сертификатов по пришедшему сырью, отражение в ИС Меркурий выпуска продукции, списание партий сырья на выпуск, ввод сертификатов на отгрузку продукции.
- В связи с прекращением поддержки 1С:Зарплата и управление персоналом редакции 2.5, появилась потребность перехода на 1С:Зарплата и управление персоналом редакции 3.1. Помимо «разового» перехода но новую редакцию ЗиУП, требуется создание «нетиповых» механизмов выгрузки данных о начисленной заработной плате в текущую систему учета: 1С: Управление производственным предприятием.
- Ввести систему штрихкодирования готовой продукции: для автоматизации отгрузки продукции покупателям, часто случались ситуации, что отгрузили не то, что нужно, или загрузили заказ покупателя не в ту машину, не в том объеме.
Решение.
Зарплата.
Решение задачи по переходу из 1С:ЗУП ред. 2.5 на 1С:ЗУП ред. 3.1 проходило по типовому сценарию: выгружены и проверены данные типовыми правилами, проведено обучение сотрудников. Так же были разработаны механизмы выгрузки данных из ЗУП 3.1 в УПП по начисленной зарплате. Как известно, в УПП есть свой блок расчета зарплаты, 1С предполагает, что все расчеты зарплаты ведутся в УПП, и никаких типовых выгрузок из ЗУП 3.1 в УПП нет. Мы такую выгрузку сделали.
Учет и Меркурий.
Задача по интеграции с ИС:Меркурий оказалась сложнее, чем переход на новую версию 1С:ЗУП. Для Меркурия нужно «явно» указывать партию продукции/сырья при списании, и после отправки данных внести изменения в отправленные данные уже нельзя.
К нам АО «Янтарь» обратилось с уже порядочно и бестолково переписанной очень известной фирмой-франчайзи конфигурацией 1С:УПП, в программе часто происходили сбои, рассинхронизации данных оперативного и бухгалтерского учетов, бессмысленные движения документов. Заложенный бюджет на внедрение УПП уже давно был исчерпан, а требуемого результата не было, система работала с массой замечаний.
Поэтому перед автоматизацией синхронизации УПП и ИС:Меркурий было принято решение «нормализовать» учет в программе. Было сделано следующее:
- введен серийный учет готовой продукции. Почему сразу для пищевого производства не было это сделано – непонятно. Мы разработали схему учета готовой продукции по сериям, согласовали её с Заказчиком, определили необходимые доработки, в основном это модификация печатных форм, оптимизация процедуры подбора серии, создание некоторых контрольных функции. Согласованный перечень доработок зафиксировали в тексте технического задания и достаточно быстро реализовали.
- изменена схема ввода производственных документов. Раньше сотрудники Заказчика вводили нетиповой документ «Дневная ведомость», документ не делал никаких движений по регистрам. Затем сотрудники запускали обработку, которая по введенным документам «Дневная ведомость» генерировала типовые документы: Требование-накладная, Отчет производства за смену, Перемещение товаров. В такой схеме учета был один существенно «слабый» момент: никакого контроля за тем, что данные, введенные в дневной ведомости, совпадают с данными, отраженными типовыми документами системы, нет. Например, сотрудники исправили ошибку в Дневной ведомости – не то сырье указано, не то количество выпуска отражено, а типовые документы так и остались со старыми данными, потому что обработку никто не перезапустил. Мы оптимизировали алгоритмы создания типовых документов, и, самое существенное, документы учета теперь создаются/меняются автоматически при изменении дневной ведомости. Были существенно переработаны механизмы и процедуры создания документов: все происходит в одной транзакции, если нельзя изменить какой-либо связанный типовой документ, то и дневную ведомость изменить тоже нельзя.
- контроль отрицательных остатков. В ИС Меркурий нельзя отправить операцию продажи продукции, которой нет не складе, Меркурий никаких отрицательных остатков не допускает. В системе Заказчика никакого контроля отрицательных остатков не было, сначала продавали, когда-то потом отражали выпуск продукции, если не забудут запустить обработку из прошлого пункта. Здесь мы предложили Заказчикам нашу собственную разработку, встраиваемый модуль «Триггер контроля отрицательных остатков», подробнее есть статья на нашем сайте: http://www.4isla.ru/poleznoe/it-analitika/polozhitelnie_ostatki/
- оптимизация проведения по партиям. Сотрудники АО «Янтарь» жаловались, что очень долго проводятся документы в УПП. Оборудование выбрано с запасом для текущих условий эксплуатации УПП, а документы проводятся долго: одна реализация, строк на 15 продукции, проводилась в районе минуты. Стали разбираться, в чем же проблема, первым делом запустили замер производительности. Сразу же было выявлено, что 95% времени от проведения документа занимает выполнение нетипового запроса к регистру партий, такой запрос «придумали» прошлые внедренцы. Кратко напишем, что в запросе вместо использования виртуальных таблиц, было выполнено обращение к обычной таблице регистра накопления. А то, что нужно использовать виртуальные таблицы – это один из вопросов «начального» теста 1С:Профессионал по платформе. Так что не постесняйтесь спросить у программиста, какие у него есть сертификаты. Заменили в запросе текст, обращаемся к виртуальной таблице: и логику доработок сохранили, и документы стали быстро проводиться. Так же сотрудники АО «Янтарь» жаловались, что партии сырья уходят в минус. Сначала мы попытались восстановить последовательность проведения документов – не помогло, проанализировали код. Конечно же проблема была в доработках, причем в этом случае логики в доработках не было никакой, мы просто убрали доработанный код, вернули типовой – и все заработало хорошо. Проверяйте сертификаты у программистов!
Для синхронизации с ИС:Меркурий был выбран программный продукт 1С:Управление ветеринарными сертификатами (1С:УВС). В базе УПП к тому моменту уже велся серийный учет готовой продукции: в серии указывалась дата выпуска и документ выпуска, т.е. при отгрузке продукции можно было достоверно определить, из какой партии выпуска отгружается продукция. Нельзя отгрузить «в минус», остатки контролируются, нельзя уменьшить документ выпуска, если продукция уже отгружена.
Синхронизация с ИС:Меркурий подразумевает два раздела:
- это добавление некоторых ограничений в учете в УПП (например, если выпуск отправлен в Меркурий, то его нельзя уменьшить, а вот увеличить можно –в Меркурии можно «довыпустить» увеличенное количество)
- разработка механизмов синхронизации, в данном проекте – это выгрузка из УПП «первичных» документов в базу 1С:УВС, и разработка механизмов «обратной связи»: если из 1С:УВС документ успешно «ушел» в Меркурий, то в УПП этот документ уже исправить нельзя. При этом был реализован достаточно «мягкий» запрет, только по тем реквизитам, которые выгружаются в Меркурий: если это документ отгрузки, то цена отгрузки в Меркурий не передается, только количество. Количество в УПП исправить нельзя, а цену можно.
После того, как была разработана и протестирована схема обмена с ИС:Меркурий, в июне 2018 года началась эксплуатация системы с основным сервером Меркурия. В середине июня был принят законопроект, вносящий поправки в перечень обязательно подлежащей сертификации продукции, а именно: сыры, плавленая продукция стали не обязательными к фиксации в ИС:Меркурий. Доработка функциональности УПП была проведена достаточно быстро и легко: если до этого мы предполагали синхронизировать все операции с поднадзорной продукцией, без участия пользователя, то теперь в документах УПП появилась галочка «Отразить в Меркурии. Смотрится такая галочка вполне уместно: управленческий, бухгалтерский, налоговый, ветеринарный учет. Конечно, за этой галочкой стоит множество механизмов контроля, например, нельзя отправить в Меркурий отгрузку той серии продукции, что не была отражена выпуском в Меркурии, и прочие. Так что, по сути, получится четвертый раздел учета в УПП.
Штрихкодирование.
Для решения поставленной задачи по штрихкодированию продукции нам очень пригодился введенный учет по сериям номенклатуры. В каждой серии продукции в УПП автоматически заполняется информация о выпуске: дата выпуска, скор годности, номер документа выпуска (это номер партии). Вся эта информация содержится в штрих-коде, который печатается для упаковок: ящики, ящики собираются в паллеты.
Реализовано рабочее место упаковщика с возможностью печати этикеток, печать происходит на специализированных высокопроизводительных принтерах этикеток. С помощью радиотерминалов оборудовано порядка 15 рабочих мест кладовщиков для учета отгрузки готовой продукции.
Мороженое.
При начале работы с АО «Янтарь» задачи по учету мороженого не ставилось. Жители Воронежа знают, что в районе площади Заставы, есть завод «Холод», производящий вкусное мороженое. Бизнес идет своим чередом, АО Янтарь развивается, теперь завод «Холод» принадлежит АО Янтарь, с 2019 года мороженое будет выпускаться под маркой «Янтарь». Соответственно, появилась задача по учету операций по выпуску мороженого. При расчете рецептур на мороженое используются другие физико-химические показатели продукции и сырья, есть некоторые отличия учета производственных операций по мороженому от плавленой продукции.
Сотрудники «Холода» попытались своими силами адаптировать конфигурацию УПП под учет мороженого. В результате за два месяца до даты начала выпуска мороженого (это сезонное производство, зимой не высокий спрос на мороженое, итак холодно) руководство АО Янтарь обратилось к нам с задачей по организацией учета мороженого. Потому что «программисты что-то написали, но ничего не работает». Пришлось нам разбираться в технологии производства мороженого, особенностях расчета рецептур, расчета расхода сырья в зависимости от показателей сырья. Решили не начинать все с нуля, как сделали наши «коллеги» из известной фирмы-франчайзи, а адаптировали все существующие механизмы по плавленой продукции для учета мороженого. При этом используется один документ для отражение выпуска и мороженого, и сыров, и вафлей, и наполнителей, просто в этом документе появились виды операций, и в зависимости от вида операций меняются алгоритмы расчета рецептуры и состав реквизитов.
Результат.
- Расчет заработной платы ведется в новом решении 1С:ЗУП редакции 3.1. Это отдельная база, без доработок конфигурации, сотрудники Заказчика самостоятельно обновляют конфигурацию. Проблем, что изменилась форма отчетности по зарплате, и нужно срочно обновить измененную конфигурацию, не возникает.
- Отгрузка готовой продукции: подбор партии, загрузка машины нужной продукцией осуществляется с использованием радиотерминалов, за счет этого существенно уменьшилось число ошибок при отгрузке продукции, увеличилась скорость затаривания.
- Количество выпущенной продукции, поступившей на склад для упаковки, фиксируется в системе автоматически, с помощью радиотерминалов, за счет этого уменьшилось число ошибок при отражении операций выпуска.
- Документы учетной системы, фиксирующие выпуск продукции на склад, формируются оперативно, менеджеры по продажам при оформлении заказов клиентов и документов отгрузки располагают корректными данными по складским остаткам в разрезе сроков годности.
- Автоматизирована работа с ИС:Меркурий, документы по отражению хозяйственных операций вводятся один раз, дальше вся синхронизация осуществляется автоматически.
- В базе порядок с данными: нет отрицательных остатков, документы проводятся по регистру партий с нормальной скоростью, и с ожидаемым результатом.
- Автоматизирован учет нового вида продукции – мороженого.