Всем привет!

Конечно, я могу почитать статьи в интернете, которые кишат сравнениями зуп 2.5 с зуп 3.1, но там все слишком общее... Поделитесь, какие мелочи и нюансы вам безумно нравятся в зуп 3.1 и которых не было в зуп 2.5?

Зуп 3 ещё поддерживается.

Есть вещи, которых не хватает в зуп 3 из 2.5

новизны, в 2.5 не хватало новизны и перемен

вопрос из разряда "почему вам нравится есть мясо" или "поделитесь своей безумной любовью к блюдам из моркови"

А какой смысл сравнивать?

(0) "Сравнение ЗУП 2.5 и 3.1"

Я думаю, что корректным будет такое сравнение:

Зарплата 2.х для дос < Зарплата 4.03 для Дос < ЗиК77 < ЗУП 2.5 < ЗУП 3.1

Регламентированная отчетность в ЗУП 3.1 лучше сделана
6-НДФЛ
СЗВ-СТАЖ

Мне нравится что ЗУП 3.1 дольше запускается

-------------------
|                 |
|    САРКАЗМ      |
|_________________|

Все эти годы развития компьютерных и программных мощностей - для чего они? Чтобы я ждал запуска базы 5 секунд до ввода пароля, а потом ещё 7-8 секунд до её открытия???!!!1111

(3) Ха-ха! Шутка дня!

(8) ЗУП + апач = 2 секунды

(8) "Все эти годы развития компьютерных и программных мощностей - для чего они?" - чтобы смотреть пор-но в качестве 4К.

(0) Вчера пришлось глянуть расчет мат выгоды, на 3.1 с досрочным погашением и изменением ставки рефинансирования в середине месяца. 3.1. Посчитала не правильно.
ЗиК 77 рассчитал верно и прозрачно и с комментарием расчета. :-) Что дало 3.1? Не знаю. По моему модный фантик.

(11) что ты там в качестве 4К разглядывать собрался? прыщи?

(12) зато права на отпуск при работе в отпуске по беременности и родам ЗУП 2.5 не считает, а 3.1 считает. Кстати, вроде и с матвыгодой проблем не было

(14) У нас и ЗиК был научен считать право на отпуск в такой ситуации. Допилить можно всё что угодно.
Мне не нравится реализация расчетов в РР в 8.х, по сравнению с журналом расчетов в 77. Расчет в документах.... Как-то это не естественно. Да с самим РР работать на порядок удобнее чем с ЖР, но реализация в ЗиУП какая-то не та.

(12) ЗИК изначально проектировалась, как программа для расчета ЗП.

ЗУП (а точнее платформа 8.х) - как универсальная платформа, которая должна работать как на винде, так и на планшете и т.д и т.п.
Любая универсальная система неоптимальна.

зуп 2.5 вроде только корп и соответственно цена итс

(16) ЗиК  - это вообще самамя страшная конфы из все конф 1С

(18) Страшнее всего неведомое.

(11) не просто порно,а VR-Porno

(18) Прикинь, но в ЗиК есть комментарий расчета, а на 8.х можно сказать его нет. В чем улучшение?

(21) Вы просто не знаете, где он.

(22) "можно сказать его нет" - означает что, то что есть это как бы не совсем, то что необходимо. :-)

Вид начисления проезд к месту работы на автобусе
В ЗУП 2.5 у меня был размер стоимости проезда был вбит прямо в форумулу вида расчета готовой цифрой.
В ЗУП 3.1 тариф на проезд заводят документом "Данные для расчета зарплаты". По этим документам можно посмотреть, например, как менялся тариф со временем.

(24) и кто ж тебе мешал в 2.5 через показатели сделать?

(7) Ну так в 2.5 не стали реализовывать уже, что бы заведомо было со временем стало хуже чем в 3.1

(20) Ну вот, подтянулись те, кто "в теме". ;)

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

не зряж камин во времена зика неплохо шел

(8) Это вы забыли расчет зарплаты в ЗиК 7.7. На тогдашнем железе работал не меньше получаса, если порядка 1000 сотров.

Разработчики 3.1 ещё боле далеки от жизни чем 2.5. Хотя это наверное один и те же люди.
Придумали паралельно несколько конфигураций сопровождать 3.1.9, 3.1.12 и т.д.

