Сабж. Поспешил обновить одну из не совсем рабочих баз, которая готовится стать рабочей и словил грабли - что-то не то произошло с подразделениями организаций, перестали в форме списка отображаться(текст "Не оформлен" вместо подразделения). Решил повторить загрузку из 2.5(периодически пока делаю это на той базе), ругнулся на смену владельца справочника Подразделения. Последствия... Во-первых, задвоились все организации - видимо что-то "сломалось" в правилах. Во-вторых, по идее при загрузке в справочниках не должны эти проверки отрабатывать, но как оно там в стандартном обмене сейчас, хз, но факт в том, что загрузка данных из 2.5 похоже не работает. К примеру, обработчик ПередЗаписью справочника подразделений сейчас выглядит примерно так:

Процедура ПередЗаписью(Отказ)    
    Если ЗарплатаКадры.ОтключитьБизнесЛогикуПриЗаписи(ЭтотОбъект) Тогда
        Возврат;
    КонецЕсли;    
    Если НЕ ЭтоНовый() Тогда
        Если ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "Владелец") <> Владелец Тогда
            ВызватьИсключение НСтр("ru='Нельзя менять организацию - владельца элемента справочника ""Подразделения""'");;
        КонецЕсли;
    КонецЕсли;    
    ПрежнееЗначение = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "ОбособленноеПодразделение");
    Если ЭтоНовый() Или ОбособленноеПодразделение <> ПрежнееЗначение Тогда        ДополнительныеСвойства.Вставить("ОбновитьИсториюРегистрацийВНалоговомОргане", Истина);
    КонецЕсли;     
    НастройкаПорядкаЭлементов.ЗаполнитьЗначениеРеквизитаУпорядочивания(ЭтотОбъект, Отказ);
    РеквизитИерархическогоУпорядочивания = РеквизитИерархическогоУпорядочивания();
    Если РеквизитДопУпорядочиванияИерархического <> РеквизитИерархическогоУпорядочивания Тогда
        РеквизитДопУпорядочиванияИерархического = РеквизитИерархическогоУпорядочивания;
    КонецЕсли;    
КонецПроцедуры

Если ещё этого не было, то вот краткое описание плюшек
http://buhpoisk.ru/obzor-zup-3-1-8-oktjabr-2018.html

(90) Ага, рубят сходу не разбираясь... раньше годами реквизиты были с Удалить..., а тут бац - и нате вам.

(99) https://yadi.sk/d/0PgEqh0tgK0vtQ

(101) так регистр же с Удалить сделали, то есть старый переименовали, новый с тем же именем создали, уже непериодический

(103) Когда конфа не на поддержке, при обновлении создаётся новый регистр, который "удалить", а у текущего, рабочего, удаляется регистрации. У меня именно так и получилось

+(104) Периодичность, а не регистрация)))))
Совсем тяжело обед прошёл.

(102) спасибо

(104) что-то ты намудрил с поддержкой. Обновляться же геморройно будет. Я тут недавно намучался с обновлением зуп 2.5 на 2.5 корп потому что ИД некоторых объектов отличались.

(107) Ничего подобного. Всегда, когда конфа готова и изменена по технологии, сразу снимаю с поддержки. Обновляю конфы в день выхода обновления или около того.
Да и для трансформации баз тоже как-то поддержка не пригождалась. На УПП бухию обновлял и работали все радостно (с небольшими корректировками данных)

А по правде все, куда не прихожу, сначала доказывают, что поддержка ой как нужна, а потом признают, что и не очень то и нужна

(108) это противоречит твоим словам о том, что случилось с регистром ЛС :)

(109) Случай с регистром ЛС редок и не причиняет много проблем, тогда как поддержка отъедает больше памяти, увеличивается время сравнения и объединения и мне не нравятся жёлтые квадратики (шутка). Другими словами, конфа находящаяся на поддержке доставляет неудобства постоянно, тогда как проблемы с регистром (или подобным) раз в несколько лет.

(104), (107) Отъезжающие идентификаторы из-за каких-то настроек при накате обновления. Этого можно избежать. Как именно - сейчас не припомню, давно не занимался обновлениями.

