Коллеги, добрый день!

Не подскажете, есть ли возможность следующей настройки для отчета J3RKKRL. Необходимо, чтобы в отчете не отражались позиции с 79* и 69* техническими счетами, а отражалась бы корреспонденция бухгалтерских счетов, которые задействованы в проводках по дебету и кредиту вышеуказанных счетов. Ну т.е. есть ли возможность связывания таких проводок?

Например:
Д 70* К 69099*
Д 69099* К 32*

Нужно, чтобы в отчете отражалась позиция с суммой по проводке Д 70* К 32*. Или это можно сделать только через доработку отчета?

Спасибо большое. У меня 2 документа, по 2 позиции каждый. Скажите, пожалуйста, а в какой таблице настраивается приоритет пары? Я нашла только тр. J3RKPAC, в которой настраивается приоритет счета.

У пар приоритетов нет. Первенство пары достигается двумя максимальными приоритетами обоих участников по дебету и кредиту. Найденная Вами настройка - это и есть то, что Вам написал Darkduck. Из пар есть только запреты. Также там мелькает драфт настройки предпочтительных пар, но он в жизнь не воплотился, так и остался рудиментом.

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

То есть, если я Вас правильно поняла, то и доработать через расширение это нельзя. Действительно, если я показываю сальдо по 70* счету, почему должна отражаться сумма по счету, с которым корреспондирует 69099? Это нарушение логики работы отчета.

А почему это нарушение логики отчета, если в Вашем документе 70 действительно корреспондирует с 6099? Это же Вы такой документ создаете, вот и корреспондирует.
Если не должен корреспондировать, то создавайте документ с корреспонденцией 70 и 32. Ну или посмотрите на ключик таблицы J_3RKKRS. Там в ключе только один документ.

Вы меня не так поняли, например, 70* счет корреспондирует с 69099 и это верно, а пользователь хочет задав на просмотр сальдо 70* счет в корреспонденции видеть не 69099, а счет, с которым последний корреспондирует, т.е. 32*. Вот это мне кажется нарушением логики отчета и есть ли смысл такое подламывать.

Предложенное ниже - это просто варианты. Каждый из них реализуем, и реализация в целом несложная, но влечет за собой довольно существенное усложнение процесса. Потому что самым правильным вариантом было бы отказаться от промежуточного 69 счета и сразу проводить 70 32. Но если отказаться никак, то.
1. Если указанный технический 69 счет используется только для этих целей И всегда закрывается в ноль в конце периода И за этим четко следят И никаких других дебетовых и кредитовых оборотов там нет, то при формировании отчета в J3RKKRL можно через расширение подменять значение в итоговой строке, рассплитивая ее на нужно число строк в корреспонденции с 32 (если этих 32 несколько). То есть в процесс разбора не вмешиваться. Вмешиваться только в финальное формирование отчета. Это обеспечивает целостность и оригинальность данных в J_3RKKRS.
2. Если 69 счет подразумевает ОП (выравнивается), то вмешиваться именно в процесс разбора и изменять таблицу отдельных и итоговых записей, анализируя при этом выравнивание 69 счета. Но делать это должен только спец, понимающий принципы обновления таблиц корреспонденции (отдельной и итоговой). Иначе можно намудрить так, что отчет не пойдет с оборотами и остатками + порвутся J3RKOBобовые транзакции выверки (сравнивающие итоговые строки корреспонденции с итоговыми записями по счетам ГК). Довольно сложный путь, но реализуемо.

Добрый день!

Опять вернулась к доработке по отчету J3RKKRL. Я думаю не получится разложить технические счета 70099000 и 69099000 на корреспонденцию бух. счетов. Задаю в отчете Счет Главной книги 70000000. Вышли дебетовые и кредитовые обороты по техническим счетам помимо оборотов по бух. счетам. Допустим в таблице J_3RKKRS зададим дебетовый счет 70099000 и кредитовый 70000000. А как мне потом выбрать все дебетовые счета для кредита 70099000, причем учитывая строго предыдущую сумму, которая "пришла" с 70000000 счета. Посмотрела в этой таблице есть проводки по дебету 70099000 и с других счетов:68* и т.д? То же самое и для дебета 69099000, там по кредиту кроме 70000000, есть счета 69041* и т.д. Как Вы видите такую ситуацию? Да, если бы по кредиту у данного 79009000 стоял бы только 70000000 то можно было сделать. Ответьте, пожалуйста, или может я не до конца поняла Вашу мысль.

Чтобы Вашу задачу решить, нужно начать недискретно мыслить.
Повторю, тут что угодно можно сделать.
1. Ломать хребтину стандартной движку.
2. Полностью сделать Z-корреспонденцию.
3. Микст-вариант: использовать стандартную в части всех счетов, кроме искомых (устраняя данные документы при разборе, когда они содержат хотя бы один искомый счет). Разбор оставшихся документов сделать своими силами через автоматическое регулярное задание. В нем по своей собственной логике разбирать такую корреспонденцию. Таблицу стандартных итоговых записей и отдельных итоговых записей вообще не трогать: условиться считать, что в ней все, кроме искомых. Корреспонденцию искомых хранить в другом месте. При формировании J3RKKRL вмешаться через расширение и докинуть свои записи. В таблице расшифровки корреспонденции (там сабмитится отдельный отчет) вмешаться через расширение и докинуть свои записи.
4. Отказаться от практики учета через технические счета.
5. Использовать полностью стандарт, а в части расшифровки искомых счетах через Z-разработку формировать некую справку-пояснение.
6........
7........

Йож, ты забыл 2 волшебные бади при разборе корреспонденции. Там можно что угодно в принципе подмахнуть. Но только надо учитывать что стандарт потом сделает "балансировку по счету".

Kengur, да про бади-то я не забыл. Я про корреспонденцию даже подробно разбор делал, помню про них. Просто мне кажется, что тут бадиха не помощник. Тут ведь как выходит: автор хочет связать счет из одного документа со счетом из другого документа. Такое даже на уровне структуры таблиц невозможно, это в старой кор. Про новую вообще молчу, от нее все плюются вроде. Теоретически можно, конечно, в бадихе устроить замут: через выравнивание технического счета (или как-то еще, если он без оп, по взаимной ссылке) найти второй док, убедиться, что там совпали суммы, что счет там только один и пр. Заменить счет в бади, досрочно выйти (типа разобрано успешно). Смириться с неконсистентной инфой в табле (ключик-то чужой). При этом второй документ не разбирать вообще (иначе двойной оборот будет). Потом еще раз смириться, когда транза типа j kobs выдаст несовпадение итоговых записей и сальдо. И еще раз, когда неразобранные доки будут торчать в спец отчете. И еще раз, когда кто-то их разберет) короче говоря, делается-то за 10 минут, но это же обман по своей сути)

Ну я делал решение для НДС по такой схеме. При этому у меня не было "затратных счетов" в Ф4 настроено. Нормально работало.