Шаманство вокруг поздней активации сплиттинга

Вот в одной конторе есть ситуация с поздней активацией сплиттинга.

Открытые позиции, созданные с момента активации отказываются выравниваться: говорит, что GLT0002 и хоть трава не расти.

Методов несколько.

Наиболее цивилизованным (вроде бы) является процедура миграции, там есть определённый сценарий "Subsequent Implementation of Document Splitting". Инструмент миграции (будто бы) является особой услугой – но на сайте как-то невнятно всё написано. Сами пумпочки этой функциональности в SPRO по этому поводу начинают спрашивать какие-то лицензии.  Боязливо ввязываться в такие действа. А мне-то хотелось всего лишь самому кнопочки понажимать…

Самым нецивилизованным способом является ручное струяченье записей сплиттинга в соответствующую таблицу. Тоже боязливо – за изменение таблиц SAP.

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

Простые документы нормально обработались, но вот один из них споткнулся с расстройством настроек по сплиттингу. По счетам ГК – платёж, а по виду документа – фактура. Система встала в позу, и я её хорошо понимаю.

Так что потребовалось изменить настройки, прогнать документ, вернуть настройки обратно.

Каждый документ пропихивать вручную – сомнительное удовольствие, но требуется ли писать мега-программу (впрочем простую и небольшую), вызывающую три волшебных программы, особенно с учётом возможных раскоряков по настройкам… ?

Дату активации сплиттинга в продуктивной системе, так сложилось, что никто точно не знает. Забавен быстрый способ по которому это дело можно посмотреть… Узнаём имя ракурса, по которым проходит такая настройка, затем в системе настройки в служебной таблице ищем запросы, связанные с этим ракурсом. Осталось по журналам транспортной системы посмотреть дату импорта запроса.

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

Получено число порядка четырёх сотен. Это не много, но и не мало…

Проводки между филиалами – БЕ против БС

Видел несколько вариантов реализаций большой организации с филиалами:

  • Несколько балансовых единиц
  • Только одна балансовая единица и несколько бизнес-сфер 

Я для себя дилемму решаю таким образом – разные юридические лица должны иметь разные БЕ.

(далее…)

Прокси-сервер в ABAP

Если вы из программы на ABAP пытаетесь получить веб-контент через HTTP, то соединение будет производиться не с компьютера клиента, а с сервера приложений. В зависимости от конфигурации локальной сети вам может понадобиться пробираться через прокси-сервер (иначе потребуется прямая видимость сервера или NAT).

При оформлении HTTP запроса можно непосредственно указать прокси-сервер:

Пример вызова HTTP

Однако здесь есть пара моментов. Во-первых: “прошитость” настройки в коде (не приветствуется), а во-вторых: нет авторизации.

Глобальную настройку HTTP-прокси можно обнаружить в транзакции SM59:

Прокси в транзакции SM59

И там уже в появившемся окошечке можно указать не только сервер/порт, но также и логин/пароль для авторизации.

Почему исходники ABAP в скриншотах

Если вы тут регулярно посматриваете, то могли заметить, что основная масса исходного кода показана скриншотами. Это не защита от копирования. Связано это с тем, что инструменты для публикации иногда очень вольно могут коверкать эти исходники (не только при подготовке публикации, но и потом — при редактировании).

Инструмент может и строки склеивать, и пробелы лидирующие для "лесенки" убирать, и цветовая разметка страдать — это всё требует подхода, имеет нюансы и даже требует владения HTML.

Много раз видел побитые таким образом исходники на ресурсах типа SDN и иже с ними. Очень расстраивает.

Скриншоты же делаются проще, и с ними почти ничего не происходит — и голова не болит. Если вдруг подберу удачный инструмент или подход — то ситуация изменится.

Проверки при создании контрагента

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

Самая примитивная проверка – проверка на дублирование через уникальный налоговый номер (ИНН, РНН …). Обычно для этого используется поле типа STCD1.

Для реализации у нас есть в CMOD пара очень тривиальных расширений:

SAPMF02D — Программы пользователя: основные данные дебиторов
SAPMF02K — Программы пользователей: основные данные кредиторов

Вот примерный кусок кода (для кредиторов) который нужно вставить:

Пример расширения проверки

Надеюсь в этом коде даже объяснять ничего не надо…

Для дебиторов – почти то же самое, только имена полей/таблиц чуточку подправить…

Сумма прописью. Нюанс

Есть совершенно несекретный функциональный модуль SPELL_AMOUNT, который позволяет получить необходимую для печатных вещей “сумму прописью”:

Пример вызова SPELL_AMOUNT

Методом проб было найдено, что для рублей пишутся слова “ХХ копеек”, хотя для остальных валют подобного эффекта не наблюдается.

(далее…)

Мелкие трюки в кассовой книге

Стандартная кассовая книга хоть и хороша собой, однако имеет ряд нюансов:

  1. Нет возможности управлять нумерацией создаваемых документов
  2. Нет возможности заместить печатную форму
  3. Имеется ненужная пользователю вкладка “Поступления чеков”
  4. Нет возможности менять контрольный счёт контрагента на альтернативный

(далее…)

Кэширование данных отчёта – тривиальная реализация

Предположим, что у нас есть отчёт в виде Z-разработки.

Кэширование данных отчёта нам может пригодиться в нескольких случаях, например:

  1. Отчёт часто требуется, но долго выполняется; при этом от результатов особой оперативности не требуется;
  2. Результат выполнения данного отчёта требуется отразить в другом отчёте (сводном); но при этом рассчитывать в сводном отчёте множество под-отчётов не хочется;

Для начала допустим, что:

  • отчёт имеет простые и стабильные параметры;
  • процедуры сбора и показа данных строго разделены;
  • данные отчёта находятся в одной внутренней таблице.

(далее…)

Удивительные алгоритмы

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

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

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

Обуреваемый скептицизмом, решил переложить на язык ABAP.

Реально работает!

Результат алгоритма Маркова

Пример кода выложил отдельно в виде SLNK.