(111) В моём случае можно было бы переименовать удаляемый регистр по имени из обновления и далее действовать как и рекомендовано. Только зачем? Быстрее было снести всё нафиг и перенести из копии данные. Оно ж так быстрее

(112) Как зачем. 1С так делает, чтоб не париться с реструктуризацией и новые данные в новый регистр тащить не из копии, а из существующего в этой базе переименованного регистра.

(113) Это актуально только если совсем без изменений. А когда вклиниваешься в конфу, то данная фича становится только обузой.
Когда включаешь возможность изменения, конфы раздваиваются и памяти больше занимают и сравнение и объединение дольше проходит.
Но это только личное мнение, основанное на личных наблюдениях. Работает данная концепция во многих конторах, поэтому не изменю своих взглядов на обновления

(114) Можно полностью снять с поддержки, удалить вообще конфигурацию поставщика и тем не менее обновлять без расхождения внутренних идентификаторов.

(115) Никогда не задумывался про идентификаторы. Честное слово. Раз случилась мелочь и пофиг. Моя задача анекдоты читать, а не вдумываться какие байтики и как там располагаются (почти шутка)

(116) Да я и не призываю менять подход. Объяснил причину.

Друзья, подскажите лентяю чего там разработчики намутили с перерасчётами? Исправление табеля делаю, а оно в перерасчёты не попадает. Даже если и попадает, то записи не сторнируются, а только плюсуются. Честно-честно не могу найти методологию.

(103) Один фиг нетиповые запросы для формирования документов в банк перестают работать.

(109) Раньше это периодически случалось с УПП на поддержке. Так что и поддержка не панацея.

(112) Быстрее было на этапе сравнения и объединения поменять соответствие регистров.

(118) Смотри описание. Они часть перерасчетов посчитали ошибочными и теперь их не делают.

(121) Это если точно знать, что на что менять, а для этого надо читать. Если перед каждым обновлением читать-изучать чего там поменяно, тогда времени много будет уходить. В общем лень

(122) Они добавили РегистрСведений.ИсходныеДанныеПерерасчетов из которого берётся информация для сторнирования.
Просто думал, что может уже кто разобрался в тонкостях изменений по перерасчётам.

(123) Зачем? Просто просмотреть соответствие объектов и новые объекты пока галки расставляешь. Новый объект с названием Удалить должен был бы смутить.

(124) "Удалить" просматриваю только в своей подсистеме. Просто в последней ЗУПе много чего поудаляли и всё просмотреть не получилось (чуть не уснул).
ЛС, это сущий пустяк. Вот перерасчёты оказались серьёзным барьером

(125) Этот регистр должен был заполниться обработчиками обновления по данным документов. Вот там и ищи логику.

Общий модуль "ПерерасчетЗарплаты", процедура ЗаполнитьИсходныеДанныеПерерасчетов()

(126) Проблема в том, что разработчики исключили табели из перерасчётов, а сертифицированные консультанты и программисты, которые были до меня, использовали этот момент для постановки учёта, вот и ломаю голову.

Конкретная ситуация: Сотрудник находится на межвахтовом отдыхе и ему за это платятся деньги. Т.е. в табеле отмечаем как межвахту. По окончанию межвахты он приносит бумажку о повышении квалификации. Раньше кадровики делали исправление табеля сегодняшним днём и перерасчёты пересчитывали начисленные и выплаченные деньги (минус дни межвахты, плюс дни обучения).

Ох, блииииин... а ведь правильнее то было бы плясать от первички, а не от табеля.

(127) Разработчики ЗУП периодически намекают, что табель в виде документа оставлен против желания самих разработчиков. Ориентироваться на него при доработке своих фич несколько рискованно, да )

Совсем запутался. Если табель не исправлять, тогда первичка делает перерасчёт, а если табель исправить, тогда и первичка и табель не делают перерасчёт.
Всё равно не вернусь на 3.1.7

(128) Увы, консультанты просто зарабатывали деньги, когда ставили учёт. А я не имею права махать шашкой, ибо хожу с важным лицом

