1. Типа поговорили :-), вообще-то код не оптимизированный, а просто код для загрузки текстов ОЗМ.
 
2. В довесок к LSMW, к сожалению метод Direct Input реализован не для всех объектов системы, вот известный мне список реализаций прямого ввода:
 
RFBISA00 -> GL A/C Master Record
RCSBI010 -> Create Material BOM
RCSBI020 -> Change Material BOM
RM06IBI0 -> Purchasing info record.
RM06BBI0 -> Purchase requisition
RM06EEI0 -> Purchase Order
RFBIKR00 -> Vendor Master
RFBIDE00 -> Customer master
RVINVB10 -> Sales documents
RM07MMBL -> Goods movement
RFBIBL00 -> Financial documents
RAALTD11 -> Fixed Assets
RCPTRA02 -> Routing
RCRAPDX2 -> Work center
RPUSTD00 -> HR master data
RHALTD00 -> Personnel Planning

В данной статье подробно рассматривается метод Direct Input для загрузки длинных текстов.
Также в комментариях освещаются альтернативные способы загрузки длинных текстов к основной записи материала.
 
В комментариях к первой части приводится текст кода оптимизированной программы, уже готовой к использованию. Импорт программы в систему занимает не более минуты с учетом наличия ключа разработчика (sapland.ru/articles/stats/2013/1/zagruzka-dlinnih-tekstov-osnovnih-zapisei-materialov-pri-pomoschi-tranzaktsii-ls.html#comment-1514).
 
Рекомендованная последовательность действий:
1) Текст указанной программы должен быть сохранён в файле .txt с кодировкой UTF-8 на ПК консультанта;
2) Транзакция se38: указываем имя программы, нажимаем создать; далее указываем заголовок программы (свободный текст), тип (можно: "1 Выполняемыя программа"), Статус (можно: "K продуктивная программа клиента"), Приложение (можно "M Управление материальными потоками")); нажимаем сохранить; указываем пакет (скорее всего, в системе уже будет создан Z-пакет для целей разработок текущего проекта; если его нет, то предварительно создать ) и создаём запрос.
3) В меню выбираем Утилиты -> Другие утилиты -> Загрузка/Выгрузка -> Загрузка -> [выбираем файл на жёстком диске].
4) сохраняем и проверяем.
Формат загрузки показан на рисунке 63 без заголовка. Первая строка файла - это данные для загрузки, а не наименование столбцов. Поэтому из текстового файла на рисунке 63 нужно удалить строку, содержащую: MATNR TAG2 TXT132. Данные в строке разделены между собой символами tab.
 
В комментариях к первой части статьи консультанты при обсуждении решения допустили определённую вольность речи в силу того, что они не равнодушны к своей работе; данную вольность они не при каких обстоятельствах не позволят себе в общении с заказчиком и пользователями.
 
После прочтения данной статьи и комментариев, проблем с загрузкой длинных текстов к любому объекту SAP ERP возникнуть не должно. В этом ценность статьи и комментариев.
 
Автор статьи очень благодарит Олега Виталиевича Точенюк за предоставленный исходный код оптимально написанной программы ABAP.

Извините, но я очень буду просить администрация SAP-Land ни в коем случае не удалять комментарии, как говорится чтобы дурь каждого видна была.
 
1. Посмотрел, рад... очень рад, что с экселями у вас все хорошо, поэтому не понял почему проблема чтения именно из файла xls в моей программе или точнее его предварительная конвертация у вас вызвала затруднения :-).
 
2. Я думаю без посредников разберусь с другими участниками колонок.
 
3. Я вашу статью не комментировал, я предложил альтернативу, которую вы назвали "стряпней", так что извини, не надо было начинать хамить дружок.
 
4. Да вы что, я на АBAP, никогда я и SAP то вижу по праздникам, когда начальство домой уходит, а меня на прогулку выпускают. А уж функционал, это да... завод и склады грузить через LSMW ни разу не пришлось и даже не виделось в страшном сне, но благодаря вам понял, все в этой жизни бывает в первые, так что и вас тоже вылечат.

Про Excel, Олег Виталиевич, Вы меня очень обидели. В своё время я концы с концами сводил благодаря написанию форм и программ с помощью Excel/VBA. Более того, даже для военных целей разрабатывал программы (это были военные образовательные цели).
И, обидели, как всегда, в противоречии с фактами:
1) посмотрите рисунок 49 моей первой статьи про Batch-Input LSMW (sapland.ru/articles/stats)
2) и рисунки 60-63 этой статьи.
 