В ЗУП 3.1 появилось понятие "Совокупная тарифная ставка". В ЗУП 3.1 я включаю оплату за вредность в совокупную тарифную ставку. Для того, чтобы достигнуть аналогичного эффекта в ЗУП 2.5, я вносил изменения в конфигурацию.

(25) А что, была такая возможность? Если была, то я не знал.

(28) э... как это не видел? Расчетчик обычно всегда сам все считал.
Другое дело, что квалификация должна быть немножко получше.
А то попадаются сейчас иногда "расчетчики", которые впадают в ступор от необходимости поработать в экселе, т.е. пользователь-расчетчик все-таки должен быть не хуже, чем манагер из продажников.

(28) В одной из организаций, где я работал, целая преступная группа была(да и сейчас есть, наверное) в лице главбуха, расчетчиков и программистки, которые в ЗиКе делали выплаты левым сотрудникам. В 3.1 я вижу, это уже не так просто.

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

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

(35) ну программист то был же в группе

(23) Я думаю, это вопрос привычки и не более того.

(36) Он в принципе ДОЛЖЕН знать, как в экселе перемножать суммы в колонках, как листы добавлять, формулы. А если он вообще не умеет им пользоваться, на уровне того, что школьники умеют, а этот "расчетчик" не умеет - я вот про что

(40) Это если руководство понимает, что сотрудников можно и нужно обучать. У меня был случай, когда вроде бы умнейшие тетки, которые отлично знают законодательство, ничего не знали про эксел, писали суммы на бумажке и складывали на калькуляторе. Просто показал, что можно иначе, у людей груз с души свалился.

(41) и в штатке минус 2, добро не бывает беззубым)

Расшифрую (2). Верните ввод произвольных отклонений за период!

(43) В ЗУП 2.5 был документ "Регистрация разовых удержаний"
В ЗУП 3.1 его нет :-(

(44) Удержания по прочим операциям? Не?

Более оперативное изменение законодательства и исправление ошибок. Все остальное вторично. Фишки все пилят под себя сами.

(42) Зачот, но две ушли на пенсию, двух приняли, все так же пока.

(45) В ЗУП 3.1 документ "УдержаниеВСчетРасчетовПоПрочимОперациям" назначает плановое удержание, которое затем рассчитывается другим документом.
В ЗУП 2.5 документ "РегистрацияРазовыхУдержанийРаботниковОрганизаций" позволяет сделать непосредственно удержание готовой суммой.

(48) Только не надо доказывать, что в 2.5 вот эта возможность была прям вот хорошо-хорошо
Непосредственно взять и удержать может не слабо так аукнуться

(48) А в ЗУП 2.5 есть очередность взыскания? Нет. Так что логика, что назначается в одном месте, а рассчитывается в другом есть

В ЗУП 3.1 при выборе способа заполнения (графика, режима работы) "По циклам произвольной длины" можно добавить только 99 дней, В ЗУП 2.5 можно было сделать на год.

(8) 15 лет назад открываешь новостную статью, браузер сжирает 5 мегабайт оперативы. Сейчас открываешь новостную статью, и браузер сжирает 200 мегабайт оперативы. Вот такой он, прогресс...

В ЗУП 2.5 в табель можно было добавить только 5 видов времени, в ЗУП 3.1 неограничено

(51) В чем смысл такого планирования на год?

(48) Когда я в ЗУп 3.1 мало что понимал, запилил свой такой документ, теперь жалею. Не надо было этого делать, вон в крайнем случае свод показатель, вид удержания и данные для расчета ЗП.

А так при обновлении постоянно следить за типами приходится.

В ЗУП 3.1 появился документ "Совмещение должностей"

Ура! Зрелизилась    3.1.13.75    20.02.20

(57) Вчера она считалась тестовой)

(58) тестовую плохо тестят )))

(57) Фрэнки, что в ней есть такого, чего нет в 3.1.10?
сблатуй меня на переход

(60) Я, правда, не Френки, но отвечу.

Вот же список "преимуществ":
https://dl04.1c.ru/content/HRMCorp/3_1_13_75/news.htm

P.S. Мы тоже сидим на 3.1.10

(61) спасибо, вкусно

