что такое сложные периодические расчеты

3. Сложные периодические расчеты

3. Сложные периодические расчеты

Сложные периодические расчеты являются наиболее трудными для освоения. С одной стороны, типовые конфигурации переложили максимум возможностей по их настройке на конечного пользователя и, для разработчика, нет такого большого поля деятельности, а значит, нет опыта практической работы с подобными задачами. С другой стороны, принципы ведения периодических расчетов полностью отличаются от принципов бухгалтерского и оперативного учета, что приводит к необходимости изучения непривычных понятий новой прикладной области. Специфические механизмы, такие, как получение данных графика, базы или перерасчет, не имеют аналогов. Для решения подобных задач необходимо глубокое изучение теории и устройства соответствующих объектов, без чего реализация задания на экзамене является невозможной. Каждая задача включает в себя несколько различных механизмов расчета.

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

Задача 3.1.

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

Сотрудники предприятия получают оплату по окладу пропорционально отработанному времени в часах. Часовая ставка рассчитывается как начальное значение оклада, деленное на количество рабочих часов в том же периоде, что и фактически отработанные часы. Первоначальное значение оклада может изменяться не чаще, чем один раз в день, но берется на начало расчетного периода. Дополнительно, сотрудникам компании может быть начислена премия процентом от начисленного в том же расчетном периоде оклада. Процент премии в течение периода начисления не меняется и задается в документе «Начисление зарплаты».

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

Механизм перерасчетов в рамках данной задачи использовать не надо.

Ввод всех начислений происходит документом «Начисление зарплаты». Считать, что все данные вводятся только в пределах одного месяца, например, можно указать начисление оклада с 10.01 по 31.01, а запись: оклад с 10.01 по 03.02 вводить нельзя.

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

Отчет может быть построен за любой расчетный период.

Источник

Что нужно знать о расчетных механизмах в «1С:Предприятие 8»

Расчетные механизмы являются наиболее сложным функционалом в платформе «1С:Предприятие 8». Именно на расчетных задачах больше всего «сыпятся» на Аттестации 1С:Специалист по платформе. Причем не из-за вредности преподавателей, а из-за множества нюансов.

Поэтому мы периодически будем публиковать статьи, посвященных расчетным механизмам платформы «1С:Предприятие».

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

Технология реализации расчетных задач

Что Вы узнаете из этой статьи?

В расчетах существует своя терминология. Поэтому начнем с того, что введем базовые определения.

Периодичность расчетов

Данные о расчетах в системе «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).

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

Что происходит при вытеснении одних записей другими? На что, собственно, влияет вытеснение?

Дело в том, что любая протяженная во времени запись, помимо периода действия, имеет так называемый фактический период действия, и именно на него оказывает влияние вытеснение. То есть при вытеснении период действия вытесняемой записи не изменяется. В общем случае фактический период действия записи – это совокупность интервалов, на котором запись действует с учетом всех вытеснений.

Рассмотрим формирование фактического периода действия записей из приведенного выше примера.

Ключевые моменты формирования фактического периода действия:

Необходимо учитывать, что в «1С:Предприятие» конкуренция и последующее вытеснение возможно, только когда вытесняющие записи вводятся в текущем или будущем периоде расчетов. То есть период регистрации вытесняющего вида расчета должен быть либо равен, либо меньше периода вытесняемой записи. Такая особенность системы связана с тем, что записи с меньшим периодом регистрации всегда имеют приоритет перед записями с большим периодом.

Например, больничный, введенный в марте за февраль, не сможет конкурировать за период действия с окладом. Его фактический период действия на интервале периода действия будет пустым, потому что записи не могут действовать одновременно, а вытеснение «задним числом» работать не будет (см. рис. 10).

Однако такие случаи очень распространены в реальном учете, и в системе существует решение. Для того, чтобы больничный имел не пустой фактический период, необходимо применить механизм сторнирования. Сторнирование – это довольно сложный процесс, в нем существуют свои нюансы, и его разбор – это тема отдельной статьи.

Зависимость по базовому периоду