Поэтому я доказательно утверждаю: у Вас в комментарии ложь.
 
Остальную часть комментария трогать не буду ибо есть поговорка: не тронь ...., ...ть не будет.
 
Жаль, что Вы его сделали под моей статьёй :-(
 
Но еще больше меня возмущает факт того, что Вы бросаете тень на автора колонки, который не является участником нашего диалога. Если бы Вы это делали под своей статьёй - опять же на здоровье Вам.
 
Но под статьёй, автором которой являюсь я, этого быть не должно - я её писал для других целей.
 
а к слову сказать: сколько колонок написали Вы за более чем 2ух летний опыт пребывания на портале, что Вы бросаете тень на авторство других колонок?
 
Поэтому диалог я с Вами продолжу при наличии, как минимум, одного из двух обстоятельств, а лучше двух сразу:
 
1) Вы ответом на Ваш же комментарий попросите извинения перед автором колонок, на которого Вы бросили тень; и этот автор примет эти извинения.
 
2) Администрация sapland.ru удалит эту Вашу часть комментария, или перенесет комментарий куда-нибудь на Вашу статью: главное, чтобы не было под моей.
 
А чтобы Вы нос, Олег Виталиевич, высоко свой не задирали скажу Вам следующее:
1) это Вы комментируете мою статью; и необходимость в нем [комменте] равна необходимости пингвинов в iPod.
2) на ABAP умеете писать не только Вы (наверное, для Вас открытие).
Каждый уважающий себя консультант использует отладчик, расширения, пишет отчёты; и знает, как работает функционал. Конечно, функциональный консультант не так умело обращается с ABAP-кодом как тот, который только и делает, что пишет код на ABAP.
Часты случаи когда из консультантов по функциональным модулям переходят в консультанты ABAP и, наоборот. И такие сотрудники весьма эффективны, т.к. смотрят неоднобоко.
 

Специально для Вас резюме (а то неправильно поймете): в Вашем комменте значительно нечистот, чтобы закончить с Вами диалог.

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

Про калошу я не понял если честно, так как писать в доказательство своих слов какие-то программки, не очень нужные мне или кому-то рядом, особо не хочется. В данный момент, как-то совпало поэтому набросал небольшой пример, заодно и время посмотрел, да в районе 30 минут, при среднем уровне знаний абапа. Вот вы там про 20 минут рассказали, вы знаете верю, только вот забыли одну мелочь, повторный импорт готового текста программы в любую систему займет минуту две, т.е. берем SE38 создаем новую программку далее Cntrl+A + Cntl+C -> Cntr+V и через минуту имеем готовую программу, протестированную ранее и полностью рабочую, хотя вы можете по этому поводу поспорить дальше.
 
1. Вы знаете действительно переход на чтение *.xls файла у меня займет минут 10, правда смысла не очень много вижу в этих действиях, хотя наверное вам операция "Сохранить как..." в экселе не ведома, поэтому и возникли данные проблемы, ну самоучитель экселя за 24 часа в руки и читаем, читаем, читаем.
 
2. Да в принципе все равно какое расширение у файла, знаете ли присвоение расширения xls не сделает файл книгой экселя, так что там все равно что в хвосте файла написано, программы знаете ли формат файла не по расширению определяют, уже лет 20 как не встречал таких программ. Хотя верю что есть еще уникальные люди, которые считают, что расширения определяет содержимое. Так что мне надо просто файл внутри которого разделитель табуляция, а как уж вы назовете эту лодку, программе все равно. Да кстати программку я запустил, результат посмотрел - работает. У меня как-то нет предвзятого отношения к расширениям файла. И кстати программы я пишу, а стряпают это где-то в другом месте.
 
3. Да читали плавали, знаем, мало того лучшие практики видели, но этой программке как-то фиолетово, так как загрузили не правильно, не страшно, запускаете второй раз с правильным файлом и все будет исправлено, но вы я так понимаю не очень представляете как работает SAVE_TEXT поэтому открою страшную тайну, он по умолчанию перегружает информацию по ключу текста. Кстати, предварительный просмотр это еще 10 минут, для простоты работы, SAP потрудился и сделал неплохой класс CL_SALV_TABLE, который позволяет вывести внутреннюю таблицу в течении 1 минуты. Меня это не затруднит сделать, если у клиента будет такая необходимость, хотя я в прошлый раз не понял на фига склады по 100 раз перегружать, так и с текстами тоже не понял, о каком постоянном использовании данной программы идет речь. Хотя опять же верю, варианты бывают разные и не все по нужде.
 
