Привет всем!
Это теперь норма, да? Что куча независимых регистров сведений, записи в которые надо ловить сидеть в дебагере.
Только по состоянию сотрудника около 4 регистров и только 1 имеет регистратор.

Чем это обусловлено?

Сделай глобальный поиск по имени регистра

(1) Это да,
но почему именно этот путь развития?
К примеру, откуда берет данные форма подбора сотрудника?

8 часов рабочий день, из них надо тратить 3 часа на поиск откуда это все тянется

(3) И зачем это искать?

Это метаданные на уровне кода. Тебе не надо знать, что где в каких регистрах хранится, тебе надо знать процедуры и функции, которые вернут тебе эти данные.

(3) А не надо трогать ЗУП, не для этого он написан.

(4) К примеру задача с обменом со сторонними базами.
Сравнить время по СКУДу и отсутствиям  сотрудника

Мне вот тоже интересна разница между РС "Данные состояний сотрудников" и РС "Состояния сотрудников".

Логотип хабра видел?

(0) Тенденция, однако. Из одной крайности в другую крайность: то собираем всё в реквизиты, то разбрасываем по регистрам. Сочувствую. "Не дай Вам Бог жить в эпоху перемен"(цы)

(3) плохому танцору яйца мешают (с)
тенденция однако

(8) Тебя не должно это волновать. Ты просто пишешь КадровыйУчет.СоздатьВТКадровыеДанныеСотрудников(ОписательТаблиц, Истина, "Состояние");

(0) ППКС. Независимые регистры сведений, двигаемые программно - потенциальные грабли, на которые просто обречены наступать. И огромный гемор в выявлении причин некорректного поведения конфигурации.

(7) Ищи типовую функцию, которая вернет тебе нужное значение.

(13) ЗУП непогрешима. Погрешим доработчик.

(14) Конечно найду. Дело не в том что не найду.
А в том, что это все жутко сжирает время.

И что особенно противно бывает, так это отсутствие штатных средств по исправлению корявок в этих регистрах. Даже форма списка регистра открывается в режиме "только чтение", специально западло.

(7) Тебе нужен общий модуль УчетРабочегоВремениРасширенный, а не регистры.

(12) а в обратную сторону, если нужно записать, а не прочитать?

(0) Для ЗУП 3 это норма уже как несколько лет. Обусловлено ускорением работы программы.
При проведении документа данные можно сразу разложить по разным регистрам в нужных разрезах.
При построении отчетов, при заполнении документов, при выполнении различных расчетов быстрее будут собраны сразу готовые данные.

(15) Если бы. Дофига было бажных релизов, которые ересь в эти регистры писали. А потом ищи, почему например в ведомость не все сотрудники попадают..

(16) Ты фикс? Или франч?

Для первого случая - "сжирает время." - и что с того? Солдат спит, служба идет.
Для второго - выставляй счет на затраченное время.

(0) коммерческий код...надо продавать ...готовить спецов на курсах чтобы рассказывать что и как хранится в куче таблиц ..опять же деньги

(8) РС "Данные состояний сотрудников" - первичный регистр, в него пишутся состояния сотрудника на дату изменения (Период).
РС "Состояния сотрудников" - вторичный регистр, в него пишутся периоды состояния сотрудников (ДатаНачала, ДатаОкончания).
Записи в РС "Состояния сотрудников" формируются после записи в РС "Данные состояний сотрудников", при этом анализируются не только текущая, но и другие записи по сотруднику.

(20) То есть ЗУП ждет скачок в область больших корпораций? Где будет работать по 10 000 сотрудников?
А нельзя для обычных земных фирм сделать все проще? :)
Совершенно не критично что отчет Штатные сотрудники будет выводиться на 2 секунды дольше, благо ssd стал доступнее.

(19) КадровыйУчет.СформироватьКадровыеДвижения

(25) >То есть ЗУП ждет скачок в область больших корпораций? Где будет работать по 10 000 сотрудников?
10000 сотрудников нормально переваривал и ЗУП 2.5