Иногда требуется, чтобы расчет одной записи зависел от расчета других записей. Например, премия может рассчитываться как процент от начисленного за предыдущие три месяца оклада. В таком случае говорят, что оклад входит в базу расчета премии, а вид расчета «Оклад» является базовым по отношению к виду расчета «Премия».

Один вид расчета может иметь несколько базовых видов расчета. При зависимости по базовому периоду происходит анализ сумм базовых видов расчета за определенный период, который называют базовым периодом.

В общем случае базовый период представляет собой интервал, который может покрывать несколько периодов расчета. В нашем примере базовым периодом для расчета премии будут три месяца, ей предшествующие (см. рис. 11).

Продолжим наш пример расчетом премии. Для этого определим величины оклада и процент премии.

Пусть у некоторого сотрудника оклад распределился следующим образом: Январь – 15 000 р., Февраль – 21 000 р., Март – 20 000 р. Процент премии равен 10%. Стало известно, что в феврале у сотрудника был штраф в размере 5 000 р., и его также нужно учесть при расчете премии, то есть в базу расчета премии входят оклад и штраф. Соответственно, виды расчета «Оклад» и «Штраф» являются базовыми по отношению к виду расчета «Премия» (см. рис. 12).

Все необходимые данные определены, переходим к расчету. Первым делом рассчитаем базу премии. В нашем случае база расчета премии составляет 51 000 рублей и состоит из суммы начислений по окладу за 3 месяца и начисленного в феврале штрафа (уменьшает базу):

Исходя из полученной базы, произведем расчет премии в соответствии с алгоритмом расчета:

Итак, размер премии рассчитан, он составляет 5 100 р.

Ключевые моменты произведенного расчета:

Итак, мы познакомились с основными терминами расчетов. Этой теории вполне достаточно, чтобы понять назначение и функциональность расчетных объектов (об них речь пойдет ниже). Однако, прежде чем переходить к рассмотрению самих объектов, необходимо определить применение механизма сложных периодических расчетов.

Наверняка вы уже заметили, что при описании основных определений расчетов повсеместно употребляется слово «период». Это ключевое слово в расчетных задачах. В отличие от задач бухгалтерского и оперативного учета, в них нет привязки к определенному моменту времени. События расчетов характеризуют период в целом.

В таких задачах, как расчет зарплаты, арендной платы и т.д. всегда есть некий период, к которому будет относиться полученный результат. Соответственно, это накладывает ограничение на применение механизма для автоматизации бизнес-процессов.

Применение механизма сложных периодических расчетов

Наибольшее распространение механизм сложных периодических расчетов получил в прикладных решениях, обеспечивающих расчет заработной платы, однако круг решаемых задач с его использованием значительно шире. Этот механизм может использоваться для автоматизации бизнес-процессов, где присутствуют следующие критерии:

Общая схема решения большинства задач с использованием механизма сложных периодических расчетов может быть представлена так:

Как видно из схемы, решение расчетных задач не ограничивается использованием только «расчетных» объектов.

В справочниках обычно хранят данные объектов, определяющих разрезы, в которых следует выполнять расчет (например, справочники «Организации», «Физические Лица») или описывается дополнительная аналитика расчета (например, справочник «Статьи расходов»).

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

Регистры накопления могут отвечать за оборотные данные, вспомогательные для расчета (хранить информацию о сдельных работах или отработанном времени, яркий пример – подсистема «Табельный учет» в типовой конфигурации ЗУП 3-й редакции).

Документы могут выступать как объект, регистрирующий первичную информацию, необходимую для расчета, так и как объект, который фиксирует промежуточный или конечный расчет (например, документ «Начисление зарплаты и взносов»).

Отчеты используются как средства представления пользователю результатов расчетов, с возможностью настройки и отбора по требуемым разрезам или аналитикам

Хочется отметить, что разделение на схеме объектов метаданных по контурам (НСИ, первичные данные, алгоритмы расчета) является условным и в зависимости от контекста задачи может меняться.