4. Как говорит народная мудрость, когда кажется - крестятся. Я вот вам почему-то верю, а вы мне постоянно нет. Все про ошибки кодирования, да какие-то песочницы рассказываете, про которые я по вашему мнению почему-то не знаю. А то типа LSMW вы сразу на боевой системе делаете, файл без всяких согласований с клиентом грузите, а потом что получилось, то получилось, главное в 20 минут успеваете как я понимаю решить все бюрократические процедуры, хотя по идее согласование формата файла с клиентом у нас должно быть по времени одинаковым.
 
Что касается ошибок кодирования, вот у меня так с абапом не выходит, там знаете ли сначала в разработке пишем, потом в тесте проверяем, потом уже продуктив, так что про ошибки кодирования это вы своей барышне расскажите за чашкой кофе, когда про ABAP-разработку в SAP ERP будете рассказывать. Да время привел без учета транспорта в продуктив, так что накиньте еще 30 секунд на STMS для продуктива.
 
Да кстати, у меня инструкция наверное займет все таки времени по меньше, чем ваша на LSMW? Нет? Ну хорошо, займет столько же, хотя экранов у меня, там будет максимум два, первый ввод файла, второй так уж и быть добавлю еще 3 строчки результата обработки данных, после загрузки итого накинем еще 5 минут к общему времени разработки.
 

Ой, а дальше давайте с вами поговорим про ваш взгляд - вот когда вы принесете мне справочку из лаборатории метрологии, где будет записано что ваш взгляд является точным прибором определяющим время работы программ на ABAP + имеющим погрешность измерения вашего взгляда, вот тогда будете рассказывать мне и остальным сказки о том что LSMW быстрее читает файл с рабочей станции, а особенно "на поржать" импортирует его в систему, как вы выразились используя Direct Input. Кстати, вы там в начале про какие-то калоши упоминали, так вот как раз сейчас речь и пойдет про эти самые калоши. Вы когда метод Direct Input выбирали на экране LSMW я так понимаю не очень поняли что оно вам там показывало, а показывало оно вам, что использоваться будет программа /SAPDMC/SAP_LSMW_IMPORT_TEXTS которая собственно говоря и проведет обновление данных длинных текстов, опять же, для вас это наверное будет открытие, но она это делает используя функцию SAVE_TEXT. А поэтому говорить, что какой-то Direct Input быстрее работает, чем приведенная мной ABAP-программа, которая тоже вы знаете пишет тексты той же функцией?! В общем возьмите свой глазок и повесьте его где-нибудь в дальнем углу и больше не используйте, а тем более не ссылайтесь на данный измерительный прибор.
 

Ну и на десерт как вы говорите оценим, опять же похоже на ваш глазок (хотя после выше приведенного примера, это уже звучит как-то странно), простоту подхода, как вы говорите. В качестве критерия вы почему-то решили использовать количество нажатий клавиш и насчитали у себя ну пусть 700, у меня вы там насчитали один диалог SE80, не угадали, эту ерунду можно и просто в SE38 набрать, а далее вы посчитали что в редакторе я нажал и ввел минимум 3782 символа. Как любят писать в интернете, "афтар пиши исчо", потому что для ввода функции загрузки файла мне нужно было сделать 5 кликов мышью + 24 нажатия на клавиатуре, по факту так как класс известный, то из 24 нажатий хватило 4 букв и два раза стрелку вниз... итого 6 мышью и 6 нажатий на клавиатуре. Так что там пропорция явно не 1 к 3, поэтому ваши 700 нажатий пусть стоят и нервно курят в стороне, потому что конечно транзакции разработки SAP-а это не верх удобства, но все таки, на данном этапе, это неплохой редактор кода, упрощающий ввод текстов за счет шаблонов и контекстных подсказок. Поэтому веселите народ в другом месте, например можно зайти к коллегам из 1С и рассказать там про ужасы разработки в SAP, по крайней мере там вам больше поверят.
 

И на остаток про широту. Минут 15 и эту программу без проблем можно модифицировать для загрузки любых текстов, для любых объектов системы, так как работа с текстами она унифицирована. Поэтому про широту тоже наверное бесполезно, это я вам верю, а вы мне почему-то нет.
 

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