Обновил, несколько дней назад, полет нормальный, кантора небольшая правда.

Если вдруг кому интересно, то пока что решение пересчётов с исправлением табелей такое: сначала делаем пересчёт и только потом исправляем табель.
Мне кажется, это опять бред бредовый, но пока так

strange2007 подскажи, пожалуйста, ты в (85) писал, что у вас почта отвалилась после перехода и надо какой-то порт открыть. Какой порт? а то у нас фтп отвалился, думаю по той же причине, админ пока не может понять в чем дело

(132) какой-то SMTP доп порт и задублировал коннект. т.е. сделал копию какого-то коннекта до (или после) этого порта.
Друзья, в терминологии админа я немного не понимаю, поэтому просто написал всё дословно.
Во! Сейчас адимн сказал, что основной пункт - дублирование коннекта.

(133) Спасибо! Передал сисадмину, надеюсь поймет о чем речь.

(131) Просто не делайте табель - тогда по результатам расчета вы будете видеть, все ли документы правильно вы ввели.

(135) Спасибо за совет. Но тут табельный учёт, это местный фундамент. На него куча отделов завязаны. Я сейчас начинаю его переделывать на стандартный табель + разработка для учёта, но по планам всё запустится ещё не скоро.
И кстати, в стандартной конфе, табельный учёт работает идеально.

Кому интересно - платформа №12 чуть больше притормаживает, нежели №11. А у №13 цвета интерфейса чуть-чуть поменяли.

Сколько лет прошло, а ЗИК/ЗУПтак и не умеют работать от табеля похоже

Вот из-за этого еще в 2002 и перешли на продукты камин

(137) а что камин еще жив до сих пор?

(138)Живее всех живых. Даже та версия которую покупали еще в 2002 году поддерживается

(138) активно развивается. Камин 5 тоже на управляемых формах. До сих пор поддерживается и редакция на обычных формах и даже 7.7

Могу ошибаться, но табель является второстепенным документом, нежели, например, больничный. Ведь в табеле пишем Н-ки, а по факту человек может оказаться на больничном.
С межвахтой вообще может быть что угодно. В табеле межвахта, а чел по факту может даже обучение пройти и табель об этом вообще знать не будет

(141) По изначальной логике 1С, сначала вводятся документы отклонений, затем производится расчет зарплаты, и после этого полученный табель сравнивается с тем, который получился по фактическому учету рабочего времени (он же подписан руководством). Если есть расхождения - значит не все документы введены правильно. Если расхождений нет - значит все ОК (ну, в части учета времени).

(141) если учет ведется методом отклонений табель является отчетом. после полного расчета зарплаты за его можно сформировать и записать. проводить категорически не рекомендуется из огромного количества записей -вроде 12 записей на человеко-день т.е 100 человек это 100*12*30=36000 в регистре сведений в месяц.

А что-то в ЗУПе придумали для разделения зарплаты по объектам/проектам.
Актуально в стройке, например, где на разных объектах люди работают в течении месяца?

(144) Дык давно
Документ Перемещение между территориями, документ Изменение мест работы

(145)И прям в течении месяца можно несколько раз двигать?

(146) Таки да, как раз для кратковременных перемещений предназначены

(147)Ну хоть что-то, Но от работа от табеля была бы и логичнее и удобнее.

У нас на каждый объект свой табель вели мастера

(148) Из одного только табеля без распорядительного документа, какого-то наряда или согласованной заявки, задания на день и т.п. все равно невозможно считать.

Если кому интересно, то в этой конфе есть болючая ошибка. Стандартная функция "КадровыеДанныеСотрудников" выдаёт не всегда верные результаты.
В общем закрыли одну штатную позицию и открыли другую. Сотрудника перебросили в открытую. Так вот функция КадровыеДанныеСотрудников возвращает информацию, что сотрудник работает в закрытой ШП.

(144) Там только по видам работ нет распределения, а по территориям уже всё более-менее нормально.

(150) что значит "не всегда"? И от чего же это зависит?

(152) Я пока только один случай увидел. Поэтому про "не всегда" не сильно то и уверен.
А от чего зависит... Пока не знаю. Сейчас костыль поставлю, а потом уже, в свободное время, буду разбираться.

