… а лучше оно потому, что если его придерживаться, то порядок увеличивается, а беспорядок уменьшается.

С практической точки зрения порядок можно увеличивать до момента, когда он уже начинает вредить “поворотливости”.

(далее…)

В плане контрольных счетов у 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 в рамках отдельных таблиц.

Просто к слову вспомнили задачку для начинающих.

Есть переменные A и B – целые числа.

Требуется поменять их местами, не прибегая к помощи других переменных и специальных методов. Перекладываю на язык ABAP:

Вот и требуется вписать в серединку несколько строчек.

Ответ давать и не буду, задачка решается и в уме.

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

Как и в любой около-денежной системе в SAP есть справочник валют.

Сделал небольшой отчётик по курсам валют:

Пару минут втуплял, что же за такая непредусмотренная колонка “Всего”, и откуда в ней ещё какое-то маленькое значение.

 

(далее…)

Вообще подход к двоеточиям и запятым в ABAP достаточно странный (если сравнивать с другими языками программирования). И я, как правило, использовал его или для определения данных DATA, или в операторах write.

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

Первый, второй и третий блоки выполняют одинаковое действие.

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

С одной стороны администратор – это человек которому ничего не говорят транзакции и объекты бизнес-процессов, а с другой стороны консультанты и пользователи ничего не смыслят в базисе и программировании.

Есть несколько разных способов, пригодных для решения этой проблемы.

Самое главное – это выбрать достаточно точные шаги по многоразовому воспроизведению проблемы.

Один из основных – это динамический анализ (транзакция SE30).

(далее…)

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

Пользователь начинает переживать, а не зависла ли программа, а также сколько времени ещё ждать. Иногда начинает бояться, что программа упадёт с ошибкой по таймауту.

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

Этот индикатор можно вызвать и самому – функциональный модуль SAPGUI_PROGRESS_INDICATOR, в котором нет ничего сложного – передаётся рассчитанный процент и текст.

Маленькая тонкость: если вызывать его слишком часто, то:

• Обновляется некрасиво и неразборчиво
• Увеличивается обмен информацией между клиентом и сервером

(далее…)

Переодически забываю этот метод. Запишу себе в блокнотик, чтоб не забывать.

Транзакция: se80

Класс: CL_EXITHANDLER

Метод: GET_INSTANCE

Точка прерывания: на первой строке CALL METHOD cl_exithandler=>get_class_name_by_interface

Имя искомого BADI: в переменной exit_name

Ставится точка прерывания и запускается нужная транзакция. В переменной exit_name будут всплывать имена подключаемых BADI.