Добрый день. Прошу знающих оказать квалифицированную поддержку.
Если коротко, вопрос такой: как добавить поле Customer (KUNNR) в вызов BAPI_ACC_DOCUMENT_POST и модифицировать транзакцию FB03,
чтобы поле Customer (KUNNR) выводилось в список позиций?

Есть программа, которая считывает эксель-файл и создает документ через вызов BAPI_ACC_DOCUMENT_POST.
Тип документа BLART = SA (G/L Account Document).
Вызов BAPI* выглядит следующим образом:


Т.е. без импортируемых таблиц: accountreceivable, accountpayable.
Пару раз добавлял поля во входной файл и в код полей, которые присутствуют в транзакции FB03 (например, поле PRCTR). Все было без проблем. Параметры вызова BAPI* за исключеением добавления нового поля в таблицу lt_accountgl не менял.

Возникла необходимость добавить в считываемый эксель поле Customer (KUNNR) и добавить колонку с Customer (KUNNR) в список позиций в FB03.
По сути, необходимо добавить поле KUNNR в позиции таблицы lt_accountgl. Добавил.
Из входного файла к вызову BAPI* поле KUNNR транспортируется корректно.

Документ надо либо парковатъ, либо сразу постить.
Если документ сразу постить, то запись производится в таблицы BKPF (заголовок), BSEG (позиции).
В BSEG есть поле KUNNR, при вызове BAPI* KUNNR корректно записывается в соответствующие позиции.

Возникли две сложности.
1) При парковке документа типа SA теряется KUNNR.
Если документ парковать, т.е. добавить в вызов BAPI* параметры:


то документ сохраняется в таблицах VBKPF (заголовок) и VBSEGS (позиции). В таблице сегментов VBSEGS поля KUNNR нет, и KUNNR теряется после вызова BAPI*.
Как правильно добавить поле KUNNR в VBSEGS?
Или нужно определенно менять тип документа на DA (Customer Document)? Паркованный документ типа DA должен иметь позиции в таблие BSEGD, в которой есть поле KUNNR.
Я пробовал менять тип документа на DA, все другие параметры в BAPI* не менял. Позиции все равно записываются в VBSEGS.

2) Как правильно добавить колонку в списке позиций / поле в выбранной позиции с Customer (KUNNR) в транзакции FB03?
- Кастомизация в транзакции SPRO?
SPRO--> Financial accounting (new) --> General ledger accounting (new) --> Master data --> G/L accounts --> Line items --> Define special fields for Line item display.
- Есть какой то подходящий USER EXIT, BADI?
- Другие варианты?

кнопка "выбрать другие варианты просмотра" и добавить нужные поля

Для KUNNR в бапи в зависимости от видов документов надо заполнять таблицы
ACCOUNTRECEIVABLE
ACCOUNTPAYABLE

Поля KUNNR нет в "Column Set". В SPRO добавил где только возможно
В частности:
Financial Accounting->Accounts Receivable and Accounts Payable->Master Data Define Additional->Fields for Line Item Display->Define Additional Fields for Line Item Display

Наряду с кастомизацией в SPRO нужно было согласно SAP Note 2491866 добавить KUNNR в структуру BSEG_ALV.
Теперь можно постить документ с KUNNR и в позициях есть поле Customer.
Теперь думаю о Таблице VBSEGS. Можно ли также просто добавить KUNNR чтобы парковать SA документ с KUNNR
или все надо делать через USER Exit в транзакции FIBF подобно как с
00001650 LINE ITEM DISPLAY: Add to data per line
в https://www.youtube.com/watch?v=hm6G5BpToc4&t=159s ?

Ох, че-то все руки не доходили дочитать это до конца. Дочитал, наконец-то.

Концепция ввода документа в RW в сапе не позволяет такое. Как уже отмечено в ветке, все счета разбиты по своему типу по таблицам. Система на основе таблицы определяет, что это будет: GL, дебитор или кредитор. Ни кредитор, ни дебитор не вводятся напрямую в BAPI.


От вида документа это вообще никак зависеть не будет.


Попробуйте зааппендить. Вдруг чего и выйдет.


Указанная Вами настройка - это отображение доп. полей в списке отдельных позиций. Это уже отчет. Сюда как раз добавить - дело пустяковое. Вы же в FB03 хотите. Вдобавок ко всему 1650 работает только для отчетов, которые строятся не на основе новой ГГК, то есть FBL*. И это не exit, это open fi. В FBL* есть еще своя бади (работает после 1650). В новой ГГК есть еще своя бади, но там не работает 1650 (fagl* отчеты). Тем не менее никто не запрещает на новой ГГК запустить FBL*. Но все это не важно. Как я уже написал, добавить туда - это дело 10 минут от разработки до переноса в продуктив.

