Из трех наших ЗУП которые я успел обновить до 3.1.9.106 заполнение документа начисления зарплаты работает только в одной.
Например выдает ошибку:
Дополнительные обработки - МенеджерРасчетаЗарплаты - Модуль объекта
Процедура ЗаполнитьЗадолженностьПоУдержаниям
...
Это разве нормально?
Например выдает ошибку:
Дополнительные обработки - МенеджерРасчетаЗарплаты - Модуль объекта
Процедура ЗаполнитьЗадолженностьПоУдержаниям
...
Отбор = Новый Структура("Удержание, ДокументОснование");
Задолженность = ЗадолженностьПоУдержаниямФизическихЛиц();
Для Каждого СтрокаЗадолженнсти Из Задолженность Цикл
Отбор.ВидРасчета = СтрокаЗадолженнсти.Удержание;
Задолженность = ЗадолженностьПоУдержаниямФизическихЛиц();
Для Каждого СтрокаЗадолженнсти Из Задолженность Цикл
Отбор.ВидРасчета = СтрокаЗадолженнсти.Удержание;
Это разве нормально?
Найденные решения
(41)Ошибка 10207127 зарегистрирована.
Если используется ограничение взысканий, то при заполнении начисления зарплаты может возникать ошибка:
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(2672)}: Ошибка при вызове метода контекста (Выполнить)
ИспольнительныеДокументы = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("ИсполнительныйДокумент");
по причине:
{(4, 75)}: Не задано значение параметра "МесяцНачисления"
РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу.СрезПоследних(<<?>>&МесяцНачисления, ИсполнительныйДокумент В (&ОтборОснований)) КАК УсловияУдержанияПоИсполнительномуДокументу
или
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(10141)}: Поле объекта не обнаружено (ВидРасчета)
Отбор.ВидРасчета = СтрокаЗадолженнсти.Удержание;
Если используется ограничение взысканий, то при заполнении начисления зарплаты может возникать ошибка:
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(2672)}: Ошибка при вызове метода контекста (Выполнить)
ИспольнительныеДокументы = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("ИсполнительныйДокумент");
по причине:
{(4, 75)}: Не задано значение параметра "МесяцНачисления"
РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу.СрезПоследних(<<?>>&МесяцНачисления, ИсполнительныйДокумент В (&ОтборОснований)) КАК УсловияУдержанияПоИсполнительномуДокументу
или
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(10141)}: Поле объекта не обнаружено (ВидРасчета)
Отбор.ВидРасчета = СтрокаЗадолженнсти.Удержание;
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3)
Ну можно ставить самый новый, особенно пятничный, а потом на форумах спрашивать почему так. А можно подождать несколько дней, посмотреть что на форумах напишут, потом уже обновлять.
Все время старый релиз нужно ставить ?
Ну можно ставить самый новый, особенно пятничный, а потом на форумах спрашивать почему так. А можно подождать несколько дней, посмотреть что на форумах напишут, потом уже обновлять.
(11)
Ну так 1С уже как бы приучила что не стоит торопится с установкой обновления "вдруг отзовут" или через пару дней фикс каких нибудь багов выпустатят. Научены горьким жизненным опытом. Вот ТС в следующий раз не будет торопиться ставить последнее обновление.
Ну и? От этого что багов меньше в релизе станет?
[
Просто, когда встречается такая ситуация, все начинают учить когда и как нужно обновляться.
Ну так 1С уже как бы приучила что не стоит торопится с установкой обновления "вдруг отзовут" или через пару дней фикс каких нибудь багов выпустатят. Научены горьким жизненным опытом. Вот ТС в следующий раз не будет торопиться ставить последнее обновление.
Иногда обновляться на новый релиз из-за нового, что есть в нем.
Ну и? От этого что багов меньше в релизе станет?
[
(11) Помочь человеку, который сразу обновляется на новейший релиз вышедший в пятницу уже наверное нельзя - такое просто не лечится...
Он должен сам набить себе рога на лбу от исправления своих же ошибок...
И это вполне гуманно!
Мы же его не ругаем - это его собственный выбор
Он должен сам набить себе рога на лбу от исправления своих же ошибок...
И это вполне гуманно!
Мы же его не ругаем - это его собственный выбор
(3) Посмотрите ветку 3.1.8. Те, кто на неё сразу перешел столкнулись со множеством ошибок, порой критичных. Только сейчас можно более менее спокойно обновляться на 3.1.8.246 (первая рабочая версия этой ветки, прошу заметить, вышла в октябре), а 3.1.9 вот только в пятницу вышла - не обкатанная, сырая, с исправленными 87 ошибками и 100500 новыми. Увы, но переходить на неё я бы не стал. Но если Вам нравится быть бесплатным бета-тестером и тратить своё время на исправление ошибок сырых релизов 1С-ников, тогда да, "верной дорогой идёте".
(12)
К сожалению в этой ситуации кто-то должен стать "бесплатным тестером".
Для этого и предназначены тестовые релизы. Но здесь же ситуация другая - выкладывают релиз в общий доступ. А отлавливать ошибки за счет чужого времени, на мой взгляд говорит о попустительстве, непрофессионализме и попахивает халтурой. Тем более работа идет с людьми и их зарплатой. Хорошо, если ошибка будет очевидная,а если нет?
(24) У меня ошибка выскочила на двух базах из тех трех где успел обновиться, документ начисления заполняется только в той базе где нет удержаний. Отписался в 1с раз они вообще этот блок не тестировали пусть заменят того студента который это писал и поищут что там еще за ошибки...
(27)
У меня ошибка выскочила на двух базах из тех трех где успел обновиться, документ начисления заполняется только в той базе где нет удержаний.
Я из своих баз тоже выбрал те, в которых есть удержания. Но после обновления при начислении зарплаты ошибок не было. Может быть из-за того, что я перезаполнил старое начисление зарплаты?
(46)
Специфика российского учета :) В конфигураторе в настройках документов даже пунктик такой есть: "Оперативное проведение: запретить"
А так, если у вас был введен такой документ, то ошибка уже бы возникла. Так что думаю смысл есть :)
Как-то времена не совпадают ;)
Специфика российского учета :) В конфигураторе в настройках документов даже пунктик такой есть: "Оперативное проведение: запретить"
А так, если у вас был введен такой документ, то ошибка уже бы возникла. Так что думаю смысл есть :)
(24) Я так понял, что этот блок задействуется при наличии задолженности по ИЛ (м.б.и при наличии добровольных взносов в ПФР) и при включенном ограничении удержаний сверху. А сами задолженности теперь в РН ЗадолженностьПоУдержаниямФизическихЛиц, причём, они записываются в кэш. Вот и надо проанализировать регистр и очистить кэш при необходимости, если регистр пустой.
У номера релиза 4 группы цифр, разделенных точкой.
Например, 3.1.9.106 - 3.1 - номер редакции и подредакции.
9.106 - номер релиза и подрелиза
Когда сменяется номер редакции, например, с 2.5 на 3.1 - приходится переносить остатки, так как фактически это новая программа.
Кода сменяется номер релиза, например, с 3.1.8 на 3.1.9 - дело обходится простым обновлением, но внутренние изменения очень большие Это всегда что-то новое, о чем пишут в новостях. На практике это означает "много изменений". А где много изменений, там и много ошибок.
Если же обновление выпущено в рамках одного релиза (например, с 3.1.8.216 на 3.1.8.246), то принципиальных изменений не было, было исправление ошибок и небольшие бантики, которые если и будут глючить, то локально, в том месте, где их прикрутили.
Поэтому безопасная стратегия должна быть такой:
- вышел новый релиз 3.1.9 - сидим ровно, не дергаемся, ведем наблюдения;
- как только вопли рассерженных пользователей поутихнут, присматриваемся к текущему последнему выпущенному подрелизу в линейке 3.1.9 и принимаем взвешенное решение - можно ли ставить.
Ну а лучше выбрать путь консерваторов и сидеть на версии длительного сопровождения 3.1.5. Ее вылизывают весь год и законодательство поддерживают, что еще надо?
Например, 3.1.9.106 - 3.1 - номер редакции и подредакции.
9.106 - номер релиза и подрелиза
Когда сменяется номер редакции, например, с 2.5 на 3.1 - приходится переносить остатки, так как фактически это новая программа.
Кода сменяется номер релиза, например, с 3.1.8 на 3.1.9 - дело обходится простым обновлением, но внутренние изменения очень большие Это всегда что-то новое, о чем пишут в новостях. На практике это означает "много изменений". А где много изменений, там и много ошибок.
Если же обновление выпущено в рамках одного релиза (например, с 3.1.8.216 на 3.1.8.246), то принципиальных изменений не было, было исправление ошибок и небольшие бантики, которые если и будут глючить, то локально, в том месте, где их прикрутили.
Поэтому безопасная стратегия должна быть такой:
- вышел новый релиз 3.1.9 - сидим ровно, не дергаемся, ведем наблюдения;
- как только вопли рассерженных пользователей поутихнут, присматриваемся к текущему последнему выпущенному подрелизу в линейке 3.1.9 и принимаем взвешенное решение - можно ли ставить.
Ну а лучше выбрать путь консерваторов и сидеть на версии длительного сопровождения 3.1.5. Ее вылизывают весь год и законодательство поддерживают, что еще надо?
(15) Для кого как. Проходит много времени и потом переход с 3.1.5 на тот же 3.1.9 может быть не очень приятный. На мой взгляд лучше переходить потихоньку с релиза на релиз. Мы делали так 3.1.5>3.1.6>3.1.7 и 3.1.8 в январе. И незаметно, и со всеми новыми функциями. Т.к. ошибки в 3.1.5 уже не исправляют, а только поддерживают релиз (о чем говорит 612 неисправленных ошибок на баг-трекере). Но это моя точка зрения, тут уже кто во что горазд.
Несмотря на то, что я им отправил конкретное указание на строку кода в которой находится ошибка, и несмотря на тот факт что даже начинающему программисту будет понятно что такой код является ошибочным, получил ответ:
%:#;%#:&%:!!!
Проверил код, нашел откуда ноги у него растут.
Воспроизвел на демке.
Ошибка возникнет при заполнении документа начисления зарплаты если в предыдущих периодах
будет введен документ «Ограничение взысканий» в котором будет зафиксирована задолженность.
Кому тоже хочется проблем в базе, здесь описание что за документ такой:
Нам не удалось воспроизвести описанную ситуацию
%:#;%#:&%:!!!
Проверил код, нашел откуда ноги у него растут.
Воспроизвел на демке.
Ошибка возникнет при заполнении документа начисления зарплаты если в предыдущих периодах
будет введен документ «Ограничение взысканий» в котором будет зафиксирована задолженность.
Кому тоже хочется проблем в базе, здесь описание что за документ такой:
(41)
Так это стандартная отговорка. Я как то штук пять писем отправил с указанием конкретной строки кода, описанием воспроизведения даже не демке. Но в ответ всегда приходил стандартный ответ "Нам не удалось воспроизвести описанную ситуацию. Пришлите вашу базу". Потом после пятого письма пришло "Ошибка зарегистрирована и будет исправлена в следующем релизе". С тех пор в 1С больше баг репорты не отправляю.... Ты им пишешь, они даже не проверяют.
Нам не удалось воспроизвести описанную ситуацию
Так это стандартная отговорка. Я как то штук пять писем отправил с указанием конкретной строки кода, описанием воспроизведения даже не демке. Но в ответ всегда приходил стандартный ответ "Нам не удалось воспроизвести описанную ситуацию. Пришлите вашу базу". Потом после пятого письма пришло "Ошибка зарегистрирована и будет исправлена в следующем релизе". С тех пор в 1С больше баг репорты не отправляю.... Ты им пишешь, они даже не проверяют.
(41)Ошибка 10207127 зарегистрирована.
Если используется ограничение взысканий, то при заполнении начисления зарплаты может возникать ошибка:
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(2672)}: Ошибка при вызове метода контекста (Выполнить)
ИспольнительныеДокументы = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("ИсполнительныйДокумент");
по причине:
{(4, 75)}: Не задано значение параметра "МесяцНачисления"
РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу.СрезПоследних(<<?>>&МесяцНачисления, ИсполнительныйДокумент В (&ОтборОснований)) КАК УсловияУдержанияПоИсполнительномуДокументу
или
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(10141)}: Поле объекта не обнаружено (ВидРасчета)
Отбор.ВидРасчета = СтрокаЗадолженнсти.Удержание;
Если используется ограничение взысканий, то при заполнении начисления зарплаты может возникать ошибка:
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(2672)}: Ошибка при вызове метода контекста (Выполнить)
ИспольнительныеДокументы = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("ИсполнительныйДокумент");
по причине:
{(4, 75)}: Не задано значение параметра "МесяцНачисления"
РегистрСведений.УсловияУдержанияПоИсполнительномуДокументу.СрезПоследних(<<?>>&МесяцНачисления, ИсполнительныйДокумент В (&ОтборОснований)) КАК УсловияУдержанияПоИсполнительномуДокументу
или
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(10141)}: Поле объекта не обнаружено (ВидРасчета)
Отбор.ВидРасчета = СтрокаЗадолженнсти.Удержание;
(55)Что вы подразумеваете под термином аудиторский след? Лет 20 слышу о том, что в западном ПО это есть, в 1с этого нет, совсем нет. Это говорили когда была версия 6.0. Сегодня уже 8.3 с историей в платформе. Аудиторский след это характеристика данных в базе. Например если вам требуется изменить название клиента или номенклатуры,
а во всех старых документах можете распечатать как оно было.
а во всех старых документах можете распечатать как оно было.
(56) Лично я под этим подразумеваю отсутствие в программе у пользователя возможности просто зайти и исправить ранее внесенный документ задним числом. В забугорных системах насколько я в курсе как правило ранее внесенный документ оставляют без изменений, а для корректировки данных вносят дополнительный корректирующий документ если нужно то к предыдущему периоду, но в документе будет видно что он создан сегодня.
История это несколько не то, это как дополнительная слежка за пользователем, историю можно потерять, не настроить, пользователь может банально не понимать что история его действий записывается.
А там изначально подход такой что пользователь должен воспринимать любое исправление задним числом как отдельную операцию, которую нужно обосновать, указать причину в документе, произвести все корректировки налоговых отчетов, если нужно доплатить все пени, если необходимо проанализировать ущерб и удержать с виновных...
То есть аудитор может быстро выбрать все осуществленные корректировки, прочитать по каким причинам они произведены, запросить обоснование, и проверить все ли требуемые по закону действия при такой корректировке произведены...
А у нас что аудитор с историей будет делать? Допустим даже проведет анализ истории и найдет документ который меняли 20 раз, так никто уже не помнит почему, может даже уже уволился тот человек у которого главбух может спросить причину...
История это несколько не то, это как дополнительная слежка за пользователем, историю можно потерять, не настроить, пользователь может банально не понимать что история его действий записывается.
А там изначально подход такой что пользователь должен воспринимать любое исправление задним числом как отдельную операцию, которую нужно обосновать, указать причину в документе, произвести все корректировки налоговых отчетов, если нужно доплатить все пени, если необходимо проанализировать ущерб и удержать с виновных...
То есть аудитор может быстро выбрать все осуществленные корректировки, прочитать по каким причинам они произведены, запросить обоснование, и проверить все ли требуемые по закону действия при такой корректировке произведены...
А у нас что аудитор с историей будет делать? Допустим даже проведет анализ истории и найдет документ который меняли 20 раз, так никто уже не помнит почему, может даже уже уволился тот человек у которого главбух может спросить причину...
(62) в моем понимании аудиторский след противоречит концепции реляционных баз данных и так исторически сложилось, что реляционные базы данных выиграли.
Sql при помощи журнала транзакций способен на уровне субд восстановить состояние всей базы данных в целом на любой момент времени. Файловая база с журналом регистрации или без него, с историей или без нее этого не может. Для этого костылем служит ежедневный бакап(или по требованию), но костыль есть костыль, а журнал регистрации всего лишь слежка.
Насчет других субд это вопрос, но 8ка зашивала конфигурацию в данные именно с этой целью.
Дисциплина при ведении учета находится вне сферы влияния аудитора, но он дает заключение о в целом достоверности данных с некоторой (известной только аудитору) прогрешностью.
Справочник не содержит информацию о датах, для него нет такого понятия как история изменений.
Если же справочник использовать только как шабон для заполнения документов, то связи по ссылке не будут иметь смысла.
Sql при помощи журнала транзакций способен на уровне субд восстановить состояние всей базы данных в целом на любой момент времени. Файловая база с журналом регистрации или без него, с историей или без нее этого не может. Для этого костылем служит ежедневный бакап(или по требованию), но костыль есть костыль, а журнал регистрации всего лишь слежка.
Насчет других субд это вопрос, но 8ка зашивала конфигурацию в данные именно с этой целью.
Дисциплина при ведении учета находится вне сферы влияния аудитора, но он дает заключение о в целом достоверности данных с некоторой (известной только аудитору) прогрешностью.
Справочник не содержит информацию о датах, для него нет такого понятия как история изменений.
Если же справочник использовать только как шабон для заполнения документов, то связи по ссылке не будут иметь смысла.
(63)
В 1с есть например документ корректировка реализации, вроде ничему не противоречит и работает :)
Мне кажется вы несколько упрощаете цели аудита :)
Как так? Вы же вроде сами коснулись вопроса функционала истории в платформе? У нас например в БПК ведется история по справочнику номенклатуры, можно получить отчет сравнения версий за разные даты...
И кстати именно поэтому и созданы периодические регистры, но понятно что они не имеют вопроса к обсуждаемой теме...
в моем понимании аудиторский след противоречит концепции реляционных баз данных и так исторически сложилось, что реляционные базы данных выиграли.
В 1с есть например документ корректировка реализации, вроде ничему не противоречит и работает :)
но он дает заключение о в целом достоверности данных с некоторой (известной только аудитору) прогрешностью.
Мне кажется вы несколько упрощаете цели аудита :)
Справочник не содержит информацию о датах, для него нет такого понятия как история изменений.
Как так? Вы же вроде сами коснулись вопроса функционала истории в платформе? У нас например в БПК ведется история по справочнику номенклатуры, можно получить отчет сравнения версий за разные даты...
И кстати именно поэтому и созданы периодические регистры, но понятно что они не имеют вопроса к обсуждаемой теме...
А у нас после обновления при расчете зарплаты за первую половину появляется ошибка
Суть ее в том, что если рассчитывать подразделение где меньше 50 сотрудников, то все норм. Больше- лови ошибку. Просто нет слов
{Обработка.МенеджерРасчетаЗарплаты.МодульОбъекта(2086)}: Ошибка при вызове метода контекста (Выполнить)
РанееОплаченныеПериоды = Запрос.Выполнить().Выгрузить();
по причине:
{(19, 24)}: Таблица не найдена "ПолученияПериодическихДанныхСотрудников"
Внутреннее СОЕДИНЕНИЕ <<?>>ПолученияПериодическихДанныхСотрудников КАК СотрудникиПериоды
РанееОплаченныеПериоды = Запрос.Выполнить().Выгрузить();
по причине:
{(19, 24)}: Таблица не найдена "ПолученияПериодическихДанныхСотрудников"
Внутреннее СОЕДИНЕНИЕ <<?>>ПолученияПериодическихДанныхСотрудников КАК СотрудникиПериоды
Суть ее в том, что если рассчитывать подразделение где меньше 50 сотрудников, то все норм. Больше- лови ошибку. Просто нет слов
(57)
Суть ее в том, что если рассчитывать подразделение где меньше 50 сотрудников, то все норм. Больше- лови ошибку. Просто нет слов
У меня такая ошибка не проявляется. Общее количество сотрудников более 50, но за первую половину рассчитывается только для одного сотрудника. Может быть дело в этом ?
После обновления на ЗГУ 3.1.9.106.
Если пытаться перезаполнить сохранив ручные исправления документ начисление зарплаты ругается: Поле объекта не обнаруженно (Вычеркнуть). Причем спотыкается только на исправлениях удержаний (Профсоюз или исполнительный лист) и договоров ГПХ. Исправление начислений к ошибке не приводят. Еще одна ошибка из за обновления, профсоюз если стоит на 2х рабочих местах из 3х, то сумму она считает правильно, но пишет ее в обе строки профсоюза не разбивая по рабочим местам пропорционально, в результате задваивается у таких людей профсоюз. Либо если профсоюз стоит на одном рабочем месте из двух, у некоторых людей удерживает с двух мест.
Если пытаться перезаполнить сохранив ручные исправления документ начисление зарплаты ругается: Поле объекта не обнаруженно (Вычеркнуть). Причем спотыкается только на исправлениях удержаний (Профсоюз или исполнительный лист) и договоров ГПХ. Исправление начислений к ошибке не приводят. Еще одна ошибка из за обновления, профсоюз если стоит на 2х рабочих местах из 3х, то сумму она считает правильно, но пишет ее в обе строки профсоюза не разбивая по рабочим местам пропорционально, в результате задваивается у таких людей профсоюз. Либо если профсоюз стоит на одном рабочем месте из двух, у некоторых людей удерживает с двух мест.
К сведению коллег - в релизе 3.1.9.106 реализовано сразу два варианта Менеджера расчета зарплаты.
МенеджерРасчетаЗарплатыАрхивный - это старый алгоритм расчета, который был в предыдущем релизе 3.1.8.246.
МенеджерРасчетаЗарплаты - это новый, оптимизированный и, похоже, сильно "глючный" вариант.
В чем суть этих оптимизаций, непонятно. По крайней мере, не нашёл явного описания нигде.
Выбор менеджера зависит от значения константы ВыполнятьРасчетЗарплатыБезОптимизации.
Старый вариант расчета выбирается при включенной константе.
Кстати, не нашёл, где в настройках можно включить эту константу. Пришлось включить через "Все функции".
МенеджерРасчетаЗарплатыАрхивный - это старый алгоритм расчета, который был в предыдущем релизе 3.1.8.246.
МенеджерРасчетаЗарплаты - это новый, оптимизированный и, похоже, сильно "глючный" вариант.
В чем суть этих оптимизаций, непонятно. По крайней мере, не нашёл явного описания нигде.
Выбор менеджера зависит от значения константы ВыполнятьРасчетЗарплатыБезОптимизации.
Старый вариант расчета выбирается при включенной константе.
Кстати, не нашёл, где в настройках можно включить эту константу. Пришлось включить через "Все функции".
(88)В 106 было 343 неисправленных ошибок.
В 107 исправлено 8, осталось неисправленных 335.
Но обновлять в ближайшее время придется:
В 107 исправлено 8, осталось неисправленных 335.
Но обновлять в ближайшее время придется:
1. Версия длительного сопровождения 3.1.5. В ней будут поддерживаться изменения законодательства и исправляться только критичные ошибки до конца 2018 года (сдачи отчетности за 2018 год), после чего ее выпуск будет прекращен.
Перестали при расчете зарплаты учитываться внутрисменные отсутствия. Как начисление при расчете не выводится, зато отнимает от отработанного целый день и норму часов по графику. То есть считается как целодневное отсутствие
(91) к 107. Странно, но внутрисменные не все не рассчитаются правильно. некоторые (самостоятельно созданные)? не считаются, другие (предопределенные) точно учитываются. Раньше неявки при расчете зарплаты в виде начислений указывались, а сей час пропали. Не понятно как они учлись. Надо глубже копать
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот