1с erp характеристики не используются

Обновлено: 07.07.2024

Вопрос 10.12 – Трансляция свойства характеристики продукции в свойство характеристики материала

Вопрос 10.12 о том, что необходимо сделать, чтобы свойство характеристики продукции в ресурсной спецификации определяло свойство характеристики материала этой спецификации.

Выбрать предлагается из следующих вариантов:

Для характеристики продукции необходимо определить состав реквизитов. Для материала – определить состав его реквизитов, создав характеристику По шаблону
Для характеристики номенклатуры создать общий реквизит
Для характеристики продукции и материала создать реквизиты с одинаковым типом
Для характеристики продукции и материала создать реквизиты с одинаковым типом и наименованием.

В системе ERP 2.0. существует механизм автовыбора материала. Когда он нужен? Когда материал или характеристику материала нельзя однозначно указать при описании структуры изделия (классический пример – цвет материала определяется цветом изделия. Не создавать же для каждой характеристики отдельную спецификацию…)

Настраивается автовыбор материала в Ресурсной спецификации (раздел Производство и ремонты – Ресурсные спецификации) на закладке Материалы и работы:

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

В текущем вопросе нас интересует автоматическое определение свойства характеристики, а именно – определение свойства характеристики материала по свойствам продукции:

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

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

ВАЖНО! В системе должны быть включены функциональные опции Дополнительные реквизиты и сведения, Реквизиты и сведения с общим списком значений, Общие реквизиты и сведения (раздел Администрирование – Общие настройки).

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

Это возможно только в двух вариантах:

Если для характеристик используется общее свойство
Если свойство характеристики материала заполнено По образцу свойства характеристики готовой продукции.

Также могут быть сопоставлены свойства, имеющие тип Число, Строка, но это справедливо не для всех типов свойств (например, для различных свойств одного типа Дополнительное значение нельзя установить соответствие).

Обратимся к формулировке вариантов ответа:

1. Для характеристики продукции необходимо определить состав реквизитов. Для материала – определить состав его реквизитов, создав характеристику По шаблону.

В системе нет возможности создать характеристику По шаблону. Есть возможность добавить дополнительный реквизит, создав его По образцу, но не По шаблону (!). Данный вариант ответа неверный.

2. Для характеристики номенклатуры создать общий реквизит.

Как мы уже рассмотрели выше, данный вариант ответа подходит.

3. Для характеристики продукции и материала создать реквизиты с одинаковым типом.
4. Для характеристики продукции и материала создать реквизиты с одинаковым типом и наименованием.

Утверждения 3 и 4 не подходят, т.к. они справедливы не для всех типов реквизитов. Например, они неверны, если для реквизитов выбран тип Дополнительное значение. Наименование реквизитов при этом роли не играет.

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

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

Особенности разработки

«Объекты УП, УТ, КА» — объекты, входящие во все прикладные решения: Управление Торговлей, Комплексная Автоматизация, Управление Предприятием (русскоязычное название ERP).
«Объекты УП, КА» — объекты, относящиеся только к конфигурациям Комплексная Автоматизация и ERP.
«Объекты УП» — объекты, относящиеся только к решению ERP

Цифры после запятой

Версия продукта ERP состоит из четырех чисел, разделенных точками. Например — 2.1.3.117.

Первое число (редакция) в версии меняется крайне редко (например КА 1.х.х.х и КА 2.х.х.х разделяет почти 8 лет).
Второе число (подредакция) меняется примерно раз в год. В версии с новой подредакцией выпускается новая функциональность. Выпуск таких версий часто приурочивается к началу календарного года, чтобы у пользователей было достаточно времени на «переезд» на новую версию.
В версиях с новым третьим числом (релиз) развивается существующая функциональность; новый релиз выходит примерно раз в два-три месяца.
Версии с обновленным четвертым числом (исправительные сборки) содержат в себе только исправления ошибок и обновления для соответствия текущему законодательству. Выходят каждые две недели.

