Необходимо реализовать алгоритм вывода корреспонденции счетов. Проанализировав содержимое таблицы BSEG пришел к выводу что не могу однозначно для конкретных документов определить корреспонденцию счетов, т.к. на один документ может приходиться до сотни записей. Анализируя записи отдельных документов интуитивно понятно, исходя из вида записи (Д/К) и сумм, как выглядит корреспонденция, но увы как алгоритмизировать этот процесс не совсем ясно, т.к. не обнаружил в таблице явных признаков, по которым можно было бы связать записи документов для корреспонденции.

Подскажите какие есть варианты реализации этой задачи?

а их и нет.

Все дело в порядке следования позиций в документе,
если он нарушен - то и стандартная корреспонденция не работает

Не уверен что даже при идеальном порядке следования записей в документе возможно алгоритмизировать корреспонденцию.

Вот пример реального документа:

BUZEI SHKZG DMBTR HKONT
1 H 6336,40 63131000
2 S 3759,70 M1560100
3 H 0,01 20100000
4 S 1520,64 M1560100
5 S 1056,07 64420000
6 H 5280,33 R999999999
7 S 5280,33 RJ0000041

А теперь вопрос. Если нас интересует 63131000 (1 позиция), то понятно только частично чего нам надо делать. 6 и 7 запись явно не корреспондируется с интересующим нас счетом, хотя и так понятно что это технические счета. Но ситуация сильно усложняется если мы берем 64420000 счет (5 позиция). Не понятно в какую сторону двигаться чтобы собрать интересущие нас счета?

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

первая позиция - один корр.счет
все следующие - до достижения суммарно суммы первой позиции
- другие корр. К НЕМУ счета,

далее - след корр.счет
и т.д.

Самое смешное, что четкого алгоритма корреспонденции действительно не предусмотрено.
Одно время тоже помучался с этим, работая с ММ. Попробовал такое решение: корреспонденция проводок друг с другом, а также их связь с документами материала устанавливается эмпирически, по косвенным признакам.
Самое удивительное - в 99.9% случаев ММ-ских проводок/движений, работало правильно. Хотя, несложно придумать ситуацию, когда будет глючить, а четкого алгоритма придумать практически невозможно.
Как уже заметили вышел - все зависит от типа документа. Везде логика своя.
Ниже - примерный алгоритм установки этого соответствия. Строго не судите - когда писалось, у меня опыт был всего годик .

Т.е. 100% реализация в принципе невозможна?

Еще один документ имеет такую мигалку в записях:

1 S 11730000 10.00
2 H 13273000 3.00
3 H INITIAL1 10.00
4 S INITIAL1 3.00

Т.е. его можно корректно обработать только анализируя суммы в записях! Но это простой пример, а в случае сложных как быть?

Дело ясное, что дело темное!

Саповский отчет RFHABU10 этот документ корректно обрабатывает, хотя и с примечанием "Сравнение сальдо счетов в базе данных и в отчете - Число ошибок: 2". А разобрать логику его работы трудновато будет. Не уж то он анализ по сумме производит, но это уже искусственным интеллектом попахивает...

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

А чем вам не нравится корреспонденция из ADD-ON ? Мы ее доработали немного, получилось, очень прилично, 98% документов разбирается. Алгоритмы там очень приличные заложены.

Если не секрет - чего вам в аддорне не хватило?
и что входит в 2% документов которые не разбираются даже с учетом ваших доработок?

Долго не реагировал на ответы. Сидел разбирался. Я теперь в легком шоке пребываю. Оказалось что в САПе нарушен принцип двойной записи, а из-за этого все проблемы с корреспонденцией. Т.е. на относительно простых документах все просматривается относительно четко. А вот на сложных документах просто мрак.

Из того, что я понял:

1) Необходимо из Адд-Она взять разборщик корреспонденции счетов, который автоматически обрабатывает чуть больше половины документов. Остальное отдает на ручной разбор. Причем не разбираются практически все документы, содержащие в идеальном случае два дебета и два кредита, об остальных документах вообще молчу.

2) Есть определенная информация о том, что можно настроить приоритеты корреспонденции для того, чтобы иметь более четкие данные при разборке документов. вот только пока FI-щики просто делают большие глаза и не понимают о чем я. вот только разборщик наверняка использует приоритеты, а так как их никто не настраивал, то и лажа получается в конечном итоге с автоматической разборкой. Бракуется почти половина документов.

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

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

Вот такие пироги... По этому если у кого есть какие мысли, очень жду ответов.
P.S. Всем спасибо за ответы...

Мы с помощью своей настроечной таблицы сделали "перекидку" позиции финансового документа на противоположную сторону счета по определенному условию. Например: для такого-то вида документа, кода проводки и номера счета переносить позицию с дебета на кредит (или наоборот) со сменой знака суммы естесственно. Очень помогло. 2 % - это сложные документы (скидки, некоторые документы FI-AA). У нас еще две валюты в системе, так что это еще добавляет приятных ощущений при разборе

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

Простые документы достаточно легко разбираются, а все виды документов кде мощность отношения дебитов к кредитам соотносится как N:M легко (по крайней мере на нашей кухне) идентифицируются по уловиям вида "№позиции && КП && xnegp".
Ну и правила исключения разных документов выравнивания понадобятся. В настройке и использовании ИМХО легче чем в SAP.

Принцип д.б. простой - то что не разрешено - вводить в систему НЕЛЬЗЯ. Тогда и не будет никогда этих самых пресловутых 2% - у нас проблем с корреспонденцией нет никаких в принципе.

PS. У нас порядка 60 документов прописано через настройки (при ~ 100.000 проводок в год), все остальное разбирается по "тривиальным" правилам.

Т.е. если подвести итог!

Необходимо в FI настроить приоритеты корреспонденции, а также настроить запреты/разрешения корреспонденции. Дальше на основании этой кухни написать свой разборщик, который и будет разбирать максимум документов. Остаток документов (надеюсь что очень небольшой) разберут бухгалтера в ручном режиме.

Примерно так я вижу дальнейшую реализацию.

Так вроде там и разборщик есть. Ничего писать даже не надо - главное настроить правильно

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

Бухгалтерия вроде бы везде одна.

Просто не пойму.