>А нельзя для обычных земных фирм сделать все проще?
Вопрос не по адресу, напишите в 1С на хотлайн.

(25) ЗУП 2.5 переваривал больше 30 тысяч сотрудников, на одном из проектов, где я работал. Так что тут скорее парадигма сменилась, и под неё перестраивают.

(24) Охренеть! Игла в яйце, яйцо в утке, утка в зайце...

Программиста "отделили" от структуры хранения данных в СУБД. Мир рухнул? Нет. Родились программисты 1С. Теперь программистов 1С отодвигают от знания хранения объектов 1С. Ничего страшного :) Выживут выжившие. Название им ещё не придумано.
PS: Я начинал программировать с перфокарт, мне всё уже по ... но вашей судьбе я не завидую :))

(29) На самом деле это довольно удобно, если закрыть глаза на (21)

Вообще это конечно намек, что структуры метаданных, поставляемой платформой, не хватает для решения возникающих задач.

(25) > А нельзя для обычных земных фирм сделать все проще?

Так УЖЕ всё сделано проще. Тебе не нужно анализировать никакие регистры.
Реализован программный интерфейс.
Тебе достаточно найти нужную функцию, которая вернёт нужные тебе данные. Причем данные будут корректными вне зависимости от структуры регистров, настроек параметров учета, учетной политики и прочих местных особенностей конкретно взятой базы данных.

(24) Спс

(30) На самом деле это здорово. Но вопрос где описание методов взять. По стандартным библиотекам на ИТС описание есть. А вот по типовым конфам?

Архитектура ЗУП движется к повышению ценности специалистов, знающих упомянутую архитектуру.
Так шта верной дорогой, правильным курсом!

(35) Описание в общих модулях, в областях "ПрограммныйИнтерфейс", в комментариях к функциям.

(33) Но ведь опять ключевая фраза "Найти"

(25) "То есть ЗУП ждет скачок в область больших корпораций? Где будет работать по 10 000 сотрудников? " - Воу, полегче!

Будь проще: есть данные, а есть методы для работы с этими данными. Вот и работай с методами. Структура данных сегодня одна, завтра другая. А вот методы можно как-то сдерживать.

(35) Описание метода есть в конфе. Существование такого метода определяется при анализе типового кода.

(39) ага, но при этом практически весь расчет идет через форму

(33) Вот-вот, ЗУП превратилась в "черный ящик". Разработчикам пришлось делать прослойку в виде программного интерфейса, потому что намудрили такую чудовищную структуру регистров, которую сами не в силах объять прямо, без прослойки.

(41) Все расчеты в обработке "МенеджерРасчетаЗарплаты".

"БСП", имхо, сейчас ключевое слово. Типизация и унификация. Те, кто работают/работали с УПП - это давно уже осознали. Беру типовые кирпичики конфигурации и строю свой барак-бардак. Мне, лично, уже пофигу для какой конфигурации писать алгоритмы, а Вам? :))

(41) В конечном итоге все идет через общие модули и обработки типа МенеджерРасчетаЗП, МенеджерДанныхУчетаВремени.

(44) зуп пока очень сильно выделяется на фоне бсп-ерп

(38) Просто держи в голове, что скорее всего, где-то есть фукнция, которая возвращает то, что тебе нужно. Ищи в общих модулях соответствующих разделов учета.

(43) Ага, только вот форма - обязательный параметр

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

(48) В крайнем случае можно вместо формы подсовывать структуру. Приходилось так делать, но нечасто.

(49) Сразу сделать нормальную устойчивую структуру - никак?

почему то никто в других конфах таким курсом не пошел

(51) Видимо, слишком сложно.

(51) для того чтобы делать нормальную устойчивую структуру программы для решения определенной задачи нужно чтобы эта задача не переворачивалась с ног на голову непрерывно, как было с нашим расчетом зарплаты, который в горячие годы меняли по нескольку раз в год чуть менее чем полностью, однако требование к программе посчитать верно данные прошлых лет никто не отменял.
думаю кто с зарплатой работал плотно помнят эти изменения под новый год, когда новый релиз выходит 29го а зарплату считать уже надо по-новому.

