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

Во-первых. Карточка контрагента.

Контрольный счёт – практически единственное необходимое поле ракурса БЕ из карточки контрагента. Без ракурса БЕ контрагент не может использоваться в бухгалтерии.

А счёт этот контрольный означает:

1. Единственный счёт, на котором могут отражаться бухгалтерские операции по нему (за исключением операций по ОГК). Здесь всё просто. Указал контрагента, и точно знаешь, на каком счёте он будет отражаться.
2. “Любимый” счёт по умолчанию. Это уже сложнее. Указал контрагента, при этом автоматически подтягивается его контрольный счёт, но его можно поменять на один из возможных (альтернативный).

 

Понятное дело, что система должна иметь некоторые ограничения, чтоб пользователи не могли по контрагентам проводить на любые счета. Иначе будет хаос.

Во-вторых. Деление в главной книге.

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

Например:

• Счета выданных авансов резидентам
• Счета выданных авансов нерезидентам
• Счета кредиторской задолженности резидентов
• Счета кредиторской задолженности нерезидентов
• Счета налоговой задолженности
• Счета сотрудников и заработной платы
• Счета долгосрочной задолженности

 

Авансовые счета – практически всегда отделяют по коду ОГК (A). Таким же образом можно разделить и долгосрочную часть. А остальные  — это обычная кредиторская задолженность по разным группам контрагентов. С моей точки зрения должно работать строгое соответствие “группа контрагентов <=> группа контрольных счетов”, жесткое, но не обязательно по принципу “один-к-одному”.

А о авансовых и долгосрочных счетах можно поговорить отдельно.

В группе задолженности резидентов (для примера) может быть выделено несколько субсчетов КР001-Услуги и работы, КР002-Материалы, КР003-Прочие и подобные.

Возникают такие вопросы:

• А зачем они так разделены, не проще ли вести задолженность на одном счёте ?
• А что делать, если одна счёт-фактура относится и к материалам, и к услугам (в счете фактуре должна быть только одна позиция кредиторской задолженности)?

 

С учетом этих вопросов можно сократить список таких счетов, передав соответствующую аналитику на откуп отчётности.

Список альтернативных счетов

Но если уж вдруг поделили и определились, то возникает понятие альтернативного счёта. Это связано с тем, что поставщик не всегда поставляет только что-то одно. Может он обычно поставляет материалы, но иногда может поставлять услуги, или наоборот. А контрольный счёт в его карточке только один. Перед проводкой на счёт менять контрольный счёт в карточке – этот вариант глуп, хотя и может быть использован в исключительных случаях.

В настройках SPRO список альтернативных счетов ведётся в ракурсе ведения V_THKON, при этом флаг разрешения альтернативного счёта должен быть также задан и в свойствах самого счёта главной книги.

Но какой именно счёт ставить контрольным в конкретной карточке контрагента: любимый(по желанию бухгалтера) или более определённый ? Здесь возникает палка с двумя концами.

С одной стороны, при использовании “любимого” счёта, потребуется вести в настройках все возможные комбинации каждого контрольного с его альтернативными из группы. Максимальное число комбинаций равно N*(N-1), то есть при десяти счетах в группе потребуется ввести до девяноста их комбинаций. А если учитывать межгрупные связи, то прозрачность также не увеличивается. Можно ещё отметить, что этот справочник является настройкой, и поэтому конфигурируется через переносы из системы разработки.

С другой стороны, при использовании “определённого” счёта необходимо в проводках переключать этот счёт на требуемый в каждом конкретном случае (хотя пользователю можно немного помочь в этом расширениями). Но зато список альтернативных счетов выглядит гораздо понятней: только один контрольный счёт из группы (первый?) и остальные как альтернативные к нему. Тем не менее, такой подход не запрещает устанавливать для конкретного контрагента контрольным счет из списка альтернативных – просто другие счета не смогут быть использованы.

Что именно выбрать – уже зависит от особенностей внутреннего бухгалтерского учёта.

Разделение контрагентов по ролям

Как один из альтернативных вариантов можно применять разделение контрагентов.

Если придерживаться схемы “группа контрагентов => группа контрольных счетов”, то вполне допустимо ведение нескольких карточек контрагентов, которые выполняют совершенно разные функции. Например: сотрудник как подотчётное лицо, и сотрудник как покупатель. Такое разделение ещё более допустимо, если учитывать, что такие операции, как правило, обслуживаются разными бухгалтерами или даже разными подразделениями бухгалтерского учёта. Таким образом устраняются связи по альтернативным счетам между группами счетов.

Зачетные операции между такими задолженностями одного контрагента следует проводить только на основании первичных документов (писем, заявлений), как и в случае “взаимозачёта”.

Разрабатывая отчетики на базе ALV можно также обратить внимание на дополнительные аспекты – не всегда простой таблицы бывает достаточно, а рисовать свои экраны не сильно тянет.

Если покопаться в примерах, то можно найти несколько полезных вариантов.

Одна оговорка: в данном случае ALV представлено не своим красивым элементом управления, а ABAP-списком. В стандарте очень много отчётов строятся похожим образом.

 

Иерархический просмотр master-detail

Пример можно найти в программе BALVHD01.

Этот отчёт строится на базе функционального модуля REUSE_ALV_HIERSEQ_LIST_DISPLAY.

Основная ALV функциональность присутствует: управление вариантами, сортировки, суммы, группировки, фильтр и прочее.

Иерархичность тут не полная, а всего лишь отношение master-detail, чего в большинстве случаев может и хватить, так как покрывает стандартные отношения типа “заголовок документа – позиции документа”.

Ко всему прочему, такой вывод поддерживает многострочность одной строки (до трёх строк), что позволяет упаковать больше данных по ширине экрана.

Несколько независимых таблиц

Пример можно обнаружить в программе BALVBT01.

Такой вариант реализуется на базе функциональных модулей REUSE_ALV_BLOCK_LIST_INIT, REUSE_ALV_BLOCK_LIST_APPEND, REUSE_ALV_BLOCK_LIST_HS_APPEND, REUSE_ALV_BLOCK_LIST_DISPLAY.

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

Таким образом можно представить несколько независимых наборов данных, с сохранением основной функциональности ALV в рамках отдельных таблиц.