> Поделитесь, какие мелочи и нюансы вам безумно нравятся в зуп 3.1 и которых не было в зуп 2.5?

Кактус, ноутбук и штатка на логотипе третьего зупа, очень нравиться и отражает все суть, особенно кактус!
Я просто снимаю шляпу и хлопаю в ладоши!!!

(63) "Вы просто не умеете его готовить"

(63) А у вас есть завершенные внедрения ЗУП 3.1?

(62) ну как-то не особо востребовано. Можно еще на 3.1.10 задержаться

(66) расчет показателя "ОтработаноДней", "ОтработаноЧасов" в начислениях типа "Оплата праздничных" все-таки починили, сегодня с утра уже проверил. Проблема с вычислением часовой ставки для оплаты праздничных исходя их оклада и всех надбавок наконец решена.

А на 3.1.10 этот показатель правильно считается ?

(67) до этого считала по виду времени?

(68) А до этого значение было равно значению показателя ВремяВДнях, ВремяВЧасах, т.е. по виду времени.

https://bugboard.v8.1c.ru/error/000057309

В 3.1 есть территориальное деление. А ещё там очень и очень круто реализован сложный учёт, в котором в итоге могут разобраться только гуру, познавшие боль мирскую.
Мне в ЗУПе 3.1 очень нравится процедура переколбашивания НДФЛ, которая на 2000+ строк. А ещё я обожаю в тройке ораву регистров без регистраторов, которые двигают документы не глядя и иногда только один раз.
В общем штука крутая, для любителей острых ощущений

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

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

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

(73) Какие конкретно случаи? Я пока только про территории могу согласиться.. Все остальное решается либо неявками, либо вводом соответствующих документов о работе в праздники, в выходные, на хуой конец - ввод данных об особых часах документом "Данные для расчета зарплаты".

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

(67) Наверное, нет. И вероятности нет, что в 3.1.10 когда-то правильно посчитается.

Тут уже будет другой момент, не в конкретной ошибке или некорректности отдельного расчета показателя, а в том, насколько будет выдерживаться задекларированная версионность вида : ветка 3.1.10 - стабильная, ветка не равная 3.1.10 - разработка на перспективу.

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

(71) Относительно применимости Табелей тоже нужна какая-то методическая определенность. Если табель точно остается всего лишь продвинутой _отчетной_ формой - это один подход.
Если же он технически применим в расчетах и допустимо его использование с _вводом_ данных для расчетов - это другой подход.

Они не должны существовать одновременно. Я бы предположил, что должна быть функциональная опция, которая жестко укажет и на уровне исполняемого кода и на уровне применимости пользователями, что работает - табель или график?

(77) // Про вредные условия - решается рабочими местами.
Ну тогда каждая позиция в штатном расписании должна быть сопоставлена или с указанными вредными условиями от рабочего места, или просто должна соответствовать не только условиям вредности, но и в целом условиям оплаты для рабочих мест.

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

(77) при больших объемам это нереально, табель очень выручает в таких случаях

(81) Не согласен, это просто плохая организация работы. Хочется быстрей-быстрей.

После перевода пары-тройки баз на 500 человек с ЗУП 2.5 на 3.1 и курения партнерского форума, видишь, что некоторые принципиальные вопросы не решаются годами в угоду каким то редко у кого используемым фишкам...
одно "Включить расчет зарплаты без оптимизации" чего стоит... Конечно кое что стало удобнее... Но товарищи которые делают походу никогда не переносили из старой базы... Потом включить изменения штатного невозможно... все слетает напрочь. Территории (если есть обособленные подразделения с другим ОКТМО) в начальной штатной расстановке указать невозможно... и расчет по ним так же косячил. Если в момент переноса были переходящие отпуска - средний считается неверно... Если есть займы то изменений ставки рефинансирования в середине месяца приводит к неверному погашению и т.д. Разница на копейки по сравнению с ЗУП 2.5 из за разного округления в алгоритмах... Если не использовать Расчет за первую половину месяца, что на крупных предприятиях просто невозможно, то для корректного уменьшения аванса в случае больничных, отпусков в первой половине приходится писать свои обработки... откройте партнерку и найдите темы где ++10 и сделайте их... а не "Поддержка исчисления взносов с доходов студентов, работающих в студотряде." много у нас в стране студотрядов???