PS: А вообще, не обижайте абаперов, потому что абапер-профессионал, практически всегда, знает как работает функциональность под которую он пишет, в отличии от бизнес консультанта по модулю, который чаще только думает, что знает как же оно на самом деле работает.

Олег Виталиевич, спасибо за комментарий!
 
Интервал "30 минут" Вы указали, чтобы не "сесть в галошу", как в прошлый раз?)))
(sapland.ru/articles/stats)
Огорчу: сели, но не так катастрофично. Поясню. Метод Direct Input не требует процедуры записи, а только сопоставление полей, поэтому занимает меньше времени, чем Batch-Input (время для которого я указал в своей прошлой статье). Поэтому создание данной загрузки я оцениваю в 20 минут.
 
Давайте сразу о Вашей программе:
1) бросается в глаза, что Вы загружаете файл из .cvs-файла, а не из .xls или .odf.
Вы не умеете делать загрузку данных из файлов .xls? Или в Вашей программе предусмотрен переход на .xls за 5 минут?
Если программу делать, то делать её удобной сразу.
 
2) пришлите пожалуйста файл загрузки в формате .cvs (именно cvs, а не csv).
я понимаю, что Вы состряпали программу на скорую руку, но можно было еще хотя бы раз запустить.
 
3) в Вашей программе отсутствует (я не заметил) процедура предварительного просмотра, что защищает от загрузки не того файла, защищает от ошибок в кодировках и, вообще, предварительный просмотр - это лучшая практика :-)))))).
Вы этого тоже не умеете делать, как консультант ABAP?)))
 
4) Ваша временные трудозатраты вообще говоря мне не кажутся реальными. Для системы-песочницы, возможно, это и так, но для того, чтобы она[программа] оказалась в продуктиве потребуется гораздо больше времени.
Процедура разработки обычно состоит из этапов (порядок может меняться, но этапы есть и их кто-то делает - скорее всего, не тот, кто загружает, но тем не менее затраты есть):
1) написание техн.задания;
2) согласование техн.задания;
3) разработка;
4) тестирование (создание протокола тестирования);
5) описание разработки;
6) перенос программы в продуктив;
7) корректировка и улучшение разработки.
+ возможно, инструкция.
 
В Ваши 30 минут, конечно же, вошло время на эту "бюрократию"? то есть приблизительно чуть более 2х минут на каждый пункт???!!!??? - очень и очень не реально.
 
Теперь об импорте программы - на мой взгляд проект LSWM импортируется быстрее, чем программа ABAP (особенно Direct Input). А объективно, если время импорта ABAP-программы из текстового файла и отличается от импорта LSMW, то речь идет о нескольких секундах - в целом, можно сказать, что как импорт программы так и проекта LSMW занимает не более минуты.
 
Оценим, простоту подходов:
 
текстовый редактор насчитал 3782 символа. то есть, как минимум, столько нужно нажать клавиш на клавиатуре, чтобы её создать - это без учета backspace; для создания загрузки через LSMW - думаю, около 700 (не считал) с учетом возможных ошибок.
Что касается диалоговых форм, то Ваша программа выигрывает: всего-то один диалог - SE80 и делов-то ))))).
Думаю (если не согласны - обоснуйте; моё обоснование - "количество нажатий") по простоте создания LSMW Direct Input выигрывает у Вашей программки даже при такой простой задаче как загрузка длинных текстов на языке системы.
 
Теперь подумаем немного шире.
Консультант, осуществивший любую загрузку методом Direct Input через LSMW, без труда перейдет к загрузке других данных.
Вопрос: за сколько Вы напишете программки для загрузки таких сущностей как: Подробные тексты, ОснЗаписи ОснСчетов, ОснЗаписи материалов, СпецификацМатериала, Сверхзапас LIFO, ОснЗаписиПоставщиков, ОснЗаписиКлиентов, Инфо-запись закупки, Запись условий, Заявка, Заказ на поставку, Торговые документы, Финансовые документы, и прочих.?
Таким образом, по критерию "переход к загрузке других данных", Ваша программа опять проигрывает; я бы даже сказал не Ваша программа, а Ваш подход.
 
Назовите и поясните, пожалуйста, хотя бы один критерий, где программа выигрывает. Только без "ну скажем" или "вот это был проектище", а желательно обосновано, если можете.
 