И если у кого ведутся сложные исправления документов, то рекомендую тщательно смотреть пересчёты. Что-то 1С-ники там переписали всё очень круто. Свёртка пересчётов там вообще крутая - работает не верно и расшифровку к ней с разбегу не прикрутишь. Но это может быть и из-за наших переписок

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

(154) смотри РС подчиненнность подразделений или как то так, там не хватает записей

(155) спасибо! сам только что дошел до этого. Ура! Выходные все таки будут :)
В понедельник обработку напишу, по проверке и дозаполнению регистра

странно, регистр вроде не новый, в 3.1.5 был. А отсутствие записей никак не проявлялось

Теперь кадровики с ограничением по группам физлиц не могут записать новое физлицо. Что опять не так?

у 1С что новая традиция - на новый год устраивать всем секас с глючным релизом? в прошлый НГ это был 3.1.4. теперь походу 3.1.8 такой же...

(159) ЖДи 3.1.9, обещают до НГ

(159) это еще не под новый год - считай за пару месяцев до него. Еще что-то успеют подправить. А вот 3.1.9 - это, да. Ждем-с. С содроганием.

После обновления на 3.1.8 словил глюк - в Организации оказалось пустое поле "Головная Организация". Из-за этого вообще все перестало работать, ничего не заполняется, ничего не рассчитывается, т.к. все типовые запросы завязаны на этот реквизит и возвращают пустые таблицы. Пол дня убил на то, чтобы разобраться, в чем дело, залезая по самые гланды отладчиком.

(162) На какой конкретно релиз обновился? На последний  3.1.8.185?

(158) Выяснил следующее:
В общем модуле МедицинскиеОсмотры
в процедуре ЗарегистрироватьИзменениеВозрастаФизическогоЛица
есть строка

КадровыйУчет.СоздатьВТТекущиеКадровыеДанныеСотрудников(МенеджерВТ, Ложь, ОтборыМассив, "ГоловнаяОрганизация");

Второй параметр, в который передается Ложь это "ТолькоРазрешенные".
После принудительной установки в него Истина ошибка не проявляется.
Пока так исправил у себя

(164) КОРП поставка?

(165) да. Но все равно странно, почему больше ни у кого не проявилась ошибка.

(166)+ на партнерском тоже молчат

Коллеги, может у кого есть информация про странный алгоритм: Если делаем штатное изменение в будущем (например январь 2019), то они видны всегда, не зависимо от даты. И вот тут случается беда. Смотрим список штатных единиц, а там по позиции 4 штуки, как указано на январь 2019. Открываем элемент этой позиции, а там 2 единички (как и должно быть на сегодня). Записываем элемент и в системе становится 2 единицы, в т.ч. и в январе 2019.
У меня только один вопрос - нафига? Франча и 1С тревожить из-за мелочи не хочу, но я ж возмущён!

(168) так вероятно, что перезаписался набор записей РС? При записи элемента логично, что у разрабов создается набор записей для РС и затем он пихается в регистр и затирает попадающее под отбор .

(169) Я как-то привык, что регистры двигаются только документами (в данном случае изменением ШР)или только справочником. А то тут получается, что записал справочник - одно значение, перезаписал документ - другое. В общем путаница и для некоторых подстава

Изменения в ФИАС в ЗУП 3.1.8, кто сталкивался, посмотрите, плиз, и мой вопрос здесь:   ФИАС: административное или муниципальное деление

(171) Ндя, слов нет

(172) Господи, Amra! Отстаньте от меня, ваши комментарии - в пустоту иногда...

(173) Уговорили, дал вам последний ответ. Больше отвечать не буду, дабы вы так не напрягались.

(167)+ признали ошибкой

Вышел тестовый 3.1.9

перешли на 3.1.8.214, пока словили ошибку доступа из поста (82), решение оттуда же помогло

Сегодня поставили новую платформу и 3.1.8
Пользователи говорят, что медленнее стало работать.
У кого-то есть такие наблюдения?

(178) наблюдения были, что некоторые платформы начинают тормозить