(31) Это же их попоболь ))Мне фиолетово - одним клиентам 3.1.12, другим 3.1.10.

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

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

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

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

Сам-то понял, что написал? В телегу не сяду и пешком не пойду, так это называется.

(86) Не совсем понял, вы имеете ввиду именно должности? Мы к позициям штатного привязываем у себя, устраивает. В наименовании позиции приходится загонять описание вредности, если оно есть. Это не вполне удобно в некоторых отчетах, но зато бардака нет.

(57) "2. Обычные версии 3.1.11, 3.1.12 и т.д. Они сменяют друг друга в течение года (выпуск новой версии означает прекращение поддержки предыдущей)..."

https://releases.1c.ru/project/HRM30

Т.е. 3.1.12 всё?

(90) ну там до ноября шли и 3.1.11 и 3.1.12
Затем внезапно по 3.1.11 перестали выдавать обновления. Но пошли тестовые 3.1.13
Предположу, что 3.1.12 перестанут выдавать после начала выдачи тестовой 3.1.14

Проблема только в количестве одновременно сопровождаемых веток

https://releases.1c.ru/total?hideUnavailablePrograms=true вот здесь черным по белому - выходить будут 3.1.10 и 3.1.13, что там не понятно?

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

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

И зачем после этого писАть какие то там обработки - ЯННП

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

(94) Это правильное организационное решение, но по факту аудиторы рисуют риски при таком подходе. Привязывают (за уши) формулировку "заработная плата" к фактическому расчету, при этом забывая про НДФЛ и льготы, которые можно узнать только в конце месяца, так как у них свой срок расчета и свой порядок. + есть огромное желание не переплачивать аванс, в случае если вдруг окажется что сотрудник не был на рабочем месте (болел, невыход и т.д.) и решил уволиться.

Поэтому самое нормальное организационное решение должны сделать наши депутаты и правительство - ввести понятие аванса и порядок его расчета. Это должен быть простой алгоритм, который рассчитывается так же как и любой другой. Обычное обязательное плановое начисление/удержание, как оклад, алименты, НДФЛ и т.д.
Но этого не произойдет, мы же заняты геополитикой, дележкой власти, Украиной, короновирусом и всем подряд... Созиданием никто не занимается.

(95) К ответу на (89).
Пример: Сотрудник1 и Сотрудник2 работает в должности = "Должность 1", каждый на своем рабочем месте. В дату Х одно из рабочих мест проходит аттестацию, а второе нет (не проходило или не прошло).
Как результат пусть Сотрудник 1 работает на рабочем месте, которое прошло аттестацию, а Сотрудник 2 на рабочем месте, которое не прошло аттестацию. И по факту работая в одной должности, согласно ШР, один из сотрудников может иметь отношение к вредным условиям, а второй нет, по факту выполняемых обязанностей.

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

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

(96) в КОРП это пофиксино

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

(96) Не понял проблемы. Ведите штатное расписание и проводите СОУТ для него, а не к позиции привязывайтесь.

т.е. не к должности

(100) пробовал? Точно пробовал?

(99) Поддерживаю, мы так и делаем у себя.

(101) Я пробовал, все в порядке. Если есть подводные камни, делись, пожалуйста. Возможно, я что-то не заметил.

(103) Те же яй.а но вид сбоку. Что к должности привязывать, что к позиции ШР.
Оргштатная структура с аттестацией рабочих мест не связана от слова совсем. Это отдельный учет.
При приеме/перемещении сотрудника мы должны отдельно указывать: Подразделение, должность, ШЕ, оклад/тариф, рабочее место и т.д.
т.е. изменение рабочего места должно быть независимо оргштатной структуры совсем.

(99) могут быть разные даты СОУТ для одной должности. Не зря в КОРП учет по рабочим местам, но все через одно место реализовано

(104) Ну да, есть в этом что-то. Я просто смотрел на эту тему немного под другим углом - с точки зрения контроля расчета. Началось с табеля вообще и его нужности или ненужности в ЗУП.

(106) "табеля вообще и его нужности или ненужности" - не понял вопроса. Без табеля в общем случае никуда. Иначе придется миллион графиков заводить и путаться в них, забывать заполнять и т.д. Графиков должно быть минимальное количество. Все остальное табелем. Как это реализовано (удобно или не удобно) и работает/не работает, другой вопрос.