Главное не это, главное - концепция. FB03 не имеет кредитора, дебитора и счета ГК, потому что она работает на типе счета. В одно и то же поле KTONR система складывает номер счета в зависимости от его происхождения (ГК, кредитор или дебитор). Благодаря этому пропадает необходимость хранить в этой самой системе все эти поля, потому что эти вещи не могут быть заполнены одновременно. Вы тут нарушаете принцип контрольности счета, и вот мы перешли к главному. Счет либо ГК, либо кредитор, либо дебитор. Других не бывает (я осы не описываю, потому что для сапа это тоже ГК). Вы хотите в проводке по счету ГК записать KUNNR. Ммм, ну такое себе. Технически это реально, как все там дальше работать будет - никто вам точно не скажет, потому что так никто не делает. Я видел в результате пары неудачных замещений, как в позицию ГК записывался LIFNR, ничего фатального не случилось, но и смысла в этом нет.

Обычно для вашей задачи в блоке контировки просто создают новое поле. Например, ZKUNNR. И его протаскивают на экран ввода (на нужный - их несколько в сапе). Это в диалоге. В BAPI решить эту проблему вроде бы тоже можно. Если не аппендом структур, то замещением или open fi. Нормально вызванный bapi, как Ваш, прекрасно воспринимает работу замещений и open fi. Не нужно верить в обратное, это миф - BAPI, вызванный как полноценный BAPI, цепляет функциональные модули из таблицы trwpr. В них точно можно записать все, что угодно, в новое поле.

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

Теперь по FB03. Как я уже сказал, плохая идея писать это в поле KUNNR, потому что сап в FB03 так не работает. Я бы лучше писал это в ZKUNNR. И уже это поле вытаскивал. Для начала попробовал бы стандартом, покопайтесь вот здесь.
Транзакции:
- O7Z1
- O7V1
Там можно вытаскивать новые поля, кажется. Но я не вдавался в детали, просто увидел, что там поля можно таскать. Почему бы в списке там не появиться новому полю вашему? И вы бы его включили в структуру, а потом присвоили.

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

Yozhhhhh,

Покорнейше благодарю за вхождение в суть моей проблемы и за подробный ответ.
Буду разбираться.
Параллельно делал :
Легко документ запостить потому что в BSEG есть KUNNR. Что и сделал.
Но получил в ответ мощный пресс пользователей что надо парковать. Вот тут и проблема: KUNNR нет VBSEGS
Набрел на структуру CI_COBL. В ней уже было несколько ZZ* полей.
Добавил туда новое поле ZZKUNNR,но делал данный шаг грязно. Просто забил новое поле в структуру CI_COBL и актвировал.
Активирование проходило минут 20.
Попробовал в в Z* имплементацию Badi ACC_DOCUMENT передать KUNNR в новое поле ZZKUNNR : не проходит.
После парковки в VBSEGS поле ZZKUNR пустое.
В структуре wa_extension значение KUNNR корректно "прилетает" в Badi

Попробовал то же KUNNR передать в старое поле ZZINSTL с таким же типом CHAR10: в VBSEGS значение сохраняется.
Причем в таблице c_accit все корректно: и в ZZKUNNR и в ZZINSTL значение KUNNR записано.
Какой-то кастомизации не хватает для ZZKUNNR. Может потому что поле добавлять в транзакции OXK3 ?

Все вопросы выше можно считать неактуальными.
Передать KUNNR при парковке в VBSEGS можно в поле VPTNR (Partner Account).
Данное поле есть и в BSEG
Теперь паркованый документ пытаюсь постить транзакцией FBV0.
Поле VPTNR в BSEG не передается.
Можно как-то передать содержимое VPTNR из VBSEGS в KUNNR или в VPTNR в таблицу BSEG при проведении поста в FBV0 через какой либо USER EXIT?
В интернете нашел подсказку на BTE 1030. Резонно ли данное направление?
Сделал в FIBF customer product подцепил функциональный модуль (FM) с BTE 1030.
FM не триггерится при проведении FBV0.
Какие шаги еще надо сделать чтобы FM триггерился?

Если просто про теорию вопроса, то для активации ФМ в open fi необходимо создать продукт клиента, активировать его, создать ФМ на нужном BTE, прописать в FIBF в P/S на 1030 в привязке к данному продукту.
Если говорить про изменения полей, то 1030 - это не самое удачное место для изменения логики проводки, а если говорить в лоб, то вообще неудачное, это событие запрещено использовать для изменения полей, если уж следовать нормальной сап логике. Если копать глубже, то BTE в P/S модулях вообще ВСЕ неправильно использовать для изменения полей. Разумеется, находятся те, кто 1025 и 1030 приспосабливают к решению такой задачи и там меняют что хотят, но так делать нельзя.

