Приветствую всех

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

А почему не "пакетным вводом"? Он не работает в этом случае или вы не хотите его по другим причинам?

Пакетный ввод-ИСКЛЮЧИТЕЛЬНО медленный, поэтому и не подходит.
Задача: по всем заказам, по которым не начато производство, проставить значения определённого/определённых признаков.
А таких заказов очень много

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

Я совсем недавно эксперементировал с похожей задачей - изменение признаков партии через САТТ и CALL TRANSACTION. Посмотрите на
http://sapboard.ru/forum/viewtopic.php?t=12965
Если у вас пакетник записывается (что не факт, т.к. у вас тоже есть признаки), то САТТ не нужен и можно просто через CALL TRANSACTION. CALL TRANSACTION версия пакетника (особенно в асинхронном виде) вообще работает быстрее чем простой пакетник, но незнаю достаточно ли быстро для вашего случая.

У нас пакетник записывемый и потом дорабатываемый .

Не понимаю в чём проблема - признаки "руками" вводим на экран когда записываем пакетник, а потом в них засовываем всё, что душеньке угодно.
Проблема как раз в том, что пакетник начинает идти по всему сбытовому заказу через транзакцию, со всеми проверками, и это происходит долго.

Ну мы делаем это через BAPI, единственное что сначала мы создаём заказ/позицию, а потом его меняем через "BAPI_SALESORDER_CHANGE", а там можно изменять значения признаков через заполнение таблицы order_cfgs_value...

Ну мы делаем это через BAPI, единственное что сначала мы создаём заказ/позицию, а потом его меняем через "BAPI_SALESORDER_CHANGE", а там можно изменять значения признаков через заполнение таблицы order_cfgs_value...

Посморим - Попробуем , но в понедельник!

А признаки конфигурации у вас влияют на заказ (цена, раскрытие спецификации) или носят только информационный характер?

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

Не нравится мне слово разузловывание. Я видел только автоматическое раскрытие спецификации в зависимости от признаков (без всяких кнопок), но это настраивается исключительно в самой спецификации через связи. Довольно трудоемкая работа.

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

Посмотрите еще эти ФМ:
CUCB_GET_CONFIGURATION
CUCB_SET_CONFIGURATION

По минимуму всё достаточно тривиально.
1. Создаём конфигурируемый ОЗМ "Грабли" (материал № 1), в ракурсе "Классификация" присваиваем класс признаков 300-го класса у которго один только признак "Цвет" (это для примера, можно больше)
2. Создаём 2 ОЗМ "Грабли зелёные" (мат №2), "Грабли красные" (№3) (можно как конфигурируемые так и неконфигурируемые)
3. Создаём спецификацию материала "Грабли"
4. В позиции спецификаци вносим ОЗМ "Грабли зелёные" и "Грабли красные"
5. В зависимости от ОЗМ №2 и 3
5.1. Конфигурируемые, в классфикации указываем класс признаков 300-го вида класса. Этот класс признаков можно взять такой же как и у материала №1, так и создать новый. Обзязательное условие чтоб присутсвовал призак "Цвет". Запоняем признак "Цвет" значением в №2 "зеленый", в №3 "красный". Допустимо наличие дополнительных признаков их в классификации не заполняем (можно и их запонить но для начала не стоит, серьёзное усложнение)
5.1.1. В позициях спецификации материала №1 ставим галочку "Как условие доступа", а в поле "Вид класса" ставим 300.
5.1.1.1. Для всех ОЗМ создаём профиль конфигурации в закладке "параметры" конфигурации": Процесс ---> Заказ клиента; Приложение спецификации --> SD01; Интерфейс --> Браузер конфигурации --> ПрисвЗначенПризнак-->Результат-->Основные данные
5.2. Не кофигурируемые, закладка "Классфикация" не обязательна. Для материала №1 выполняем п/п 5.1.1. и 5.1.1.1.
5.2.1. Если в ОЗМ № 2 и 3 не завели ракурс "Классфикация" тогда пишем глобальное отношение (Транзакция CU01), вид отношения "Условие выбора", в редакторе пишем без кавычек (Цвет = зелёные). Это отношение вставляем в позицию специякации мат №2, для №3 делаем аналогичное в вносим в позицию №3.

Разузлование получили. Но это примитив и явно не достатчно для нормальной работы. В подчинённые позиции в заказе нельзя внести руками количество, оно приходит из спецификации. В конфигурации количество спецификации менять можно и нужно апдейтя поле STPO-MENGE что тоже делается элементарно. В таком виде по идее можно уже это кушать. Для нормальной работы ещё ограничения навешать, нормальный профиль кофигурации и если будет много уровневая конфигурация тогда ещё и функциональный модуль прицепить для принудитьного заполнения конфигурации чтоб не тормозило и тогда совсем всё будет супер