(107) перечитай..

(108) В каком псоту из более чем 100? :-)

те кого я обучал зуп 2.5 уже приближаются к пенсии
те кто сейчас осваивает зуп 3.1 еще ходят на танцы

я не люблю пенсии и люблю смотреть танцы и по барабану сколько времени на запуск.

(109) где-то в первой сотне, инфа 100%

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

(111) Перечитал по табелю что нашел.
Всё равно не понял вопроса. Совсем без табеля не обойтись.
Графики используют для объединения режима работы большого количества сотрудников в одну сущность.
Например: ИТР по пятидневке, три или четыре сменных графика для Ивановских ткачих, несколько графиков для охраны, и т.д.
Но всё равно бывают сотрудники, у которых нет четкого графика - подменный состав, ремонтный (авария - работают 24 в сутки, исправили и на три дня отдыхать) и т.д. Для таких сотрудников плановым графиком обычно делают какой-то, но он обязательно есть и прописан, а по факту работы вводят фактическое присутствие - или фактический табель. Баланс рабочего времени обычно у них максимальный - это год. Соответственно переработки за сверхурочную работу они получат, только при увольнении или в конце года.

Сотрудники, в зависимости от рода деятельности могут в течении месяца менять плановый график (кадровое перемещение). В итоге плановый табель состоит из планового времени, по каждому дню по периодам действия графика.
С точки зрения МЕСЯЧНОГО оклада, не существует такого понятия как отдельный план по каждому календарю. В регистрах расчетах, с какого-то перепуга есть.
т.е. Если у сотрудника МЕСЯЧНЫЙ оклад 30 000 рублей, то как бы его график не менялся в течении месяца, если он все положенные дни отработает, то он должен ПО ОКЛАДУ получить 30 000 рублей. Далее + переработки за работу в сверхурочное время, в зависимости от баланса рабочего времени (от недели до года). Но это отдельное начисление, которое компенсирует возможные переработки, в том числе из-за смены графика. Если в результате смены графика так получилось, что сотрудник в течении месяца почти не работал, по сравнению с любым из графиков, если бы тот не менялся, то это проблема работодателя, что не обеспечил работой своего сотрудника. Поэтому сотрудник всё равно должен получить свои 30 000 рублей.

Общий вывод:
Оклад МЕСЯЧНЫЙ, значит у каждого сотрудника, который работал по месячному окладу, есть план времени за МЕСЯЦ. И этот план имеет единственное значение для каждого сотрудника.
То что в регистре расчетов есть план график по каждой строке оклада в разрезе действующего графика в периоде - "бред сивой кобылы".

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

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

(111) То нашел или нет?

Alexandr_U1982
"Вы просто не умеете его готовить"
А у вас есть завершенные внедрения ЗУП 3.1?

Я не занимался переводом на третий зуп, за исключением тестовых переносов, которые клиент заказывал.
То что я его никуда не внедрял, не означает что я его не знаю, я постоянно читал партнерский форум, и был в курсе дел.
Он меня разочаровал очень сильно своей структурой и лезть туда и сопровождать его - это выше моих сил!
Я за "всю Одессу" не готов сказать, но у меня от этого произведения искусства "ЗУП 3" - головная боль!
Нет, там есть конечно, хорошие идеи, но все это в такой реализации - так что я - пас!
Я бы даже сейчас его не стал никуда внедрять, глядя на этот зоопарк третих зупов.
А у вас позиция конечно удобная - хвалить то что продвигает 1с - в проигрыше никогда не будете, да еще и денег можно с клиентов поиметь за исправление их ошибок.

С ЗУП 2.5 иногда просят помочь.
Да, за 2.5 обидно, доверили каким-то юным дилетантам, даже запросы по сотрудникам в СЗВ-ТД не могли правильно написать, зарплатчики блин!

+117, забыл написать, теперь я зуп не занимаюсь, работаю в компании, известную на всю страну, разрабатываю специфические конфигурации.

