03_Производственный учет ремонта вагонов

Документы по производственному учету ремонта вагонов

Эта папка предназначена для ознакомления с текущими материалами по модели производственного учета ремонта вагонов в `1С:ERP`.

Рекомендуемый порядок чтения

1. `model-remont-vagonov-draft.md`

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

1. `technical-notes-remont-vagonov.md`

Технические заметки консультанта/разработчика: рассмотренные варианты, ограничения, причины отказа от части решений на первом этапе, возможные направления развития.

1. Спецификация обработки АПС_ЗапускРемонтаВагонов

Материал вынесен в раздел технических решений и доработок, так как описывает конкретную обработку.

Важные замечания

• Материалы являются рабочими и могут уточняться по итогам выверки апреля 2026 года.

• Ключевая проблема, которую нужно учитывать при развитии модели: пересортица по моделям и вагонам при закрытии месяца.

• Сейчас фактическая рабочая цепочка ремонта отражается через "Производство без заказа" и акты выполненных работ; сверка этой связки неудобна, потому что строки приходится сопоставлять по номеру вагона в текстовых/дополнительных реквизитах, номенклатуре, характеристике и подразделению.

• Возможное направление развития: построение учетной цепочки от заказа клиента к объекту ремонта, операциям, материалам, трудозатратам, затратам и закрытию работ.

• В документы не следует добавлять пароли, токены, закрытые URL, персональные данные и другие секретные сведения.

Обсуждение модели учета ремонта вагонов в 1С:ERP

Цель обсуждения

Предприятие выполняет ремонт вагонов сторонних организаций. Каждый вагон имеет уникальный номер, у вагона есть тип/модель, от типа зависят нормативы работ и материалов.

Основная цель учета в ERP - получать себестоимость ремонта по заказам и корректно оформлять реализацию работ и материалов.

Ключевая проблема

Вагон не является обычной номенклатурой, которую предприятие производит или продает. Это объект клиента, над которым выполняются работы. При этом номер вагона важен для документов, актов и анализа себестоимости.

Если вести номер вагона просто текстом, теряется контроль.

Если вести номер вагона как характеристику работы, быстро разрастается список характеристик и смешиваются разные смыслы: характеристика номенклатуры начинает играть роль объекта ремонта.

Если сразу вводить полноценный справочник вагонов и сложный ремонтный контур, модель может стать избыточной для первого этапа.

Предлагаемая модель на первом этапе

На первом этапе предлагаем принять упрощенную, но управляемую модель:

Один заказ клиента = один вагон / один ремонтный случай

Номер вагона указывается в заказе клиента

Производство выполняется по заказу клиента

Реализация оформляется по заказу клиента

Сейчас применяется вариант "производство без заказа". Это можно использовать как временное упрощение, но в целевой схеме заказ клиента нужен как связующий документ: он связывает клиента, договор, номер вагона, состав работ и материалов, дальнейшее производство и реализацию.

Дополнительно зафиксировано текущее рабочее состояние: производство сейчас закрывается связкой "Производство без заказа" + "Акт выполненных работ". Эта связка неудобна для контроля: документы могут вводиться в произвольной очередности, а номер вагона находится не в структурной связи документов, а в разных местах - в комментарии/дополнительном реквизите производственного документа и в текстовом содержании строки акта. Поэтому перед закрытием месяца строки приходится сопоставлять вручную или отдельными диагностическими отчетами по номеру вагона, номенклатуре, характеристике и подразделению. Ошибки в 1-2 цифрах номера вагона, пересортица характеристик и строки с номенклатурой типа "Услуга" делают сверку хрупкой. Это дополнительный аргумент в пользу перехода к цепочке через заказ клиента.

Пример:

Заказ клиента: ремонт вагона 5340381

Строки заказа:

• Работы по нанесению антикоррозийного защитного покрытия на вагон-хоппер модели 19-3054-01 N 5340381

Более составной пример:

Заказ клиента: ремонт вагона 59860403

Строки заказа:

• Восстановление кузова вагона без покраски, модель 19-3116-03
• Замена крышки вагона, модель 19-3116-03
• Крышка загрузочного люка 3116.020.04.000СБ

Для таких составных случаев можно использовать комплекты или типовые наборы строк как способ быстрого заполнения заказа. При этом в учете работы и материалы желательно оставлять отдельными строками, чтобы корректно отражать их себестоимость и реализацию.

Крышка люка должна учитываться как товар/материал, а не как услуга. Работы должны оставаться работами/услугами.

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

Номер вагона

На первом этапе номер вагона предлагаем вести через дополнительный реквизит заказа клиента.

Формулировка:

На первом этапе номера вагонов ведутся через дополнительный реквизит заказа клиента. В дальнейшем, если потребуется строгий контроль связи номера вагона с типом/моделью, историчность ремонтов и расширенная аналитика, возможно создание отдельного справочника вагонов.

Дополнительно рабочая обработка может показывать номер вагона рядом с заказом клиента. Тогда при контроле реализации, производства и этапов будет видно не только номер заказа, но и номер вагона.

Пример:

Заказ клиента 0000-000001 от 25.05.2026 / вагон 59860403

Связь номера вагона с типом

На первом этапе система не будет жестко контролировать, что вагон с номером 59860403 относится именно к типу 19-3116-03. Тип фактически будет определяться выбранной номенклатурой работы.

Это допущение нужно осознанно принять.

Проблема: стандартный дополнительный реквизит "Номер вагона" не позволяет удобно ограничить список вагонов в зависимости от выбранной номенклатуры работы.

Если такой контроль станет необходимым, потребуется следующий этап:

Справочник Вагонов:

• номер вагона
• тип/модель вагона
• владелец/контрагент
• статус
• комментарий

Справочник Типов вагонов:

• модель
• группа нормативов
• применяемые работы/спецификации

Тогда система сможет проверять: если в заказе выбран вагон типа 19-3116-03, нельзя случайно поставить работу для типа 19-3054-01.

Номенклатура работ и характеристики

Поскольку от модели вагона зависят нормативы, на первом этапе модель вагона оставляем в характеристике номенклатуры. Это соответствует текущему способу работы и не требует перестройки НСИ.

Примеры:

Номенклатура: Восстановление кузова вагона без покраски

Характеристика: модель 19-3116-03

Номенклатура: Работы по нанесению антикоррозийного защитного покрытия

Характеристика: модель 19-3054-01

Номенклатура: Замена крышки вагона

Характеристика: модель 19-3116-03

Это допустимый вариант, если характеристики уже используются для моделей и по ним можно подобрать нужные нормы, спецификации или правила заполнения. Важно не смешивать модель вагона и номер вагона: модель остается характеристикой номенклатуры, а номер конкретного вагона хранится отдельно в заказе клиента.

Рабочая обработка запуска цепочки

Вместо расширения для жесткой связи номера вагона с документами на первом этапе можно использовать отдельную обработку. Она не заменяет типовые документы ERP, а служит рабочим экраном для запуска и контроля ремонтных цепочек.

Форма обработки содержит табличную часть:

Номер вагона

Работа

Характеристика / модель вагона

Заказ клиента

Заказ на производство

Этап производства

Реализация

Сценарий работы:

1. Пользователь нажимает команду "Запустить цепочку".

1. Вводит номер вагона строкой.

1. Выбирает работу из справочника номенклатуры и характеристику с моделью вагона.

1. Отмечает признаки создания документов: заказ клиента, заказ на производство, этап производства.

1. Нажимает OK.

1. Обработка создает выбранные документы, связывает их между собой и заполняет строку табличной части ссылками.

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

Главная учетная связь при этом остается в типовых документах:

Заказ клиента -> Заказ на производство -> Этап производства -> Реализация

Табличная часть обработки является контрольным и пользовательским рабочим списком, а не отдельным параллельным регистром учета.

Производство

Пока не предлагаем использовать сложный ремонтный контур ERP, ОВЗ или тип производственного процесса "Ремонт".

Текущее состояние: используются производство без заказа и акты выполненных работ. Это снижает сложность запуска, но хуже связывает производственные затраты с конкретным заказом клиента и номером вагона.

Рекомендуемый стартовый вариант:

Заказ клиента

-> Заказ на производство по заказу клиента

-> один этап производства

-> списание материалов

-> трудозатраты / ресурсная спецификация

-> выпуск работы

-> Реализация товаров и услуг по заказу клиента

Производство по заказу на первом этапе нужно максимально упростить:

• один заказ на производство на один заказ клиента;

• один этап;

• без полуфабрикатов;

• без сложного маршрутного планирования;

• без цеховой кладовой, если можно обойтись списанием с основного склада;

• основная цель - собрать себестоимость ремонта по заказу клиента.

Уточнение по рабочей базе: если этап производства требует расход из цеховой кладовой, не нужно пытаться заменить это динамическим формированием заказов. Динамическое формирование заказов полезно для планирования обеспечения и создания заказов поставщикам/перемещений по потребностям, но не упрощает фактическое списание материалов в этапе.

Для первого запуска принимаем фактовый сценарий:

Обеспечение этапа = фактически нужные материалы

-> действие "Отгрузить"

-> передача материалов в производство из основного склада в кладовую цеха

-> расход этапа заполняется отгруженными

То есть нормативы и динамическое формирование заказов не должны автоматически превращаться в расход. В расход попадает только факт, подтвержденный отгрузкой/передачей материалов в производство.

Почему пока не используем тип "Ремонт"

В ERP есть ремонтные сценарии: заказ на ремонт, ремонтируемое изделие, давальческая схема. Они полезны, если нужно учитывать само изделие клиента как принятое в ремонт, вести дефекты, историю ремонтов, разборку, возврат изделия и т.д.

Для текущей задачи это может быть избыточно. Сейчас важнее запустить понятную цепочку:

Заказ клиента -> Производство по заказу -> Реализация

Ремонтный контур можно рассмотреть позже, если появятся требования по полноценному учету принятых в ремонт вагонов как объектов клиента.

Расширение и 1C:Fresh

Так как база работает в 1C:Fresh, доработки должны быть минимальными и безопасными.

На первом этапе желательно использовать стандартный функционал ERP и БСП:

• дополнительные реквизиты;

• настройки форм;

• типовую цепочку заказов и производства;

• минимальное расширение только там, где стандартного функционала недостаточно.

Создание отдельного справочника вагонов в расширении в принципе возможно, но это лучше оставить на следующий этап. Новый справочник должен быть маленьким, автономным, с префиксом, без небезопасных операций и без тяжелого заимствования типовых форм. Окончательно пригодность расширения для Fresh подтверждается аудитом 1С.

Отраслевые решения

Существуют отраслевые и специализированные решения вокруг учета вагонов, ЭТРАН, дислокации, истории ремонтов и вагонного парка. Также есть крупные внедрения 1С:ERP на вагоноремонтных предприятиях.

Примеры направлений:

• отраслевые решения для учета вагонного парка, дислокации, ЭТРАН и ремонтов;

• индивидуальные внедрения 1С:ERP на вагоноремонтных заводах;

• 1С:ТОИР для ремонта и обслуживания собственных объектов эксплуатации.

Ссылки для ориентира:

• [1С: ремонтное производство в ERP](https://v8.1c.ru/metod/article/remontnoe-proizvodstvo.htm)

• [Пример проекта 1С:ERP на вагоноремонтном заводе](https://solutions.1c.ru/projects/1125020/)

• [Информационная система "Магистраль"](https://www.botcreation.ru/magistral)

• [А.И.С.Т. учет вагонов и контейнеров](https://aist.systems/)

• [1С:ТОИР](https://industry.1c-toir.com/)

Вывод по отраслевым решениям: их стоит рассматривать, если задача расширится до учета парка вагонов, ЭТРАН, дислокации, паспортов вагонов, дефектации и полной истории ремонтов. Для первого этапа по расчету себестоимости ремонтов в ERP отраслевое решение, скорее всего, избыточно.

Вопросы к заказчику

Для дальнейшей настройки нужно, чтобы заказчик подтвердил несколько принципиальных решений:

1. Принимаем ли правило: один заказ клиента = один вагон / один ремонтный случай?

1. Нужно ли в одном акте закрывать несколько вагонов? Если да, готовы ли мы делать одну реализацию по нескольким заказам клиента?

1. Достаточно ли на первом этапе вести номер вагона через дополнительный реквизит без жесткого контроля типа?

1. Готовы ли оставить модель вагона в характеристике номенклатуры?

1. Какие работы и материалы должны входить в типовые комплекты по каждому типу вагона?

1. Нужно ли уже сейчас учитывать историю ремонтов по каждому номеру вагона?

1. Требуется ли интеграция с ЭТРАН или учет дислокации вагонов?

1. Нужен ли заказчику учет дефектов, актов осмотра, паспортов вагонов?

1. Какой уровень детализации себестоимости нужен: по заказу, по работе, по материалам, по трудозатратам, по подразделению?

1. Насколько критичен контроль ошибок при выборе номера вагона и типа работ?

Рекомендуемое решение для запуска

На первый этап предлагаем:

1. Номер вагона - дополнительный реквизит заказа клиента.
2. Один заказ клиента - один вагон.
3. Модель вагона отражается в характеристике номенклатуры.
4. Работы и материалы ведутся отдельными строками.
5. Запуск цепочки выполняется обработкой: заказ клиента, заказ на производство, этап производства.
6. Производство - по заказу клиента, один этап.
7. Реализация создается отдельной командой обработки по одной или нескольким строкам.
8. Справочник вагонов - возможный второй этап.

Это не идеальная конечная модель, но хороший старт: она не перегружает ERP, позволяет начать считать себестоимость и оставляет понятный путь развития.

Спецификация обработки АПС_ЗапускРемонтаВагонов

Спецификация вынесена в раздел технических решений, потому что описывает конкретную обработку и логику доработки, а не общую методику производственного учета ремонта вагонов.

Технические заметки по модели учета ремонта вагонов

Документ предназначен для внутренней работы консультанта/разработчика. В нем зафиксированы рассмотренные варианты, причины отказа от части решений на первом этапе и возможные направления развития модели.

Рабочая цель

Нужно организовать учет ремонта вагонов сторонних организаций в 1С:ERP.

Основные требования:

• расчет себестоимости по заказам;

• один вагон имеет уникальный номер;

• номер вагона должен фигурировать в заказе и актах;

• от типа/модели вагона зависят нормативы работ и материалов;

• крышка люка и другие материальные позиции должны учитываться как товары/материалы, а не как услуги;

• база работает в 1C:Fresh, поэтому доработки должны быть минимальными, безопасными и проходить аудит.

Текущее рабочее решение

На первом этапе принимается упрощенная модель:

Один заказ клиента = один вагон / один ремонтный случай

Номер вагона = дополнительный реквизит заказа клиента

Производство = пока возможно производство без заказа, далее желательно производство по заказу клиента

Реализация = по заказу клиента

Заказ клиента нужен как центральная связка между клиентом, договором, номером вагона, составом работ/материалов, производством и реализацией.

Фактическое текущее состояние отличается от целевой схемы: сейчас ремонт отражается документами "Производство без заказа" и актами выполненных работ. Эта схема позволила начать учет без полной перестройки процесса, но она не дает удобной структурной связи между производством, актом и конкретным вагоном.

Для сверки приходится строить внешние диагностические отчеты и сопоставлять строки по косвенным признакам: строка акта = номенклатура + характеристика + подразделение + номер вагона из содержания; строка ПБЗ = номенклатура + характеристика + получатель + номер вагона из комментария/дополнительного реквизита. Такая сверка неудобна и чувствительна к опечаткам в номере вагона, пересортице характеристик и строкам с номенклатурой типа "Услуга".

Для запуска и контроля цепочки на первом этапе предлагается внешняя обработка или обработка в расширении:

АПС_ЗапускРемонтаВагонов

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

Почему отказались от номера вагона как характеристики работы

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

Причины отказа:

• номер вагона не является характеристикой самой работы;

• количество характеристик быстро растет;

• один и тот же вагон может участвовать в разных видах ремонта;

• характеристика смешивает технологическую аналитику и объект ремонта;

• становится трудно контролировать связь номера вагона, типа вагона, заказа и акта.

Вывод: этот путь нужно сворачивать.

Почему номер вагона пока остается дополнительным реквизитом заказа

Вариант с дополнительным реквизитом заказа клиента выбран как минимальный и наиболее безопасный для первого этапа.

Плюсы:

• не требует отдельного справочника вагонов;

• хорошо подходит для 1C:Fresh;

• номер вагона находится в документе, где он нужен коммерчески и юридически;

• номер вагона можно использовать в обработке запуска цепочки и в печатных формах.

Минусы:

• стандартный дополнительный реквизит не обеспечивает строгую связь номера вагона с типом/моделью;

• список номеров не фильтруется по выбранной номенклатуре работы;

• нет полноценной карточки вагона и истории ремонтов;

• контроль ошибок пока организационный.

Вывод: на первом этапе приемлемо, но это не финальная модель при росте требований.

Обработка запуска ремонтной цепочки

На первом этапе вместо жесткой объектной модели вагонов используется рабочая обработка, которая создает и показывает цепочку стандартных документов.

Табличная часть формы:

Номер вагона

Работа

Характеристика номенклатуры / модель вагона

Заказ клиента

Заказ на производство

Этап производства

Реализация

Команда "Запустить цепочку":

Ввод:

• номер вагона строкой;
• работа из справочника Номенклатура;
• характеристика номенклатуры с моделью вагона;
• признак "Создать заказ клиента";
• признак "Создать заказ на производство";
• признак "Создать этап производства".

Результат:

• создается заказ клиента;
• в заказ клиента записывается номер вагона;
• создается заказ на производство по заказу клиента;
• создается этап производства;
• строка табличной части заполняется ссылками на созданные документы.

Команда создания реализации выполняется отдельно. Пользователь может выделить одну или несколько строк, после чего обработка создает документ "Реализация товаров и услуг" по связанным заказам клиента.

Такой сценарий полезен, если закрывающие документы нужно формировать пакетно: например, один документ реализации по нескольким вагонам или ремонтным строкам. При этом нужно проверить типовые ограничения ERP: возможность одной реализации по нескольким заказам клиента, совпадение партнера, договора, организации, склада, валюты, соглашения и условий НДС.

Обработка не должна становиться единственным местом хранения связи. Основные связи должны оставаться в типовых документах ERP, а табличная часть обработки является рабочим списком и экраном контроля.

Возможный справочник вагонов

В дальнейшем возможен переход к отдельному справочнику вагонов в расширении.

Минимальная структура:

Справочник АПС_ТипыВагонов

Наименование: 19-3116-03

Описание

Группа нормативов / комментарий

Справочник АПС_Вагоны

Номер вагона

Тип вагона

Владелец / партнер

Статус

Комментарий

Преимущества:

• можно жестко связать номер вагона с типом/моделью;

• можно проверять, что выбранные работы соответствуют типу вагона;

• появляется база для истории ремонтов;

• можно развивать учет в сторону дефектации, паспортов, ЭТРАН, отраслевого учета.

Риски:

• расширение становится крупнее;

• появляются новые формы, права, пользовательские инструкции;

• нужно аккуратно пройти аудит Fresh;

• потребуется миграция существующих доп. реквизитов в справочник.

Вывод: справочник вагонов логичен как второй этап, если заказчик подтвердит потребность в строгом контроле и истории ремонтов.

Почему пока не используем ОВЗ

Объекты возникновения затрат рассматривались как вариант аналитики "ремонт конкретного вагона".

Причины не использовать на первом этапе:

• появляется дополнительная сущность, которую нужно создавать и контролировать;

• ОВЗ больше подходит для накопления и распределения постатейных расходов, а не как основной объект заказа;

• есть риск усложнить закрытие месяца и анализ себестоимости;

• естественным центром модели сейчас является заказ клиента.

Возможное применение в будущем:

• для расходов, которые невозможно прямо отнести на заказ, этап производства или номенклатуру;

• для транзитного накопления и последующего распределения затрат;

• если появится необходимость отдельной аналитики ремонтного случая в регламентированном механизме затрат.

Вывод: ОВЗ оставить как резервный инструмент, но не включать в модель первого этапа.

Почему пока не используем тип производства "Ремонт"

В ERP есть ремонтные сценарии:

• заказ на ремонт;

• ремонтируемое изделие;

• давальческая схема;

• производство с типом процесса "Ремонт".

Они полезны, когда нужно учитывать само изделие клиента как принятое в ремонт, вести дефекты, историю ремонтов, разборку, возврат изделия и т.д.

Причины не использовать на первом этапе:

• вагон заказчика пока не нужно отражать как складскую номенклатуру или принятое изделие;

• ремонтный контур может потребовать лишнюю НСИ: объекты эксплуатации, виды ремонтов, ремонтные мероприятия, дефекты;

• задача первого этапа проще: себестоимость работ по заказу клиента и корректная реализация работ/материалов.

Вывод: пока использовать обычную цепочку производства по заказу клиента. Ремонтный сценарий рассмотреть позже, если появится требование учитывать принятый в ремонт объект клиента.

Производство без заказа и производство по заказу

Сейчас используется производство без заказа вместе с актами выполненных работ.

Плюсы текущего варианта:

• проще запуск;

• меньше требований к обеспечению и планированию;

• проще для пользователей на старте.

Минусы:

• слабее связь производственных затрат с заказом клиента и номером вагона;

• сложнее анализировать себестоимость конкретного ремонта;

• больше риск ручных ошибок при сопоставлении производства и реализации.

неудобная сверка перед закрытием месяца: ПБЗ и акты приходится сопоставлять по номеру вагона в текстовых полях, номенклатуре, характеристике и подразделению;

при ошибке в номере вагона или характеристике регистр "Материалы и работы в производстве" может давать отрицательные/положительные остатки по разным аналитикам.

Целевая упрощенная схема:

Заказ клиента

-> Заказ на производство по заказу клиента

-> один этап производства

-> материалы

-> трудозатраты

-> выпуск работы

-> Реализация товаров и услуг по заказу клиента

Рекомендации для первого внедрения производства по заказу:

• один заказ на производство на один заказ клиента;

• один этап;

• без полуфабрикатов;

• без сложных маршрутов;

• без цеховой кладовой, если можно списывать с основного склада;

• не включать лишние механизмы обеспечения до подтверждения необходимости.

По результатам проверки рабочего сценария: если этап производства в ERP требует склад с признаком "Цеховая кладовая" для подразделения исполнителя, фактическое списание материалов нужно вести через передачу материалов в производство. Упрощение в этом случае не означает прямое списание с основного склада, а означает минимальную типовую цепочку без лишнего планирования:

факт в обеспечении этапа

-> Отгрузить

-> Передача материалов в производство

-> Расход заполнить отгруженными

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

Номенклатура работ и модели вагонов

Так как от модели вагона зависят нормативы, на первом этапе модель вагона отражается через характеристику номенклатуры. Это соответствует текущей базе и позволяет не размножать номенклатуру работ только из-за модели.

Примеры:

Номенклатура: Работы по нанесению антикоррозийного защитного покрытия

Характеристика: модель 19-3054-01

Номенклатура: Восстановление кузова вагона без покраски

Характеристика: модель 19-3116-03

Номенклатура: Замена крышки вагона

Характеристика: модель 19-3116-03

Причина: модель уже используется как характеристика, и это приемлемо, если по характеристике можно определить нужные нормативы, ресурсные спецификации или правила заполнения.

Недостаток: система пока не проверяет, что выбранный номер вагона относится к модели, указанной в характеристике номенклатуры.

Возможное развитие: при появлении справочника вагонов проверять соответствие типа вагона выбранным работам.

Комплекты и типовые наборы строк

Для составных ремонтов можно использовать комплекты или типовые наборы строк как способ быстрого заполнения заказа.

Важно: комплект не должен скрывать учетную суть. В реализации и производстве желательно видеть отдельные строки:

• работы;

• материалы;

• товары для продажи клиенту.

Это нужно для корректной себестоимости, складского учета и реализации.

Отказ от акта как обходного пути

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

После ввода заказа клиента как центральной связки эта необходимость отпадает:

Заказ клиента хранит номер вагона

Реализация оформляется по заказу клиента

Обработка показывает номер вагона рядом со связанными документами

Это позволяет использовать документ "Реализация товаров и услуг" по назначению:

• работы отражаются как работы/услуги;

• крышка люка и другие материальные позиции отражаются как товары или материалы;

• не нужно превращать товар в услугу только из-за формы акта;

• связь с номером вагона обеспечивается через заказ клиента.

Вывод: заказ клиента снимает прежнее ограничение, из-за которого приходилось использовать акт и помещать номер вагона в текстовое содержание строки.

Отраслевые решения

Существуют специализированные решения и крупные внедрения вокруг вагонов:

• учет парка вагонов;

• ЭТРАН;

• дислокация;

• паспорта вагонов;

• история ремонтов;

• дефектация;

• учет деталей и узлов;

• индивидуальные внедрения ERP на вагоноремонтных предприятиях.

Примеры направлений:

• 1С:ERP на вагоноремонтных заводах;

• отраслевые решения для учета вагонного парка;

• системы интеграции с ЭТРАН;

• 1С:ТОИР для ремонта собственных объектов эксплуатации.

Практический вывод:

• для первого этапа отраслевое решение, скорее всего, избыточно;

• если появятся требования по ЭТРАН, дислокации, паспортам, дефектации и истории ремонтов, нужно отдельно оценивать отраслевое решение или расширение модели ERP.

Риски первого этапа

Основные осознанные ограничения:

• нет жесткой связи номера вагона и типа вагона;

• нет полноценной карточки вагона;

• нет истории ремонтов по вагону как отдельного объекта;

• производство без заказа хуже связывает затраты с заказом клиента;

• часть контроля остается организационной.

Эти ограничения допустимы, если цель первого этапа - запустить управляемую цепочку продаж, производства и себестоимости без тяжелой кастомизации.

Возможная дорожная карта

Первый этап:

Доп. реквизит "Номер вагона" в заказе клиента

Обработка запуска и контроля ремонтной цепочки

Модель вагона в характеристике номенклатуры

Реализация работ и материалов по заказу клиента

Постепенный переход от производства без заказа к производству по заказу клиента

Второй этап:

Справочник типов вагонов

Справочник вагонов

Контроль соответствия вагона и работ

История ремонтов по вагону

Миграция номеров из доп. реквизитов

Третий этап, если потребуется:

Дефектация

Паспорта вагонов

Интеграция с ЭТРАН

Дислокация

Отраслевое решение или расширенная подсистема учета вагонов