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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опубликовано 01.12.2010 в 11:51 · Автор ivan · Ссылка
Рубрики: ABAP

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

Подписаться на комментарии по RSS

  1. Написал(-а) dsfskh
    13.02.2015 в 17:20
    Ссылка

    SPRO:4209AC166A2F1A27E10000000A114E5C ??

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

  2. Написал(-а) ivan
    13.02.2015 в 17:29
    Ссылка

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

Подписаться на комментарии по RSS

Написать комментарий