(117) А 3.1 тем же наверное доверили. :-) Что не релиз, то куча полей и объектов с префиксом "УДАЛИТЬ".
Это как надо проектировать, чтобы столько потом перепроектировать.
Не было такого никогда. Точнее в таких объемах не было. Да и если и было, то по мелочам. А тут только этим и занимаются.

Тоже самое и с платформой и т.д.
Потом некоторые тут на форуме искренне удивляются, а чего это МАГНИТ с 1С уходит.
А зачем Магниту этот зоопарк конфигураций? Проще с SAP отчетные формы ждать по пол года.
Да, справедливости ради скажем, что на SАP уходят по велению финансистов и им глубоко фиолетово, что там с отчетностью у бухгалтеров, что в оперативном учете и т.д. Кто платит, тот платит, тот и заказывает музыку. Но вопросы по производительности и сопровождению, отличный аргумент для финансистов сделать переход прямо сегодня, а не когда-то потом.

Самый простой пример с префиксом УДАЛИТЬ:
Справочник "ВидыДоходовНДФЛ" и паралельно такой же справочник "УдалитьВидыДоходовНДФЛ".
Разница в том, что в новом справочнике есть дополнительно реквизит "ВычетПоУмолчанию", типа "СправочникСсылка.ВидыВычетовНДФЛ".
Предопределенные элементы практически такие же.
Что мешало добавить реквизит в существующий справочник?

Аналогично справочник "ВидыВычетовНДФЛ" - добавили несколько реквизитов.

Полно такого.

В чем сакральный смысл подобных действий?

"В чем сакральный смысл подобных действий?" - может кто знает?

И сразу любители современных конфигураций куда-то пропали.

(122) Да фиг знает, просто все работает нормально. Зашел вот почитать отзывы тех, у кого не работает, почитал.

(123) Не нормально подобные действия. Если долго не обновлять конфигурацию и потом обновить, то возможна потеря данных.

(124) если обновлять в соответствии с рекомендациями 1С, то ничего не потеряется

(124) Это точно мне? Если да, переведи, я ничего не понял.

(125) Если разрабатывать, в соответствии с рекомендациями 1С, то такого как в (120) быть не должно. Но разработчикам на свои же рекомендации наплевать. :-)

(127) они тебе сами сказали?

Было бы иниесно почитать мнение человека, который там работал, но вряд ли это возможно.

(128) Обсуждалось уже. Держи.
Бывший сотрудник 1С, разработчик конфигурации, рассказывает о своём опыте

> они тебе сами сказали?

А вы сами подумать пробовали?
1. Если ничего не удалять из конфигурации а только добавлять, то наверное ничего не пропадет, логично ведь, да?
2. Теперь почитаем их стандарты, в которых написано, что удалять объекты можно при смене версии (не релиза, а версии).
3. А теперь вопрос, почему все таки появляются рекомендации "обновлять последовательно"? У меня другого ответа, как - "накуролесили в конфигурации, и поэтому сами уже не помнят, чего они там наделали пару релизов назад и удалили" - нет!

(130) Пометил как неадеквата, запомнил.

(129) Спасибо.

> Да фиг знает, просто все работает нормально. Зашел вот почитать отзывы тех, у кого не работает, почитал.

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

Я считаю, что компания 1с просто безобразно относится к пользователям (тем кто платит за итсы). Пропихивать свою "зеленую" конфигурацию, и отрабатывать алгоритмы на них - как то не солидно, для такой большой компании. И самое не приятное - насильственно ссаживать с 2.5.
А прикормленные франчи всегда будут хвалить то что она делает - это же выгодно и приносит деньги, и тем и тем.

> Пометил как неадеквата, запомнил.

Всегда пожалуйста!

(131) В чем неадекватность? Написана правда.

Конечный клиент хочет сэкономить и обновить программу не последовательно, а сразу на последний/необходимый релиз. Технически это возможно. 1С делает всё, что бы это проходило максимально не удобно. Понятно, что обновлять всё равно придется минимум в два этапа. Сначала без удаления объектов, потом обработка обновления ИБ, а в конце ещё раз обновление с удалением лишних объектов. И то не всегда пройдёт.

(121) "В чем сакральный смысл подобных действий?" - нет никакого смысла. Вопрос риторический.
Конфигурация ЗиУП 3.1 реализуется по принципу "стреляй потом целься". Такой принцип имеет место быть для проектирования систем на самых начальных стадиях, когда не подразумевается промышленная эксплуатация. А тут пол страны работает. :-)

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