Если совсем хочется заместить через open fi, то используйте 1120 в модулях процесса. Это более правильно по хронологии процесса и по логике системы. В 1120 надо предварительно поработать с bseg_subst и добавить туда поле, так как замещаться будут только поля, которые есть в этой структуре. При работе с модулями процесса надо еще не забывать, что они не способны вызываться во множественном числе на одном и том же процессе. Например, если уже есть у вас сделанное кем-то до вами на 1120, то ваше уже повторно не отработает. По этой самой причине sap в своих процессах тоже устраивает вечеринки в этом же месте, но у него свое событие 1130.

Данную задачу не обязательно решать через open fi, это можно реализовать через замещение 2 или 3 момента в ggb1. Предварительно убедитесь, что в таблице gb01 в классах 9 (второй момент) или 15 (третий момент)
- исходное поле (с которого будете брать значение) разрешено в булевых правилах (там чаще всего весь BSEG разрешен). Это на случай замещения типа field 2 field. Булевы правила с типом класса B. Данный пункт не будет важен, если будете использовать тип замещения exit подпрограмма
- целевое поле (в которое будет записываться значение) разрешено для замещения. Обычно там разрешен весь BSEG, а потом точечно помечены на исключение очень многие поля. Разумеется, там не будет Z, стало быть оно будет разрешено. Это на случай замещения любого типа (как field 2 field, так и exit)
После любых манипуляций с GB01 не забывайте перегенерировать все в rgugbr00. Потом можно создавать замещение.

Yozhhhhh,

Благодарю за поддержку. Я теперь не так одинок в этой циничной кутерьме
После неудачных попыток с BTE я так и сделал подстановку Z* через правило в ggb1.
На мое "счастье" было одно свободное Z* поле которое имело такой же тип что и KUNNR,
которое передавалось через Badi почти во все сегментные таблицы для паркинга а также в BSEG.
Иначе бы пришлось модифицировать CI_COBL. А это уже мрачный эксперимент, чреватый тяжелыми последствиями
Для BLART = SA теперь работает.
Думаю теперь.. а не захотят ли коллеги впихнуть KUNNR в документ типа Vendor,
в котором на данный момент нет даже Z* полей.
Очень познавательно насчет BTE. Еще раз благодарю!

Ну и прекрасно
По поводу KUNNR я бы еще раз отметил (хоть меня об этом и не просили ) НЕ СТОИТ этого делать.
Используйте Z поля. Все равно Вы не сможете использовать стандартный функционал на KUNNR.
А в отчетность можно вытягивать и Z.
Что касается CI_COBL, то это не так уж и опасно. Эта вещь предназначена для добавления поля в блок контировок и не более того.
Не любой аппенд таблицы BSEG может открыть поле в блоке контироки, а только правильно оформленный в OXK3.
Но любой аппенд таблицы BSEG может быть заполняемым и замещаемым в зависимости от потребности и в зависимости от способа заполнения (BADI, open FI, замещения).

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

Я бы рекомендовал вернуться к бизнес-задаче, сформулировать её в явном виде и подумать какими другими техническими способами её можно решить.

Вот техническое задание:
Attached is the SAP Journal Entry template that we are currently using to upload JE’s to SAP.
The template does not have the SAP Customer field.
Accounting needs the Customer Number field to be added to the attached JE upload template to allow us to record JE’s at a customer level.
Хотят документ BLART= 'SА' (и другие) парковать, потом постить, после этого видеть заполненное поле Customer в FB03 и ALV список с JE в отдельном отчете c заполненным Customer полем .
На модификацию CI_COBL наложено вето.
Что посоветуете делать?

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

Я не скажу, что такое сплошь и рядом, но в защиту автора я своими глазами видел, как достаточно известные компании делают ZCOUNTERPARTY в BSEG на кодах проводки 40 и 50. И заполняют его, а потом тащат в консолидацию. Есть ситуации, когда ничего не доказать. Если увольняться после каждой тупизны, которую приходилось делать, то уже трудовая книжка закончилась бы. Хотя она и правда закончилась давно уже. Разумеется, я бы сперва высказал, что про все это думаю, а потом, если не получается продавить, стал бы делать. Конкретно к этой задаче вариантов множество. И если без кобла, то от заметок на уровне позиции в BELEG до Z-таблицы.