PS.
я поддерживаю такой подход, который удобен исполнителю (какой бы он ни был) - если Вам так удобно, то на здоровье!!!

Программка загрузки текстов, пишется минут за, ну скажем ниже приведенную программу с нуля написал за 30 минут. Модифицировать ее под разные языки, 5 минут времени. Для загрузки под разные объекты аналогично. Импорт программы в систему клиента тоже минут 5 (LSMW пожалуй по дольше будет создаваться). Скорость, ну вряд ли, что-то будет быстрее, хотя можете на своей системе проверить.
 
*&---------------------------------------------------*
*& Report  YTSH_SAVE_LONG_TEXT
*&
*&---------------------------------------------------*
*&
*&
*&---------------------------------------------------*
REPORT ytsh_save_long_text.
TABLES: rlgrap.
 
PARAMETERS: p_file LIKE rlgrap-filename DEFAULT 'C:\1.cvs'.
 
DATA: BEGIN OF lt_text OCCURS 1,
  matnr LIKE mara-matnr,
  tdformat LIKE tline-tdformat,
  tdline LIKE tline-tdline,
END OF lt_text.
 
PERFORM read_text.
PERFORM save_text.
 
*&---------------------------------------------------*
*&      Form  READ_TEXT
*&---------------------------------------------------*
*       Прочитать файл с даннами
*----------------------------------------------------*
*  <--  LT_TEXT - Данные загруженные для обработки
*----------------------------------------------------*
FORM read_text.
  DATA: l_filename TYPE string,
        l_filelength LIKE sy-tabix.
 
  l_filename = p_file.
  CALL METHOD cl_gui_frontend_services=>gui_upload
    EXPORTING
      filename                = l_filename
      filetype                = 'DAT'
    IMPORTING
      filelength              = l_filelength
    CHANGING
      data_tab                = lt_text[]
    EXCEPTIONS
      file_open_error         = 1
      file_read_error         = 2
      no_batch                = 3
      gui_refuse_filetransfer = 4
      invalid_type            = 5
      no_authority            = 6
      unknown_error           = 7
      bad_data_format         = 8
      header_not_allowed      = 9
      separator_not_allowed   = 10
      header_too_long         = 11
      unknown_dp_error        = 12
      access_denied           = 13
      dp_out_of_memory        = 14
      disk_full               = 15
      dp_timeout              = 16
      not_supported_by_gui    = 17
      error_no_gui            = 18
      OTHERS                  = 19.
  IF sy-subrc <> 0. MESSAGE 'Ошибка чтения файла с данными' TYPE 'I'. EXIT. ENDIF.
ENDFORM.                    " READ_TEXT
*&---------------------------------------------------*
*&      Form  SAVE_TEXT
*&---------------------------------------------------*
*       text
*----------------------------------------------------*
*  -->  LT_TEXT - Данные для обработки
*----------------------------------------------------*
FORM save_text.
  DATA: l_count LIKE sy-tabix,
        ls_header LIKE thead,
        lt_lines LIKE tline OCCURS 1 WITH HEADER LINE.
  SORT lt_text BY matnr.
  CLEAR: lt_lines[].
 
  LOOP AT lt_text.
    ON CHANGE OF lt_text-matnr.
      DESCRIBE TABLE lt_lines LINES l_count.
      IF l_count > 0.
        CALL FUNCTION 'SAVE_TEXT'
          EXPORTING
            header   = ls_header
            insert   = 'I'
          TABLES
            lines    = lt_lines
          EXCEPTIONS
            id       = 1
            language = 2
            name     = 3
            object   = 4
            OTHERS   = 5.
      ENDIF.
      ls_header-tdobject = 'MATERIAL'.
      ls_header-tdname = lt_text-matnr.
      ls_header-tdlinesize = '132'.
      ls_header-tdid = 'GRUN'.
      ls_header-tdspras = sy-langu.
 
      CLEAR: lt_lines[].
    ENDON.
    MOVE-CORRESPONDING lt_text TO lt_lines.
    APPEND lt_lines.
  ENDLOOP.
 
  DESCRIBE TABLE lt_lines LINES l_count.
  IF sy-subrc = 0.
    CALL FUNCTION 'SAVE_TEXT'
      EXPORTING
        header   = ls_header
      TABLES
        lines    = lt_lines
      EXCEPTIONS
        id       = 1
        language = 2
        name     = 3
        object   = 4
        OTHERS   = 5.
  ENDIF.
  CALL FUNCTION 'COMMIT_TEXT'
    IMPORTING
      commit_count = l_count.
  IF l_count > 0. COMMIT WORK. ENDIF.