https://ru.wikipedia.org/wiki/Денормализация

(54) и что кардинально менялось? что требовалась другая структура?

(52) С зарплатой всегда были "какие-то нюансы". Помню, еще в ЗИК открываешь конфигуратор и со словами "Ох, йо.." закрываешь.

(57) просто там супергениальный архитектор. остальные до него еще не доросли

это говорит о том, что архитектура всех этих регистров мало подходит для решаемых задач ..
аксес форева)

(40) Это очень неудобно. И может меняться.

(58) Просто его задолбало все время писать запросы по периодическим данным на каждый день периода.

(47) Хоть бы справочник тогда выпустили по этим функциям :)

(60) Ну суть такая, что в методе меняется только содержимое, но не описание.

(54) ЗиК 7.7 сколько лет живет? ЗУП 2.5?
Почему они без кардинальной ломки обходятся?

(57) Модуль расчета в 7.7 - рулит!

(8)(24) Добавлю только что данные в РС "Состояния сотрудников" формируются с учетом приоритетов соответствующего перечисления.

(62) По БСП есть https://its.1c.ru/db/bsp243doc#content:9260:hdoc

Довольно удобно. Сделали б по типовым, и пусть тогда меняют как хотят.

(67) Да, подобное сейчас очень бы пригодилось в сабже

(42) > Разработчикам пришлось делать прослойку в виде программного интерфейса.

Ты путаешь причину и следствие. Регистры регистрами, а программный интерфейс программным интерфейсом. И не надо смешивать всё в одну кучу.

Осмелюсь предположить, что рано или поздно этот подход будет реализован во всех конфигурациях и подсистемах.

+(55) Раньше в ЗУПе был один регистр РаботникиОрганизаций, и 100500 запросов к нему, в которых многократно повторялось
ВЫБОР
КОГДА РаботникиОрганизаций.ПериодЗавершения <> ДАТАВРЕМЯ(1,1,1) И РаботникиОрганизаций.ПериодЗавершения <= &Период
ТОГДА РаботникиОрганизаций.<Поле>Завершения
ИНАЧЕ РаботникиОрганизаций.<Поле>
КОНЕЦ

сейчас сделали несколько регистров, но позволяющих получать "популярные" данные без лишних соединений-пересоединений и конструкций ВЫБОР. Т.е. сразу можно получить те же подразделение и должность сотрудника на дату без лишних заморочек. Больше данных, но меньшая сложность в запросах. И это ПРАВИЛЬНО!

(64) Потому что при изменении структуры хранения данных пришлось переписать половину ЗИК 7.7 и ЗУП 2.5

(69) Если подумать, то это лучше, чем ловить проблемы при переименовании элементов метаданных. Ну, и им так проще будет затыкать методологические дыры.

(38) > опять ключевая фраза "Найти".

Недостаток документированности этого интерфейса по аналогии с любыми типовыми библиотеками, как, например, сделано для БСП, это серьёзная проблема.
Связана она скорее с тем, что процесс ещё идёт и возможны серьезные изменения этого интерфейса.

Пишешь нетленку:
Событие на запись любого регистра
И в процедуре выкидываешь в файл имена регистров, куда шла запись

(73) Возможно, все эти ЗарплатаКадрыОбщиеНаборыДанных, ЗарплатаКадрыОтчеты, ЗарплатаКадрыПериодическиеРегистры и т.п. когда-нибудь попадут в БСП, тогда и документация будет.

(75) > Возможно ... когда-нибудь попадут в БСП.

Никогда. В БСП ключевое слово "СТАНДАРТНЫХ". Расчет з/п, бухучет, оперативный учет - всё это никак не может считаться стандартными подсистемами и задачами. Они уникальны и специфичны для каждой конкретной конфигурации. В конце концов расчет з/п - это всего лишь одна из задач, которые можно решать при помощи регистров расчета и планов видов расчета.

Сразу тогда на уровне платформы, механизмы повторного использования запросов.  А то СКД уже используются извращенным способом, заходишь посмотреть запрос - а там болванка.

(76) Там нет специфичного. Там всякие ВТПериоды, построения срезов, движений интервальных регистров и тд.

(71) Когда это половину ЗУП 2.5 переписать успели? Мои доработки 2011 года отлично до сих пор работают.

(79) Пропустил "бы"))

Нужно читать:
"ЗиК 7.7 сколько лет живет? ЗУП 2.5? Почему они без кардинальной ломки обходятся? (из (64))
"Потому что при изменении структуры хранения данных пришлось бы переписать половину ЗИК 7.7 и ЗУП 2.5"

(33) "Тебе достаточно найти нужную функцию, которая вернёт нужные тебе данные. Причем данные будут корректными вне зависимости от структуры регистров, настроек параметров учета, учетной политики и прочих местных особенностей конкретно взятой базы данных."
Угу, а при очередном обновлении эта функция окажется мало того что в другом общем модуле, так еще и вместо объекта будет например принимать в качестве параметра форму. И гадай потом, где эту форму взять например в контексте сервера)

Если бы интервальные регистры ещё и корректно собирались.
Сейчас воюю с проблемой: что если в течении временного перемещения сделали ещё одно временное перемещение то в регистре кадровая история интервальный в записи после окончательного завершения временных перемещений стоит результат первого перемещения а не основного места работы.

А может кто подскажет, где та волшебная функция, которая возвращает изменение начислений за период?

(81) Не бурчите. Ну то же самое, что реквизиты справочника стали бы ресурсами регистра, один непериодический регистр стал бы периодическим, а другой вообще регистром накопления.

(83) Вроде нет такой. Посмотрите как строятся отчеты по плановым начислениям.
"Динамика изменений плановых начислений", "Анализ плановых начислений" - вроде так называются.

(81) Научитесь отличать "Программный интерфейс" от "Служебного программного интерфейса" и "Служебных процедур и функций".
Процедуры и функции программного интерфейса не переносят из одного модуля в другой.

(81) > а при очередном обновлении...

Пока что чаще при каждом очередном обновлении меняется структура метаданных, чем программный интерфейс.
Кроме того, важным преимуществом программного интерфейса является то, что при работе с регистрами напрямую надо хорошо разбираться в том, что конкретно лежит в каждом конкретном регистре и в каком случае информацию надо  брать из оного регистра, а когда - из другого.

Тебя же не напрягает, что после очередного обновления поле таблицы _InfoRg6355, хранящее ссылку на физлицо стало вдруг именоваться _Fld6356 вместо _Fld6353. Тебя устраивает уровень абстракции, который предоставляет платформа 1С.
Но когда тебе предложили ещё более абстрагироваться от вопросов физического размещения данных, ты впадаешь в ступор и панику. Подайте мне работу с таблицами!!!

(87) Я не против, если мне предложат работу через высокоуровневый уровень абстракции. Только вот он слишком часто меняется тоже, и не может считаться стабильным интерфейсом.

(88) В общем, "восьмерка сырая еще"

Еще удивляет, зачем они ломают то, что эффективно работает. Тот же регистр "ответственные лица организаций", с указанием должности каждого. Теперь должность берется из сотрудника. Но зачем? Всякое бывает, иногда за руководителя подписывает например внешний управляющий, который не числится в штате.

(90)"Теперь должность берется из сотрудника"
Это не так. Должность ответственного лица берется из РС "ОснованияПолномочийОтветственныхЛиц".

(90) а еще я им посоветовал сделать ответственных лиц периодическими, они согласились на это, так что ждите новых изменений ))

(92) Новое - это хорошо забытое старое)

(91) Ага. Прибили гвоздями ресурсы "должность руководителя", "должность кассира" и тому подобное. Уродство сделали какое-то. Помню пару лет назад в ЗУП3 было адекватнее сделано.

