Поступил вопрос о том, что со след года будут прямые выплаты больничных на Мир из-за чего надо предусмотреть ситуацию наличия у сотрудника двух карт - обычной для зп и Мир для больничных выплат. Кому-то задавали такой вопрос?

(0) вроде тут есть ответ - https://okssoft.ru/blog/t_staheeva/neskolko-zarplatnykh-proektov-litsevykh-schetov-u-sotrudnika-v-1s-zup-/

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

У нас в регионе пилот довольно давно начинался. Это в каком-то смысле тоже было аргументом для перехода с 2.5 на 3 побыстрей.

(2) Самый насущный вопрос: "Зачем зарплатный проект?!" (правда, слова слегка другие... Все на нервах...)

(3) ну и это тоже. Так сказать, если это костыль, то он костылем и останется - как бы ты его ни вертел в руках

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

Т.е. основная карта может быть вообще любой, а МИР запоминается только для прямых выплат, если введена в заявлении.
У нас пилотный проект с середины 2017.

А мы вообще решили карты Мир посадить в свойства сотрудника.
Все равно ЗП туда не платим и не планируем.
P.S.: да, пришлось поправить выгрузку.

(5) у вас пилотный проект? подскажи, сумма больничного в зуп где-то при этом фигурирует? образно - если есть задача доплатить больничный до оклада, это можно сделать или суммы только в ФСС и сколько доплачивать - не ясно (надо делать свой расчет больничного)?

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

(7) Сумма нет, если речь про больничный из средств ФСС. Но в самом больничном зафиксирован средний заработок, а в табличной части по начислениям - количество дней к оплате. Сильно глубоко не копал, но нужные данные вытащить можно либо из больничного, либо из связанного с ним заявления в ФСС.

(9) А РСВ как заполняется?

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

(11) Мне везло в том плане, что у нас нет доплат к больничному... Поэтому не разбирался. Но думаю, что альтернативный расчет не так сложен, особенно у хозрасчетников, можно взять средний заработок напрямую из реквизита.

(10) В РСВ не попадает то, чего нет в базе, все в порядке ))

(12) А налоги кто считает? А платит?

+ (13) И в расчетном листке тоже ничего нет?

(13) Кто выплаты производит, тот и налоговый агент.
(14) Если речь про начисления из ФСС - нет.

(13) Ст. 24 НК РФ, п.1.

(12) там все довольно криво реализовано. Взять может и можно, но если совсем-совсем ничего не дорабатывать, то созданный расчетчиками вид расчета не может увидеть Показателей от введенного больничного со значениями. Как бы без дописывания своего кода не работает.

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

1. Создать показатель расчета зарплаты
2. Создать вид начисления - начислять, если введено значение показателя
3. Обработка: анализирует больничные, вытаскивает из них данные о среднем, рассчитывает доплату, сливает данные в документ "Данные для расчета зарплаты", проводит его

Плюсы такого решения - все реализовано штатными средствами, и при обновлении конфигурации нужно всего поправить обработку.
Минусы - кому-то может не понравиться, что расчет идет не в документе "Больничный", но это уже дело вкуса, я считаю.

(18) Ну вместо обработки можно и расширением докрутить. Конфиг будет обновляться как типовой. И кстати, если уж делать обработкой, то результат можно привязать к таб части в самом больничном. Просто в штатном исполнении интерактивное добавление расчетов туда не доступно.

Вариантов много. Иногда, даже интересные. Для заказчика они все плохие тем, что должен быть в наличии разработчик.

(19) Есть один вариант без разработчика ))

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

(21) - А почему? -Не знаю… пробуют, хвалят, а не берут.

(22)+ не ужели всё ещё практикуют подобные схемы ?

(22) Видать кто-то им поближе к Москве приглянулся. Кроме возраста, это все еще значимый фактор, т.к. удаленка хоть и есть, но если потребуется внезапно приехать в офис, то преимущество у того, кто может добраться до офиса в пределах нескольких часов и без перелета на самолете :-)

(21) насколько я понял, расширения - самое геморное в поддержке, на нынешнем этапе развития 1с. Хотя и вмешательство в конфигурацию немногим лучше. Исключение - доработки "сбоку", не затрагиваюшие основной функционал.

Поэтому я за штатные решения + обработки.

(24) весной это наверно так и было и в большем количестве.
сейчас можно сказать поговоркой "не было бы счастья — да несчастье помогло!" к удаленке относятся все терпимее. )
можно сказать освободительный локдаун от офисной зарузки по миру распространился  )

(25) Неправильно ты понял. На своем опыте могу сказать, что все в точности наоборот.

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

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

Моя мысль в том, что все-таки иногда что-то на работе происходит, когда быть там все-таки приходится. Может организация труда не отработана до конца. Всяко бывает. Но из двух удаленщиков предпочтение отдадут тому, кто находится ближе, кому не нужно планировать поездку в офис строго за пару-тройку недель, либо ехать самому в легковой машине примерно от 12 до 20 часов (как повезет с состоянием дороги)

походу надо походить по вакухам, посмотреть, что сейчас на рынке с удаленкой. 5 дней в неделю ездить в офис в разгар эпид. сезона не очень радует, но местное руководство считает это нормальным

(27) То есть - с расширениями все норм? Можно справочники, документы пилить? И регистры? После обновления не падает?

(30) про релиз платформы не забывать только.

(27) Все от задачи зависит, так что спорить не буду. На самом деле, комбинирую все три способа, но если есть возможность обойтись только внешней обработкой - добавленной в справочник внешних - то ею и обхожусь.

Расширения отваливаются, у изменения конфы свои минусы (долгое обновление). В общем, я не фанатик обработок, но лезть лишний раз в конфу не буду.

(27) "На выборах в США победит кандидат с именем на букву "Д"(русск.)"

У меня в отделе ведения учета 42 базы, я лучше выложу обработку в расшаренную папку. Так что насчет расширений не надо мне тут ))

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

Блин в 33 не то в буфер вставил. Но по номеру понятно что, я надеюсь.

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

(30) Ну я не жалуюсь.

Новые документы, справочники и регистры. Роли пользователей, опять же - не снимая типовую с замка.

Лично я типовые объекты структурно не модифицирую совсем. Принципиально. Хоть напрямую внося изменения в конфигурацию, хоть через расширение.

Бурно обсуждавшееся в свое время на Мисте проблема с разрушением данных, если использовалось расширение - это была все-таки модификация структуры у типовых. Даже тогда, если данные в расширении были созданы отдельно, да, они могут стать недоступны, если расширение отключится, но они не удаляются физически.
А бэкапы никто не отменяет, хоть есть расширения, хоть их нет совсем.

(34) Внешние обработки из папки стартовать... Ну ладно, я программист и прав выше крыши. Для пользователей может быть критично.

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

И обновить расширение из внешнего файла на 40 базах, а какая разница, когда надо 40 раз ее заменить внутри справочника внешних обработок?

Как-то так :-)

Но я не гипер-фанат. Просто не люблю, когда что-то ругают, а чего ругать, если для каждого инструмента есть свое оптимальное применение и кому-то оно идеально подходит :-)

(37) "И обновить расширение из внешнего файла на 40 базах, а какая разница, когда надо 40 раз ее заменить внутри справочника внешних обработок?"

Да, тут разницы никакой, поэтому в отделе ведения учета просто из расшаренной папки открываем.  пока что это оптимальный способ.