5000 сотрудников, 200 видов начислений,РАУЗ, сделка, повременка, весь гемор - какой только может быть при расчете ЗП и еще столько же, чего быть не может. В УПП - бухия и немного производства, планирования, бюджетирования (150 одновременных подключений) всего 400 пользователей. Нужен расчет ЗП. У кого летает?  УПП или ЗУП?

(59) и что?

(60) что, что
не видишь - гуру пришел

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

ааааааа

>>Надо выбрать оптимальный вариант УПП или ЗУП.
объясняю для 1сников:
не может быть оптимального варианта из этих двух программ - они совершенно разного уровня ориентации и "тяжелости".
Зарплатный "модуль" из УПП во многом (но не во всем) повторяет ЗУП, и обновляет 1С их одновременно.
Но ЗУП всегда будет перегонять по скорости УПП, т.к. не содержит тех гирь, которые содержит УПП.

я за ЗУП. Сами планируем выносить из УПП его... тяжёл больно, особенно узко в обменах стало РИБа, как расчет ЗП - так обмены километровые. Грёбаный регистр Графики работ по видам времени, причем с разбивкой по сотрудникам как правило

(65) на сколько сотрудников зп считаешь?

(66) 15 филиалов, там от конкретного зависит, я в центре, 600 чел. в филиалах 1000-2000. Всего - много, мпасает пока РИБ

(67) все, что накопал по крупным зарплатным проектам в 1С твоя схема - филиалы. Действительного крупняка предъявить пока никто не может. Меня терзают смутные сомнения, что король то голый.

Нет, был один. Стройка. 6000 человек. Все на окладе. Отпуска и все. Даже больничных нет.

(68) 4-5 тысяч на прошлой работе было, без филиалов, там завод. но не скажу что сильно крупняк, тыщ 15 - это да.
Знаю организацию где реально крупняк, там внедрение заканчивается вроде, на заводе Сухого.

(64) Да,да... Бла-бла-бла... Сферическая в вакууме... 2*2=4...

(70) Сухой?! Это уже интересно! Надо будет с ними пообщаться.

(71) ну что еще ждать от 1с-ника..
(69) вот скажи мне, мил человек, какая разница - расчет 1000 человек или 10000 в ЗУП? А в УПП?
Предположим, что "сервер" не на персоналке.

(70) Закончилось уже. Но его мало кто повторить может - там гемора немерено было. Даже привлекали разработчиков платформы из 1С. Там Oracle  в виде корпоративного стандарта и внедренцы сдуру под него подписались.

(71)>>Да,да... Бла-бла-бла...
.. еще и говорить не научился, а уже туда же - всех тянет в 1с... :)

(73) у меня проблемы с РИБом начинаются, а не с количеством

Oracle - это сила.
Которой надо уметь пользоваться.

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

з.ы. внедренцы там тока с ораклом и работают, скл - штучные проекты, основа оракл

(81) спасибо, пробью их по своим каналам.

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

(82) Вряд ли Вы из "пробъете". Они не любят делиться информацией.

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

(84) результат-то где?
а то уже графики составлены - ходить по таким клиентам через год-другой и переделывать все вчистую.
После знатоков таблиц умножения... :)

(85) боюсь Туда вас не подпустят на пушечный выстрел

(86) я не про себя.
Меня ЗУП интересует только с точки зрения удобства расчета ЗП.
А пускают только "своих"? Ну вот поэтому потом и переделывают. За "только своими" :)

(87) + я имел ввиду - переделывают на 1С.
Так как нормально внедрить Оракл не могут.

(84) (86) Я знаю их "специфику". Есть варианты. Попробую.

(85) Ага. Только сначала им двери нужно расширить. Ибо Вы с такими растопыренными пальцами войти не сможете.

(88) Для тех, у кого рация на бронепоезде - речь шла о SQL-сервере Oracle.

УПП и ЗУП... закрытие табеля - очень сильно тормозит 1с так же как и расчет з/п

(91) сильно это как?

(90) кто в бронепоезде - скажите, что у вас там внедряет "команда внедренцев"? Оракл? :)
И, видимо, прирост производительности и  успехов таков, что сначала "внедренцы сдуру под него подписались", а потом - "внедренцы там тока с ораклом и работают".

(93) Внедренцы там специализируются на Оракле, его палитновые партнёры. И поверьте, они вкурсе как работать с ним

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

(94) так какой смысл мутить на Оракл то, что даже с SQL работает как с помойкой? Прирост-то где? Результат?

(96) результат - успешное внедрение системы на 1с в связке с субд оракл, скуль бы не потянул

(95) В месяц примерно 10000 нарядов по 50 строчек. В чем гемор вылезет?

(0) Дай угадаю- РАйкон?

100!

(99) мимо

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

(101) Местный?

(97)>>скуль бы не потянул
позвольте не согласиться.
Что бы не потянул SQL? В дайте цифру "непотянутого".

(93) Для тех, у кого рация на бронепоезде - выше было написано, что на предприятии Oracle корпоративный стандарт. И заказчик продавил решение именно на этой платформе.

(97) Да потянул бы. Нет никакой разницы на таких объемах. Условия "внешние" были. Из-за особенностей работы 1С с Oracle возникли некоторые проблемы и пришлось разработчиков платформы выдергивать. В своем роде уникальный проект.

(98) Гемор в движениях документа. Прикол в том, что сдельный наряд сам делает движения по регистрам учета страховых взносов и отражение в бухучете, в то время как начисления и соответственно взаиморасчеты с сотрудниками двигает другой документ (Начисление зарплаты), который заполняется на основании сдельных нарядов, причем только для тех сотрудников, у которых основная сдельная оплата труда. То есть, имеем аккуратно уложенные грабли.

(104) + уже начинаю потихоньку подсмеиваться - это "нечто" тянет 1С и Оракл, но не тянет SQL :)

(107) Перестаньте флудить. Это тематическая ветка. Иначе пойдете в бан.

(1050 >>что на предприятии Oracle корпоративный стандарт
вот поэтому потом и идут к вам внедренцы 1С на "родном" MS SQL.
Каждому мишке - своя фишка.

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

(0) возьмите любую программу расчета зарплаты не под 1С (фокспро, клиппер и т.п.) - будет летать. Те поделки, которые делает 1С в нынешнем виде - летать не будет никогда.

(111) Зачёд

(65) А вот нефиг табеля Т-13 на сотрудников вводить.

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

(115) и у вас такая же деградация с фокспро? вот так оно и есть по всей стране.

(92) Запись табеля происходит с помощью менеджера записи либо кучи небольших наборов записей (зависит от данных и настроек документа), т.к. ГрафикиРаботыПоВидамВремени не подчинен регистратору, и одним набором записать его невозможно. Табель на 100 человек может записываться минуту-другую, при этом есть подтормаживания у всех.

(115) Сколько денег на это готовы выделить? Если не брать в штат
Вроде уже спрашивал :)

(115) > Сейчас в ДОСе, фокспро, и т.п. считается нормально
Не верю! (с) Станиславский.

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

Очень сомневаюсь, что это возможно. Вряд ли Вы сможете держать своих методистов и программеров. Заодно и постоянно отслеживать все изменения в законодательстве. Это было бы крайне дорогое решение.

(119) бог с тобой, им нужен расчет обычный, потом как обычно отчетность руками сводят наверняка

(119) 1 методист и один программист. Считает ВСЕ.

20 лет делали, что бы все считало.

(121) Ну Вы монстры! :)

+ к этому массив начисленной ЗП с налогами по 10 измерениям раскладывается. Сам удивляюсь.

(124) изменения законодательства то как?

например расчет среднего за 2 года который - это алгоритм менять прилично жеж

Конечно лучше ЗУП отдельно вынести. Все таки обновлять его проще, а думаю изменений в отчетности будет еще много в связи с реформами ПФР и прочее.
В целом нормально 5 кило человек расчитывалось, правда было дробление по подразделениям максимально 800 человек в одном подразделении.

(118) денег выделить на что?