ЗУП это, конечно, что-то с чем-то. Два дня просидел, чтобы создать обработку по автоматическому созданию документов начисления и его правильному заполнению (актуально, когда сотня подразделений).
Одна ТЧ "показатели" чего стоит. Куча данных на форме, а заполнение - ум отъешь

(94) Это тоже не так.

В РС "ОснованияПолномочийОтветственныхЛиц":
Измерения - Организация, ФизическоеЛицо
Ресурсы - ОснованиеПодписи, Должность

В РС "СведенияОбОтветственныхЛицах" ресурсы "Должность руководителя", "Должность кассира" и т.д. помечены префиксом Удалить.

ОснованияПолномочийОтветственныхЛиц делали бы уже тоже периодическим тогда. Основание подписи - может быть Доверенность, она обычно дается на конечное число дней, потом основание подписи уже другая доверенность, при этом ответственный и его должность не меняются

(97) а смысл? Полномочия либо есть, либо их нет. Если бы физлицо было в ресурсах, а полномочие в измерениях, тогда имело бы смысл прикрутить период

(95)Ага, примерно тоже - загружал документы премии - потребовалось проставлять показатели расчета времени - пришлось эмулировать работу формы.

посмотрите второе исправление в новом 3.1.9.108 ) за всю боль, долистай до ста

(100) Всего две ошибки исправлено ?

(101) там код исправления страниц на 30

У меня вот вылезла ошибка подсчета рабочего года для отпусков. Релиз свежий. В багборде зарегистрирована под номером 30157765 и исправлена аж в версии 3.1.7.61 !!!
Написал в сапорт, жду ответа.

(102) Это я видел, надо было дописать, что сравнивал сс 339 неисправленных...

Вот кстати любопытный вопрос - нам, простым смертным, положено страдать, если мы в недобрый час запустили отладчик в ЗУП3. Но как разработчики сами отлаживают своё творение, погружаясь в модули на 10 уровней, и разглядывая МВТ с 20 таблицами? Или они уже все поголовно в EDT? Или у них какие-то другие инструменты отладки, или просто мозги как у Нео, способные видеть отлаживаемый код без нажатия Shift+F9?

(105) Ходят слухи, что разработчиками являются женщины, а  у них, в отличие от нас, мужчин, аппаратно вшита в мозги многозадачность. Следовательно, удержать в голове запрос с 20-50 МВТ для них не представляет никакого труда.

(106) если это правда, то есть побочный эффект - обычно код, написанный женщиной, у мужчин-разработчиков вызывает головную боль и жжение ниже спины.

(107) Не верьте отзывам плохих программистов, которым 50 таблиц в МВТ работать мешают.

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

(105) > ...погружаясь в модули на 10 уровней, и разглядывая МВТ с 20 таблицами.

А зачем им это? Зная программный интерфейс и принципы его работы в этом нет особой необходимости.
Достаточно знать контрольные точки и понимать как собирается информация из источников.

В 99% случаев проблемы не в работе алгоритмов, а в исходных данных.
То ради чего нам, не имеющим толковой документации и описания программного интерфейса, приходится лезть в отладчик, не вызовет проблем у разработчика. Это тот самый случай, когда они и так знают куда стукнуть и с какой силой, чтобы оно заработало.

(0) в ЗУП 3 уже сделали бригадный наряд? или там конфа для тех, кто в пределах МКАДА?

(0) Напиши справку про програмный интерфейс ЗУП - станешь миллионером!

(105) Код покрывается тестами и не надо никуда лезть, по результату теста все ясно и понятно что поломалось )

(113) Если уповать на тесты, вместо анализа кода, то код непременно скатится в какашку с "приемлимым уровнем ошибок".

(114) приемлемый это только на 100% прошедший тесты код.

(115) нет. "Не 100% - неприемлемый", а вот отрицание надо по правилам протаскивать

(24) С Периодами стажа ПФР такая же фигня, есть первичный Параметры периодов стажа и независимый Периоды стажа. Мы написали обработку и теперь перед формированием отчётов перезаполняем(типовой функцией) Периоды стажа за год

