Всем привет.
ЗУП 3.1.10.443
Зарплата начисляется по подразделениям.
Если сотрудник был переведен из одного подразделения в другое, то при заполнении документов Начисление ЗП по этим подразделениям, сотрудник попадает в каждый из этих документов.
В связи с чем по некоторым начислениям есть ошибки расчета. А некоторые вообще не попадают ни в один документ.
Если сделать Начисление ЗП без подразделения и вручную подобрать такого сотрудника, то в документ правильно встают все его начисления по обоим подразделениям.
Если же начисление ЗП разбивается на 2 документа, то сотрудник попадает в оба, начисления делятся по двум документам, а некоторые начисления, в расчетную базу которых входят другие начисления, не попадают никуда. Причем я заметил, что не попадают те начисления, у которых пустая вкладка приоритетов.
Я думаю было бы удобно, если бы при кадровом перемещении сотрудник попадал в документ Начисление ЗП по последнему подразделению, чтобы собрать всё в одном месте.
Нет такой настройки в ЗУП?
И как все выходят из данной ситуации?
Просто узнал, что расчетчики оказывается вручную таких отслеживали, но их у нас очень много. А сейчас добавился один вид расчета, с которым совсем стало проблемно делать вручную.

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

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

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

(1) В ЗУП2.5 было можно разделить собственно начисление зарплаты (и делать его отдельными документами по подразделениям) и начисление налогов и взносов. Там всё удобно было для больших организаций с множеством расчетчиков. А налоги считал старший расчетчик.
Теперь же в 3.1 если человек работал в нескольких подразделениях и расчет ведется в нескольких документах, у него будет несколько расчетов налогов и взносов, зависящих от порядка ввода документов - в результате практически неизбежны ошибки или лишние перерасчеты. И за этим всем надо следить особо внимательно. Считаю, зря они так сделали.

(2) не, не думаю, что совсем зря - там сделано с умыслом :-)

(3) Ну да.. 6-ндфл, чтоб её..

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

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

(5) Не совсем. ГОда полтора назад было чтото в обновлении с описанием типа "делалось для проекта в Росгвардии". Но оно и понятно, проект там - чуть ли не крупнейший в стране

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

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

Подразделений очень много, сотрудников тоже. Мы и так разбили на самые крупные подразделения, программа еле ворочается, когда считает такие огромные документы по несколько тысяч строк в каждом. Укрупнять дальше точно нельзя.
Значит выхода нет, только вручную остлеживать, ну там с помощью отчетов каких-то самописных...

А разве нельзя таких переведенных сотрудников собрать в один документ, без учета подразделений, и рассчитать?
А из документов расчета по подразделениям, соответственно, убрать.

(9) Конечно можно, но это вручную и долго. Сотрудников очень много, переведенных тоже. Расчетчиков тоже.
Так и придется делать.

(10) Обработки заполнения ТЧ в помощь.

(8) Вам нужно искать более корректное решение.
Выше косвенно в (7) об этом сказано.

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

А сколько у вас на одной Организации расчетчиков? Хотя, это уже будут размышления не о том, что спрашивалось в топике :-)

(12) "Оно оттого и считается с таким напряжением, что делается грубо говоря не с тем способом"
А каким способом нужно?
Ну допустим разделим начисление зарплаты и взносов на разные документы (хотя честно говоря я тоже не слышал о такой типовой возможности).
Допустим отключим авторасчет (кстати он всегда был отключен, недавно заметил что его включили, но жалоб на тормоза как-то не прибавилось от этого).
Дальше думать как ещё облегчить документ, выносить какие-то расчеты вне его?
Но у нас есть подразделения, в которых по 5 тыс. строк. Всё-равно в один документ все подразделения не запихать. Тут проще отслеживать перемещения, мне кажется.
Или я не понял Вашей идеи.

Основной посыл моей идеи - у вас данных больше, чем "доступно и всерьез" - путь дальнейших доработок в программе, вне зависимости от того, хочу на этом денег заработать я лично или нет (на практике я на подобном ни хера не заработал ни разу увы и ах))... так вот путь этот не простой и достаточно трудозатратный. Как в плане программирования, так и в плане методической работы в части постановки учета, организации процессов и т.д. и т.п.

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

Проще отслеживать Перемещения? Конечно! Тысячу раз проще. Автоматизируйте им эту процедуру или процесс должным образом и все будет просто замечательно.

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