ОбщийМодуль.УчетНДФЛРасширенный.Модуль(322, 29)
...
    // Запрашиваем ставку рефинансирования
    СтавкаРефинансирования = 0;
    Выборка = РегистрыСведений.СтавкаРефинансированияЦБ.Выбрать(, ДатаПолученияДохода, , "Убыв");
    Если Выборка.Следующий() Тогда
        СтавкаРефинансирования = Выборка.Размер;
    КонецЕсли;

(136) Для обсуждения политики вендора, насколько я помню, есть партнерский семинар, который проводится раз в полгода или раз в квартал

(136) Продолжение по мат выгоде.
Т.е. учитываются периоды погашения займа, но не учитывается периоды изменения ставки рефинансирования.

(137) Я не обсуждаю. Констатирую факт - не более того.

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

(137) а где здесь на форуме написано, что нельзя критиковать фирму 1С и чтобы кто хочет это делать, то шли с этим на партнёрский семинар???

(140) https://1cers.ru/rules.php
"1. Запрещена огульная критика платформы 1С:Предприятие и неуважительное отношение к программистам 1С."

(141) Ключевой слово "ОГУЛЬНАЯ". Т.е. без фактов.
Тут я не вижу критики вовсе. Только констатация фактов - не более того.

"Не нравится - отойди и не стой в этом во всём". (М. Жванецкий) :)

(136) " В чем неадекватность? "

Цитата: "А вы сами подумать пробовали? "

Если ты не понял, речь не про конфы.

(136) Полно проблем в ЗУП, это правда. Но мне непонятно, как клмментарии этого товарища как-то могут улучшить ситуацию.

А с материальной выгодой совсем беда :-)

Зарплата и управление персоналом, редакция 3.1 (3.1.13.75)

Пока не определил причину, но происходит как-то так.
Сотруднику вводим досрочные погашения займа два штуки в месяце в середине в разные даты. Пусть 10 и 20 числа. Документы двигают РН "Начисления удержания по сотрудникам", в том числе в части материальной выгоды. Вводим документ начисление ЗП. Он тоже двигает этот РН, в том числе в части материальной выгоды. Наблюдаем три записи по материальной выгоде.

Если после этого просто перепровести документы погашения займа, то движения по РН "Начисления удержания по сотрудникам" в части материальной выгоды и не только удаляются. Остается запись только по документу начисления ЗП.
Перепроводим документ начисления ЗП - записи не появляются. Перезаполняем документ начисления ЗП и проводим - записи не появляются.

Т.е. скорее всего, документы досрочного погашения займа смотрят на наличие документа начисления ЗП и если он есть, то не двигают этот регистр. Но сам документ начисления ЗП движения не делает в части материальной выгоды только за период с последнего погашения до конца месяца (-1 день).

На последнем релизе 3.1.13.76 надо попробовать.

На последнем релизе 3.1.13.76 тоже самое.

Вывод.
ЗиУП 3.1 не умеет считать материальную выгоду от слова совсем.

Проверил в Зарплата и Управление Персоналом, редакция 2.5 (2.5.110.1) релиз от 30.09.2016.
Учлось изменение ставки рефинансирования и досрочные погашения. По сравнению с ручным расчетом ошибка в 5 копеек (больше похоже на округление).

ЗиК 77 - наверняка тоже посчитает, так как я не помню что бы с материальной выгодой вопросы были. + ещё и комментарий расчета покажет. Единственное в 77 методология расчета была с последнего числа прошлого месяца по предпоследнее число текущего с поправкой на первый и последний месяц расчета.

Вообще странно. Розница лежит и ред 2.0 за 2013 год и 2.1 за 2015 год, а ЗиУП 2.5 только КОРП оставили.

Вот такой какой-то прогресс. :-)

(149) // ЗиК 77 - наверняка тоже посчитает, так как я не помню что бы с материальной выгодой вопросы были

Я помню, что вопросы были и оно там считало худо-бедно - как минимум, расчетчиков устраивало и править кодом ничего не пришлось.

(151) Вопрос как раз был к методологии с последнего числа прошлого месяца по предпоследний текущего.
Если считать с первого по последний, то всегда будет по две строки, так как погашение в последний день месяца это уже другая сумма остатка в этот последний день. Т.е. пришлось бы каждый раз по две строки в журнал расчетов помещать. Получается, что за последний день месяца матвыгоду и НДФЛ мы начислим в следующем месяце - за исключением месяца полного погашения займа.

Ещё в ЗиК и ЗиУП 2.5 можно было в документе выбрать, что за материальная выгода - 13% или 35% НДФЛ. Расчет был чуть сложнее.

В конфигурации не автоматизированы базовые вещи вроде выплаты зарплаты.

Если в организации несколько зарплатных проектов и статей финансирования, типовой сценарий выплаты - бухгалтер сидит и играет в угадайку какие комбинации статей/зарплатных проектов нужно заполнить.

А что же меня никто не поправил?
Ладно я ЗиК и ЗиУП давно не занимаюсь....
В 2016 году поменяли НК РФ

НК РФ Статья 212. Особенности определения налоговой базы при получении доходов в виде материальной выгоды
...
2. При получении налогоплательщиком дохода в виде материальной выгоды, указанной в подпункте 1 пункта 1 настоящей статьи, налоговая база определяется как:
1) превышение суммы процентов за пользование заемными (кредитными) средствами, выраженными в рублях, исчисленной исходя из двух третьих действующей ставки рефинансирования, установленной Центральным банком Российской Федерации на дату фактического получения налогоплательщиком дохода, над суммой процентов, исчисленной исходя из условий договора;

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

Но удаление движений при перепроведении погашения займа при наличии начисления ЗП, это конечно лишнее...

(120) Конфигурации строятся по библиотечному принципу.
Объекты с префиксом "Удалить" - это объекты из старой библиотеки. Без префикса - из новой.

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

(154) "А что же меня никто не поправил?"

Теперь ты точно запомнишь )) Потому что сам разобрался.

Да просто не всегда читаешь ветки, где участвуешь. А этот момент я учитывал еще в своей самописке на 1с77.

(153) "Если в организации несколько зарплатных проектов и статей финансирования, типовой сценарий выплаты - бухгалтер сидит и играет в угадайку какие комбинации статей/зарплатных проектов нужно заполнить."

Это уже не проблема, я написал вышел.
Реальная проблема - это чехарда со статьями финансирования в НДФЛ. Приведу несколько простых примеров из моего опыта , у меня два бюджетника на сопровождении.

1. Считаем больничный в январе, в нем пересчитывается зарплата за декабрь прошлого года в меньшую сторону, образуется отрицательный НДФЛ по статье "Бюджет", статья расходов 211.
   Но при этом в корректировке выплаты этот отрицательный НДФЛ вдруг раскладывается на все статьи, которые были в НДФЛ по документу в целом, и я вижу корректировку выплаты по бюджету 266 статьи (т.е. по статье, которой был начислен больничный за счет работодателя ЭТОГО ГОДА !!!) А этот НДФЛ был положительный.

При ходится корректировку выплаты править вручную.
А потом, в следующем документе, где эта корректировка зачитывается - снова чехарда по статьям затрат. Зачитывается из того, что есть в текущем документе, а не по статьям, по которым НДФЛ был принят к зачету.


2. Буквально вчера было - отсторнировали разовое начисление из внебюджета, статья расходов 211, НДФЛ минусовой, корректировка выплаты из этой же статьи, вроде бы красиво, со всем согласен. Далее сотрудник пишет заявление на возврат НДФЛ, оформляем документ возврата и тадам!!! Возврат идет из бюджета 211. Снова правим вручную.

Убедить техподдержку в том, что это проблема, пока не удалось. Там такое мнение, что НДФЛ считается в целом по физлицу (кто бы спорил, с этим я согласен). Но из-за чехарды со статьями финансирования получается так, что по одной статье сотрудник должен (из-за излишней выплаты), а по другой наоборот, ему должны, а оснований для этого фактически нет.

(157) не... не запомню ЗиУП не занимаюсь.
Когда-то такие вещи знал и постоянные изменения законодательства контролировал, а сейчас нет. Остаточные знания - не более того.
Но ЗиУП 3.1 стал хуже - к бабушке не ходи.