(113) Это другая техника разработки Разработка через тестирование (test-driven development), 1С пишется не по ней

(118) откуда такая уверенность ? К тому-же не обязательно упарываться в ТДД по полной, достаточно покрывать код тестами, тоже имеет право на жизнь.

(119) "достаточно покрывать код тестами" - возникает соблазн писать код "абы как, лишь бы тесты прошло".

(113) Да, в сферической базе в вакууме с минимальным количеством документов, как любят писать на саппорте. Все прочие ошибки они ошибкми не считают, отвечая, что это мы ведем учет как-то не так.

Это я все еще не могу забыть историю с НДФЛ в релизе 3.1.4, когда саппорт не смог воспроизвести ситуацию, а потом втихушку в 3.1.4.167 все исправили.

(119) Я 10 лет с ней работаю, тестированием там и не пахнет))

(105) моё нубское предположение. Возможно, одни разработчики пишут "движок" ЗУП (основные справочники, регистры и общие модули), и прикручивают программный интерфейс для работы со всем этим добром. А другие разработчики под этот "движок" пишут документы, организовывая работу с основными расчетными механизмами через программный интерфейс. Что-то типа как в этих ваших ООП: разработчик знает что есть такие-то классы с такими-то методами и свойствами, и ему совершенно незачем вникать во внутреннее устройство этих классов. Также как нам, 1сникам, незачем знать внутреннее устройство, например, регистра накопления, достаточно знать как он работает и где его применять.
Нагрузка на отдельного разработчика заметно снижается, ему уже не нужно быть ходячей энциклопедией, достаточно знать точки соприкосновения и как их применять. Profit

(120) как написать покрытие тестами изменения учета по ндфл заполярного летчика шахтера в декрете? и потом отключить тесты переходящих вахтовых отпусков в облястях приравненных к заполярью в части проезда в санатории республики крым потому что он внезапно стал наш?

(0) у них до сих пор в головах ошибка : они дату получения дохода пишут в документе начисления зп

вот когда осознают, исправят -- можно говорить по переменах

(124) И сторно всего этого из-за больничного с продлением после окончания болезни

(125) Вообще то дата получения дохода корректируется при выплате

А в документе это как бе предварительная предполагаемая дата получения дохода

(119) Они, вроде, по BDD, а не чисто TDD  решили работать...

(110) "В 99% случаев проблемы не в работе алгоритмов, а в исходных данных. "

ну да, ну да.

удар номер раз https://bugboard.v8.1c.ru/error/000051092.html

удар номер два https://bugboard.v8.1c.ru/error/000051188.html (причем эта до сих пор не исправлена на рабочем релизе)

про 3.1.4 вообще лучше не вспоминать, а то дьявола призовешь

причем я прекрасно помню, как год назад оказался в такой вот ситуации, когда вроде бы отлежавшийся после выхода релиз после установки начал считать в двойном размере что-то. "Прелестно, просто прелестно"

(127) тупая задумка

из-за неё
делают лишние движения в регистре налогового учёта
в справку 2ндфл попадает то, что не должно

(131) Расскажи своё видение решения этого вопроса.

(132) убрать к чёртовой матери реквзит дата получения дохода из документов начисления

перечитать НК и понять, в какой момент определяется дата получения дохода
после этого реализовать

(105) "о как разработчики сами отлаживают своё творение". посмотрим на выпускаемые релизы, применим принцип бритвы Оккама
ответ - "никак". все сходится

(133) постоянный пересчет НДФЛ не особенность реализации в программе, а потребность, установленная нормами НК РФ. ©https://buh.ru/articles/documents/79563/

это пугает. Как объяснить "блодинке" кадровичке, что сотрудник не отображается сотрудник т.к не записи в каком-то регистре. И как сделать эту запись ХЗ

(133) А НДФЛ без даты дохода ты как считать будешь? Вычет за какой месяц применять?

(130) + ЗУП(базовая), 3.1.9.108 - После обновления перестала считаться премия пишет деление на 0 . да этот список можно продолжать до бесконечности. конечно, конечно, проблема именно в данных

(138) В описании к релизам ЗУПа честно написано о 400 неисправленных зарегистрированных ошибках

вспоминая 2017ый год, когда на новом месте я стал работать с 3.1, после 2.5 - я всерьез тогда раздумывал, может ну его, завязать с зуп и уйти на другую конфу. но нужно было жилищный вопрос решать и просадки по зп были не желательны

(139) одно дело, когда ошибка аля что-то не так в печатной форме выводится. с этим можно жить годами. а все приведенные мною примеры - прямые косяки в расчете зп или ндфл. с ними в первый же расчет можно налететь на миллионные переплаты, фактически с такими косяками релизы надо отзывать

(140) Аналогично, бро. Жизнь разделилась на "до" и "после", как мы перешли работать с ЗУП 2.5 на ЗУП 3.1 - светлая полоса сменилась непроглядной коричневой.

(141),(142) Такие же мысли нет нет и возникают. Ну что, братья по разуму, на какую конфу все бежим?)

(143) Пока на 3.1.8. Мелких перевожу на 3.1.9, чтобы выцепить косяки.

(143) Дело не в конфе, а в НДФЛ) Чемодан-вокзал-Израиль)

(143) Бегите на ERP, Роме в отдел консультантов не хватает)

(143) Бежать не надо, нужно уволить архитектора ЗУП в 1С. Может новый станет разрабатывать так, что его женщины-кодеры будут в состоянии отлаживать то, что написали.

(146) в ерп тот же зуп есть

Нууу, по идее в УПП пока еще "ламповый" ЗУП.

(148) И?

Какие разноплановые советы) Подытожим: с чемоданом в Израиль внедрять ЕРП у Ромы в связке с ЗУП версии 3.1.8.

(149) Как он лампово предсказывает дату выплаты(получения) дохода?

(124) Для этого тесты и пишутся. Впилил ты куда-то дополнительное когда - тогда, чтобы понять, что старый функционал у тебя цел - уже есть его тесты. Чтобы понять, что новый функционал работает верно - так же покрываешь его тестами. И тебе впринципе не надо знать как весь зуп работает, достаточно того, что твоя функция возвращает то что требуется.

Вообще на эту тему есть хороший рассказ чувака из оракла, который занимался разработкой БД. А уж там строк кода чуть поболее чем в ЗУП 3. Как раз на написание теста и процесс тестирования уходит большая часть времени.

(129) Ну и это не плохо. А то что тестирование типовых конф присутствует, это факт. Про разработку платформы писали, что тесты у них есть.

(135) причём тут перерасчёт больных и дата получения дохода ?


(137) в ведомости укажи за какой период выплата

(154) Ведомость не начисляет НДФЛ. Его начисляет и рассчитывает Больничный, а для расчёта нужно знать вычет, а для вычета нужно знать месяц получения дохода

(153) Погляди до чего тесты компанию Oracle довели.
https://habr.com/ru/post/429946/

(155) ну так пусть ведомость и проставляет дату где нужно

(157) Так она и проставляет, ведомость корректирует дату получения. Но начислить НДФЛ нужно до Ведомости

Чел принёс больничный 27.02.19, тебе нужно дать проводку Дт70 Кт 68 в феврале, а выплата будет в марте(или не будет, может в апреле выплатят)

(155) почитай НК в какой момент надо исчислить НДФЛ

(158) это тупость

зачем делать движения по регистру ндфл, если но нему надо делать движения тогда, когда это написано в НК

нну и самое главное -- распечатав справку 2ндфл для сотрудника -- её исказишь

(159) проводка должна делаться тогда, когда ндфл удерживается

(162) на партнёрку не писал?

"Мужики то не в курсе"(с)
хотя есть мнение что не мужики

(163) там абрек какой-то возомнил себя мегачтецом матчасти, с ним общаться бесполезно

но ТП разделилась во мнении : одни сказали, что действительно надо делать тогда, когда удерживаем, а другие нет, по другому
позже они ушли на внутренний дискус и перестали отвечать