Например, в типовом решении ЗУП 3.1 регистр сведений «Графики работы по видам времени» носит смешанный характер. С одной стороны, он хранит эталонные графики работы (базовая НСИ), назначенные сотрудникам, с другой – при окончательном расчете зарплаты в него пишется фактический график, по которому работал сотрудник, если в течении месяца у него были отклонения от эталона.

Напоследок хочется отметить, что на практике множество задач и бизнес-процессов любых предприятий связаны с расчетами разной сложности, однако не всегда в них имеет смысл использовать механизм сложных периодических расчетов.

Более того, подавляющее большинство из них прекрасно решаются с использованием других объектов (регистров накопления, регистров сведения) и механизмов. Это такие задачи, как расчет себестоимости, расчет нормы рентабельности, расчет прибыли по заказу и т.д. Поэтому использование механизма сложных периодических расчетов должно быть обосновано как минимум следующими критериями:

В следующей статье рассмотрим основные объекты механизма сложных периодических расчетов, а также их конфигурирование.

На текущий момент в качестве продолжения готовятся статьи на такие темы:

Если вам интересна тема, касающаяся механизма сложных периодических расчетов, то напишите в комментарии:

Об авторе

Автор статьи – Дмитрий Игоревич Макаревич

УК “Содружество”, г. Калининград

Источник

Что такое сложные периодические расчеты

Основа любого расчета, как понятия является вид расчета (собственно определение того, что именно рассчитывается). Виды расчета хранятся в плане (планах) вида расчета. (ПВР)

Результат расчета хранится в записях Регистра Расчета. В одном регистре расчета могут храниться записи, содержащие виды расчета, принадлежащие только одному ПВР.

Период действия записи регистра расчета. Имеет смысл для записей, протяженных во времени. Например, командировка, зарегистрированная в марте может иметь период действия с 20 по 25 февраля. Если запись не имеет протяженности во времени, то для такой записи не имеет смысла понятие периода действия.

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

Теперь по поводу протяженности периода действия. Если, например, регистр расчета имеет периодичность в месяц, то невозможна запись, у которой, например, период действия c 01.01.2009 по 15.02. 2009. Придется делать две записи с периодами: с 01.01.2009 по 31.12.2009 и с 01.02.2009 по 15.02.2009.

Вытисняющие расчеты

Речь о том, что не все периоды действия всех записей могут мирно сосуществовать друг с другом. Действительно, пусть сотрудник получает оклад за январь и командировочные за 3 дня января-месяца. Понятно, что оклад, в этом случае должен быть начислен не за весь январь, а за январь без злополучных 3-х дней! Ведь иначе работнику переплатят и работодатель уволит расчетчика зарплаты!

Таким образом, говорят, что период действия командировки вытисняет период действия оклада. При этом период действия оклада не меняется! Меняется фактический период действия оклада. В нашем случае, фактический период действия оклада будет состоять из двух диапазонов дат, отстоящих друг от друга на 3 командировочных дня. Отметим, что если бы не было командировки, то фактический период действия оклада совпадал бы с периодом действия.

Важно:
Важно учитывать, что вытеснение срабатывает только при вводе вытесняющих расчетов текущим или будущим периодом. При вводе расчетов за предыдущий период («задним числом») механизм вытеснения не действует. Это связано с тем, что записи, введенные в систему рань¬ше (то есть с меньшим периодом регистрации), имеют больший приоритет в конкуренции за период действия, чем более поздние записи (с большим периодом регист¬рации), причем это не зависит от настройки списка вы¬тесняющих расчетов

Что такое сторнирование? Дело в том, что оклад уже начислен и выплачен, следовательно, изменить что-либо в прошлом периоде невозможно, ибо в комплект поставки платформы 1С до сих пор не входит машина времени! За неимением таковой, придется выкручиваться в текущем периоде, а именно, необходимо отменить в текущем периоде ту часть оклада, которая попадает на больничный, а так же, необходимо позволить больничному иметь ненулевой фактический период действия в текущем периоде.

