Наверх

База знаний
Try 2 Fix
beta

СБИС++: Сдача больничных листов в ФСС

Наш бухгалтер снова толкает нас на подвиги: потребовалась сдача листов о временной нетрудоспособности (больничных листов) в электронном виде через СБИС++. Мы нашли множество инструкций как это сделать, но есть одна загвоздка: такого отчёта нет в списке. Находим его!

Для того, чтобы сдавать отчётность через СБИС++, делаем следующее:

  1. Выберите в левой панели «ФСС».
  2. В главном окне программы идём по пути: «Сервис» > «Конфигурация задачи»
  3. Переходим на вкладку «Параметры ФСС»
  4. Ставим галочку «Организация участвует в пилотном проекте ФСС»

Теперь больничные листы можно сдавать через СБИС++. Для этого

  1. Нажимаем в главном окне «Новый отчёт»
  2. Идём на вкладку «ФСС» > «Дополнительно»
  3. Выбираем «Реестр сведений, необходимых для назначения и выплаты пособий». Готово!

Остались вопросы?

Лоджик Флоу


Аутсорсинг / Системное администрирование / Техническая поддержка / Сопровождение 1С:Предприятие

+7 (8634) 383-490 / +7 (906) 430-7000
mail@logicflow.ru

Что-то пошло не так? Специалисты нашей компании помогут Вам разобраться с возникшими проблемами! Обращайтесь! →

Также Ваши вопросы Вы можете задать в нашей группе ВК или на нашем YouTube канале!

Эти статьи будут Вам интересны

Zimbra 8.6 OSE: Произошла неизвестная ошибка (mail.TRY_AGAIN). Ошибка сети. postfix/postqueue fatal: Queue report unavailable — mail system is down

На корпоративном почтовом сервере Zimbra OSE пользователи при отправке внутренней почты стали получать сообщение "Произошла неизвестная ошибка (mail.TRY_AGAIN)", другие пользователи увидели "Ошибка сети". А мы во всех логах (/var/log/zimbra.log, /var/log/mail.log и /var/log/mail.err)  увидели это волшебное сообщение "postfix/postqueue fatal: Queue report unavailable - mail system is down". Работа была парализовано, но решение оказалось простым.

Тюнинг PostgreSQL 9.4.2-1.1C для 1С:Предприятия 8.3: рельаный опыт настройки

Как только размер файловой базы данных 1С:Предприятие одного из наших клиентов достиг размера в 32Гб (да, 32Гб), в следствии чего всё постепенно начало тормозить, а потом и встало намертво, наши клиенты попросили нас решить эту проблемы. SSD Enterprise класса ненадолго подсластил пилюлю, но через некоторое время всё вернулось в исходную точку. Ну что ж, тут и к бабке не ходи – переходим на SQL версию БД. Поскольку мы ярые пользователи Windows, доступно нам только два варианта СУБД – это MSSql и PostgreSQL. Первый хорош до безумия, но стоимость не порадовала. А ещё больше не порадовала новость о дополнительных лицензиях 1С для работы с MSSQL. Поэтому PostgreSQL. Подробная инструкция с видео доступна здесь. В этой статье мы пройдёмся по ключевым моментам. Не забываем про резервное копирование баз данных 1С! Исходные данные: ОС Windows Server 2008R2, Intel Core i7-2600K 3.40GHz, 32Gb RAM, Intel SSD DC3700 100Gb (только под БД, ОС на отдельном SSD), от 10 до 20 пользователей в БД ежедневно, обмен с 5 узлами распределённой БД в фоне. Зловеще, не правда ли? Приступим.

Удалённый доступ с мобильного устройства к видеорегистратору HikVision без статического белого IP адреса. Проброс портов в Windows с помощью portproxy

Не так давно столкнулись со следующей задачей: необходимо предоставить удалённый доступ с Android устройства к видеорегистратору HikVision, который находится в сети, Интернет в которой раздаётся с помощью 4G-модема (то есть нет белого статического IP). Недолго думая, мы предоставили клиенту доступ к нашему OpenVPN, с помощью которого мы собирались связать мобильное устройство на Android и сам видеорегистратор. Ок, на Android существует множество OpenVPN клиентов, но вот на видеорегистратор клиент OpenVPN поставить никак не получится. Тогда было решено задействовать ПК на ОС Windows, который находился в одной сети с видеорегистратором. Подробно рассказываем о наших шагах к достижению поставленной цели.