Зарплата и управление персоналом, редакция 3.1 (3.1.16.108)
Столкнулся с такой ситуацией:
При расчете зарплаты за октябрь и ноябрь 2020 г., сумма начисления по некоторым сотрудниками регистр накопления "Учет доходов для исчисления страховых взносов" не совпадают. Пример во вложении.
Обнаружили при подготовке отчета за 2020г.
Если предположить, что в декабре программа сделает перерасчет за год, то нет. Мы и обнаружили, что сумма по году не совпадает. Потом я стал сравнивать по каждому сотруднику.
До октября цифры совпадают
Регистр "Начисления и удержания по сотрудникам" совпадает с расчетным листком.
Проверял с помощью «chdbfl.exe», тестировал из конфигуратора : реиндексация, проверка логической целостности, проверка ссылочной целостности, перерасчет итогов, сжатие таблиц, реструктуризация таблиц. Ошибка осталась
Отменил все начисления зарплаты после октября 2020, на текущей конфигурации, с помощью нового документы сделал начисление зарплаты. Результат тот же.
При нажатии на строку в регистре, открывает документ начисление зарплаты, где ни у кого нет такой суммы начисления.
В регистре "Учет доходов для исчисления страховых взносов" документ-основание "Начисление зарплаты и взносов" стоит на всех записях октября
Сравнивал конфигурацию рабочей базы с чистой конфигурацией. Они идентичны.
Выгрузка в «dt» и обратная загрузка в пустую конфигурацию не помогла.
У меня несколько клиентов, у всех все нормально.
Внешнего воздействия на базу не было, за исключением загрузки кадровых документов из «Контур персонал». Кадровичка не хочет работать с 1С. Следов в этом регистре тоже не обнаружил.
Не совпадают начисления почти все, за исключение созданных отдельным документом, доплаты и т.д.
Повторюсь, ошибки примерно у половины сотрудников из 350 чел
Пробовал отследить с отладчиком откуда берется дурное значение, запутался в модулях.
Я так глубоко давно не разбирался с конфигурацией.
Если кто то подскажет хотя бы примерно где копать, буду очень благодарен.
Зарплата и управление персоналом, редакция 3.1 (3.1.16.108)
Столкнулся с такой ситуацией:
При расчете зарплаты за октябрь и ноябрь 2020 г., сумма начисления по некоторым сотрудниками регистр накопления "Учет доходов для исчисления страховых взносов" не совпадают. Пример во вложении.
Обнаружили при подготовке отчета за 2020г.
Если предположить, что в декабре программа сделает перерасчет за год, то нет. Мы и обнаружили, что сумма по году не совпадает. Потом я стал сравнивать по каждому сотруднику.
До октября цифры совпадают
Регистр "Начисления и удержания по сотрудникам" совпадает с расчетным листком.
Проверял с помощью «chdbfl.exe», тестировал из конфигуратора : реиндексация, проверка логической целостности, проверка ссылочной целостности, перерасчет итогов, сжатие таблиц, реструктуризация таблиц. Ошибка осталась
Отменил все начисления зарплаты после октября 2020, на текущей конфигурации, с помощью нового документы сделал начисление зарплаты. Результат тот же.
При нажатии на строку в регистре, открывает документ начисление зарплаты, где ни у кого нет такой суммы начисления.
В регистре "Учет доходов для исчисления страховых взносов" документ-основание "Начисление зарплаты и взносов" стоит на всех записях октября
Сравнивал конфигурацию рабочей базы с чистой конфигурацией. Они идентичны.
Выгрузка в «dt» и обратная загрузка в пустую конфигурацию не помогла.
У меня несколько клиентов, у всех все нормально.
Внешнего воздействия на базу не было, за исключением загрузки кадровых документов из «Контур персонал». Кадровичка не хочет работать с 1С. Следов в этом регистре тоже не обнаружил.
Не совпадают начисления почти все, за исключение созданных отдельным документом, доплаты и т.д.
Повторюсь, ошибки примерно у половины сотрудников из 350 чел
Пробовал отследить с отладчиком откуда берется дурное значение, запутался в модулях.
Я так глубоко давно не разбирался с конфигурацией.
Если кто то подскажет хотя бы примерно где копать, буду очень благодарен.
Зарплата и управление персоналом, редакция 3.1 (3.1.16.108)
Столкнулся с такой ситуацией:
При расчете зарплаты за октябрь и ноябрь 2020 г., сумма начисления по некоторым сотрудниками регистр накопления "Учет доходов для исчисления страховых взносов" не совпадают. Пример во вложении.
Обнаружили при подготовке отчета за 2020г.
Если предположить, что в декабре программа сделает перерасчет за год, то нет. Мы и обнаружили, что сумма по году не совпадает. Потом я стал сравнивать по каждому сотруднику.
До октября цифры совпадают
Регистр "Начисления и удержания по сотрудникам" совпадает с расчетным листком.
Проверял с помощью «chdbfl.exe», тестировал из конфигуратора : реиндексация, проверка логической целостности, проверка ссылочной целостности, перерасчет итогов, сжатие таблиц, реструктуризация таблиц. Ошибка осталась
Отменил все начисления зарплаты после октября 2020, на текущей конфигурации, с помощью нового документы сделал начисление зарплаты. Результат тот же.
При нажатии на строку в регистре, открывает документ начисление зарплаты, где ни у кого нет такой суммы начисления.
В регистре "Учет доходов для исчисления страховых взносов" документ-основание "Начисление зарплаты и взносов" стоит на всех записях октября
Сравнивал конфигурацию рабочей базы с чистой конфигурацией. Они идентичны.
Выгрузка в «dt» и обратная загрузка в пустую конфигурацию не помогла.
У меня несколько клиентов, у всех все нормально.
Внешнего воздействия на базу не было, за исключением загрузки кадровых документов из «Контур персонал». Кадровичка не хочет работать с 1С. Следов в этом регистре тоже не обнаружил.
Не совпадают начисления почти все, за исключение созданных отдельным документом, доплаты и т.д.
Повторюсь, ошибки примерно у половины сотрудников из 350 чел
Пробовал отследить с отладчиком откуда берется дурное значение, запутался в модулях.
Я так глубоко давно не разбирался с конфигурацией.
Если кто то подскажет хотя бы примерно где копать, буду очень благодарен.
Подскажите пожалуйста, формирую отчет по остаткам сумм на бух счетах.
В запросе необходимо выбрать конкретные счета для вывода остатков.Но план счетов нетиповой, имеются счета, с маской ******** в которых присутствуют пробелы, т.е формат 1110 21, 1030 25 итд.Пробел чем то заменить нельзя. По законодательству только так.
Как в запросе этот пробел проставить? Пробовала и @ и нижнее подчеркивание, но при выводе отчета вылезает ошибка что такого счета нет (с нижним пробелом) или что задано неверное имя атрибута структуры.
Есть два справочника Штатное и Подразделения. В справочнике Штатное есть автоматически генерируемое поле Наименование. Как программно сделать так чтобы в поле Наименование справочника Штатное выводились списком значений из поля Наименование справочника Подразделения? Я только начал изучать программирование в 1С. Вариант с добавлением в код модуля списка выбора я уже реализовал. Но сами понимаете что это не то. Посмотрите код. Может у кого то решение есть лучше.
подскажите пожалуйста, стоит 1с 8.3 бухгалтерский учет для Украины2.0
на одной платформе 2 предприятия. В одном предприятии при офрмлении документа "ведомости выплаты через банк" Аванс (без предварительного расчета) есть две кнопки "заполнить" и "расчитать" и соответственно в таблице сумма чистыми и сумма грязными, а вот по второму предприятию нет кнопки расчитать и соответственно в таблице нет суммы грязными и расчет налогов не делает.Куда нужно посмотреть?
Доброго времени суток. Имеется самописная конфигурация. В ней имеется документ "комплектовка" с табличной частью "материалы" (реквизиты: наименование материала, код, количество, цена, сумма). Позиций в табличной части очень много.
После заполнения документа, он проводится. Проведенный документ изменять нельзя. Спустя какое-то время может возникнуть ситуация, что нужно внести изменения в данный документ. Как реализовать механизм корректировки, если в базе нет типового решения? На основании проведенного документа формируются отчеты.
Выдает ошибку {Форма.Форма.Форма(301)}: Ошибка при вызове метода контекста (ПолучитьСсылку): Произошла исключительная ситуация: Несоответствие типов (параметр номер '1')
Нужно уникальный идентификатор создавать в com: Соединение.Справочники.Номенклатура.ПолучитьСсылку(Соединение.NewObject("УникальныйИдентификатор",Строка(УИ)));
Для формирования и выполнения запросов к таблицам базы данных в платформе 1С используется специальный объект языка программирования Запрос. Создается этот объект вызовом конструкции Новый Запрос. Запрос удобно использовать, когда требуется получить сложную выборку данных, сгруппированную и отсортированную необходимым образом. Классический пример применения запроса - получение сводки по состоянию регистра накопления на определенный момент времени. Так же, механизм запросов позволяет легко получать информацию в различных временных разрезах.
Текст запроса – это инструкция, в соответствии с которой должен быть выполнен запрос. В тексте запроса описывается:
таблицы информационной базы, используемые в качестве источников данных запроса;
поля таблиц, которые требуется обрабатывать в запросе;
правила группировки;
сортировки результатов;
и т. д.
Инструкция составляется на специальном языке – языке запросов и состоит из отдельных частей – секций, предложений, ключевых слов, функций, арифметических и логических операторов, комментариев, констант и параметров.
Язык запросов платформы 1С очень похож на синтаксис других SQL-языков, но имеются отличия. Основными преимуществами встроенного языка запросов являются: разыменование полей, наличие виртуальных таблиц, удобная работа с итогами, нетипизированные поля в запросах.
Рекомендации по написанию запросов к базе данных на языке запросов платформы 1С:
1) Текст запроса может содержать предопределенные данные конфигурации, такие как:
значения перечислений;
предопределенные данные:
справочников;
планов видов характеристик;
планов счетов;
планов видов расчетов;
пустые ссылки;
значения точек маршрута бизнес-процессов.
Также текст запроса может содержать значения системных перечислений, которые могут быть присвоены полям в таблицах базы данных: ВидДвиженияНакопления, ВидСчета и ВидДвиженияБухгалтерии. Обращение в запросах к предопределенным данным конфигурации и значениям системных перечислений осуществляется с помощью литерала функционального типа ЗНАЧЕНИЕ. Данный литерал позволяет повысить удобочитаемость запроса и уменьшить количество параметров запроса.
Пример использования литерала ЗНАЧЕНИЕ:
ГДЕ Город = ЗНАЧЕНИЕ(Справочник.Города.Москва)
ГДЕ Город = ЗНАЧЕНИЕ(Справочник.Города.ПустаяСсылка)
ГДЕ ТипТовара = ЗНАЧЕНИЕ(Перечисление.ВидыТоваров.Услуга)
ГДЕ ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
ГДЕ ТочкаМаршрута = ЗНАЧЕНИЕ(БизнесПроцесс.БизнесПроцесс1.ТочкаМаршрута.Действие1
2) Использование инструкции АВТОУПОРЯДОЧИВАНИЕ в запросе может сильно время выполнения запроса, поэтому, если сортировка не требуется, то лучше вообще ее не использовать. Во большинстве случаях лучше всего применять сортировку с помощью инструкции УПОРЯДОЧИТЬ ПО.
Автоупорядочивание работает по следующим принципам:
Если в запросе было указано предложение УПОРЯДОЧИТЬ ПО, то каждая ссылка на таблицу, находящаяся в этом предложении, будет заменена полями, по которым по умолчанию сортируется таблица (для справочников это код или наименование, для документов – дата документа). Если поле для упорядочивания ссылается на иерархический справочник, то будет применена иерархическая сортировка по этому справочнику.
Если в запросе отсутствует предложение УПОРЯДОЧИТЬ ПО, но есть предложение ИТОГИ, тогда результат запроса будет упорядочен по полям, присутствующим в предложении ИТОГИ после ключевого слова ПО, в той же последовательности и, в случае если итоги рассчитывались по полям – ссылкам, то по полям сортировки по умолчанию таблиц, на которые были ссылки.
Если в запросе отсутствуют предложения УПОРЯДОЧИТЬ ПО и ИТОГИ, но есть предложение СГРУППИРОВАТЬ ПО, тогда результат запроса будет упорядочен по полям, присутствующим в предложении, в той же последовательности и, в случае если группировка велась по полям – ссылкам, то по полям сортировки по умолчанию таблиц, на которые были ссылки.
В случае же, если в запросе отсутствуют предложения и УПОРЯДОЧИТЬ ПО, ИТОГИ и СГРУППИРОВАТЬ ПО, результат будет упорядочен по полям сортировки по умолчанию для таблиц, из которых выбираются данные, в порядке их появления в запросе.
В случае, если запрос содержит предложение ИТОГИ, каждый уровень итогов упорядочивается отдельно.
3) Что бы избежать повторного запроса к базе данных при выводе результата запроса пользователю (например, построение запроса или отображение результата запроса с помощью табличного документа) полезно использовать инструкцию ПРЕДСТАВЛЕНИЕССЫЛКИ, которая позволяет получать представление ссылочного значения. Пример:
Так же возможно использование инструкции ПРЕДСТАВЛЕНИЕ - предназначена для получения строкового представления значения произвольного типа. Отличие этих инструкций в том, что в первом случае, если инструкции передать ссылку, результатом будет строка, В остальных случаях результатом будет значение переданного параметра. Во втором случае, результатом инструкции всегда будет строка!
4) Если в запросе имеется поле с составным типом, то для таких полей возникает необходимость привести значения поля к какому-либо определенному типу с помощью инструкции ВЫРАЗИТЬ, что позволит убрать лишние таблицы из левого соединения с полем составного типа данных и ускорить выполнение запроса. Пример:
Имеется регистра накопления ОстаткиТоваров, у которого поле Регистратор имеет составной тип. В запросе выбираются Дата и Номер документов ПоступлениеТоваров, при этом при обращении к реквизитам документа через поле Регистратор не происходит множество левых соединений таблицы регистра накопления с таблицами документов-регистраторов.
Если приведение типа считается не осуществимым, то результатом приведения типа будет значение NULL.
5) Не стоит забывать про инструкцию РАЗРЕШЕННЫЕ, которая означает, что запрос выберет только те записи, на которые у текущего пользователя есть права. Если данное слово не указать, то в случае, когда запрос выберет записи, на которые у пользователя нет прав, запрос отработает с ошибкой.
6) В случае, если в запросе используется объединение, и в некоторых частях объединения присутствуют вложенные таблицы (документ с табличной частью), а в некоторых нет, возникает необходимость дополнения списка выборки полями – пустыми вложенными таблицами. Делается это при помощи ключевого слова ПУСТАЯТАБЛИЦА, после которого в скобках указываются псевдонимы полей, из которых будет состоять вложенная таблица. Пример:
7) Что бы в результат запроса не попали повторяющиеся строки, следует использовать инструкцию РАЗЛИЧНЫЕ, потому что так нагляднее и понятнее, а инструкция СГРУППИРОВАТЬ ПО применяется для группировки с помощью агрегатных функций. Ксати, при использовании агрегатных функций предложение СГРУППИРОВАТЬ ПО может быть и не указано совсем, при этом все результаты запроса будут сгруппированы в одну единственную строку. Пример:
8) Инструкция СГРУППИРОВАТЬ ПО позволяет обращаться к полям верхнего уровня, без группировки результатов по этим полям, если агрегатные функции применены к полям вложенной таблицы. Хотя в справке 1С написано, при группировке результатов запроса в списке полей выборки обязательно должны быть указаны агрегатные функции, а помимо агрегатных функций в списке полей выборки допускается указывать только поля, по которым осуществляется группировка. Пример:
9) Инструкция ЕСТЬNULL предназначена для замены значения NULL на другое значение, но не забываем, что второй параметр будет преобразован к типу первого в случае, если тип первого параметра является строкой или числом.
10) При обращении к главной таблице можно в условии обратиться к данным подчиненной таблицы. Такая возможность называется разыменование полей подчиненной таблицы.
Пример (поиск документов, содержащих в табличной части определенный товар):
Преимущество этого запроса перед запросом к подчиненной таблице Приходная.Товары в том, что если есть дубли в документах, результат запроса вернет только уникальные документы без использования ключевого слова РАЗЛИЧНЫЕ.
11) Интересный вариант оператора В - это проверка вхождения упорядоченного набора в множество таких наборов (Поле1, Поле2, ... , ПолеN) В (Поле1, Поле2, ... , ПолеN).
Пример:
12) При любой возможности используйте виртуальные таблицы запросов. При создании запроса система предоставляет в качестве источников данных некоторое количество виртуальных таблиц - это таблицы, которые так же являются результатом запроса, который система формирует в момент выполнения соответствующего участка кода.
Разработчик может самостоятельно получить те же самые данные, которые система предоставляет ему в качестве виртуальных таблиц, однако алгоритм получения этих данных не будет оптимизирован, так как:
Все виртуальные таблицы параметризованы, т. е. разработчику предоставляется возможность задать некоторые параметры, которые система будет использовать при формировании запроса создания виртуальной таблицы. В зависимости от того, какие параметры виртуальной таблицы указаны разработчиком, система может формировать РАЗЛИЧНЫЕ запросы для получения одной и той же виртуальной таблицы, причем они будут оптимизированы с точки зрения переданных параметров.
Не всегда разработчик имеет возможность получить доступ к тем данным, к которым имеет доступ система.
13) В клиент-серверном варианте работы функция ПОДСТРОКА() реализуется при помощи функции SUBSTRING() соответствующего оператора SQL, передаваемого серверу баз данных SQL Server, который вычисляет тип результата функции SUBSTRING() по сложным правилам в зависимости от типа и значений ее параметров, а так же в зависимости от контекста, в котором она используется. В большинстве случаев эти правила не оказывают влияния на выполнение запроса, но бывают случаи, когда для выполнения запроса существенна максимальная длина строки результата, вычисленная SQL Server. Важно иметь в виду, что в некоторых контекстах использования функции ПОДСТРОКА() максимальная длина ее результата может оказаться равной максимальной длине строки ограниченной длины, которая в SQL Server равна 4000 символам. Это может привести к неожиданному аварийному завершению выполнения запроса:
Microsoft OLE DB Provider for SQL Server: Warning: The query processor could not produce a query plan from the optimizer because the total length of all the columns in the GROUP BY or ORDER BY clause exceeds 8000 bytes.
HRESULT=80040E14, SQLSTATE=42000, native=8618
Чтобы избежать такой ошибки, не рекомендуют использовать функцию ПОДСТРОКА() с целью приведения строк неограниченной длины к строкам ограниченной длины. Вместо нее лучше использовать операцию приведения типа ВЫРАЗИТЬ().
14) С осторожностью используйте ИЛИ в конструкции ГДЕ, так как использование условия с ИЛИ может значительно "утяжелить" запрос. Решить проблему можно конструкцией ОБЪЕДИНИТЬ ВСЕ. Пример:
15) Условие НЕ В в конструкции ГДЕ увеличивает время исполнения запроса, так как это своего рода НЕ (ИЛИ1 ИЛИ2 ... ИЛИn), поэтому для больших таблиц старайтесь использовать ЛЕВОЕ СОЕДИНЕНИЕ с условием ЕСТЬ NULL. Пример:
16) При использовании Временных таблиц нужно индексировать поля условий и соединений в этих таблицах, НО, при использовании индексов запрос может выполняться еще медленнее. Поэтому необходимо анализировать каждый запрос с применением индекса и без, замерять скорость выполнения запроса и принимать окончательное решение.
Если вы помещаете во временную таблицу данные, которые изначально индексированы по некоторым полям, то во временной таблице индекса по этим полям уже не будет.
17) Если вы не используете Менеджер временных таблиц, то явно удалять временную таблицу не требуется, она будет удалена после завершения выполнения пакетного запроса, иначе следует удалить временную таблицу одним из способов: командой УНИЧТОЖИТЬ в запросе, вызвать метод МенеджерВременныхТаблиц.Закрыть().
Чтобы провести деноминацию в 1С на 1 июля 2016 года, нужно учесть, что желательно учёт вести в двух суммовых измерениях в белорусских рублях старого и нового образца. Однако, даже если Вы решите упростить задачу и проведёте деноминацию в программе вручную или с помощью обработки на 1 июля, то есть деноминируете итоги в соотношении 1:10000, то получите "кашу" в базе данных. Такие отчёты как ОСВ, акт сверки, карточка счёта, журнал-ордер и все остальные в программе 1С будут воспринимать данную операцию как "логичную". Обороты за период "поплывут", а итоги будут суммировать старые и новые деньги как равнозначные. Поэтому этот вариант исключим сразу.
Пять вариантов решения:
1)Корректный вариант!Разделить базу данных на две. Во второй провести деноминацию 1 июля.
Выполнить доработку форм и метаданных до копеек. Первое полугодие в первой базе оставить как есть. А учёт во втором полугодии, во второй базе, уже начать вести в денежном выражении нового образца. Перед разбиением базы на две, нужно доработать модуль и все метаданные, создать её копию и сделать свёртку обработкой WRAP.ert. Потом, этой же обработкой, в новой базе провести деноминацию - убрать из уже сделанных, во втором квартале, проводок и метаданных "0000". Но есть один недостаток. Разбивая базу на две Вы лишитесь оперативность при получении данных. Теперь, например, для того чтобы построить акт сверки за год по контрагенту - придётся делать это в двух базах! Выбирая этот вариант нужно понимать все нюансы разделения базы на полугодия.
2)Корректный вариант!Проведение деноминации в рабочей базе (без разделения):
Выполнить доработку форм и метаданных до копеек. Создать сторнированные проводоки с учётом коэффициента деноминации 10000 (то есть если на Сч.по Дт.=3.000.000 -> будет сделана проводка Дт. -2.999.700 -> в итоге Сч.Дт=300). Внимание! Нужно иметь ввиду, что отчёты желательно строить в двух экземплярах (до 1 июля и после).
Выполнить доработку форм и метаданных до копеек.
3) Корректный вариант, но очень затратный! Доработать все метаданные 1С для деноминации и провести её на 1 июля 2016 года.
Самый дорогой вариант для предприятия.
В версии 8.2 и 8.3 можно создать дополнительное измерение "сумма в рублях старого образца".
В версии 7.7 на невалютных счетах можно использовать вал.сумму или доп.забалансовый счёт (рубли образца 2009 года).
Плюс ко всему придётся переделать практически все объекты метаданных. Отчеты, справочники, документы, обработки, глобальный(7.7) и общие(8) модули, план счетов, регистры и т.п. Реализовать данный метод смогут лишь крупные предприятия с массивным штатом программистов 1С.
4) Признан некорректным!Продолжить вести учёт в старых денежных единицах.
Совершенно не затратный и для большинства компаний самый оптимальный, так как делать то ничего и не надо. Коротко говоря - оставить всё как есть. В шапке некоторых отчётов, например, акта сверки, для корректности, можно добавить фразу типа этой: "в расчётах используется белорусский рубль образца 2000 года".
5) Признан некорректным!Разделить базу данных на две. Во второй провести деноминацию 1 января.
"Закрыть" период (первое полугодие) в первой базе, чтобы больше не вносить туда изменения. Во второй базе сделать свёртку обработкой WRAP.ert на 1 января. Незабудьте предварительно создать копию. Соответственно с 1 января 2016г. учёт будет деноминированный. Помните, что вносить изменения (если таковые будут) до 01 июля 2016 придётся вносить в обе информационные базы. В начале 2017 можно будет свернуть и обрезать Вашу рабочую базу на 1 июля. Так у Вас будет две базы: 1-я до 1.07.2016 (без деноминации) и 2-я после 1.07.2016 (с деноминацией).
6) Признан некорректным! Доработать только отчёты в 1С для деноминации 1 июля 2016 года.
В отчётах, которыми чаще всего пользуются бухгалтера для отправки данных "внешним" контрагентам (акт сверки, деб.задолженность, отчёт по движению ДС и т.п.), выводить дополнительную строку с коэффициентом 1:10000 под суммой с названием "сумма в белорусских рублях образца 2009 года".
В отличие от яндекс карт в GMaps можно использовать панорамы - за что им большой плюс! Надеюсь в яндексе прочитают этот пост и тоже когда-нибудь это сделают!
Для клиента нужно было сделать вывод объектов на карту
В УТ реализация не проводится. ошибка - указана сумма предоплаты (сделка: " ") больше возможной по документу
ответ: такая ошибка может возникать, если договор в документе "по документам расчетов с контрагентами". в этом случае активна закладка "предоплата". на закладке "предоплата" появляется платежка. сумма предоплаты берется из нее. либо другую платежку подтяните, либо очистите закладку "предоплата".
Несовпадение начисленной зарплаты и регистра накопления "Учет доходов для исчисления страховых взнос 
