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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(далее…)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(далее…)

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

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

(далее…)

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

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

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

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

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

(далее…)