Расчетные механизмы являются наиболее сложным функционалом в платформе «1С:Предприятие 8». Именно на расчетных задачах больше всего «сыпятся» на Аттестации 1С:Специалист по платформе. Причем не из-за вредности преподавателей, а из-за множества нюансов.
Поэтому мы периодически будем публиковать статьи, посвященных расчетным механизмам платформы «1С:Предприятие».
Прежде чем браться за решение задач по расчету зарплаты, нужно понимать теорию – её изучением и займемся в текущей статье.
Технология реализации расчетных задач
Что Вы узнаете из этой статьи?
- Термины и определения, которые лежат в основе расчетных механизмов платформы «1С:Предприятие 8»
- Виды связей между расчетами, которые возникают в процессе автоматизации бизнес-процессов.
- Применение механизма сложных периодических расчетов.
В расчетах существует своя терминология. Поэтому начнем с того, что введем базовые определения.
Периодичность расчетов
Данные о расчетах в системе «1С:Предприятие» регистрируются в виде записей (упрощенно говоря, совокупности значимых полей) с определенной периодичностью в специальных объектах – Регистрах расчета (подробнее рассмотрим этот объект и его назначение ниже).
Периодичность регистрации записей определяется условиями задачи и представляет собой дискретный интервал времени – период расчета, за который требуется производить анализ учета.
Например, учет зарплаты на предприятиях обычно ведется помесячно. То есть анализ начислений и удержаний, планирование ФОТ (фонд оплаты труда) может осуществляться и за другие периоды – квартал, полугодие, год, но главная задача ведения взаиморасчетов с сотрудниками решается в рамках месяца, поэтому период расчета в рамках этой задачи вероятней всего будет месяц.
Регистрация записи происходит с обязательным указанием вида расчета и периода регистрации.
Период регистрации
Период регистрации – это конкретный период расчета, в котором зарегистрирована запись. В системе «1С:Предприятие» в зависимости от задачи период регистрации может принимать одно из 4 значений: день, месяц, квартал или год. Например, при ежемесячном расчете зарплаты, начисления могут быть отнесены к периоду регистрации следующим образом:
В данном случае оклад и командировка были начислены в феврале, поэтому и период регистрации у обоих начислений – февраль.
Вообще, расчет некоторых начислений часто осуществляется заранее, до момента их наступления. То есть это обычная ситуация, когда, например, командировка происходит в марте, а рассчитывается в феврале (см. рис. 2).
Важно понять, что периодом регистрации командировки будет именно тот месяц, в котором она начислена. Несмотря на то, что фактически командировка будет в марте, ее расчет и начисление произошли в феврале. То есть в этом случае период регистрации командировки – 01.02.
Вид расчета
Вид расчета – это объект, который содержит алгоритм расчета записи. Например, в контексте задач по расчету заработной платы вид расчета описывает способ расчета оплаты труда. Также в виде расчета могут храниться важные сведения для учета, напрямую не связанные с расчетом, например – способ отражения зарплаты в бухучете.
Упрощая, можно сказать, что вид расчета – это «кирпичик», из которого формируются начисления и удержания сотрудника. Примеры видов расчетов: оплата по окладу, оплата за работу в ночные часы, расчет по больничному листу, расчет отпуска, удержание за прогул. Причем последний вид расчета влияет на зарплату отрицательно, то есть уменьшает ее.
Период действия записи
Записи, участвующие в расчетах, могут как быть, так и не быть протяженными во времени. Что это значит?
Дело в том, что для расчета часто необходимо знать его длительность. Например, для отражения больничного листа сотрудника важно оперировать информацией, когда он был открыт и когда закрыт (иначе говоря это «с… по…») – ведь от этого зависит сумма выплаты сотруднику. В то же время для расчета алиментов или регистрации штрафа совершенно не важна протяженность, важно знать лишь период расчета, когда это событие имело место. Так вот, интервал, в течение которого длится протяженная во времени запись, называется периодом действия данной записи.
Период действия имеет ряд особенностей.
В отличие от периода регистрации, период действия записи задается датой начала и датой окончания.
Например, факт болезни сотрудника с 11.02 по 20.02 можно представить следующим образом.
В этом случае запись «больничный» будет иметь период действия 11.02 – 20.02 и период регистрации 01.02.
Иначе говоря, период действия записи представляет собой один интервал времени, у одной записи не может быть два и более периодов действия, у протяженной во времени записи он всегда один. К примеру, если сотрудник дважды за месяц был в командировке, то такое состояние отражается не одной, а двумя записями, каждая из которых имеет свой период действия (см. рис. 5).
Например, необходимо отразить больничный сотрудника с 10.02 по 15.03. Учет зарплаты ведется помесячно (то есть период расчетов – месяц). Что будет, если запись «Больничный» мы отразим одной записью с периодом действия 10.02 – 15.03?
На первый взгляд, ничего не произошло. А теперь попробуем ответить на вопрос: к какому периоду расчетов принадлежит эта запись? Проще говоря, какой у нее будет период регистрации?
Очевидно, что у одной записи не может быть два разных периода регистрации, иначе нельзя сказать, к какому периоду расчетов она относится (к февралю или к марту). Поэтому, если событие пересекает несколько расчетных периодов, то такую запись требуется разбить на несколько записей, каждая из которых будет иметь свой период действия, лежащий в рамках одного периода расчетов.
При этом “месяц” периода расчетов (для помесячного расчета зарплаты) не обязательно должен совпадать с месяцем периода действия, они могут быть равны, а могут быть разными – все будет зависеть от момента регистрации факта события. Именно тогда можно однозначно идентифицировать запись.
Для нашего примера предполагаем, что больничный лист сотрудник предъявил в марте. Поэтому, регистрируя больничный сотрудника, получим две записи: первая запись с периодом регистрации 01.03 и периодом действия 10.02 – 28.02, вторая запись с периодом регистрации 01.03 и периодом действия 01.03 – 15.03.
Как видим, у первой записи месяц периода расчетов не совпадает с месяцем периода регистрации (см. рис. 6).
Период действия записи может лежать как в прошлом, так и в будущем относительно периода регистрации.
Например, начисление за предстоящую в марте командировку происходит феврале. В этом случае период регистрации записи будет 01.02, несмотря на то, что период действия записи лежит в марте.
Обратная ситуация возможна, когда сотрудник болел в январе, а оформленный больничный лист принес в феврале. Тогда период регистрации записи – 01.02, период действия принадлежит январю, то есть больничный будет начислен в феврале, так как за январь зарплата уже начислена. (см. схему ниже).
Вытеснение по периоду действия
Некоторые протяженные во времени расчеты не могут действовать в один и тот же период времени. Это происходит, когда расчеты являются взаимоисключающими.
Например, виды расчета оклад и больничный не могут действовать в одном и том же промежутке времени, так как сотрудник не может работать по основному месту и находиться на больничном одновременно. При вводе записи о больничном за период, который пересекается с периодом действия записи оклад на определенном интервале, виды расчета будут конкурировать между собой за период действия этого интервала (см. рис. 8).
В результате такой конкуренции должно быть исключено действие оклада на этом интервале, так как эти записи не могут действовать одновременно. Виды расчетов, которые исключают действие записей других видов расчетов, называют вытесняющими.
Что происходит при вытеснении одних записей другими? На что, собственно, влияет вытеснение?
Дело в том, что любая протяженная во времени запись, помимо периода действия, имеет так называемый фактический период действия, и именно на него оказывает влияние вытеснение. То есть при вытеснении период действия вытесняемой записи не изменяется. В общем случае фактический период действия записи – это совокупность интервалов, на котором запись действует с учетом всех вытеснений.
Рассмотрим формирование фактического периода действия записей из приведенного выше примера.
Ключевые моменты формирования фактического периода действия:
- До вытеснения фактический период действия записи «Оклад» содержал один интервал 01.02 – 28.02, который совпадал с периодом действия.
- При вводе записи о больничном виды расчета «Оклад» и «Больничный» конкурируют между собой за период действия 11.02 – 20.02.
- В результате конкуренции видов расчетов произошло разбиение фактического периода действия записи «Оклад» на два интервала: 01.02 – 11.02 и 20.02 – 28.02. Механизмы вытеснения не оказывают влияния на периоды действия записей конкурирующих видов расчетов, изменения происходят на уровне фактического периода действия.
- Фактический период действия записи «Больничный» представляет собой один интервал: 11.02 – 20.02, который совпадает с периодом действия.
Необходимо учитывать, что в «1С:Предприятие» конкуренция и последующее вытеснение возможно, только когда вытесняющие записи вводятся в текущем или будущем периоде расчетов. То есть период регистрации вытесняющего вида расчета должен быть либо равен, либо меньше периода вытесняемой записи. Такая особенность системы связана с тем, что записи с меньшим периодом регистрации всегда имеют приоритет перед записями с большим периодом.
Например, больничный, введенный в марте за февраль, не сможет конкурировать за период действия с окладом. Его фактический период действия на интервале периода действия будет пустым, потому что записи не могут действовать одновременно, а вытеснение «задним числом» работать не будет (см. рис. 10).
Однако такие случаи очень распространены в реальном учете, и в системе существует решение. Для того, чтобы больничный имел не пустой фактический период, необходимо применить механизм сторнирования. Сторнирование – это довольно сложный процесс, в нем существуют свои нюансы, и его разбор – это тема отдельной статьи.
Зависимость по базовому периоду
Иногда требуется, чтобы расчет одной записи зависел от расчета других записей. Например, премия может рассчитываться как процент от начисленного за предыдущие три месяца оклада. В таком случае говорят, что оклад входит в базу расчета премии, а вид расчета «Оклад» является базовым по отношению к виду расчета «Премия».
Один вид расчета может иметь несколько базовых видов расчета. При зависимости по базовому периоду происходит анализ сумм базовых видов расчета за определенный период, который называют базовым периодом.
В общем случае базовый период представляет собой интервал, который может покрывать несколько периодов расчета. В нашем примере базовым периодом для расчета премии будут три месяца, ей предшествующие (см. рис. 11).
Продолжим наш пример расчетом премии. Для этого определим величины оклада и процент премии.
Пусть у некоторого сотрудника оклад распределился следующим образом: Январь – 15 000 р., Февраль – 21 000 р., Март – 20 000 р. Процент премии равен 10%. Стало известно, что в феврале у сотрудника был штраф в размере 5 000 р., и его также нужно учесть при расчете премии, то есть в базу расчета премии входят оклад и штраф. Соответственно, виды расчета «Оклад» и «Штраф» являются базовыми по отношению к виду расчета «Премия» (см. рис. 12).
Все необходимые данные определены, переходим к расчету. Первым делом рассчитаем базу премии. В нашем случае база расчета премии составляет 51 000 рублей и состоит из суммы начислений по окладу за 3 месяца и начисленного в феврале штрафа (уменьшает базу):
Исходя из полученной базы, произведем расчет премии в соответствии с алгоритмом расчета:
Итак, размер премии рассчитан, он составляет 5 100 р.
Ключевые моменты произведенного расчета:
- При расчете результата зависимости по базовому периоду анализируются суммы базовых видов расчетов за определенный период, который называется базовым.
- Базовый период может покрывать несколько расчетных периодов. Он не обязательно кратен периодам расчета, его интервал может быть задан произвольно, например, он может быть определен как 15.02 – 15.03, 25.01 – 01.04 и т.д.
- Суммы всех базовых видов расчета, попавших в базовый период, образуют расчетный показатель – базу. Вхождение вида расчета не всегда увеличивает базу, в нашем случае штраф – это удержание, его вхождение уменьшает базу.
- Расчет по базовому периоду может быть реализован для всех видов расчетов – как для протяженных во времени (с периодом действия), так и для непротяженных во времени. В нашем примере премия не имеет периода действия, хотя базовый период у нее определен и равен трем предшествующим месяцам.
Итак, мы познакомились с основными терминами расчетов. Этой теории вполне достаточно, чтобы понять назначение и функциональность расчетных объектов (об них речь пойдет ниже). Однако, прежде чем переходить к рассмотрению самих объектов, необходимо определить применение механизма сложных периодических расчетов.
Наверняка вы уже заметили, что при описании основных определений расчетов повсеместно употребляется слово «период». Это ключевое слово в расчетных задачах. В отличие от задач бухгалтерского и оперативного учета, в них нет привязки к определенному моменту времени. События расчетов характеризуют период в целом.
В таких задачах, как расчет зарплаты, арендной платы и т.д. всегда есть некий период, к которому будет относиться полученный результат. Соответственно, это накладывает ограничение на применение механизма для автоматизации бизнес-процессов.
Применение механизма сложных периодических расчетов
Наибольшее распространение механизм сложных периодических расчетов получил в прикладных решениях, обеспечивающих расчет заработной платы, однако круг решаемых задач с его использованием значительно шире. Этот механизм может использоваться для автоматизации бизнес-процессов, где присутствуют следующие критерии:
- Периодичность. Выполнение расчетов через определенные промежутки времени. Например, расчет аренды помещений, автомобилей.
- Сложный расчет. Необходимость настройки взаимосвязи между расчетами, влияние одних видов расчетов на другие. В качестве примера можно привести задачи расчета жилищно-коммунальных услуг.
- Хранение результатов расчета. Хранение как произведенных, так и промежуточных и предстоящих расчетов, по периодам расчета и требуемым разрезам аналитики.
Общая схема решения большинства задач с использованием механизма сложных периодических расчетов может быть представлена так:
Как видно из схемы, решение расчетных задач не ограничивается использованием только «расчетных» объектов.
В справочниках обычно хранят данные объектов, определяющих разрезы, в которых следует выполнять расчет (например, справочники «Организации», «Физические Лица») или описывается дополнительная аналитика расчета (например, справочник «Статьи расходов»).
В регистрах сведений зачастую хранят изменяющуюся с течением времени информацию, необходимую для расчета, например, величину окладов, размер арендной платы.
Регистры накопления могут отвечать за оборотные данные, вспомогательные для расчета (хранить информацию о сдельных работах или отработанном времени, яркий пример – подсистема «Табельный учет» в типовой конфигурации ЗУП 3-й редакции).
Документы могут выступать как объект, регистрирующий первичную информацию, необходимую для расчета, так и как объект, который фиксирует промежуточный или конечный расчет (например, документ «Начисление зарплаты и взносов»).
Отчеты используются как средства представления пользователю результатов расчетов, с возможностью настройки и отбора по требуемым разрезам или аналитикам
Хочется отметить, что разделение на схеме объектов метаданных по контурам (НСИ, первичные данные, алгоритмы расчета) является условным и в зависимости от контекста задачи может меняться.
Например, в типовом решении ЗУП 3.1 регистр сведений «Графики работы по видам времени» носит смешанный характер. С одной стороны, он хранит эталонные графики работы (базовая НСИ), назначенные сотрудникам, с другой – при окончательном расчете зарплаты в него пишется фактический график, по которому работал сотрудник, если в течении месяца у него были отклонения от эталона.
Напоследок хочется отметить, что на практике множество задач и бизнес-процессов любых предприятий связаны с расчетами разной сложности, однако не всегда в них имеет смысл использовать механизм сложных периодических расчетов.
Более того, подавляющее большинство из них прекрасно решаются с использованием других объектов (регистров накопления, регистров сведения) и механизмов. Это такие задачи, как расчет себестоимости, расчет нормы рентабельности, расчет прибыли по заказу и т.д. Поэтому использование механизма сложных периодических расчетов должно быть обосновано как минимум следующими критериями:
- Сложный расчет. Под сложным расчетом понимается не просто сложный алгоритм или последовательность формул, под сложным расчетом понимается необходимость использования механизмов вытеснения, зависимости по базовому периоду, перерасчета.
- Периодичность. Расчет производится с определенной периодичностью, за которую, как правило, важно анализировать результат расчета.
P. S.
Если вам интересна тема, касающаяся механизма сложных периодических расчетов, то напишите в комментарии:
- О каких компонентах механизма вам хотелось бы в первую очередь узнать?
- Какие моменты задач для подготовки к экзамену «1С:Специалист по платформе» было бы хорошо осветить?
Об авторе
Автор статьи – Дмитрий Игоревич Макаревич
УК “Содружество”, г. Калининград
E-mail: mitia.mackarevich@yandex.ru
Здравствуйте, получается, что на рисунке 7 больничный лист, который записан на 1.02 не вытеснит оклад за январь. Исходя из:
“Необходимо учитывать, что в «1С:Предприятие» конкуренция и последующее вытеснение возможно, только когда вытесняющие записи вводятся в текущем или будущем периоде расчетов. То есть период регистрации вытесняющего вида расчета должен быть либо равен, либо меньше периода вытесняемой записи. Такая особенность системы связана с тем, что записи с меньшим периодом регистрации всегда имеют приоритет перед записями с большим периодом.”
Добрый день! Да верно, вытеснение не сработает, т.к. у больничного период регистрации больше чем у вытесняемой записи по окладу. В таком случае применяется сторнирование, т.е. выполняется отмена записи по окладу и она становится неактуальной (если описать упрощенно), после этого запись по больничному может быть корректно отражена.
Добрый день. Немного запутался.
В статье говориться что нужно разбить период действия по периодам расчета, что бы у каждого периода был свой период регистрации. Но дальше вы двум этим периодам устанавливаете один и тот же период регистрации. Тогда зачем разбивать?
…
“На первый взгляд, ничего не произошло. А теперь попробуем ответить на вопрос: к какому периоду расчетов принадлежит эта запись? Проще говоря, какой у нее будет период регистрации?
Очевидно, что у одной записи не может быть два разных периода регистрации, иначе нельзя сказать, к какому периоду расчетов она относится (к февралю или к марту). Поэтому, если событие пересекает несколько расчетных периодов, то такую запись требуется разбить на несколько записей, каждая из которых будет иметь свой период действия, лежащий в рамках одного периода расчетов.”
“Для нашего примера предполагаем, что больничный лист сотрудник предъявил в марте. Поэтому, регистрируя больничный сотрудника, получим две записи: первая запись с периодом регистрации 01.03 и периодом действия 10.02 – 28.02, вторая запись с периодом регистрации 01.03 и периодом действия 01.03 – 15.03.”
Добрый день! В статье речь только о разбивке периода действия, который включает в себя несколько месяцев (период действия 10.02 – 15.03 разбивается на периоды: с 10.02 по 28.02 и с 01.03 по 15.03). “В статье говориться что нужно разбить период действия по периодам расчета, что бы у каждого периода был свой период регистрации” – здесь имеется в виду что одной записи нельзя назначить несколько периодов регистрации, например указать период действия 10.02 – 15.03 и назначить ей два периода регистрации (февраль и март) и это верно. Однако это объяснение не вполне точное, т.к. период регистрации у разделенных записей вполне может совпадать, по сути это отдельная сущность которая показывает в каком месяце мы отражаем в учете данную запись, а период действия – за какой период был выполнен расчет.
Подскажите ваш официальный сайт ? Где можно ознакомиться с программой курса ? Заранее спасибо
Здравствуйте, Наталья! Вы пишите нам с нашего официального сайта. Вот ссылка на полный каталог курсов https://курсы-по-1с.рф/courses/. Выбираете интересующие Вас курсы и по кнопке “Подробнее о курсе” переходите на страницу курса. Там можно ознакомиться с подробным описанием, примерами видео, стоимостью курса и оформить заказ.
Добрый день. подскажите пожалуйста по следующему вопросу.
Есть утверждение на счет получения базы по периоду регистрации:
“При этом у базовых начислений, которые имеют период действия, есть одна интересная особенность. База, полученная запросом, пересчитывается пропорционально вхождению периода регистрации (полный месяц) в базовый период. Например, если в базовый период включается только половина рабочих дней за месяц по данным графика, то база будет уменьшена на 50%. Однако это верно только при получении базы запросом, при объектной технике алгоритм такой же, как для базовых видов расчета без периода действия.”
Но на деле все работает совершенно по другому.
Если период действия базовой записи не перекрывается с базовым периодом, она попадает в базу полностью в том случае, если период регистрации базовой записи находится в том же периоде, что и базовый период (но не обязательно входит в него).
Если период действия перекрывается с базовым периодом, расчет базы происходит аналогично тому, если бы получение базы было бы по периоду действия а не пропорционально вхождению периода регистрации (полный месяц) в базовый период.
Объясните пожалуйста, с чем это может быть связано?
Я уже все перепроверил, но работает именно так.
Может быть существует разное поведение в зависимости от релиза платформы?
Добрый день!
Если базовые виды расчета имеют период действия (например оклад), то база по периоду регистрации определяется следующим образом: к периоду регистрации, который всегда равен началу расчетного периода (чаще всего месяцу), прибавляется месяц (периодичность регистра) и далее проверяется вхождение полученного периода в базовый период. При этом, если полученный интервал не включается в базу полностью, то база пересчитывается пропорционально вхождению периода регистрации (полный месяц) в базовый период. Например, для ПВР Удержания настроено получение базы по периоду регистрации, в качестве базового вида расчета используется Оклад. В этом случае, если базовый период будет равен полному месяцу (например 01.10 – 31.10) и период регистрации оклада совпадает с базовым периодом (01.10), то база будет равна полному значению оклада. Если базовый период будет меньше (например 15.10 – 31.10), то рассчитана пропорционально вхождению полного месяца (01.10 – 31.10) в базовый период (15.10 – 31.10). Соответственно если интервал записи по периоду регистрации (например 01.09 – 30.09) совсем не попадает в базовый период рассчитываемой записи (01.10 – 31.10), то в базу он включен не будет.
Да, должно быть именно так. Но проблема в том, что так не происходит. А происходит именно так, как я написал. У меня есть выгрузка, на которой это можно увидеть. Могу отправить на e-mail.
Да, выложите пожалуйста ссылку на базу на файлообменнике, самому интересно почему не работает
Выложил. Вот ссылка https://yadi.sk/d/Ie1MUgC1I1JD2g
Там начисление по пользователю Дима с 01 по 08. Компенсация введена с этим же периодом. В итоге в базу попадает полностью все начисление.
Если период регистрации базовой записи не падает в базовый период (относится к другому месяцу), то результат в базу не включается (как и ожидалось). Но если период регистрации относится к тому же месяцу что и базовый период, то далее уже проверяется отношение интервала периода действия (не полного месяца периода регистрации) базовой записи к базовому периоду и таким образом рассчитывается пропорция от полной суммы базы. Действительно, получается что отличие способа получения базы по периоду регистрации, только в том что еще дополнительно проверяется соответствие периода регистрации базовому периоду (месяцы совпадают). В документации описан другой алгоритм, в какой момент было измненено не ясно. Проверялось на 8.3.15
Добрый вечер. Спасибо за ответ. Есть еще один нюанс. Если базовый период в том же месяце что и период действия и не пересекается с ним – база попадает в полном объеме. Пропорция берется только в том случае, если периоды пересекаются. Как-то это на ошибку больше похоже. Вариант описанный в документации гораздо более логичный.
Да, действительно все так, согласен что такое поведение системы не выглядит логичным и даже похоже на баг
Добрый вечер. В комментарии к рисунку №1 приведено следующее: “Вообще, расчет некоторых начислений часто осуществляется заранее, до момента их наступления”. Получается , что расчет и начисление разнесены во времени. Наступление начислений – как это понять.
Добрый вечер! Это означает что начисление выполняется раньше чем происходит событие, например командировка, которая по периоду относится к ноябрю, может быть начислена в октябре. Возможно и обратная ситуация, когда начисление выполняется после того как событие уже произошло, например больничный лист за октябрь может быть начислен в ноябре.
“Вообще, расчет некоторых начислений часто осуществляется заранее, до момента их наступления. То есть это обычная ситуация, когда, например, командировка происходит в марте, а рассчитывается в феврале (см. рис. 2).” Если расчет происходит в феврале, то на рисунке №2 надо показать совокупность значимых полей. Не так ли?
Уточните пожалуйста что Вы имеете в виду под совокупностью значимых полей
Я имею ввиду совокупность полей регистра расчета, которые заполнены, что находит графическое отражение на рисунке 1, и не находит на рисунке 2. Например, из содержания рисунка № 1 можно сделать вывод, что произведена регистрация видов расчета “оклад” и “командировка” за февраль. Из комментария к рисунку №2 следует, что расчет и начисление вид расчета “командировка” произведено в феврале, значит синий прямоугольник должен располагаться в феврале, а не в марте, хотя фактически работник будет находится в командировке в марте.
На рисунках 1 и 2 по горизонтальной оси выведен период действия начисления, период регистрации при этом отражается в виде отдельной сноски. Так как на рисунке 1 период действия равен периоду регистрации, то можно сделать вывод что по горизонтальной оси отображается период регистрации (расчетный период), хотя на самом деле это период действия. Поэтому на рисунке 2 период действия командировки (март) отображается корректно, при этом есть сноска что период регистрации у этой записи отличается и равен 01.02
прекрасная статья. доходчиво и понятно и просто о сложном. было очень полезно
Добрый день, Анна. Благодарим за обратную связь! Рады помочь.
Спасибо!
Что значит аббревиатура НСИ (на рисунке 13 и ниже)
Нормативно-справочная информация
Здраствуйте! Каким образом вытесняет вид расчета внутрисменныйпрогул вида расчета оклад?
Добрый день!
Период действия можно указывать с точностью до времени, например для внутрисменного прогула можно указать интервал c 20.01.2020 10:00 по 20.01.2020 15:00. В этом случае вытеснение сработает нормально и интервал оклада будет разбит с учетом времени прогула, т.е. на 2 интервала: 01.01.2020 – 20.01.2020 09:59 и 20.01.2020 15:01 – 31.01.2020 23:59:59
“В качестве примера можно привести задачи расчета жилищно-коммунальных услуг.”
Я много видел (практически все) конфигурации для ЖКУ, и ни одна не построена на регистрах расчёта. Как думаете, почему?
Насколько мне известно, конфигурации по расчету ЖКУ базируются на базе БП. Вероятно разработчики решили, что рациональнее за основу взять БП, чем ЗУП, но ведь здесь и не говорится о том что для расчета ЖКУ нужно использовать только расчетные механизмы, это просто пример по возможному их использованию. Вообще привести реальный пример (не гипотетический) использования расчетных механизмов кроме как в расчете ЗП очень проблематично, например я в своей практике не встречал конфигураций где используются расчетные механизмы в других целях. Возможно одна из причин в том, что расчетные механизмы не популярны среди программистов и их стараются избегать по возможности.
“Базируются на основе БП” – это верно в той части, что расчетная часть ЖКХ пристыкована к типовой БП, но вполне может функционировать и без БП. Сами расчеты организованы на регистрах накопления, а не на проводках регистров бухгалтерии. И я тоже думаю, что использовать рег.накопления просто проще большинству программистов, хотя в расчетах ЖКХ понятия вытеснения и перерасчетов нужны постоянно, механизмы уже есть в платформе.
Ещё один, казалось бы, здравый аргумент, который я слышал, что регистры накопления работают быстрее регистров расчета. Но примеров “тормоза на РР, всё летает на РН” я не видел, к сожалению.
Регистры накопления, в отличие от регистров расчета, используют таблицу итогов, в связи с этим регистры накопления работают быстрее когда требуется получить данные за большой период времени (например при формировании отчетов). Кстати говоря, разработчики ЗУП это учли и поэтому дублируют информацию из регистров расчета в регистрах накопления, в итоге получается что за счет некоторой избыточности при хранении данных, были использованы сильные стороны различных механизмов платформы.
Спасибо за статью! Настраиваю вытеснение оклада вр оплата по среднему заработку Диспансеризация( не отработанные полные смены) В фактический период действия периоды правильно формируются:
01,04,2019 по 01.04.2019 оклад
02.04.2019 по 02.04.2019 диспансеризация
03.04.2019 по 30.04.2019 оклад
Но отработано часов в 1 и в 3 период записываются по 167, я ожидала увидеть
в 1 период -8 часов
в 3 период – 159 часов
Что делаю не правильно ? Спасибо за ответ
1.Есть начисления по сотруднику. В период начисления у сотрудника был (док. Замена) “Временный перевод” (не кадровое перемещение) -работал на другой должности по другому графику . И есть 2 премии которые начисляются по итогам месяца.
2.В настройках ВР “Оплата по часовой тарифной ставке” есть вытесняющий вид расчета “Временный перевод”
3. При расчете Премий в базу не включаются сумма (По замене) “Оплата по часовой тарифной ставке” из за вида расчета “Временный перевод”. если удаляю строку с видом расчета “Временный перевод” сумма включается В базу Для расчета премий
Вопрос почему база для премий не берется полностью, если она уже расчитана . Что сделать для этого?
“Например, больничный, введенный в марте за февраль, не сможет конкурировать за период действия с окладом. Его фактический период действия на интервале периода действия будет пустым, потому что записи не могут действовать одновременно, а вытеснение «задним числом» работать не будет”
Не понятен этот абзац. Почему не может конкурировать? Почему факт. период действия больничного будет пустым?
Записи не могут действовать одновременно: имеется ввиду запись об окладе и больничном? почему они не могут действовать одновременно, что это значит?
Добрый день,
Далее в ответе сокращения: РР -регистр расчета, ВР – вид расчета
про вытеснение:
чтобы сработали внутренние механизмы платформы, а именно – конкуренция, затем вытеснение и последующее получение фактического периода действия – необходимо, чтобы записи РР вытесняющего ВР имели период регистрации либо в одном периоде расчетов с вытесняемым ВР, либо его период регистрации должен быть меньше.
Это особенность платформы. Приоритет у записей с меньшим периодом регистрации в механизмах вытеснения – выше. Это можно отследить профайлером в SSMS если хочется посмотреть очень глубоко=)
Чтобы обойти эту особенность и был придуман механизм сторнирования. Который по сути “освобождает” в контексте периода действия определенный интервал. Наглядный пример “сторнирования” можно увидеть, при работе с документом “Больничный лист” в ЗУП 3.1. Попробуйте ввести его сотруднику задним числом
Спасибо за разъяснение)
Добрый вечер.
Пример. Период регистрации у б/л и оклада равный 01.06.2019. Но по б/с нет фактического периода действия. Почему?
Добрый вечер. Пример. Период регистрации у б/л и оклада = 01.06.2019, но у б/л нет фактического периода действия. Почему? т.е. б/л период регистрации 01.06.2019, периоды действия 22-27.05.2019, у оклада периода регистрации 01.06.2019.
Добрый день! Статья неплохая. Интересуют нюансы при закрытии периода при ОСНО, например, если организация оказывает только услуги (нет выпуска продукции) и наоборот или оба вида деятельности актуальны. Спасибо))
Ок, учту ваше пожелание на будущее=)
Добрый день! Очень хочется курс по ЗУП 3.1.
На данный момент нет курса по ЗУП.
Запись курса планируется, но сроки выхода пока что сообщить не сможем.
1) О каких компонентах механизма вам хотелось бы в первую очередь узнать?
2) Какие моменты задач для подготовки к экзамену «1С:Специалист по платформе» было бы хорошо осветить?
1) распишите все про перерасчеты.
2) все моменты касаемо периодических задач
Статья очень понравилась, спасибо.
Ошибка в тексте: “могут хранятся важные”
Благодарим за подсказку!
Прекрасная статья.Хотелось бы поподробнее узнать про регистры и внутреннюю кухню. А вообще, было бы очень полезно посмотреть точки из которых можно быстро находить алгоритмы расчета. Так как много времени уходит на то, чтобы отыскать нужное в модулях.
Буду с нетерпением ждать курса по ЗУП 3.1
С уважением Ковалев Виталий.
Автору спасибо за подробное описание механизмов, освежил в памяти принципы. Ждем с нетерпением продолжения!
Соглашусь, что нужен новый курс по зарплате, т.к. 2.5 сильно отличается от последних решений.
Насчет возможности осветить какие-либо вопросы в следующих публикациях: лично мне было бы очень интересно увидеть примеры использования расчетных механизмов для решения задач, не связанных с расчетом зарплаты, и которые именно так реализовать проще и быстрее, чем традиционными методами.
Вспоминается разрыв шаблона, когда немного поняв расчет зарплаты в ЗиК 7.7, я увидел как организован расчет в “Камине” ))
Статья очень хорошая, спасибо автору. Хорошо и понятно написаны основные принципы расчетных механизмов. К сожалению одна такая статья не поможет понять практическое применение РР, поэтому если сделаете ряд статей по теории и практической настройки даже примитивных ВР это очень многим поможет.
Еще раз спасибо
Добрый день! Очень нужна информация по ЗУП 3.1. Те курсы по ЗУП, что представляет 1С не освещают нюансы. Знаю, что часто на предприятиях снимают флажок поддержки и дорабатывают механизмы учета. Но даже в типовой ужасно формируются регламентированные отчеты: РСВ исходный тасует доходы и взносы между месяцами и рассихронно, а уточненный РСВ отчет ЗУП вообще не умеет делать; СЗВ-М теряет сотрудников; 6-НДФЛ теряет доход, с которого взят налог, таскает рубль по разным датам; – а собственно для их автоматического формирования и нужна программа. А главные отчеты хорошо формируются только на предприятиях, где нет расчетов за прошлые периоды, где нет обособки. Вот такая грусть. Заранее спасибо, если составите курс по ЗУП.
Добрый день.
Хотелось по подробнее узнать про регистр расчёта. Как в нем храниться информация. По описанию выше я понял что РР используется только для отчетов.
Курса по ЗУП 3.1 очень не хватает…(
Курс по ЗУП планируется, но сроки пока что назвать не сможем.
+1 :-)
Статья понравилась, спасибо. Возможно надо будет перечитать даже.
Вот на тему “Расчетные объекты в типовых конфигурациях (на примере прикладных решений семейства ЗУП)” было бы неплохо почитать статью.
В ЗУП 3.1 косяков очень много вылезает. Ту же 6-НДФЛ почти везде формируют “ручками” т.к. штатно работает только в самых простых случаях на небольших предприятиях.
Спасибо за статью! Конечно, хотелось бы подробный курс по конфигурированию ЗУП 3.1. Думаю, спрос был бы.
Спасибо за интересную статью. Было бы интересно посмотреть как решаются задачи с использованием табеля. Интересна настройка регистров расчета и накопления.
Спасибо! Хотелось бы целый курс по реализации расчетных механизмов именно в ЗУП 3.1. Например, где/какие/для чего общие модули. И как их модифицировать грамотно. Как там реализованы перерасчеты и т.д., и т.п. А то курс по доработкам в УТ 11 есть, а в ЗУП 3 – нет =(
Присоединяюсь к пожеланием Ильи.
Если не секрет, то в какой программе делали такие красивые схемы? :)
Спасибо за статью!
https://www.draw.io/
Спасибо!
Благодарю, очень понятная и полезная статья.
Господи ! спасибо Вам !
Большое спасибо за статью! Все очень доступно описано. Очень жду продолжения про детальную настройку объектов конфигурации.
Прекрасная статья. Отличное оформление. Дмитрий, ждем продолжения.
Хотелось бы узнать подробности о том как информация хранится на физическом уровне в таблицах.
Например, фактический период действия хранится в отдельной таблице. Если я меняю в настройках вида расчета список вытесняющих, то таблица фактического периода действия обновляется?
Добрый день, у объекта “РегистрРасчетаНаборЗаписей” есть метод Записать, у метода есть есть параметры ТолькоЗапись и ЗаписьФактическогоПериодаДействия. Комбинация данных параметров при записи набора может дать нужный результат. Например
….
НаборЗаписей.Записать(,Ложь, Истина);
….
Вызовет пересчет фактического периода действия, соответственно возможно обновление таблицы. Если говорить о ЗУП 3.1., то при изменении вида расчета, нужно пересчитывать документ с интересующим расчетом.
Про расчеты интересно действительно всё! Спасибо за статью, как раз готовлюсь к экзамену.
Жду продолжения!
Спасибо за качественный материал и замечательные рисунки!
Добрый день. Напишите пожалуйста про механизм перерасчётов и, если можно, на примерах из Зуп 3. Спасибо!
Спасибо за статью.
“Базовый период может покрывать несколько расчетных периодов. Он не обязательно кратен периодам расчета, его интервал может быть задан произвольно, например, он может быть определен как 15.02 – 15.03, 25.01 – 01.04 и т.д.”
Не совсем понятно, как будет определена база в случае, если периодичность расчетов установлена в месяц. Допустим, оклад начислен за март, в феврале вводится зависимое по периоду регистрации начисление, базовый период установлен с 10 по 20 марта. Возьмет весь оклад за март, не возьмет вообще, или возьмет пропорционально?
* в апреле *, не в феврале.
Настройка плана видов расчета и регистров расчета это тема отдельной статьи=) Но все-таки в общем случае логика будет такой:
“Если у плана видов расчета установлена зависимость по базе в положение “по периоду регистрации” и речь идет о виде расчета (далее ВР) этого плана то при получении базы будет происходить анализ пересечения периода, отсчитываемого от периода регистрации + месяц (для вашего случая) базовых записей с базовым периодов рассчитываемой записи. Период действия базовой записи не имеет никакого значения в данном случае.”
Для вашей задачи не хватает исходных данных – а именно периода регистрации оклада.
Обычно март оклад начисляется в апреле тогда у записи с ВР “Оклад” период регистрации – 01.04. Берем 01.04-30.04(так как периодичность расчетов месяц). Этот период не пересекается с 10-20 марта, поэтому база пустая. Если у записи с ВР “Оклад” период регистрации 01.03 тогда периоды 01.03 -31.03 и 10.03-20.03 пересекаются и упрощенно говоря “база равна значению оклада”, то есть возьмет целиком.
Опять же подчеркну сейчас мы говорим о зависимости по базе по периоду регистрации.В случае зависимости по периоду действия результаты будут иными
Благодарю за подробный ответ.
Жду продолжение!
Спасибо, ждем продолжения!
Разработчики типовой ЗУП не согласятся, что штраф может быть базовым расчетом для премии. Удержания вообще не могут входить в базу начислений.
Это зависит от специфики предприятия. Например, я встречал такое начисление как “управлеческая премия”(это термин конкретного предприятия), которую считали отдельно и потом,на ее основании, формировали премии (фиксированной суммой) топ менеджерам— поверьте база ее расчета была очень лоскутна, туда входило все, что только можно было посчитать.Иначе говоря, рег.учет тонко переплетался с управленческим.
Огромное спасибо.
Только планирую подготовку к спецу по платформе, никак не могла уложить в голове все периоды и их взаимосвязи. Все очень доступно.
Жду продолжения!
Добрый день! Наступил долгожданный день, когда появились материалы по расчетным механизмам!!! Очень много вопросов по конфигурации ЗУП 3.1.
Задача, которую мало кто может решить, это районный коэффициент и северная надбавка, рассчитываемая в начисление зп и межрасчетные выплаты премии, которые входят в зависимости РК и СН! И обязательное условие в расчетных листах выделять РК и СН.
Почему у видов расчетов фактические периоды действия работают по правилу “с-до”, а не “с-по”? Т.е., при больничном с 11 по 20 февраля, у оклада период действия 01.02-11.02 и 20.02-28.02, а не 01.02-10.02 и 21.02-28.02?
Очень интересует подход к решению экзаменационных задач, где используется табель учета времени. В курсе подготовки к аттестации этого не было, вскользь упоминалось в Продвинутом курсе по программированию. И все.
Спасибо за статью! Хорошо все изложено.Тоже готовлюсь к спецу по платформе и интересует решение наиболее сложной расчетной задачи, с комментариями почему так а не иначе….
Большое спасибо! Можно попросить pdf версию?
Данная статья существует только на сайте.
PDf-файла, к сожалению, нет.
Тема интересная, для большинства сложная.
Что-то конкретно не могу придумать, интересно все про расчеты.
Здравствуйте! В “Период действия записи” указано, что если БЛ попадает в два периода расчета (февраль-март), то создаются два одинаковых БЛ с разными периодами действия. А как тогда быть с выгрузкой БЛ в ФСС? Два xml-файла отправлять?
Это никак не связано
Добрый день, если вы про конфигурацию ЗУП тогда
1)Документ “больничный лист” создается один и период отсутствия в нем указывается целиком. В статье речь идет о том как попадут сами записи в регистр расчета. Суть в то , что если “период отсутствия” пересекает период расчетов то одной записью это представлено быть не может, и такой “переходящий” больничный отражается двумя записями.
2)По поводу выгрузки XML – если говорить упрощенно и речь идет об электронных больничных, то отправляется один файл на один документ и в нем так сказать”две секции”, которые соответствуют периодам.
Спасибо за статью! Как раз готовлюсь к спецу.
Тоже как раз готовлюсь к экзамену, полезная статья. Спасибо автору.
всё очень подробно было в курсе Чистова, Павел всё разжевывал по расчетным задачкам
Имеется ввиду курс по подготовке к спецу по платформе?
Запись такого курса планируется, но сроки пока что назвать не сможем.
копируете стилистику партнёрского форума разработчиков фирмы 1С :) лично меня фраза “планируется, но сроки пока что назвать не сможем” дико раздражает :)
Тогда напишем по-другому: мы не анонсируем сроки по курсам, пока не будет записано / подготовлено хотя бы 80% контента.