(127) Ага. Главное - не делать "полный расчет" одним документом, если их в периоде несколько (по подразделениям). Замучаетесь потом с пересчетами НДФЛ для сотрудников, которые перевелись из одного подразделения в другое. На мой взгляд, правильная схема такая - на каждое подразделение по документу начисления зарплаты (только начисления), и далее сводно по предприятию удержания, погашения займов и НДФЛ. Это минимизирует проблемы.

Второй день ветка висит и только одна реальная ссылка на расчет ЗП в 1С для 5000 сотрудников! Как-то мало для 1С )))

или люди с такими проектами здесь не ходят?

(130) Интересует факт существования таких внедрений или какой-то результат для себя?
Они есть, но ни у кого не "летает", 100%
Я предлагаю написать нетленку на 1С + SQL, не очень дорого.

(132) скорее матрасик подложить хочется. Если так как ты говоришь - хрень, просто матрасиком не отделаешься)))

Скорее хочется матрасик подложить, хотя если верить тому, что ты говоришь, матрасиком тут не отделаешься.

(134) Не 1С-ные решения не рассматриваются в принципе?

что сделал не так?

(132) Скорее хочется матрасик подложить, хотя если верить тому, что ты говоришь, матрасиком тут не отделаешься.

(130) Одномоментно было расчет, 5340 человек в базе.
Только много всяких факторов, одно дело у всех оклад и пятидневка, плюс по мелочи больничные/отпуска все белым бело. Другое дело, если множество заморочек и т.д. но пути решения всех затыков разные вплоть до административных и т.д.
С точки зрения производительности, особых затыков небыло все таки ЗУП по сравнению с ЗиКом это земля и небо.

Нюансов много. Нужен грамонтый расчетчик(руководитель) который очень хорошо шарит в ЗУПе + равноценно грамотный кадровик(руководитель). И главное что бы была нормально выработанная система работы. Кадры/Расчет. Ну и спец который всегда сможет ответить на любой вопрос расчетчика/кадровика. И желательно что бы спец. минимально ковырял типовой код, то есть предлагал всевозможные решения типовыми механизмами.

(137) Юр. лицо у Вас одно ? или мега пупер холдинг ? с десятками юр.лиц ?

одно

))

(135) пока нет, думаю, что будет еще хуже.

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

тема закрыта?

(144) ну тебе сказали ещё и реальное внедрение на 15000 расчет, но как там что узнать хз, а денег нанять тех внедренцев врятли хватит

(144) у тебя какие вопросы остались?

(145) К сожалению тут не все видно. Понятно только, что с эской надо быть осторожнее ))

(119) ты не поверишь! )) до сих пор пользуемся программой расчеты зарплаты под клиппером с 98 года - все формируется, и даже больше чем в 1С.

(145) Они относительно недорого обходятся. Если у кого есть интерес - пусть пишет. Сведу.

УПП (1.3, РАУЗ) - 4,5 тысячи человек. 8 расчетчиков - не тормозит. Железо новое.

При работе 5000 в ЗУП могут возникнуть проблемы не в производительности в необходимости постоянного обмена с БП или УПП из за появления новой аналитики.
Пример:
У меня клиенты вели учет в ЗУП. 2000 сотров. Занимаются производством. Постоянно ремонты или создания новых ОС. Приходилось постоянно делать обмен для новых объектов аналитики. Опять же авансовые отчеты, спецодежда требует появления физ лиц в БП или УПП. Опять нужно постоянно выгружать. Поэтому для себя решил что лучше при большом числе сотрудников начислять з.п. той же базе УПП или КА если производительность позволяет.
При 2000 сотрудников никаких проблем с производительностью нет.

(129) Так для 5000 рыл наверняка не один расчетчик работает.

(119) Вышеуказанные клиенты были приучены работать в нетленке написанной еще под DOS. Там они почти все считали вручную. Ничего не жужали. При переходе на 1С не верили, что автоматические расчеты налогов вообще возможны.

(151) +1

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

(153) - не АМБА случайно?

(155) Нет. Это наша местная разработка. Не видел даже названия у нее.

(150)(151) Спасибо!

(0) 24000 сотрудников. ЗУП. Слегка подкорректированный. Видов расчётов поменьше было. Всё летало.

(158) и куда улетело? :)