Если простой произошел по вине работодателя или по причинам, не зависящим от работника и работодателя, то время простоя подлежит оплате.
Для начисления оплаты за время таких простоев вводится документ Регистрация простоев сотрудников организаций.
В шапке документа указываются:
организация; месяц начисления; работник, которому производится начисление оплаты за период простоя;
На закладке Условия выбирается вид простоя:
По вине работодателя - оплата производится в размере 2/3 среднего заработка; По причинам, не зависящим от работодателя и работника - оплата производится в размере 2/3 тарифной ставки работника.
В реквизите Дата начала периода простоя указывается указывается дата начала простоя, на которую будет определяться тарифная ставка работника или расчетный период для расчета среднего заработка для оплаты простоя.
В группе реквизитов Период оплачиваемого времени указывается оплачиваемый период простоя (для целодневных простоев) или дата и количество часов простоя (для внутрисменных простоев).
Расчет оплаты производится по кнопке <Рассчитать>.
Результаты расчета помещаются в табличную часть на закладке Оплата.
В табеле:
Время простоя по вине Работодателя - РП
Время простоя по вине Работника - ВП
По причинам, не зависящим от них - НП
Время простоя оплачивается на основании данных табеля учета использования рабочего времени, в котором указываются часы и дни простоя. Простой, который произошел в течение одной смены, оформляется листком учета простоев, в котором отражаются его причины, продолжительность, тарифная ставка работника, размер оплаты и сумма.
При этом время простоя по вине работодателя оплачивается в размере не менее 2/3 среднего заработка работника, а время простоя по причинам, не зависящим от работника и работодателя, - в размере не менее 2/3 тарифной ставки (оклада).
Время простоя по вине работника не оплачивается!
Обратите внимание! Законом установлены низшие пределы оплаты времени простоя. Если трудовым, коллективным договором или соглашением предусмотрен иной порядок оплаты, то применяются правила соответственно трудового, коллективного договора, соглашения, если они не ухудшают положение работника по сравнению с действующим трудовым законодательством Российской Федерации.
Средний заработок при оплате времени простоя по вине работодателя определяется в общем порядке, установленном ст. 139 ТК РФ, а также Постановлением Правительства РФ "Об особенностях порядка исчисления средней заработной платы".
В расчет включаются все предусмотренные системой оплаты труда выплаты, которые начислены работнику за 12 месяцев, предшествующих тому, в котором произошел простой.
Я думаю каждый хоть раз, но сталкивался с ошибкой 1С Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Неопознанная ошибка HRESULT=80004005
Вот некоторые способы, которые помогут решить данную проблему:
1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду “Проверка конфигурации” с установленным флажком “Проверка логической целостности конфигурации”. При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).
2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.
3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С – это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.
2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)
вот пример работоспособности этого приема
http://partners.v8.1c.ru/forum/thread.jsp?id=543293
или
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
Взято с http://www.forum.mista.ru/topic.php?id=465608
можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]
5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.
6) Ошибка :"Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005"
Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)
Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется... Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки - все ОК.
У Вас есть свое решение!? оставьте его в комментариях)
Часто при ведении учета в различных конфигурациях 1с возникает необходимость выполнения обмена данных. Для решения этой задачи принято использовать Универсальный обмен данными XML или другие внешние обработки, общим у которых является использование текстовых файлов посредников.
Я предлагаю использовать Web-сервисы 1с. В чем необходимость обмена: Обмен данными между базами требуется для исключения дублирующих вводов одних и тех же данных в различных учетных системах. В чем необходимость обмена в режиме online: Обмен в онлайн режиме требуется когда функции учета комплекса учетных систем выполняются в разных учетных системах.
1. Например компания использует: CRM систему учета, для ведения учета взаимоотношений с клиентами; БП 2.0 для ведения взаиморасчетов с клиентами в разрезе счетов; Счета выставляемые клиентам создаются в торговой базе, а оформление заказов поставщикам исходя из потребности клиентов в базе ориентированной на работу с пайсами поставщиков. При таком разделенном построении учета, для выставления счета в одной из баз к примеру требуется завести карточку клиента в другой базе с тем чтобы данные о контрагенте так же были доступны в базе со счетами.
2. Помимо синхронизации первичных данных, может возникнуть необходимость построения сводного отчета по данным из нескольких баз, что тоже потребует обращения к внешним данным в online режиме.
Вариант автоматизации данного процесса с использованием файлов обмена, потребует подключения обработчика ожиданий, что сможет обеспечить обмен данными только с установленной задержкой времени обмена, кроме того любая обработка ожидания будет не эффективно использовать машинное время.
Обращение к Web сервисам, возможно при возникновении любых событий (ПриЗаписи, ПриПроведении, при нажатии кнопки и т.д.). при этом не возникнет ни какой задержки реакции информационной базы к которой происходит обращение, (в отличие от запуска еще одного приложения 1с в качестве com объекта).
Итак рассмотрим вариант реализации синхронизации элементов справочников, начнем с наиболее простого со справочника "Товары" в базах "Продажи" и "Закупки". Синхронизация для начала будет односторонней, предположим что перечень товаров заводится в базе "Продажи", а в "Закупки" он передается.
Что нам потребуется для того чтобы задача возникла и могла быть решена.
1. Сервер 1с, с установленной web компонентой;
2. веб-сервер (например IIS 6.0);
3. Две или более конфигурации учетных систем.
Что нам потребуется для решения задачи.
1. Создадим в базе "Закупки" Web-сервис "Синхронизация", и добавим ему Операцию "СинхронизироватьТовар", со строковыми параметрами.
1. "GuidТовара" - сюда будем передавать уникальный идентификатор товара присвоенный в базе Продаж.
2. "GuidРодителя" - уникальный идентификатор родителя данного товара.
3. "стрСтруктураРеквизитов" - Структура реквизитов товара в виде примитивных типов (число,строка,дата,булево) преобразованная в строку.
4. "этоГруппа" - реквизит котрый позволит нам не раскрывая всей структуры реквизитов товара узнатья явлется ли товар группой и соответственно его обработать.
5. "стрТаблицаЕденицИзмерения" - Таблица содержащая описание доступных единиц измерения для товара
Далее потребуется опубликовать данный сервис на веб сервере. для этого нужно будет создать текстовый файл "wssinhron.1cws", в каталоге сайта опубликованном на веб сервере. Библиотека wsisapi.dll, должна быть подключена. Проще всего корректную настройку работы веб сервера с 1с можно провести опубликовав веб приложение через конфигуратор Администрирование->"Публикация на веб сервере". Единственным минусом является, то что в версии 8.2 файлы веб сервисов *.1cws, сами не создаются. Возможно просто мне не хватает знаний по этому вопросу но для публикации веб сервисов я пользуюсь блокнотом.
Также следует учесть что на серверах 64x следует использовать wsisapi.dll из поставки 1с 64x, даже если сам сервер 1с у вас 86x.
Итак создаем файл "wssinhron.1cws" с текстом.
{Название вашего сервера 1с}";Ref="{Назваение базы. у нас это "Market"}";"/>
Далее перейдем в модуль обработки нашего Сервиса, для наглядности я приведу пример кода своей разработки
Теперь, как вызвать веб сервис не зациклив при этом систему.
в нашем справонике "Товары" в базах "Продажи" и "Закупки" нам потребуются служебные реквизиты. 1. "GUIDтовара" - строковый реквизит (50)
2. "ВремяСинхронизации" - Реквизит с типом Дата и Время
3. "Синхронизирован" - тип булево.
В модуль объекта Справочника добавим предопределенные обработчики событий "ПередЗаписью()", "ПриЗаписи()" функцию "Синхронизация()" и общую переменную "передавать", и под текстом модуля присвоим этой переменной значение Истина. Перем передавать Экспорт;
Процедура ПередЗаписью(Отказ)
Процедура ПриЗаписи(Отказ)
Функция Синхронизация()
передавать = истина;
Таким образом получится что при любой инициализации модуля наша переменная всегда имеет значение истина.
Рассмотрим наши процедуры:
Таким образом остается добавить в событие формы элемента "ПриЗаписи()"
И мы сможем записывать наш элемент сколько угодно раз не вызывая зацикливания.
Для варианта двусторонней синхронизации, (когда элемент справочника может редактироваться в обоих базах) нам потребуется скопировать наш веб сервис из базы закупок в базу продаж переименовав имя файла публикации и URI пространство имен и внести соответствующие изменения в вызов веб сервиса из базы продаж в базу закупок и опубликовать его. Важно: При успешном срабатывание вызванного сервиса из базы "Продажи", в качестве результата работы должен быть возвращен уникальный идентификатор элемента справочника из базы "Продажи". Данный результат необходимо будет присвоить соответсвующиму реквизиту справочника из базы закупок.
Аналогично приведенному примеру можно синхронизировать данные любого справочника или документа.
Построение сводных отчетов
Для получения сводного отчета нам также потребуется вызов веб сервиса из какой - либо базы. Данный веб сервис должен будет возвращать преобразованною в строку, таблицу с данными которые мы хотим использовать в нашем отчете (Например таблицу содержащую "Код товара" и "Актуальную цену поставщика на данный товар"). Далее можно преобразовать эту строку в таблицу и использовать в качестве вложенной временной таблицы любом запросе к базе "Продажи" с соединением по Коду. Исключением является использование данной таблицы в Построителе отчетов, для случая построителя нам понадобится создание, дополнительного справочника с предопределенным элементом и табличной частью, с реквизитами соответствующими полям таблицы.
Автор: allert73
Код причины постановки на учёт (КПП) представляет собой девятизначный цифровой код, который вместе с ИНН организации позволяет однозначно идентифицировать её обособленные подразделения (см. КПП в Википедии).
Структура КПП:
* 4 цифры – код подразделения ФНС России (справочник СОУН);
* 2 цифры – код причины постановки на учёт;
* 3 цифры – порядковый номер постановки на учёт;
В большинстве случаев КПП выглядит как: код подразделения ФНС + 01001 поскольку не так уж много организаций имеют обособленные подразделения.
К недостаткам КПП можно отнести невозможность проверки КПП по контрольной сумме. Максимум можно проверить “разумность” заполнения каждого из его элементов. В общем случае КПП не несёт больше информации чем несёт ИНН, и практически никогда не используется по отдельности в ИНН организации.
Идентификационный номер налогоплательщика
Идентификационный номер налогоплательщика (ИНН) - в Российской Федерации уникальный код используемый при учете в налоговом органе юридических и физических лиц. ИНН юридических лиц (организаций) состоит из 10 цифр. ИНН физических лиц, в т.ч. индивидуальных предпринимателей состоит из 12 цифр.
ИНН указывается налогоплательщиками в документах, предусмотренных законодательством, подаваемых в налоговые органы. Для идентификации отдельного подразделения организации, в связи с постановкой на учет в разных налоговых органах применяется код причины постановки (КПП).
Структура ИНН юридического лица
ИНН юридического лица состоит из 10 последовательных цифр.
1-2: код субъекта Российской Федерации.
3-4: номер налоговой инспеции в субъекте РФ.
1-4: код налоговой инспекции по СОУН (Справочник кодов обозначения налоговых органов для целей учёта налогоплательщиков) осуществивщей регистрацию.
5-9: номер записи в территориальном разделе ЕГРН (Единый государственный реестр налогоплательщиков).
10: контрольная цифра.
Структура ИНН физического лица
ИНН юридического лица состоит из 10 последовательных цифр.
1-2: код субъекта Российской Федерации.
3-4: номер налоговой инспеции в субъекте РФ.
1-4: код налоговой инспекции по СОУН осуществивщей регистрацию.
5-10: номер записи в территориальном разделе ЕГРН.
11-12: контрольные цифры.
Для проверки ИНН можно обратиться в налоговый орган за выпиской из ЕГРН или провести проверку контрольных цифр в соответствии со следующим алгоритмом:
1. Для расчета десятого контрольного разряда в 10-ти значном ИНН каждая цифра ИНН (кроме десятой) умножается на соответствующий множитель в соответствии с таб.1 , ззатем все значения суммируются , сумма берется по модулю 11, затем полученное число берется по модулю 10 это и есть десятый разряд.
2. Для расчета 11-ого контрольного разряда (1-ой контрольной цифры) в 12-ти значном ИНН каждая цифра ИНН (кроме 11-ой и 12-ой) умножается на соответствующий множитель в соответствии с таб.1 , затем все значения суммируются , сумма берется по модулю 11, затем полученное число берется по модулю 10 это и есть 11-ый разряд.
3. Для расчета 12-ого контрольного разряда (2-ой контрольной цифры) в 12-ти значном ИНН каждая цифра ИНН (кроме12-ой) ,11-ая вычисляется в соотв. с пред. пунктом, умножается на соответствующий множитель в соответствии с таб.1 , затем все значения суммируются , сумма берется по модулю 11, затем полученное число берется по модулю 10 это и есть 12-ый разряд.
Конкретные примеры
ИНН 500100732259 — 12 цифр (первый попавшийся в Интернете ИНН).
Причины возникновения
Причины этой ошибки разняться по своей "природе", но их объединяето то, что уже существующее (т.е. ранее установленое) соединение с клиентом разрывает сервер.
1. С версии 8.1.11 включен циклический перезапуск процессов, по наступлению интервала происходит автоматический перезапуск рабочих процессов rphost.
2. В некоторых случаях причиной ошибки могут стать утечки памяти.
3. Действия администратора в консоли (команда удалить пользователя)
4. Процесс rphost на серверном компьютере завершился аварийно
5. Ошибочное принятие высокой интенсивности пользователей за атаку на протокол в некоторых случаях Windows
6. Устаревание данных в кэшах
7. Плохо отслеживаемые события в фоновых процессах
8. Нестандартные запросы могут приводить к падениям rphost
Способы устранения
1. с 8.1.11 включен циклический перезапуск процессов, для анализа этого события на компьютере сервера 1С:Предприятия необходимо включить запись в технологический журнал событий PROC (пример файла logcfg.xml).
Когда процесс выключается, будет выведено событие PROC со свойством Txt=Process become disable.
Когда процесс останавливается, будет выведено событие PROC со свойством Txt=Process terminated. Any clients finished with error. Если аварийные завершения работы пользователей совпадают по времени с выводом этого события, то причиной является принудительная остановка рабочего процесса либо администратором (через консоль кластера), либо вследствие автоматического перезапуска.
2. перезагрузить сервер
3. убедиться, что причиной являются/не являются действия администратора в консоли
4. создать на сервере приложения два или более рабочих процесса, чтобы иметь возможность переподключиться в случаи сбоя рабочего процесса
5. Запусти программу regedit.exe, добавь новое значение типа DWORD с именем SynAttackProtect в раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ и присвой ему значение 00000000
Имеет смысл делать для ОС Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx).
8. найти технологическим журналом запрос, приводящий к падению
p.s. Кроме того, 54 ошибку можно получить на релизах <= 8.1.12.98 при ри конвертации конвертором ИБ 77(DBF) -> 81(SQL) в типовой ТиС (демо, взятой с ИТС) релиз. 954 в клиент-серверном варианте.
обойти можно так:
- выполните конвертацию в файловый фариант информационной базы 1С:Предприятия 8.1,
- выгрузите полученную информационную базу в файл,
- загрузите в клиент-серверный вариант информационной базы 1С:Предприятия 8.1.
Полезные функции: Принятые и Уволенные, работающие сотрудники, Неполное рабочее время, Отпуск без ЗП 