ENDFORM.                    " SAVE_TEXT

Согласен с Александром: нужна статья.
А потом сравним два подхода по следующим критериям:
 
1) простота: количество диалоговых форм, с которыми имеет дело консультант при создании той или иной загрузки, и количество кликов мышкой и нажатий клавиш с клавиатуры.
Чем меньше того и другого, тем подход проще.
 
2) возможность изменения пакетного ввода по загрузки текста основных данных к "длинным" сбытовым и закупочным текстам на языке, который в системе не ведется.
(например, для клиентов из Италии мы создадим длинный текст на итальянском языке, при этом в системе можно работать на английском и русском); а также трудозатратратность перехода на загрузку сбытовых и закупочных длинных текстов ОЗМ.
также оценивается по количеству кликов и нажатий на клавиатуре.
 
3) скорость осуществления загрузки на 1500 ОЗМ с длинным текстом 500 символом с различным форматированием на одном и той же системе с одинаковой загрузкой.
 
4) любые другие критерии, которые подчёркивают достоинства и недостатки того или иного подхода.
 
Итак, задача:
Имеется перечень ОЗМ, к которым требуется загрузить длинные тексты "Основные данные" к ОЗМ с различным форматированием посредством тэгов SAPscript (как это выглядит - у меня описано во второй части данной статьи).
 
А пока статьи нет, я утверждаю следующее:
1) загружать длинные тексты ОЗМ с помощью метода Batch-Input вместо DirectInput все равно, что использовать сковородку для забивание гвоздей вместо молотка.
2) твой комментарий не более, чем попытка бездоказательно "поумничать".

"И я просто АХУ... дожник так красиво все описал"" (с). Вообщем LSMW - это сила. Олег, спасибо большое за подробное изложение процедуры использования данного инструмента. И в самом деле, какая разница, чего загружать конкретно. Важно то, что этот инструмент предоставляет широкие возможности, когда приходится иметь дело с большим объемом данных, которые надо быстро загрузить в систему.

Привет Олег, в этом случае я обычно стандартный Batch-input делаю, мне кажется так проще. В рекординге каждую строчку заполняю цифрами, затем гружу данные в формате MATNR TEXT1 TEXT2 TEXT3...

Привет Олег, в этом случае я обычно стандартный Batch-input делаю, мне кажется так проще. В рекординге каждую строчку заполняю цифрами, затем гружу данные в формате MATNR TEXT1 TEXT2 TEXT3...

Да, похоже не в теме.
Автор объясняет, как планировать производство некоторых материалов в сегменте СПП-элемента, а некоторых - в сегменте завода. При этом начинает вроде правильно - в позиции сбытового заказа указывается СПП-элемент, из сегмента которого будет происходить отгрузка. Но далее для генерации потрбености в этом сегменте СПП-элемента использует резервирование на операцию сетевого графика (указывает компоненты в операции), а не передачу потребности в сегмент СПП-элемента через вид потребности позиции сбытового заказа. Вот в этом кривизна предлагаемого решения    по моему скромному мнению.
И СПП-элементы тут используются только для сегментирования планирования, а не для сбора затрат. На СПП-элементы или операции сетевых графиков тут ничего не списывается. Затраты собираются на РР заказах и в конечном итоге на материале - с аналитикой СПП-элемента или без нее.

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

Я не имел в виду описание, просто согласно политике компании SAP, нравится она или нет, но курс случайно попасть в руки, в принципе не может... :-) по факту же, все понимаем, что пути курсов извилисты и длинны как провода у электриков.

Олег, приветствую!
 
Пост вполне корректный, описывающий изменения в курсе. Нет распространения всего курса и публикации его материалов.
 
Будет официальное недовольство со стороны SAP CIS, будем решать этот вопрос.

Ой, извините конечно, но с точки зрения компании SAP даже не знаю как это «к вам попало» назвать. Ну где то в районе не санкционированного доступа и использования учебных материалов компании SAP, что категорически порицается и считается недопустимым. Кстати, там в этих материалах это на первых страницах обычно написано :-), а тут ресурс официальный, так что как же вам не ай, яй, яй... такое писать...