Про курсы не знаю, может что-то свежее есть. Раньше мне нормальных материалов не попадалось.
Есть вопрос о целесообразности "создания своих собственных отчетов на базе стандартных DAQ-полей".
А зачем?
Собственная разработка должна быть, прежде всего, легко поддерживаемой.
Использование DAQ не даст преимуществ в скорости разработки. Заморочь еще та.
Если есть надежда использовать что-то из кучи стандартных ФМов, использующихся в DAQ-поля стандартных отчетов, то напрасно. Да, много ФМов есть. Пока разберетесь с ними, уже 20 раз всё можно разработать с нуля.
Если хотите использовать настройку HRPAYRUT7RUN для чтения результатов ЗП - это неплохая идея. Но для этого не обязательно юзать дак. Для этого достаточно использовать CL_HRPAYRU_PLTAXRUN без лишних наворотов.
Но и тут не всё гладко, т.к. используя CL_HRPAYRU_PLTAXRUN, бывает непросто понять, почему по коду дохода собралась именно такая сумму. Обычно эта сумма верная, но доказать пользователю трудно, т.к. суммы собираются только в разрезе периодов и кодов дохода (ни табельного, ни seqnr, ничего нет). Если заказчик недоволен суммой по БЕ, разбираться можно долго.
Зачастую, проще написать очень несложный отчет с подробнейшей расшифровкой собранных сумм.
С другой стороны, понимать дак полезно, чтобы решать инциденты со стандартными программами.
Посмотрите, как устроены стандартные программы. Например, 4-ФСС. Потом РСВ-1. Код 6-НДФЛ лучше не смотреть
Всё не просто, но поддаётся.
А еще в коде вы увидите, что в этих отчетах не всё решается DAQ, а кое-где имеется обычный хардкод. Т.е. дак - это конечно круто, но больше в теории, чем на практике.