Эксель имеет большое количество сфер применения. Владеть им в рамках необходимости очень рекомендуется. Сферы применения мне видятся такими:
Шаманство вокруг поздней активации сплиттинга
Вот в одной конторе есть ситуация с поздней активацией сплиттинга.
Открытые позиции, созданные с момента активации отказываются выравниваться: говорит, что GLT0002 и хоть трава не расти.
Методов несколько.
Наиболее цивилизованным (вроде бы) является процедура миграции, там есть определённый сценарий "Subsequent Implementation of Document Splitting". Инструмент миграции (будто бы) является особой услугой – но на сайте как-то невнятно всё написано. Сами пумпочки этой функциональности в SPRO по этому поводу начинают спрашивать какие-то лицензии. Боязливо ввязываться в такие действа. А мне-то хотелось всего лишь самому кнопочки понажимать…
Самым нецивилизованным способом является ручное струяченье записей сплиттинга в соответствующую таблицу. Тоже боязливо – за изменение таблиц SAP.
В качестве баланса между ними можно использовать метод, в котором запускаются поочерёдно три волшебные служебные программы в SA38.
Простые документы нормально обработались, но вот один из них споткнулся с расстройством настроек по сплиттингу. По счетам ГК – платёж, а по виду документа – фактура. Система встала в позу, и я её хорошо понимаю.
Так что потребовалось изменить настройки, прогнать документ, вернуть настройки обратно.
Каждый документ пропихивать вручную – сомнительное удовольствие, но требуется ли писать мега-программу (впрочем простую и небольшую), вызывающую три волшебных программы, особенно с учётом возможных раскоряков по настройкам… ?
Дату активации сплиттинга в продуктивной системе, так сложилось, что никто точно не знает. Забавен быстрый способ по которому это дело можно посмотреть… Узнаём имя ракурса, по которым проходит такая настройка, затем в системе настройки в служебной таблице ищем запросы, связанные с этим ракурсом. Осталось по журналам транспортной системы посмотреть дату импорта запроса.
С полученной датой активации можно отфильтровать таблицы открытых позиций контрагентов по полю CPUDT для пущей надёжности.
Получено число порядка четырёх сотен. Это не много, но и не мало…
Проводки между филиалами – БЕ против БС
Видел несколько вариантов реализаций большой организации с филиалами:
- Несколько балансовых единиц
- Только одна балансовая единица и несколько бизнес-сфер
Я для себя дилемму решаю таким образом – разные юридические лица должны иметь разные БЕ.
Прокси-сервер в ABAP
Если вы из программы на ABAP пытаетесь получить веб-контент через HTTP, то соединение будет производиться не с компьютера клиента, а с сервера приложений. В зависимости от конфигурации локальной сети вам может понадобиться пробираться через прокси-сервер (иначе потребуется прямая видимость сервера или NAT).
При оформлении HTTP запроса можно непосредственно указать прокси-сервер:
Однако здесь есть пара моментов. Во-первых: “прошитость” настройки в коде (не приветствуется), а во-вторых: нет авторизации.
Глобальную настройку HTTP-прокси можно обнаружить в транзакции SM59:
И там уже в появившемся окошечке можно указать не только сервер/порт, но также и логин/пароль для авторизации.
Почему исходники ABAP в скриншотах
Если вы тут регулярно посматриваете, то могли заметить, что основная масса исходного кода показана скриншотами. Это не защита от копирования. Связано это с тем, что инструменты для публикации иногда очень вольно могут коверкать эти исходники (не только при подготовке публикации, но и потом — при редактировании).
Инструмент может и строки склеивать, и пробелы лидирующие для "лесенки" убирать, и цветовая разметка страдать — это всё требует подхода, имеет нюансы и даже требует владения HTML.
Много раз видел побитые таким образом исходники на ресурсах типа SDN и иже с ними. Очень расстраивает.
Скриншоты же делаются проще, и с ними почти ничего не происходит — и голова не болит. Если вдруг подберу удачный инструмент или подход — то ситуация изменится.
Проверки при создании контрагента
Если мы создаём контрагента(дебитора/кредитора) в системе, то к нему очень рекомендуется делать базовые проверки, для контроля.
Самая примитивная проверка – проверка на дублирование через уникальный налоговый номер (ИНН, РНН …). Обычно для этого используется поле типа STCD1.
Для реализации у нас есть в CMOD пара очень тривиальных расширений:
SAPMF02D — Программы пользователя: основные данные дебиторов
SAPMF02K — Программы пользователей: основные данные кредиторов
Вот примерный кусок кода (для кредиторов) который нужно вставить:
Надеюсь в этом коде даже объяснять ничего не надо…
Для дебиторов – почти то же самое, только имена полей/таблиц чуточку подправить…
Сумма прописью. Нюанс
Есть совершенно несекретный функциональный модуль SPELL_AMOUNT, который позволяет получить необходимую для печатных вещей “сумму прописью”:
Методом проб было найдено, что для рублей пишутся слова “ХХ копеек”, хотя для остальных валют подобного эффекта не наблюдается.
Мелкие трюки в кассовой книге
Стандартная кассовая книга хоть и хороша собой, однако имеет ряд нюансов:
- Нет возможности управлять нумерацией создаваемых документов
- Нет возможности заместить печатную форму
- Имеется ненужная пользователю вкладка “Поступления чеков”
- Нет возможности менять контрольный счёт контрагента на альтернативный
Кэширование данных отчёта – тривиальная реализация
Предположим, что у нас есть отчёт в виде Z-разработки.
Кэширование данных отчёта нам может пригодиться в нескольких случаях, например:
- Отчёт часто требуется, но долго выполняется; при этом от результатов особой оперативности не требуется;
- Результат выполнения данного отчёта требуется отразить в другом отчёте (сводном); но при этом рассчитывать в сводном отчёте множество под-отчётов не хочется;
Для начала допустим, что:
- отчёт имеет простые и стабильные параметры;
- процедуры сбора и показа данных строго разделены;
- данные отчёта находятся в одной внутренней таблице.
Удивительные алгоритмы
Бороздя просторы своих подписок, наткнулся между делом на нечто. В чём суть этого бессмысленного и беспощадного ненормального приёма программирования:
Требуется выполнить деление двух целых чисел с точностью до четырёх знаков после запятой, но используя только оператор простой замены подстроки.
В качестве базового алгоритма использован Нормальный Алгоритм Маркова, который можно реализовать на любом языке программирования. Входные значения – унарные числа.
Обуреваемый скептицизмом, решил переложить на язык ABAP.
Реально работает!
Пример кода выложил отдельно в виде SLNK.