Расчет в 1С:Предприятие 8.2 и 8.3 – это сложно или просто?
Итак, это для начинающих работать с подсистемой Расчет - по результатам собственного опыта. Сразу скажу - сначала все казалось крайне сложным, сложнее, чем все остальные подсистемы, а потом оказалось, что всего лишь надо было понять несколько принципиальных моментов и все резко упростилось.
Вот и давайте разберемся с принципами работы этой подсистемы, ведь многие программисты категорически отказываются ей заниматься. В чем же причина? Это действительно так сложно?
Для чего используется подсистема Расчет в 1С:Предприятие 8.2 и 8.3?
Почти всегда – для расчета заработной платы, хотя, ее назначение более универсальное.
Например, можно сделать расчет для биллинговых систем у провайдеров. Но, это редко кому требуется. А вот зарплату считают все.
Почему это отдельная подсистема?
Можно и без нее, только, тогда придется много-много программировать для расчета зарплаты, а эта подсистема – «заточена» под такие расчеты и в ней есть много механизмов, обеспечивающих расчеты зарплаты без дополнительного программирования. Можно провести аналогию, когда в программно-аппаратных комплексах какие-то функции, сложные для программирования, реализуются аппаратно, тогда программирование резко упрощается. Вот и здесь, часть функций для расчетов уже реализована в объектах 1С:Предприятие 8.2 и 8.3.
Так из чего же состоит подсистема Расчет в1С:Предприятие 8.2 и 8.3?
Если посмотреть на структуру даже самой простой конфигурации, увидим много блоков, во взаимосвязях которых, на первый взгляд, очень трудно разобраться. Если посмотрим на типовые конфигурации УПП или ЗУП, тем более совсем не захочется даже разбираться в их структуре. А какие там сложные запросы многократной вложенности…
Но, иногда все-таки очень надо разобраться хотя бы в принципах этой подсистемы, работа есть работа.
Для примера возьмем простейшую конфигурацию. Какие в ней объекты для расчета зарплаты? Например:
Справочники: Физические лица, Подразделения, Работники организаций, Группы видов расчета, Типы графиков
Регистры сведений: Плановые начисления, Плановые удержания, Графики работы
Планы видов расчета: Основные начисления, Дополнительные начисления, Удержания
Регистры расчета: Основные начисления, Дополнительные начисления, Удержания
Документы: Прием на работу, Увольнение, Кадровое перемещение, Начисление зарплаты, Регистрация разовых начислений,
Отчеты: Расчетные листки, Расчетная ведомость
Обработка: Регистр расчета
Общий модуль: Расчет зарплаты.
Ну вот, даже в простейшей конфигурации все очень сложно – больше двух десятков объектов с непонятными взаимосвязями. Вот и причина, почему не все программисты хотят с этим разбираться.
Попробуем упростить.
Зададим себе вопрос, а все ли из этих объектов действительно относятся к подсистеме Расчет?
И обнаружим, что, оказывается, нет. Объектов именно этой подсистемы – на удивление мало, поэтому и разобраться в таком маленьком количестве объектов вполне возможно.
Почему такое утверждение? Сейчас поймем.
Действуем методом исключения.
Без чего Расчет остается Расчетом, а без чего Расчетом быть перестанет?
Часть объектов есть в любой конфигурации, даже, если Расчет не будем использовать.
Это, например, справочники – Физические лица, Подразделения.
Часть объектов – носит просто вспомогательный характер, с ними удобнее, но, можно и без них, только придется вводить часть информации вручную. Это не страшно, ведь мы хотим понять взаимосвязи именно для Расчета.
К таким объектам относятся, например, регистры сведений для плановых данных.
Ну, про отчеты даже говорить не будем – отчеты есть отчеты, запрос к базе данным, они аналогичны сотням других отчетов конфигурации.
Часть объектов – для учета кадров. Это просто, там расчет делать не надо, обычные справочники для сотрудников и документы для приема на работу.
Так что же осталось для собственно Расчета из этой схемы?
Остался очень важный объект – План видов расчета.
Не менее важный объект – Регистр расчета.
Без них, действительно никак не обойтись.
Что еще?
Графики работы, конечно, иначе как зарплату начислять, надо ведь знать: какие дни рабочие, какие выходные.
А раз начислять зарплату надо, да и регистру расчета нужен регистратор – это документ начисления зарплаты, в котором вводим исходные данные (в нем и разовые начисления вводить можно на отдельной закладке) Если будут вспомогательные объекты, о которых говорили – берем данные из них, если нет – расчетчик вводит данные из бумажных документов, для подсистемы Расчет это не принципиально.
Ну вот, совсем мало объектов у нас в Расчете осталось:
План видов расчета;
Регистр расчета;
График работы и Типы графиков;
Документ начисления заработной платы.
Разбираемся с ними.
Графики работы с Типами графиков – это элементарно. Пятидневка – Тип графика, конкретные значения часов по датам для рабочих дней – сам график. Шестидневка может еще быть, сменные графики - кому как надо.
Теперь сложнее, но не очень. Для чего необходим План видов расчета? И сколько их должно быть?
Это, можно сказать, аналог плана счетов, только для видов расчета - список видов расчета с основными характеристиками.
Что такое Вид расчета – ну, например, Основная заработная плата, Премия, Оплата за отпуск. В-общем, понятно.
Какие основные характеристики?
Базовый вид или зависит от других, зависит от времени или нет, при изменении каких видов надо делать его перерасчет, да еще несколько аналогичных принципиальных моментов. Например, какие виды расчета должны вытеснять другие, например, Прогул вытесняет Основную заработную плату.
Причем, программировать ничего не надо, надо, в основном, отметить флажками, или указать из какого объекта брать данные, то есть, вполне можно разобраться с такими настройками.
Сколько таких планов - сколько надо по смыслу и, например, по зависимости от времени или от некоторых других принципиальных характеристик.
Регистр расчета. Это что за объект?
А вот он и делает все расчеты, обычно по одному для каждого плана.
Этот регистр удивительно точно умеет вычислять без программирования, сколько надо было отработать рабочих дней и часов по указанному ему графику работы за указанный период, сколько за этот период действительно отработал сотрудник, если часть прогулял. А еще, сколько дней, например, в периоде для расчета отпуска и т.д.
Ну, без программирования, конечно, условно, совсем без этого не обойдемся – просто есть команды, которые эту информацию получают. Синтаксис-Помощник подскажет, быстро разберетесь.
Ну, а после того, как эти дни регистр командами определит, тогда, правда уже с помощью обычного программирования, результат расчета зарплаты и отпуска регистр с помощью движений в себя же запишет. Это уже не так сложно – вид расчета предполагает вполне конкретный алгоритм расчета (законодательство это четко определяет), так что, по указанной регистру зарплате сотрудника по трудовому договору, периоду расчета, да по тому, сколько тот прогулял, когда должен был работать, вполне можно не слишком сложно запрограммировать такой расчет.
Только, раз этот регистр знает, какая зарплата по трудовому договору и сколько сотрудник прогулял, кто-то ему это сказать должен был.
А сказал ему это – документ Начисление заработной платы, который необходимые для расчета зарплаты записи в регистр расчета сделал. Обычный документ, как и другие в конфигурации, ничем особенным не отличающийся, в который данные по сотрудникам расчетчик вручную ввел или этот документ из вспомогательных объектов взял, о которых мы говорили.
Вот, собственно, и все основные принципы этой подсистемы.
Про отчеты мы уже говорили. Регистр расчета – это ведь всего лишь регистр. Запросы к нему вполне можно сделать, если программист умеет работать с другими регистрами.
Когда сложно одним запросом все учесть, можно пока и несколько сделать – не оптимально, конечно, но работать будет.
А когда совсем осознаем весь этот Расчет, сделаем все очень оптимально, ведь теперь уже не так все сложно будет.
Ну, а в типовых конфигурациях теперь уже точно разберемся, там же аналогично все.
