MX -- ALEX

для сравнения - зарплата со всеим наворотами и перерасчетами
за прошлые месяцы для металлургического предприятия 3000 чел
считается за 15 секунд
CACHE 5.1

Очень интересная информация! Нельзя ли немного подробней рассказать об этой программе, ну там ссылки на демо-версии и т.п. Уж больно не вериться, что такая существует...

To: MX – ALEX

> как нам не верится что зарплату можно считать больше минуты
> - заглянуть бы внутрь - что оно там делает так долго ..

Ну, например, в моей программе по расчету зарплаты (на Украине) используются следующие соображения:

Алгоритмы различных видов расчета можно разделить по технологическому принципу:

1. Простые или термальные виды расчета;
2. Сложные виды расчета, основанные на расчете сумм простых видов.

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

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

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

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

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

Что такое «контекст расчета»? Это множество всех параметров и данных, относящихся к заданному периоду расчета, достаточных для проведения необходимых расчетов в этом периоде. Нужен механизм быстрого и удобного переключения контекста, что существенно упростит расчет зарплаты.

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

Требуемая детализация учета подразумевает, что все данные представлены с достаточным уровнем точности, относительно минимального субпериода данного периода. Для внешних параметров расчета практически достаточно точности, если они известны для произвольной даты, т.е. с точностью до одних суток. Иначе возможны теоретические коллизии, ведущие к неточностям в расчетах. Для внутренних данных (для каждого сотрудника) достаточно, если они представлены с точностью до минуты. К счастью внутренних данных не очень много. Это могут быть время прихода / ухода на работу и практически все. Особенно удобно, если учетная система подключена к электронной проходной, ведущей автоматический учет прихода / ухода сотрудников на работу. Отсюда следует, что для полноценного учета, нужно вести ежедневный учет рабочего времени сотрудников, с достаточной точностью. Все это показывает, что данных может быть очень много, поэтому нужны будут механизмы сворачивания данных, т.е. если параметры не изменяются в течение некоторого субпериода данного периода, то должна быть возможность их интегрированного представления. Иначе говоря, модуль ежедневного учета рабочего времени сотрудников должен быть достаточно автономным, чтобы, во-первых, можно было работать без него (после сворачивания данных или их непосредственного ввода), а во-вторых, чтобы он мог быть легко подвергнут сжатию, выгрузке (с возможностью загрузки) и удалению. Этот модуль должен иметь возможность работы с электронной проходной (через соответствующий драйвер устройства). Помимо параметров устройства (стандартный журнал событий электронной проходной) должна быть возможность ручного редактирования индивидуальных данных сотрудников, например выбор графика работы, типа учетного дня (рабочий / выходной / праздничный / больничный / командировка / отпуск и т.д. и т.п.).

Что касается группового учета и расчета, то здесь все достаточно очевидно. Объединяем нужные данные, а потом их обрабатываем.

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

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

Итак, в первом приближении общий алгоритм расчета по каждому лицевому счету сотрудника можно представить в следующем виде:

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

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

Что лучше, считать «свернутые» или «развернутые» данные?

Вопрос конечно интересный. «Свернутые» данные считать экономичней, нет дублирования одинаковых данных за разные дни. Но могут быть нюансы, связанные с внешними параметрами. Допустим данные свернуты на субпериод, в течение которого некоторые внешние параметры меняют свое значение. Тогда данные надо будет разворачивать на соответствующие субсубпериоды и рассчитывать каждый из них. В общем случае делать это утомительно с немалой вероятностью ошибиться. Второй же вариант проще в расчетном смысле, все параметры и внешние и внутренние приведены к одному дню (одним суткам). Однако возможен частый повтор одинаковых расчетов, что повышает время расчета. Причем необходимо хранить «развернутые» данные за все периоды. Хотя, вероятно, перед расчетом данные можно будет «разворачивать». Возможно, только практическое сравнение двух моделей расчета покажет более оптимальную из них. Как бы там ни было, нужно будет уметь «свернутые» данные «разворачивать», а «развернутые» «сворачивать».

Уже только одна выборка (подготовка) данных занимает время значительно больше минуты, хотя если делать весь расчет уже при вводе…

> подробнее - система MX:
> сервер = CACHE 5.1 или MSM 4.4 или m3-lite

К сожалению, система для меня незнакома, хотя был знаком с системой MSM 4.0 (интерпретатор операционной системы и базы данных (первая версия разработана в Массачусетском госпитале в 60-х годах), не знаю только – та ли система имеется в виду?)

> клиенты в локальной сети - 50 штук - сидят на EXCEL

А сколько юзверей сидят на «зарплате»?

> применяются интерактивные MX-smart-forms :

Хотелось бы увидеть скрин-шот…

> прилагаю расчетный листок по зарплате с небольшой транспортной фирмы

К сожалению, не могу распаковать *.zip файл. Нельзя ли выслать не запакованный файл в <emmerald@mail.ru>;

To: MX – ALEX

Скорее всего, речь идет о цене за скорость расчета. Ведь помимо расчета есть еще интерфейс, цель которого удобство ввода/вывода данных, навигации по ним. Насколько я знаю MSM это не та система, с которой приятно работать, хотя она и очень скромна в потребляемых ресурсах. Однако, если Вашу фирму устраивает эта система, то нет вопросов… Но боюсь, что меня бы она не устроила. Потому и написал собственную «зарплату». Скорость расчета у нее сейчас 1000 человек за час, но уже занялся оптимизацией, думаю, будет хватать 10 минут. Кстати, какой у Вашего расчетного модуля объем? У меня более 400 КБ, а после оптимизации будет раза в два меньше. Технология доступа к данным принципиально файл-серверная, а сам сервер терминальный. Это дает колоссальные преимущества при использовании MDI-интерфейса, хотя сильно замедляет доступ к данным относительно клиент-серверной технологии. Зато существенный выигрыш в цене. Я еще использую полное протоколирование расчета по каждому сотруднику. Объем данных одного сотрудника (в формате *.txt) от 20 до 200 КБ. Интересно сколько бы у Вас занял места протокол расчета по одному сотруднику? И еще вопрос. Как вы печатаете табульки / лицевые счета сотрудников? В один или два ряда на страницу? Сколько бумаги уходит на всех? Как отражаются расчеты по разным периодам в одной табульке? К сожалению, в прилагаемом Вами файле текст был не по-русски, а табулька содержала слишком мало данных, чтобы можно было что-либо понять. Так что пока я не вижу у Вас тех преимуществ, которые бы соблазнили меня, остаюсь при своем мнении и «зарплате» :) .

> диссертацию тоже делал - специальность - научная организация и экономика труда –
> автоматизированный учет трудозатрат - но не защищал – тупой

Я думаю, что человека, который написал соответствующую программу и / или внедрил автоматизированный учет зарплаты на солидном предприятии уже можно автоматически считать кандидатом наук по Computer Science, как говорят в Америке. А сами корочки кандидата наук лично для меня имеют мало значения…