Для производственного предприятия самый логичный вариант - перейти на 1C ERP(или КА). Но учитывая космический ценник на внедрение, на сколько жизнеспособна схема УПП+БП+ЗУП?
Расскажу наш опыт. После долгого выбора остановились на связке УПП+БП+ЗУП. Закупили программные продукты. Перевели кадровый и зарплатный учет на ЗУП. Это не так сложно. Обмен идет из ЗУП в УПП сотрудники справочник, отражение БУ и резервы по отпускам документы. Написали планы обмена. И началось...Перевод на единый налоговый счет - переписали, замена резервов по отпускам на резервы по оплате - переписали, ну и по мелочам. Если есть свой человек по обменам на окладе, тогда можно такую связку использовать. Дак это всего лишь ЗУП! А в БП подобных изменений будет куда как больше. В итоге купили ERP.
(4)На предприятии не используем данный вид работ. Все данные для расчета зарплаты ведутся через вид документа КТУ, а сдельных работ нет. Полагаю, что по данному функционалу надо настроить новый способ отражения и переносить в УПП. Но это не точно)) Нет подобной практики.
(4) Если вы про "Сдельный наряд", который в УПП.
Его можно вести в УПП, но при работе в тандеме с ЗУПом в том документе надо отключать движения.
Ну пожалуй кроме РН "Фактическая выработка сотрудников организаций"
Рекомендую следующее:
1. Сдельный наряд - без движений, кроме фактической выработки.
А еще лучше к этому документу написать свой регистр, куда он будет выкладывать нужную для обмена в ЗУП информацию.
2. Создать свой документ-агрегатор, который собирает в себя данные из этого регистра.
Это денежная выработка на каждого сотрудника в разрезах:
-- период (день)
-- подразделение - исполнитель
-- подразделение затрат
-- номгруппа затрат
-- статья затрат
Режим заполнения в целом: за 1 половину месяца (для аванса), за месяц (для расчета зарплаты), произвольный (для увольнения)
Булевный реквизит "Передать в ЗУП".
Проведение документа-агрегатора передает в ЗУП этот набор данных.
И еще к агрегатору свой регистр, куда выкладывается "его содержимое", чтобы очередной агрегатор, при условии пересечения параметров заполнения учитывал уже выложенное в регистр
3. На стороне ЗУП набор данных ОБМЕНОМ приходит в "Данные для расчета зарплаты".
Сделать один вид работ для этого, лучше - предопределенный.
Расценка = 1 руб.
В документ суммы входят как "объем работ", при проведении умножаются на 1 руб и становятся суммой дохода сотрудника
В табличной части заполнение по дням, по сотруднику.
Подразделение - синхронизируется с "подразделением - получателем" из УПП. Но оно здесь больше для наглядности.
Способ отражения также заполняется в табличную часть
В нем сделать 3 реквизита (можно допреквизиты, но значения плана вида характеристик лучше предопределенные)
1. - Для подразделения затрат
2 - номгруппа
3 - статья затрат
Способ при загрузке данных подыскивается автоматически по значениям этих допреквизитов, если нет - создается автоматически и способ подставляется в строку документа.
4. Эти суммы "прокручиваются" в Начислении зарплаты. Важно, чтобы у сотрудника основной вид начисления имел назначение "Сдельная оплата"
5. В отражение его сдельный заработок зайдет множеством строк по "Способам отражения", которые в табличной части "Данных для расчета зарплаты". Что и требовалось достичь.
"Резервы" будут также в разрезе "способов"
6. Для загрузки в УПП предварительно эти же (синхронизируемые) способы отражения должны быть предварительно настроены, то есть четко в них проставлены: подразделение затрат, номгруппа и статья затрат.
Итог:
Обменом заходит отражение, и в нем сделаны проводки точно такие же, какими их сделал бы в УПП "Сдельный наряд"
(7) мы планировали приобрести
https://infostart.ru/marketplace/310433/ общались на эту тему с техподдержкой инфостарта, все выглядело вроде и не плохо, но не рискнули.
Вот человек занимается
https://infostart.ru/1c/tools/1845401 Но у нас завод, 24/7, полагаться на не типовые решения без своих компетенций руководство не одобрило.
Да какой "внедряли"?! Только в самом начале пути. На начало года запланировали покупку здесь планов обмена, "туда-обратно" с модулем автообмена. А пока пилим свои планы переноса. Хотя бы для того, чтобы поработать с ERP в более-менее реальных данных. Да и с инфостартовскими планами обмена будет легче потом разобраться. Надеемся, что до 2026 года все успеем))