С чего начинали
На старте у предприятия было несколько проблем. Так данные вводились вручную, поэтому при переносе информации между системами и участками возникали ошибки. Отчётность приходилось консолидировать между берегом и судами, находящимися в море, — этот процесс занимал несколько дней.
Отдельной трудностью являлось и то, что у компании не было единого контроля за тем, где физически находится конкретная партия продукции и сколько у неё остаётся срока годности.
При этом предприятие не хотело менять привычный интерфейс работы с 1С — решение должно было встроиться в существующую в компании систему, а не превратиться в отдельное приложение, которому нужно заново обучать людей.
Отдельным требованием было прикрепление к операциям сканов сопроводительных документов — например, коносаментов и сертификатов.
И отдельно стояла задача регламентированной отчётности для Росрыболовства: в ней должны были автоматически собираться коды видов сырья, даты вылова, объёмы и сроки.
На чём построено решение
Для автоматизации мы использовали подсистему «ЦКП: Оперативный учёт рыбопродукции» — она встраивается в действующую учётную систему на базе 1С, а не разворачивается как отдельная программа. Справочники, документы и отчёты подсистемы вынесены в отдельный раздел меню, поэтому пользователи продолжают работать в привычном интерфейсе, а не переучиваются заново.
Выглядит это так:
В основе — набор справочников, каждый из которых закрывает свою часть учёта:
- Номенклатура — для позиций рыбопродукции заполняются дополнительные реквизиты: артикул (по нему идёт автоматическая загрузка данных), признак «Оперативный учёт рыбопродукции» (партионный учёт ведётся только для отмеченных позиций), вид сырья и вид готовой продукции;
- Виды сырья и Виды готовой продукции — их коды используются при формировании отчётности, в том числе для автоматического расчёта кода вида промысла;
- Подразделения и Склады — для элементов, которые соответствуют судам, заполняется код судна, по которому идёт сопоставление с данными из файлов судовых донесений;
- Разрешения на вылов — хранит владельца квоты, вид квоты, судно, период и доступные зоны вылова;
- Партии рыбопродукции — справочник для обособленного учёта партий (подробно про это в следующем разделе);
- Транспортные суда, Зоны вылова, Виды квоты — вспомогательные справочники, которые пополняются в процессе работы.
Все движения по рыбопродукции с контролем остатков в разрезе партий фиксирует регистр накопления «Движения рыбопродукции» — это техническая основа всего учёта: приход, расход и остаток по каждой номенклатуре, складу и партии.
Доступ к подсистеме разделён по ролям: у рядовых пользователей — доступ только на просмотр справочников, документов и отчётов без права их менять, у администраторов — отдельная роль с полным доступом к созданию и редактированию. Это снижает риск случайного изменения уже проведённых данных.
Как организован учёт партий
В качестве основы использовали модуль оперативного учёта рыбной продукции, интегрированный со стандартной конфигурацией 1С.
Основной принцип работы заключался в том, чтобы собирать сведения о продукции и партиях в единой базе и связывать их с этапами движения продукции:
вылов → переработка → склад → отгрузка или экспорт
Это позволило не хранить сведения об отдельных этапах изолированно, а использовать единую информацию о партии при дальнейших операциях.
Учёт партий — центральный механизм всей подсистемы. Справочник «Партии рыбопродукции» заполняется автоматически в процессе работы и решает две разные задачи, для которых нужны разные наборы данных.
Партия выпуска. Пока продукция находится на борту промыслового судна, партия выделяется по каждому разрешению на вылов — то есть фактически по владельцу квоты. В карточке такой партии заполнено только поле «Разрешение на вылов», остальные реквизиты — пустые. С этой аналитикой регистрируются: выпуск продукции в период промысла, корректировка выпуска по уточнённым данным и выгрузка с борта.
Партия отгрузки. В момент перегрузки продукции с промыслового судна — на транспорт, на береговой склад или сразу под реализацию с борта — формируется новая партия отгрузки. В неё, помимо разрешения на вылов, дополнительно попадают: промысловое судно, транспортное судно, дата выгрузки, рейс и номер коносамента или декларации. Именно эта партия дальше используется для анализа остатков, движения по складам и реализации.
Такое разделение решает конкретную практическую задачу: пока продукция в море, важно знать только её принадлежность к разрешению и владельцу квоты. Как только она попала на транспорт или на берег — нужна уже полная логистическая аналитика: какое судно привезло, каким рейсом, по какому коносаменту. Тащить эту детализацию с самого начала не нужно — она появляется ровно тогда, когда становится нужна.
Модель учёта при этом гибкая: часть данных в принципе допускает ведение как по партиям, так и без них — в зависимости от того, что требуется на конкретном участке. Для этого проекта решили вести партионный учёт полноценно на всех этапах: от вылова до реализации. Такое решение обусловленно тем, что именно партия даёт связку между уловом, конкретным разрешением и конечной отгрузкой, которая нужна для отчётности перед Росрыболовством.
Для партий также был предусмотрен контроль сроков годности. При приближении срока списания система формировала уведомление. Например, можно было настроить предупреждение за три дня до истечения срока.
К операциям с партиями также можно было прикреплять сканы документов.
Что потребовалось доработать
Одной настройки типового учёта для решения всех задач проекта было недостаточно. Под задачи предприятия потребовалось закрыть ещё четыре отдельные задачи.
Доработка 1. Загрузка данных из судовых донесений
Проблема. Данные о вылове и выпуске поступали с судов в виде файлов Excel — судовых суточных донесений. Переносить их в документы 1С вручную означало воспроизводить ту самую проблему, из-за которой всё затевалось, — ручной ввод и человеческий фактор.
Решение. Для загрузки используется обработка «Загрузка данных по вылову». Пользователь указывает организацию, выбирает один или несколько файлов, и по кнопке «Создать документы» система расшифровывает данные и создаёт для каждого файла пару документов: «Регистрация вылова» и «Отчёт производства за смену».
Форма «Загрузка данных по вылову»
Сопоставление идёт по заранее заданным кодам, а не по названиям — это защищает от ошибок из-за разного написания одного и того же объекта в разных источниках. Все коды нужно единожды согласовать со справочниками до начала загрузки, так как если это не сделать, то обработка не найдёт нужный элемент и пометит документ ошибкой.
Ограничения, которые важно учитывать. Номер рейса физически отсутствует в исходном файле, поэтому не подтягивается автоматически — его дописывают вручную в каждом созданном документе. Если сопоставление не удалось, документ помечается в списке восклицательным знаком, а причина фиксируется в журнале загрузки — журнал стоит проверять всегда, даже когда в списке нет видимых ошибок: например, если файл вообще не удалось прочитать, документ не создастся и в списке не появится, но запись в журнале останется. При повторной загрузке того же файла система не проверяет, что документы по нему уже создавались, и формирует новые — контроль дублей остаётся задачей пользователя.
В «Журнале загрузки» можно узнать были ли допущены какие-то ошибки при расшифровке или нет
Доработка 2. Учёт партии при перемещении продукции между судами и складом
Проблема. Один и тот же физический груз на пути от вылова до берега несколько раз меняет и место хранения, и партию, к которой относится, — а это два разных изменения, которые не всегда происходят одновременно.
Решение. Для этого используется документ «Перемещение товаров» с разными видами операции — набор зависит от того, что именно меняется:
- при перегрузке с промыслового судна на транспортное — вид операции «Передача на новую партию»: одновременно меняются и место хранения, и партия учёта (создаётся партия отгрузки);
- при дальнейшем перемещении с транспортного судна на береговой склад — «Передача между складами»: место хранения меняется, партия — нет;
- если продукция уходит с промыслового судна сразу на берег — снова «Передача на новую партию»;
- отдельно есть вид операции «Новая партия без перемещения» — она нужна, когда партию отгрузки нужно сформировать перед реализацией прямо с борта, без физического перемещения продукции. Важный нюанс: по этой операции не формируются бухгалтерские проводки — если попутно нужно изменить ещё и счёт учёта, используют «Передачу на новую партию».
Партия-получатель может подбираться автоматически — по кнопке «Подобрать партию» на основе уже заполненных реквизитов, а сам список продукции с партией списания заполняется единым механизмом «Подбор по партиям».
Результат. Учёт не теряет связь между уловом и партией на каждом физическом перемещении: в любой момент видно, из какой партии выпуска родилась конкретная партия отгрузки, и наоборот — по партии отгрузки можно поднять исходное разрешение и владельца квоты.
Доработка 3. Контроль сроков годности и прикрепление сканов
Чтобы при проверке можно было поднять не только цифры, но и первичный документ, не выходя за пределы 1С, мы добавили к операциям с партиями возможность прикреплять сканы сопроводительных документов, например, коносаментов и сертификатов.
Для контроля сроков годности реализовали уведомление о приближении даты списания. Так, например, можно настроить предупреждение за несколько дней до истечения срока, чтобы склад успевал принять решение по партии заранее, а не разбираться с проблемой когда она уже возникнет постфактум.
Доработка 4. Регламентированный отчёт для Росрыболовства
Проблема. Отчёт нужен не сам по себе, а с конкретными реквизитами: кодами видов сырья, датами вылова, объёмами, сроками — и отдельно с кодированными полями, которые требует форма отчётности для регулятора.
Решение. В нашем решении есть специальный «Оперативный отчёт» — в заданной кодированной форме он собирает информацию о вылове сырья, выпуске и реализации готовой продукции. Ключевая идея в том, что большинство кодированных полей не вводится вручную, а вычисляется на основании уже заполненных справочников: код владельца квоты берётся из карточки организации или контрагента, код зоны вылова — из справочника зон вылова, код вида сырья — из справочника видов сырья, а код вида промысла определяется автоматически по признаку «Квотируемое» у вида сырья. Код вида продукции подтягивается из номенклатуры, а код реализации зависит от условий договора с контрагентом.
Практический вывод из этого механизма простой: чтобы отчёт формировался корректно, всю эту разметку — код владельца квоты, признак «Квотируемое», коды зон и видов сырья — нужно один раз аккуратно завести в справочники до начала работы, а не донастраивать по ходу.
Для этого проекта реализовали частичное автоматическое заполнение отчётности по продукции. Таким образом, часть данных собирается автоматически из учёта, часть всё ещё проходит проверку и ручной контроль перед выгрузкой в Росрыболовство.
Как партия проходит путь от вылова до отчёта
Чтобы показать, как всё это работает вместе, — условный путь одной партии от вылова до отчётности.
- Судно передаёт судовое суточное донесение с данными о вылове и выпуске за сутки.
- Обработка «Загрузка данных по вылову» сопоставляет судно, разрешение, зону вылова, вид сырья и номенклатуру по кодам и создаёт документы «Регистрация вылова» и «Отчёт производства за смену».
- Ответственный на берегу открывает созданные документы, проверяет данные, вручную дозаполняет номер рейса и проводит документы.
- При проведении «Отчёта производства за смену» по кнопке «Подобрать партию» система находит или создаёт партию выпуска — с заполненным разрешением на вылов.
- Если при выгрузке выясняется, что фактическое количество продукции отличается от зафиксированного на борту, до операции перемещения проводится «Корректировка выпуска / вылова» — иначе при списании не пройдёт контроль остатков.
- При перегрузке с промыслового судна на транспортное оформляется «Перемещение товаров» с видом операции «Передача на новую партию»: партия выпуска закрывается списанием, а система формирует новую партию отгрузки — уже с транспортным судном, датой выгрузки, рейсом и номером коносамента.
- Дальнейшие перемещения между транспортным судном и береговым складом идут видом операции «Передача между складами» — партия отгрузки при этом не меняется.
- Под конкретную продажу продукция резервируется документом «Счёт покупателю» с указанием партий списания и склада отгрузки, а фактическая реализация списывается из этого резерва документом «Реализация».
- Все параметры партии — разрешение, владелец квоты, судно, дата выгрузки, коносамент — остаются доступны и после реализации: их можно поднять в отчётах по остаткам и движению и использовать при формировании отчётности для Росрыболовства.
Как проходило внедрение
Работу начали с диагностики текущего учёта: провели аудит процессов на предприятии, определили, где именно данные теряются или дублируются между участками.
После этого установили подсистему и интегрировали её в текущую конфигурацию 1С, стараясь сохранить привычный для пользователей интерфейс — справочники и документы подсистемы вынесены отдельным разделом, а не заменяют существующие рабочие места.
Далее шли доработки, описанные выше: загрузка данных из судовых донесений, логика партий при перемещении, контроль сроков годности, прикрепление сканов и регламентированный отчёт.
Тестирование проводили не только по отдельным документам, но и по полной цепочке — от загрузки судового донесения до готового отчёта, — чтобы убедиться, что данные не теряются и не расходятся на стыках между этапами.
Пользователей обучили работе с системой — очно и дистанционно, дополнительно подготовили методические материалы. После перехода в промышленную эксплуатацию систему сопровождали до стабилизации процессов.
Что важно учесть при похожем внедрении
Справочные коды нужно согласовать до начала автоматической загрузки. Сопоставление судов, разрешений, зон вылова, видов сырья и номенклатуры при загрузке идёт по кодам, а не по названиям. Пока коды не заведены в справочники именно так, как они встречаются в исходных файлах, автоматическая загрузка будет создавать документы с ошибками сопоставления.
Модель партий стоит продумать заранее. Партия выпуска и партия отгрузки решают разные задачи и содержат разный набор данных — лучше заранее решить, на каких этапах партионный учёт действительно нужен, а где детализация избыточна.
Автоматическая загрузка не отменяет контроль пользователя. Часть полей, например, номер рейса, физически отсутствует в исходных данных и не заполняется автоматически. Повторная загрузка тоже не проверяется системой — контроль за дублями остаётся на пользователе. Это стоит закладывать в регламент работы, а не считать процесс полностью автономным.
Отчётность собирается настолько хорошо, насколько хорошо заполнены справочники. Код владельца квоты, признак «Квотируемое», коды зон и видов сырья должны быть заполнены заранее — тогда большая часть отчёта формируется автоматически, а ручной проверки требует только часть данных.
Часть требований выходит за рамки типового решения. Контроль сроков годности и прикрепление сканов документов не входят в базовый механизм подсистемы и потребовали отдельной доработки — такие требования стоит обсуждать отдельно от партионного учёта, а не считать, что они «идут в комплекте».
Результат
После запуска время подготовки регламентированной отчётности сократилось с нескольких дней до нескольких минут — при условии, что исходные данные заполнены корректно.
Ручной перенос данных между участками практически исключён: сведения о вылове и выпуске попадают в систему из судовых донесений автоматически, а не переносятся вручную с бумаги или из отдельных файлов. Количество корректировок отчётности со стороны регулятора стало статистически незначимым, а доля отчётов, уходящих без ручных правок сократилась в первые месяцы использования решения на треть.
Появился единый контроль движения партий — от вылова до реализации — и контроль сроков годности с уведомлением, который снижает риск списания продукции из-за пропущенного срока. Это и есть главный результат проекта — не отдельная печатная форма отчёта, а связанный учёт продукции, в котором партия проходит через все этапы движения
При этом автоматизация отчётности начинается не с самой формы отчёта. Сначала необходимо обеспечить корректное и единообразное ведение исходных данных на всех участках учёта. Только после этого формирование отчётности можно перевести из ручной консолидации в автоматический процесс.