(165) есть ссылка? Чисто поржать

(165) Вангуешь, что нас ждет ЗУП 4.0 где все будет совсем не так?

(166) позже поищу

(167) да пипец ждёт, криворучек всё больше и больше
но ща эдо завалили, раньше хоть была прямая связь с руководителем направления, а ща ужас-ужас

(82) Про интервальные регистры они сказали, щас процитирую:

Ответ отдела разработки:
Это задуманное поведение программы.
При вводе второго временного события после первого, программа "забывает" что было сказано в первом событии.
Теперь она считает, что окончательным событием является второе.

А чего, почему, зачем - хрен пойми...

(169) перевожу на русский, они сказали "это не баг, это фича"

плюсы тоже есть  - портянок запросов как в зупе 2.5 вроде не стало. Как по мне упорядоченности в коде, в логике кода в 3 больше чем в 2.

(170) Там вагон таких "фич", например, при использовании территорий и отсутствии отработанного времени, оно обнулит нахер все процентные начисления (типа РК на какую-нить премию сотруднику, который был в отпуске), т.к. "отработанного времени жи нету!". Да, и ответ отдела разработки точно такой же: задуманное поведение программы :)

(172) ок. еще фича - если используется учет по террирориям с привязкой к налоговым, то ввод табеля за 15 дней месяца приводит к тому, что оставшиеся 15 дней месяца у сотрудников неверно распределяются по территориям. То есть табель либо не вводить вообще, либо только за полный месяц. отговорить отдел от ввода табелей, так и не получилось

(173) У нас такая же проблема.

(174) Толкователь ЗУП становится востребованной профессией.
Раньше это называлось Консультант, но теперь это что-то другое

Разобраться в современной архитектуре ЗУП не хватает знаний. Сейчас сопровождение 1С сводится к тому, что надо уходить в специализацию на конкретную конфигурацию, тогда и сопровождать будет легче. Только как объяснить руководству, что нужен ещё один специалист, когда последние десять лет сопровождением занимался один человек.
Конфигурация очень усложнилась, непонятно как дорабатывать и исправлять ошибки. То что раньше дорабатывалось за несколько часов, сейчас может затянуться на неопределенное время. Жизнь боль...

Вот по поводу одна конфигурация - один специалист, это давно уже реальность. Смотрю на типовые вакансии с "человеком-оркестром" (ЗУП,БУХ,УТ,ЕРП,УПП) и понимаю, что большинство работодателей живут еще временами 7-ки.

supersonic, покупки в складчину организуй, плиз, на другом ресурсе.

(179) Понял, учту. А почему нельзя?

А правильно я понимаю что все игрища с регистрами расчета - период действия, вытеснения, перерасчеты сейчас не используются в типовых конфигурациях.

Если да, то давно от этого отказались?

(181) Фактический период действия и вытеснения регистра расчета используются.
Сбор расчетной базы и перерасчеты реализованы с помощью отдельных механизмов на регистрах сведений/накопления.
Отказались чуть ли ни с самого начала выпуска ЗУП 3, ну или в первые годы развития системы.

(182) "Сбор расчетной базы и перерасчеты реализованы с помощью отдельных механизмов на регистрах сведений/накопления. " - так надо было поступать с самого начала. Регистры расчета с момента появления - убоги в этом плане. Им больше 10 лет понадобилось, чтобы это понять.

(183) Хорошо хоть в 3.1 не сделали как в 2.5 отдельные регистры расчета для основных и дополнительных начислений.
А вообще, согласен. С учетом того, что специфическая функциональность регистров расчета в ЗУП3.1 практически не задействуется, всё делается вручную, и перерасчеты и вытеснения - смысла в них нет.

(182) А почему отказались, кстати?

(185) можно было бы в платформе допилить, но с++ которые их понимали уже давно не работают в 1с

(185) Регистры расчета очень медленно работают. С помощью регистров сведений и накопления данные можно собрать гораздо быстрее.

(173) поддерживаю. Написал письмо в поддержку. Ответа нет...