Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

ЗУП 3.1. Прямые выплаты больничных на карту МИР

ЗУП 3.1. Прямые выплаты больничных на карту МИР
Я
   Target25
 
03.11.20 - 08:06
Поступил вопрос о том, что со след года будут прямые выплаты больничных на Мир из-за чего надо предусмотреть ситуацию наличия у сотрудника двух карт - обычной для зп и Мир для больничных выплат. Кому-то задавали такой вопрос?
   Target25
 
1 - 03.11.20 - 08:09
   Фрэнки
 
2 - 03.11.20 - 08:15
Угу. Выглядит немного костылями, т.к. все обламывается наличием "зарплатного проекта". Нужно не просто иметь множество лицевых счетов, но еще и иметь отметки в какой платежной системе эти счета работают. Но в полуавтоматическом режиме все работает.

У нас в регионе пилот довольно давно начинался. Это в каком-то смысле тоже было аргументом для перехода с 2.5 на 3 побыстрей.
   Масянька
 
3 - 03.11.20 - 08:19
(2) Самый насущный вопрос: "Зачем зарплатный проект?!" (правда, слова слегка другие... Все на нервах...)
   Фрэнки
 
4 - 03.11.20 - 08:20
(3) ну и это тоже. Так сказать, если это костыль, то он костылем и останется - как бы ты его ни вертел в руках
   SleepyHead
 
5 - 03.11.20 - 08:42
При оформлении первого заявления на выплату пособия реквизиты карты МИР придется ввести вручную, дальше ЗУП их запоминает и использует только в заявлениях.

Т.е. основная карта может быть вообще любой, а МИР запоминается только для прямых выплат, если введена в заявлении.
У нас пилотный проект с середины 2017.
   Lokli
 
6 - 03.11.20 - 09:22
А мы вообще решили карты Мир посадить в свойства сотрудника.
Все равно ЗП туда не платим и не планируем.
P.S.: да, пришлось поправить выгрузку.
   KnightAlone
 
7 - 03.11.20 - 09:30
(5) у вас пилотный проект? подскажи, сумма больничного в зуп где-то при этом фигурирует? образно - если есть задача доплатить больничный до оклада, это можно сделать или суммы только в ФСС и сколько доплачивать - не ясно (надо делать свой расчет больничного)?
   Масянька
 
8 - 03.11.20 - 09:30
НУ, вы же понимаете: "зарплатный проект" был создан для облегчения работы расчетчиков, а теперь - костыль. А что будет через год (два и более вообще не стоит трогать) - даже Богу не известно (эксперимент по заселению Земли вышел из-под контроля).
   SleepyHead
 
9 - 03.11.20 - 09:34
(7) Сумма нет, если речь про больничный из средств ФСС. Но в самом больничном зафиксирован средний заработок, а в табличной части по начислениям - количество дней к оплате. Сильно глубоко не копал, но нужные данные вытащить можно либо из больничного, либо из связанного с ним заявления в ФСС.
   Масянька
 
10 - 03.11.20 - 09:37
(9) А РСВ как заполняется?
   KnightAlone
 
11 - 03.11.20 - 09:38
(9) ясно, ну я так и предполагал, что точной суммы известно не будет, то есть надо будет делать свой расчет. сейчас то ладно, все алгоритмы еще есть в больничном, скорее всего их можно оттуда вырвать и использовать, а через год другой, когда расчет другой придумают, в а ЗУП его реализовывать никто не будет ибо не надо - надо будет все вручную допиливать
   SleepyHead
 
12 - 03.11.20 - 09:45
(11) Мне везло в том плане, что у нас нет доплат к больничному... Поэтому не разбирался. Но думаю, что альтернативный расчет не так сложен, особенно у хозрасчетников, можно взять средний заработок напрямую из реквизита.

(10) В РСВ не попадает то, чего нет в базе, все в порядке ))
   Масянька
 
13 - 03.11.20 - 10:02
(12) А налоги кто считает? А платит?
   Масянька
 
14 - 03.11.20 - 10:02
+ (13) И в расчетном листке тоже ничего нет?
   SleepyHead
 
15 - 03.11.20 - 10:08
(13) Кто выплаты производит, тот и налоговый агент.
(14) Если речь про начисления из ФСС - нет.
   SleepyHead
 
16 - 03.11.20 - 10:10
(13) Ст. 24 НК РФ, п.1.
   Фрэнки
 
17 - 03.11.20 - 13:13
(12) там все довольно криво реализовано. Взять может и можно, но если совсем-совсем ничего не дорабатывать, то созданный расчетчиками вид расчета не может увидеть Показателей от введенного больничного со значениями. Как бы без дописывания своего кода не работает.
   SleepyHead
 
18 - 03.11.20 - 13:29
(17) Эту тему  какой-то другой ветке обсуждали, я предложил решение без вмешательства в конфигурацию. Ты там тоже был, насколько помню.

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

Плюсы такого решения - все реализовано штатными средствами, и при обновлении конфигурации нужно всего поправить обработку.
Минусы - кому-то может не понравиться, что расчет идет не в документе "Больничный", но это уже дело вкуса, я считаю.
   Фрэнки
 
19 - 03.11.20 - 13:36
(18) Ну вместо обработки можно и расширением докрутить. Конфиг будет обновляться как типовой. И кстати, если уж делать обработкой, то результат можно привязать к таб части в самом больничном. Просто в штатном исполнении интерактивное добавление расчетов туда не доступно.

Вариантов много. Иногда, даже интересные. Для заказчика они все плохие тем, что должен быть в наличии разработчик.
   SleepyHead
 
20 - 03.11.20 - 13:46
(19) Есть один вариант без разработчика ))
   Фрэнки
 
21 - 03.11.20 - 13:50
(20) да меня по весне пытались тестировать при приеме на работу. Примерно из этого, тоже со средними, кстати, больничные там в задании тоже были. Тем кто тестировал меня вроде бы мои предложения понравились, хотя я так сам себе догадываюсь, что им хотелось с меня расширением все решение получить и не заплатить за него. Уж хвалили, хвалили, но на работу не взяли. Но и я им расширения делать не стал.
   kzot
 
22 - 03.11.20 - 13:54
(21) - А почему? -Не знаю… пробуют, хвалят, а не берут.
   kzot
 
23 - 03.11.20 - 13:56
(22)+ не ужели всё ещё практикуют подобные схемы ?
   Фрэнки
 
24 - 03.11.20 - 14:02
(22) Видать кто-то им поближе к Москве приглянулся. Кроме возраста, это все еще значимый фактор, т.к. удаленка хоть и есть, но если потребуется внезапно приехать в офис, то преимущество у того, кто может добраться до офиса в пределах нескольких часов и без перелета на самолете :-)
   SleepyHead
 
25 - 03.11.20 - 14:07
(21) насколько я понял, расширения - самое геморное в поддержке, на нынешнем этапе развития 1с. Хотя и вмешательство в конфигурацию немногим лучше. Исключение - доработки "сбоку", не затрагиваюшие основной функционал.

Поэтому я за штатные решения + обработки.
   kzot
 
26 - 03.11.20 - 14:08
(24) весной это наверно так и было и в большем количестве.
сейчас можно сказать поговоркой "не было бы счастья — да несчастье помогло!" к удаленке относятся все терпимее. )
можно сказать освободительный локдаун от офисной зарузки по миру распространился  )
   Фрэнки
 
27 - 03.11.20 - 15:03
(25) Неправильно ты понял. На своем опыте могу сказать, что все в точности наоборот.

И еще раз, если ты используешь обработку, то совершенно нет никаких разумных причин держать эту обработку где-то неизвестно где, вместо того, чтоб использовать ее размещение внутри расширения.
   Фрэнки
 
28 - 03.11.20 - 15:08
(26) "Они" терпимее, мне в нынешней ситуации теперь и здесь, в самой ближайшей к дому локации почти не приходится на работу ездить, в сравнении с тем, как было раньше.

Моя мысль в том, что все-таки иногда что-то на работе происходит, когда быть там все-таки приходится. Может организация труда не отработана до конца. Всяко бывает. Но из двух удаленщиков предпочтение отдадут тому, кто находится ближе, кому не нужно планировать поездку в офис строго за пару-тройку недель, либо ехать самому в легковой машине примерно от 12 до 20 часов (как повезет с состоянием дороги)
   KnightAlone
 
29 - 03.11.20 - 15:20
походу надо походить по вакухам, посмотреть, что сейчас на рынке с удаленкой. 5 дней в неделю ездить в офис в разгар эпид. сезона не очень радует, но местное руководство считает это нормальным
   Масянька
 
30 - 03.11.20 - 15:38
(27) То есть - с расширениями все норм? Можно справочники, документы пилить? И регистры? После обновления не падает?
 
 Рекламное место пустует
   kzot
 
31 - 03.11.20 - 15:40
(30) про релиз платформы не забывать только.
   SleepyHead
 
32 - 03.11.20 - 16:04
(27) Все от задачи зависит, так что спорить не буду. На самом деле, комбинирую все три способа, но если есть возможность обойтись только внешней обработкой - добавленной в справочник внешних - то ею и обхожусь.

Расширения отваливаются, у изменения конфы свои минусы (долгое обновление). В общем, я не фанатик обработок, но лезть лишний раз в конфу не буду.
   SleepyHead
 
33 - 03.11.20 - 16:05
(27) "На выборах в США победит кандидат с именем на букву "Д"(русск.)"

У меня в отделе ведения учета 42 базы, я лучше выложу обработку в расшаренную папку. Так что насчет расширений не надо мне тут ))
   SleepyHead
 
34 - 03.11.20 - 16:11
Но если есть способ как-то натянуть расширение на базу не вручную, я бы рассмотрел. Но пока такого не знаю.
   SleepyHead
 
35 - 03.11.20 - 16:11
Блин в 33 не то в буфер вставил. Но по номеру понятно что, я надеюсь.
   SleepyHead
 
36 - 03.11.20 - 16:16
Такое умеет обновлятор, и он у нас куплен, так что при желании можно реализовать. Объяснил другому, сам понял, всем спасибо.
   Фрэнки
 
37 - 03.11.20 - 16:25
(30) Ну я не жалуюсь.

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

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

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

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

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

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

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

Но я не гипер-фанат. Просто не люблю, когда что-то ругают, а чего ругать, если для каждого инструмента есть свое оптимальное применение и кому-то оно идеально подходит :-)
   SleepyHead
 
38 - 03.11.20 - 17:35
(37) "И обновить расширение из внешнего файла на 40 базах, а какая разница, когда надо 40 раз ее заменить внутри справочника внешних обработок?"

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.