Именно сторно запись выправляет ситуацию.
Пусть в феврале сотрудник проболел пять дней, но расчетчик начислил ему полный оклад. В марте это выяснилось, ибо появился больничный. Тогда расчетчик вводит сторно запись c с периодом регистрации март, которая:
— отменяет начисление оклада за период болезни (например, 4000р)
— позволяет больничному иметь ненулевой фактический период в феврале, в результате чего сотруднику будет начислен больничный за февраль в марте.

Попросту говоря, мы как бы сделали «дырку» в фактическом периоде действия оклада в прошлом периоде и в это, в хорошем смысле слова, отверсие втиснулся больничный.

Итак, один вид расчета может вытеснять другие виды расчета и при этом изменять период действия вытесняемого расчета.

Зависимость по базовому периоду

Ведущие расчеты и перерасчет

Платформа позволяет автоматически отслеживать изменения ведущих расчетов, и формировать список расчетов, кото¬рые необходимо перерасчитать.

Источник

Что такое сложные периодические расчеты

v8: Сложные периодические расчеты в 8.0 для чайников

Ключевые слова: регистр расчета, зарплата, ЗУП

Введение

Многие программисты 1С никогда не сталкивались в своей практике с компонентой «Расчет», поэтому когда им приходится сдавать экзамены на Специалиста по Платформе 8.0, где в каждом задании есть задача по сложным периодическим расчетам, возникают сложности, прежде всего сложности понимания.
Попробуем разобраться с этой компонентой в 8.0.

Вместо того чтобы решать различные задачи на расчет попробуем разобраться с этой компонентой так, чтобы можно было решить любую задачу по расчету. Изучив это пособие вы поймете как устроены и работают регистры расчета. Для примера будем использовать каркасную конфигурацию, устанавливаемой на экзаменах. Честно говоря я долго пытался придумать, для чего еще нужны расчеты, но не придумал, поэтому будем рассматривать задачу расчета зарплаты.

Что такое расчеты

В принципе, конечный продукт расчета зарплаты – это набор записей регистра расчета вида:

Значение в колонке «Данные» отражают базовый оклад работника (согласно трудового договора), но эта сумма может быть увеличена премиями, уменьшена штрафами и невыходами и т.п, поэтому реальная сумма к выплате заносится после выполнения расчета в колонку «Результат». В этом и заключается расчет. Сумма по колонке «Ресурс» для данного сотрудника – причитающаяся ему зарплата.

Таким образом регистр расчета – по сути набор записей, по структуре похож на оборотный регистр накопления. Просто для выполнения сложных расчетов для него указываются дополнительные настройки, которые позволяют затем строить много виртуальных таблиц для регистра расчета, хотя по сути этот регистр – просто набор записей, указанных на рисунке.

Каждая запись регистра расчетов относится к определенному виду расчета и периоду времени.

Виды расчетов

Каждая запись видов расчета имеет служебный реквизит – вид расчетов.

Для примера заведем план видов расчета Основной и в нем предопределенные виды расчета оклад, премия, невыход, командировка.

Виды расчета используются функционально для того, чтобы отразить влияние записей регистра расчета друг на друга. Но сокращенно говорят о влиянии видов расчета друг на друга:

Ведущие расчеты

Расчет зависит от ведущего расчета, но не прямо, а косвенно, т.е. расчет А зависит от базового расчета Б, а расчет Б зависит от базового расчета В, следовательно А косвенно зависит от В, т.е. А зависит от ведущего расчета В. В самом деле, при изменении расчета В может измениться Б и следовательно может измениться А. Система автоматически не отслеживает такие сложные зависимости, поэтому нужно указывать какие расчеты являются ведущими.

Премия зависит по базе от оклада, но также косвенно зависит и от невыхода.

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

Графики времени

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

График времени – это простой регистр сведений, одно измерение которого хранит дату, другое связывается с измерением регистром расчета, а один из ресурсов используется для учета времени.
Измерение, которое связывается с регистром расчета обычно носит смысл «вид графика».

Почему используется измерение «дата», а не периодический регистр сведений? Все очень просто – если 11 января в пятницу по пятидневке у нас 8 рабочих часов, то это еще не значит, что на следующий день у нас будет опять же 8 рабочих часов. А ведь если бы мы использовали периодический регистр, значение на следующий день бралось бы из предыдущего дня при отсутствии записей.

Таким образом, имея определенный период (фактического действия, регистрации, базовый период и т.п.) мы можем автоматически получить количество часов за ээтот период по графику.

Перерасчет

Перерасчет чем то напоминает границу последовательности. Так как у нас есть зависимые расчеты, то при изменении их базовых и ведущих расчетов система должна как-то отметить, что мы должны пересчитать зависимые расчеты. Для этого и служат перерасчеты.

Если мы рассчитаем базовые записи, то система отметит в перерасчетах, что нам нужно рассчитать зависимые записи. Как только мы рассчитаем зависимые записи, перерасчеты очистятся. По сути перерасчеты – это список записей регистра расчета, которые нужно перерасчитать. Если в перерасчетах не заводить ни одного измерения, то при изменении базовых расчетов в список перерасчета занесутся все зависимые записи. Если мы заведем измерение «Сотрудник» в перерасчете, то при изменении базового расчета по сотруднику в перерасчеты добавятся зависимые записи только по этому сотруднику.

Практическое задание

Достаточно теории. Попробуем изучить детали на практике. За основу возьмем каркасную конфигурацию.

Постановка задачи:

Пусть премия задается фиксированным процентом к окладу (за вычетом невыходов и командировочных).
Командировочные пусть оплачиваются в двойном окладе + фиксированная сумма выплат за каждый день командировки.

Пусть за невыходы с сотрудника взымается штраф в размере половины оклада за период невыхода.

Ход выполнения:

Создадим новый план видов расчета «Основной».

Определим виды расчета и зависимости между ними:

Занесем эти виды расчета в план видов расчета «Основной» и в свойствах видов расчета поставим зависимости согласно таблице.

В конфигурации уже имеется документ «Начисление зарплаты».

В нем две даты в шапке – «дата» и «период регистрации», а также по две даты «дата начала» и «датаконца» в каждой строчке.

Подразумевается что дата – это просто дата оформления документа, период регистрации указывает, за какой месяц мы считаем зарплату, а даты в каждой строке описывают период действия каждого вида расчета.

Модуль документа будет выглядеть примерно так:

Реквизит «Сторно» нужен чтобы сторнировать записи (аналог минуса).

Проставляем вид расчета, даты приводим к началу и концу дня. Конечно базовый период можно проставлять только у зависимых по базе видов расчета, а Данные можно проставлять только у оклада, но и так все работает.

Все документы датировать будем 20.01.2003, период регистрации будем ставить 02.01.2003 (специально указываю не начальные и конечные данные, здесь это неважно, все равно при записи в ПериодРегистрации преобразуется в начало периода 01.01.2003). Январь 2003 года используем, потому что за этот период заполнены графики работ.

Заведем перерасчет «Перерасчет», добавим в него измерение «Сотрудник», связанное с измерением «Сотрудник».

Играем с Перерасчетами

Для игры откроем консоль запроса – обработка «ПроизовльныйЗапрос» в каркасной конфигурации. Создадим новый запрос конструктором запроса, добавим туда виртуальную таблицу Перерасчеты.Расчеты.Перерасчет, текст запроса будет таким:

Сформируем три документа – первым начислим оклад сотрудникам А и Б. Сотрудник А работает с 1 по 31 января, Б работает с 1 по 20 января. Вторым начислим премию сотруднику Б за период с 1 по 31 января, третьим назначим невыход сотруднику А с 20 по 25 января.

Играем с Фактическим периодом действия

Создадим новый запрос – на этот раз в него добавим данные таблицы РегистрыРасчета.Расчеты.ФактическийПериодДействия.

Сформируем запрос и увидим, что сотруднику А период действия оклада разбит на два периода – с 1 по 19 и с 26 по 31 января. Надеюсь вам понятно, что период был разбит на два, т.к. невыход вытеснил оклад.

Думаю, механизмы работы регистра расчета проясняются на глазах.

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

Источник