Определение корреспонденции в главной книге

Сталкивался с ручной интерпретацией определения корреспонденции.

  1. Для определения допустимой и запрещённой корреспонденции
  2. Для получения отчётов по корреспонденции (журнал-ордер)
  3. Для передачи документов в систему, в которой используются только пары Дт-Кт

До этого такие функции я видел только в Z-разработках, но есть, оказывается, в стандарте кое-что вокруг этого.

Результат определения корреспонденции попадает в таблицы:

J_3RKKR0 – итоговая таблица

J_3RKKRS – отдельные позиции по дебету и кредиту

Таблицы кажутся вполне вменяемыми для использования в отчётности, если они при этом корректно заполняются.

Основные настройки определяются в SPRO:4209AC166A2F1A27E10000000A114E5C

Главная транзакция, которая формирует корреспонденцию: J3RKKRS, вот пример:

Автоматическое определение корреспондирующего счёта

Всё, что делится автоматически – то и делится автоматически. Если что не скорреспондировалось, то можно поделить ручками – на этот случай есть соответствующий интерфейс:

Список позиций в определении корреспонденции

После нажимания кнопочек получается примерно такой:

Определённая корреспонденция

Там же в настройках есть некоторое расширение BADI:/CCIS/SMOD_J_3RKAC1, которое и должно покрывать 99,99% всех документов.

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

Список допустимых (разрешённых и запрещённых) корреспонденций хранится в настроечной табличке J_3RKKRN, судя по тестам – блокировка определения корреспонденции действительно происходит.

Насколько такой подход лучше собственной разработки – это надо детально разбирать.

[TODO] Надо попробовать собственные наработки по определению корреспонденции вставить в расширение, и посмотреть на результат.

[TODO] Надо посмотреть, в каких стандартных отчётах используются данные этих таблиц.

ЗЫ. Программа ориентирована на Россию, и имеет косячки при переносе – исковерканная русская кодировка для комментариев:

неверная кодировка

2 комментария

  1. SPRO:4209AC166A2F1A27E10000000A114E5C ??

    А с алгоритмом интерпретации вы не работали?

  2. Алгоритм интерпретации ткнул пару раз, но увидел, что его трудно отлаживать и забросил.
    На текущем проекте управляю записями в таблице приоритетов J_3RKPAC.
    Чудеса разные бывают, но в целом годится.

Добавить комментарий

Ваш e-mail не будет опубликован.