MAGAZKA

Была здесь тема о зарплатном модуле. Соответственно у меня вопрос: что именно нужно в зарплатном модуле? И почему не годится стандартный ЗиК или ЗУП, если такой вопрос возникает?

в двух словах - у нас несколько одежных магазинов. Заработная плата работников рассчитывается исходя из 2х динамических параметров: общая выручка торговой точки и личные продажи продавца-консультанта. Чистой воды сделка. Что касается существующей системы учета этих параметров - то в автоматическом режиме, заведя уровень процентов по общим и личным продажам и еще какие-либо динамические параметры (штрафы, премиальные, динамическую систему увеличения процентов, при достижении каких либо плановых величин) - программа выдавала бы расчетный лист сотрудника за определенный период времени. Не могу сказать может ли выполнять такой функционал озвученные программы - да и нет желания в них залазить - так как основная работа ведется в конфигурации МАГАЗьКА - хочется именно в ней в перспективе увидеть такую обработку. Эта необходимость вызвана постепенно растущим количеством магазинов и, соответственно - расширением штата. Когда нужно посчитать зар.плату 2-3 работникам - это не критично, а когда - 6-10? или еще большему количеству? Вот собственно, мое понимание какой нужен функционал.

Естественно, если на входе есть данные об общей выручке точки и личных продажах каждого продавца-консультанта, то можно реализовать алгоритмы расчета любой сложности, если они описаны понятно и точно. Это вопрос постановки задачи и уточнения деталей.
Более важный вопрос, что потом предполагается делать?
Вариант 1: распечатывается расчетный листок, показывающий сотруднику, каким образом образовался его заработок, т.е. реализация алгоритма с его конкретными данными.
Вариант 2: получившийся заработок является только частью зарплатно-кадровой системы. А она включает в себя, систему расчета НДФЛ, взносов в ПФ, Соцстрах, медстрах, расчет больничных, отпускных, командировочных и других оплат по среднему заработку, выдачу и возврат ссуд и расчет материальной выгоды и соответствующих налогов на материальную выгоду, расчет алиментов и других удержаний по исполнительным листам. Связанная с этим всем кадровая подсистема: прием, увольнение, перемещения, отпуска, отзывы из отпусков и т.д и т.п.
Исходя из наличия этих вариантов, сложность реализации и поддержки которых отличается во многие десятки раз и хотелось бы узнать, о каком варианте требований к зарплатному модулю мы будем вести речь?
Выяснив этот главный вопрос, можно обсуждать дальнейшие действия.

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

Вариант 2 в платформе 77 оперативный учет технически невозможен, потому что там нет календаря. Кроме того, в торговой программе 2 вариант неуместен в принципе, для этого есть ЗУП и другие программы.

ProstoSkazka писал(а):
Вариант 2 в платформе 77 оперативный учет технически невозможен, потому что там нет календаря. Кроме того, в торговой программе 2 вариант неуместен в принципе, для этого есть ЗУП и другие программы.
Ну, насчет технической невозможности Вы, пожалуй, несколько погорячились . По крайней мере несколько лет моя конфигурация делает по зарплате и кадрам все, что я перечислил выше плюс формирует необходимые отчеты в ПФ и Налоговую, работая как на платформе Расчет, так и Бухгалтерия. При этом в ней нет ни одного календаря. Думаю, она будет работать и с Оперативным учетом, хотя и не пробовал.
Другое дело, целесообразность этого варианта. Тут, как раз, я с Вами соглашусь. Поэтому я и задал вопрос о требованиях к зарплатному модулю. Я предполагал, что пользователи могут недооценивать сложность полнофункциональных зарплатных программ, а соответственно и трудозатрат на их написание и, что очень важно поддержание актуальности, учитывая непрерывно меняющееся законодательство.
Поэтому я бы очень осторожно отнесся к идее поэтапного перехода от простого расчета начисления заработка, связанного с продажами к полнофункциональной зарплатной системе. Соотношение трудозатрат по написанию и поддержке с одной стороны, количества возможных заказчиков с другой стороны и суммы регулярной оплаты поддержки такой системы вряд ли будет взаимоприемлемым для разработчиков и клиентов.