хотелось бы поподробнее, возможно ли поделиться примерной обработкой для понимания?
Ок, опишу возможности с позиции обычного пользователя и с позиции разработчика.
С позиции пользователя:
Например я являюсь бухгалтером обычной бюджетной организации. Устанавливаю конфигурацию, сама конфигурация без подключенных модулей не считает, не хранит никаких данных и расчетов, короче не делает ничего. Загружаю в базу модули, которые нужны для расчета зарплаты работникам бюджетной сферы, замечу, что ничего лишнего кроме того что касается расчета зарплаты бюджетникам, не загружается (модуль состоит из файла с описанием структуры данных и внешних обработок). Если же у меня есть еще и военнослужащие, то дополнительно загружаю модель для расчета денежного довольствия военнослужащим и тд. При этом реализован механизм разделения учета по этим самым модулям, у меня они называются категории сотрудников, можно в одной базе работать как с денежным довольствием так и с бюджетниками, например двум бухгалтерам одновременно, и при этом совершенно не мешая друг другу.
Что касается функциональности. В моей конфигурации организация даных привязана к 3-м объектам: к подразделениям, к должностям в этих подразделениях, ну и соответственно к самим сотрудникам. Для чего это нужно? Ну например у каждого подразделения в организации есть специальные надбавки, которые распространяются на всех работников. Достаточно просто установить надбавку для подразделения, и всем сотрудникам данного подразделения будет начисляться эта надбавка. Можно конечно ввести и каждому сотруднику, а если этих сотрудников человек так 400, то вводить всем им одинаковые суммы это утомительно. При этом если будет принят новый человек в это подразделение ему автоматически тоже будет начисляься эта надбавка.
Что касается расчетов надбавок и выплат. Они настраиваются путем ввода формул, типа как в экселе. В формулах можно оперировать данными сотрудников, должностей и подразделений, а также использовать значения уже существующих надбавок, еще существуют так называемые функции, которые подключаются к базе как внешние обработки и так же учавствуют в расчете заработной платы (например для расчета каких либо исключительных ситуаций, которые не опишешь обычнымми формулами). У каждого аглоритма расчета есть условия для его выполнения, а также есть еще дата действия. Кроме формул можно использовать мастер для ввода набавок, который так же хранится во внешней обработке, и который так же вводит формулы, только предоставляет пользователю более дружественный и понятный интерфейс.
Что касается документов по вводу больничных, отпуска, табеля и тд. У меня в конфигурации это вводится 2-мя документами "Ввод по объекту", и "Ввод по списку объектов". В этих документах Выбирается операция (например табель, больничные или отпуск...), после чего изменяются те или иные данные по объекту (например подразделение, должности или сотрудники), на основе которых программа будет расчитывать те или иные выплаты.
В остальном конфигурация ничего примечательного и принципиально отличного от других не содержит.
Теперь с позиции разработчика:
Наверное все будутсо мною согласны что если разрабатывать конфигурацию, которая сразу бы подходила для расчета нескольких категорий сотрудников, то это достаточно сложно. Нужно учитывать все ньансы разных систем оплаты труда, при этом делать это так, чтобы все это было взаимосвязано между собой и все работало верно. И если один человек разрабатывает систему оплаты труда для одной категории, а другой человек для следующей категории, то при этом им нужно знать не только ньансы расчетов своей системы, но и все ньюансы другой системы, хорошо если этих систем 2 или 3, а если их больше, что тогда? Нужно иметь квадратную голову и кучу сотрудников для решения данной задачи. В моей же конфигурации каждая система оплаты труда разрабатывается и существует независимо от других систем, то есть если разработчик занимается одной системой оплаты труда, то он владеет знаниями и ньансами непосредственно своей "зарплаты" и ничего более, на другие системы ему наплевать.