ISergiv написал(а):
Когда-то в 2018 разбирал соответствующие методы, определяющие даты для RUDAT, обнаружил там вызов функции ядра, которая определяла является ли дата рабочим днем. Поскольку это был не абап, понять принцип работы было затруднительно, но мне показалось, что этот фм анализирует недельный график рабочего времени и календарь праздничных дней. Вне зависимости от того стоял ли в конкретном календарном дне однодневный рабочий график или однодневный график выходного дня, система определяла его как рабочий день, вероятно на основе графика за период (недельного графика). Может быть вы разбирались более подробно и можете сказать какие необходимо сделать настройки в графике рабочего времени, чтобы система определила 22.02.2021 как выходной день.
Спасибо.
Производственный календарь (ПК) - это отдельная сущность. ПК никак не связан с графиками сотрудника в ИТ0007, для него не применимо понятие однодневного графика или графика работы на период (недельный график). Это просто календарный год, где указанны выходные и праздничные дни.
Ведется в SPRO отдельно (настройка, по моему, даже мандантонезависимая). Заходим в spro - Управление временными данными - Графики рабочего времени - Определение классов праздников.
Заходим, выбираем "производственный календарь", находим RU, открываем, заходим в особые правила и прописываем переносы выходных дней.
Затем для проверки заходим в режим календаря и проверяем, что 20.02.2021 - это рабочий день, а 22.02.2021 - выходной.
Реализация определения срока уплаты налога.
Определение дат дохода реализован через BADI, базовый класс реализации BADI - CL_HRPAYRU_IM_PAYDATES. в нем есть метод GET_NEXT_BUSINESS_DAY, который собственно и реализует определение следующего рабочего дня. На данный момент реализация строиться на использовании класса производственного календаря - cl_timecalendar_generic, где реализуется интерфейс IF_TIMECALENDAR.
Здесь есть метод IF_TIMECALENDAR~MOVE_DAYS, где происходит сдвиг.
Если копать глубже, то действительно можно найти вызовы фукнции, реализованных не на ABAP. Но лично у меня никогда не было необходимости копать так глубоко.