2.1.3.X – Поддерживаемый релиз предыдущей подредакции. Будет выпускаться до конца 2016 года. В этой версии идет только исправление ошибок и правки для соответствия текущему законодательству.
2.2.1.X – Текущий релиз текущей подредакции. В нем новая функциональность подредакции. Для него до выпуска релиза 2.2.2.X, будут выпускаться исправительные сборки.
2.2.2.X – Развитие функциональности текущей подредакции. Именно этот релиз активно разрабатывается.

Учитывая, что из каждой ветки ERP получаются, помимо ERP, еще 3 решения – КА, УТ и УТ Базовая – получаем 12 версий продуктов, находящихся в 12-ти разных хранилищах.
В ходе разработки мы имеем до 4 горизонтов планирования, например:

2.1.3 (поддерживается), решаем, какие ошибки правятся, какие проекты, связанные с изменением законодательства, будем реализовывать. Будут реализованы только те изменения, которые вступят в силу в 2016 году. Горизонт – до конца 2016 г.
2.2.1 (поддерживается) – исправляются «внешние» ошибки + изменения законодательства, вступающие в силу до выхода 2.2.2. Горизонт – до выхода 2.2.2.
2.2.2 (активно разрабатывается) — исправляются «внешние» ошибки + найденные нами ошибки + реализуется новая функциональность. Горизонт – до выхода 2.2.3
2.2.3 (планируется). Если проект большой, то он может сразу разрабатываться на эту версию (и не войдёт в предыдущую). Горизонт – до выхода 2.2.4 или до конца 2017 года.

Использование продукта «1С:Система проектирования прикладных решений» в разработке ERP

Запрос от партнера или клиента. Такие запросы мы собираем, в частности, на партнерских семинарах; путем голосования среди партнеров мы выделяем наиболее приоритетные из них.
Запрос может возникнуть в ходе пилотного проекта по внедрению новой версии в том случае, если у клиента возникло важное для него пожелание.
Запрос от нашей службы техподдержки (точнее, запрос от партнера или клиента, прошедший через нашу техподдержку), запрос с нашего партнерского форума или от нашего аккаунт-менеджера (который сопровождает важного для нас клиента/клиентов).
Запрос от команды разработки платформы 1С:Предприятие. Платформенная команда просит команду разработки ERP (и других типовых конфигураций) использовать новую платформенную функциональность – например, интерфейс Такси, отказ от модальных окон, отказ синхронных вызовов и т.д.
Рефакторинг, оптимизация архитектуры, улучшение юзабилити.

Поводом для рефакторинга (п.5) могут быть серьезные архитектурные изменения (например, пересмотр распоряжений на отгрузку, когда вместо накладных стали использоваться заказы).

Продукт СППР поставляется в составе ERP (но его можно купить и отдельно). Решение ERP может быть запущено в режиме интеграции с СППР; в этом случае на каждой форме будет кнопка «Открыть функциональную модель», при ее нажатии откроется описание функциональности формы в СППР.

Вот, что открывается – это модель рабочего места в IDEF0:

Можно и наоборот – изучать функциональную модель и из нее открывать формы рабочих мест. Такой режим можно использовать при изучении работы программы.
Важный момент – открывается не СППР, открывается форма внутри ERP, куда подгружаются данные из СППР. Т.е. интеграция «бесшовная» (пользователь ее не видит). Этот прием применяется при интеграции и с другими продуктами. Например, с 1С:Документооборот (можно работать не выходя из ERP с почтой, задачами, бизнес-процессами, которые работают в другой базе).

Как мы разрабатываем ERP: 6 контрольных точек проекта

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

Точка 1. Открытие проекта

Тим-лид заводит технические проекты в СППР списком на релиз. В каждом проекте расписываются цели, указываются реализуемые требования. Список перед началом работы над релизом обсуждается с руководителем разработки. Собственно при открытии проекта совещаний не проводят – просто проект в СППР посылают на открытие.
Команда проекта приступает к разработке концепции.

Точка 2. Согласование концепции

Для согласования концепции проводится онлайн или офлайн встреча, в которой участвуют ответственный за проект, тим-лид, руководитель разработки, вовлеченные в проект специалисты. Обычно к этому этапу у ответственного за проект готов «крупноблочный» концепт, который дошлифовывается в ходе встречи. Также обсуждаются (и прописываются в СППР) сценарии, описание пользовательского интерфейса. Если требование родилось из запроса партнеров или клиентов, то материалы проекта (концепции, сценарии, UI) могут быть отправлены партнеру/клиенту для оценки решения.
В процессе встречи согласуется трудоемкость создания прототипа (обычно создание прототипа занимает до 5 рабочих дней). Команда приступает к созданию прототипа.

Точка 3. Согласование прототипов

Согласование правильности описания проекта в СППР (в частности, отслеживается, что все задачи на предыдущих контрольных точках проекта выполнены).
Какие новые объекты метаданных (справочники, документы и т.д.) будут добавляться в решение
Какие изменения будут делаться в уже существующих объектах метаданных
Согласование планов обменов данными с другими решениями(будут ли новые/измененные данные участвовать в обмене данными с другими приложениями, и если да – то как именно)

Точка 4. Согласование разработанного решения

Решение разработано, подготовлена презентация (в формате PowerPoint). Часто проводится очное совещание с «живым» показом разработанного решения.
Если проект публичный (опубликован в доступном партнерам списке планов на сайте 1С), то презентация выкладывается на партнерском форуме в разделе ERP, чтобы все заинтересованные партнеры могли ознакомиться и высказать свои замечания.

Точка 5. Тестирование и аудит проекта

Точка 6. Окончание проекта

Закрываем проект в СППР – присваиваем ему статус «Выполнено».

Выпуск версии

Примерно за месяц до выпуска нового релиза накладывается мораторий на заливку новых проектов в основное хранилище (разработка в хранилищах тех. проектов продолжается); те проекты, которые не успели закончиться к этому времени, переносятся на другую версию.
В течение этого месяца проводится регрессионное тестирование; вносить изменения в код разрешено только для исправления привнесенных в этом релизе ошибок. Непривнесенные ошибки (те, которые воспроизводились и на предыдущих релизах), к началу регрессионного тестирования обычно почти все исправлены; те же ошибки, что остались, переносятся на следующий релиз. Основная задача регрессионного тестирования – гарантировать неухудшение качества продукта.
В качестве баг-трекера, как уже говорилось, используется все тот же СППР.

Исправительные сборки

Каждые две недели мы выпускаем исправительные сборки к версиям; на сегодня это 2.1.3.x, после выхода релиза 2.2.1 будут выпускаться 2 исправительные сборки — 2.1.3.x и 2.2.1.х. От регистрации ошибки до появления ее в исправительном релизе у нас проходит менее двух недель; наша статистика показывает, что среднее время от обращения клиента с ошибкой в ERP в поддержку до выхода ее исправления в исправительной сборке на сегодня – 9 дней.

Разветвленная разработка

В групповой работе над ERP мы стараемся использовать средства, предоставляемые нам платформой 1С:Предприятие. Конфигурации хранятся в хранилище конфигураций, при чекине новой функциональности в ветки используется стандартный механизм поставки и поддержки. Все операции автоматизируются по максимуму; в случае, если объекты менялись только на стороне разработчика – объединение кода происходит без участия программиста. Если для объединения исходников нужно вмешательство разработчика, обычно мы используем встроенные возможности платформы. Но есть также возможность вызова сторонних инструментов сравнения/объединения из инструментов платформы (например, KDiff3 или Araxis). Кстати, эта фича – вызова сторонних инструментов сравнения/объединения — была добавлена в платформу по запросу именно команды разработки ERP.

Читайте также: