Мне необходимо собрать все входящие и исходящие денежные платежи для построения ОДДС.
Текущее предложение: самостоятельно собрать все проводки по платежам, выгрузив FAGLL03 - на мой взгляд это достаточно неудобно.
Использование каких-то готовых отчетов для формирования ОДДС неактуально, нет информации, что из них настроено...

Вопрос: имеются ли таблицы, в которых хранится реестр платежей (для исходящих платежей - кому заплатили, дата, сумма в руб и валюте, основание, ссылка на документ FI; для входящих - аналогично), из которых выгрузить данные через SQVI было бы проще, чем делать через FAGLL03 ?

BSEG

Ответил как топором махнул.



В системе стандартный ДДС работает через таблицы корреспонденции. Если уверены в том, что корреспонденция разбирается в компании правильно, попробуйте на J_3RKKRS. Это будет немного сложно, потому что без абапа информацию по поставщику и т.д. все равно не вытащить. Кроме того, это будет еще и безумно долго. Однако стандартный ДДС в системе все равно дохлый, за год может работать несколько суток, там некрасиво реализовано, а переделывать САП, судя по всему, не собирается.

Какой вопрос - такой ответ...

А где там в ДДС можно увидеть "кому заплатили"?

Я и не писал, что в стандартном отчете можно увидеть, "кому заплатили", так что улыбочек не понимаю.
Я написал, что без абапа не получится увидеть. Из позиции по кор. счету легко можно обратиться к нужной таблице и забрать поставщика.
Можно расширить саму J_3RKKRS и user-exit'ом писать в нее хоть папу римского. Можно все.

Тут уже не топор, а целый TK 722...

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

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

Ну а если активирован FM - там можно покопаться, куда там кто что засунул, на какие ФП что пришло-ушло.

Если уже совсем по хорошему, то для БДДС и ДДС есть специальный модуль FSCM-LP. Настраивается быстрее чем корреспонденция и систему не корежит как FM.

Планировщик ликвидности LP в части настройки в разы превосходит по сложности корреспонденцию, требует предварительной подготовки данных и катастрофически зависит от правильности выравнивания. Уходя в глубь выравнивания на несколько порядков, он раскручивает цепочку документов, сплитя платеж на порой невероятные вещи. Это огромная самостоятельная функциональность, и сам факт того, что LP умеет работать с такими вещами, как мемо-записи или позиции заказа, говорит о том, что она на порядки сложнее примитивной корреспонденции счетов. Вероятность разобраться новичку в LP в короткие сроки равна 0,0%. Если только это не система, внедренная в чебуречном киоске.

Внедрял с нуля без помощников в крупнейшем в России чебуречно-киосковом Холдинге. Описанных проблем не обнаружил Подготовки данных не больше чем в корреспонденции. Да и качество решения на порядок превосходит.

Внедрял в не менее крупной пирожковой с 35 балансовыми единицами в России, а также дочерними обществами в Африке, Азии и Америке. И обнаружил все описанные проблемы И главная проблема была в выравнивании. Возможно, в Вашем чебуречном Холдинге клиент всегда платит копейка в копейку, иначе Вы бы непременно столкнулись с проблемами, возникающими в LP при использовании в России: постоянные проблемы при использовании метода частичного платежа, недочеты в кассе, постоянная докатка нот и общение через service.sap.com. Что значит почти нет предварительных операций? А сальдо на момент миграции функционала? Для корреспонденции не надо вообще ничего. А сколько было запросов на первом и втором шаге? У нас порядка 80. А писались ли Z-модули? А сколько составляла глубина детализации цепочки на втором шаге? Начиная с третьего документа тянется просто сплошной мусор. А ситуации, когда новый счет добавляется в перечень банковских посреди года? Снова подготовка сальдо. А когда счет с середины года перестал считаться релевантным? Неужели Вы будете спорить, что проставить для счетов ГК приоритет и вылизать пары запрещенных корреспонденций по трудоемкости аналогично всему описанному?:)

В любом случае меряться <этими самыми> не вижу смысла. В России эта вещь по-прежнему экзотика, радостно осознавать, что есть те, кто смог ее запустить без пинка и задоринки. Респект.

Ноты были. Все остальное с бубуном заработало. Но не будете вы отрицать, что решение "проще" и логичнее чем Ф4. И правила LP, по сравнению с неописанной логикой разбора - чище детской слезы (консультанта 1 года)

Решение замечательное, спору нет. Я всегда на всех собеседованиях на вопрос "как собрать четвертую форму" говорил, что я бы собирал ее через LP. К тому же еще одно ее неоспоримое преимущество - это то, что если вторая область по дебитору в компании через технический счет реализована, то корреспонденция всегда будет выглядеть одинаково, а LP сходил бы и разрулил там, порешал все по-братски Но просто на моем опыте он обычно ходил и приносил мне 10 разных статей ликвидности, как деревенский кот по утрам неизменно приносит к ногам дохлую мышь. К примеру, с прошлого платежа болталась копейка. Потом приходит новый платеж, на копейку меньше (ушлый дебитор запомнил, что копеечку переплатил когда-то). В результате при выравнивании LP ту копейку находил в цепочке, добирался до документов задолженности (оплаченных прошлым платежом, на копейку больше) и начинал считать пропорцию. В итоге дебитор оплачивал данным платежом унитазные ершики, а платеж раздробился еще и на бейсболки USA. Если первый и второй платежи в одном месяце, то все ничего - платеж за бейсболки USA распределится с унитазными ершиками. Но что если в разных? На мой вопрос саповский support ответил мне: до чего странные у вас платежи, пусть ваши контрагенты платят вам четко, копейка в копейку. Ну не ездят на BMW по болотам, не ездят

В остальном соглашусь. В SAP пацаны ваще ребята, сделали хорошую вещь. Я правда рад, что у Вас она работает, как надо

Svsvsv, посмотрите на Финансовые позиции в 51 счете, может за вас уже все сделано...
Бывают решения, когда в 51 счет деривацией ставится ФП (реальная с типом 30, но с признаком статистическая), как раз с целью формирования ДДС.

PS
А этих двух перцев простите, они все никак не могут решить у кого, ну, вы поняли...