(178) а чтобы сама по себе 3.1.8 - это трудно заметить, т.к. для нее же и приходится платформу обновить. Платформа какая?

поставили 8.3.12.1685. я думаю в первый день после перехода пользователи ради, что оно вообще работает) жалобы на тормоза, если и будут, то позже

(180) Платформа 8.3.13.1644

(181) Срочно обнови платформу на 8.3.12.постарше. На этой замечены зависания при подборе сотрудников.

(0) У меня обмен не проходил Бух 3.0.67.38 и 3.0.67.63 с ЗУП 3.1.8.155, 3.1.8.185 и 3.1.8.216, падал на этом

Ошибка получения значения свойства объекта (по имени свойства источника)
    ПКО                    =  ПодразделенияОрганизаций  (Справочник: Подразделения)
    ПКС                    =  9  (СоответствуетСудамЗарегистрированнымВРоссийскомМеждународномРеестреСудов --> СоответствуетСудамЗарег)
    Объект                 =  Расходы НИОКР  (Catalog Object: Подразделения)
    СвойствоПриемника      =  СоответствуетСудамЗарегистрированнымВРоссийскомМеждународномРеестреСудов  (Булево)
    ОписаниеОшибки         =  Object field not found (СоответствуетСудамЗарегистрированнымВРоссийскомМеждународномРеестреСудов)
    ПозицияМодуля          =  Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(10880)
    КСообщенияОбОшибках    =  13

Дело оказалось в реквизите "СоответствуетСудамЗарегистрированнымВРоссийскомМеждународномРеестреСудов" со всех сторон.
Он стоял "УдалитьСоответствуетСудамЗарегистрированнымВРоссийскомМеждународномРеестреСудов".

После переименования в "СоответствуетСудамЗарегистрированнымВРоссийскомМеждународномРеестреСудов", как говориться в зад, все завелось.

Т.е. по факту в обмене правило осталось старое.

Обнаружил странное поведение 3.1.8.216
Если сделать продолжение БЛ за декабрь, то часть видов расчета сторно кидается в январь.
И в справке 2НДФЛ за январь стоят минусы за 2019 год

Вроде ничего странного. Нужно при продолжении делать так, чтоб сторно не было.

Бюджетники заранее закрывают год.
Не указали невыходы заранее
Как в этой ситуации без сторно?

В результате 2НДФЛ такое
http://imglink.ru/show-image.php?id=44a387a03f70a1332dd240b034f1ed0a

(187) ну так бюджетники... все печально

Еще один косяк 3.1.8
Вычет для матпомощи 2762 должен быть 508, а в выгрузке 503 (хотя в документе все верно)
Вот часть файла выгрузки:
- <ДохВыч>
- <СвСумДох Месяц="02" КодДоход="2762" СумДоход="30000.00">
<СвСумВыч КодВычет="503" СумВычет="4000.00" />
</СвСумДох>
<СвСумДох Месяц="03" КодДоход="2003" СумДоход="7000.00" />
- <СвСумДох Месяц="08" КодДоход="2760" СумДоход="5000.00">
<СвСумВыч КодВычет="503" СумВычет="4000.00" />
</СвСумДох>
</ДохВыч>

(190) А в ЗУП 3 код вычета нельзя поменять в документе, которым вводится матпомощь?

(190) В 3.1.8.216 не так, но не работает) В начислении код дохода 2762, а в документ подставляется вычет 503, и изменить его нельзя, для выбора доступен только 503

(191) это вроде как от "Виды доходов НДФЛ" зависит больше.

1C ошиблась. Обещают в ближайшем релизе исправить.

Очень, очень долго создается реестр ЭЛН в 3.1.8.216. Около получаса. Хотя таких ЭЛН, неотправленных, несколько щтук всего.
Беглый анализ в отладчике показал, что перебирается ТЗ где 32к строк - строки по всем больничным в разрезе месяцев базы для расчета среднего.
Кто-то сталкивался?

(195) Одинаково и 3.1.8.216, и в 3.1.5.380

(196) одинаково долго?

(107) Да

(198) -> (197)