Переход с ЗиК на ЗУП не сначала года

Вот инструкция по переносу
http://www.avt-1c.ru/1C_Enterprise/Artics/Arctic2/zikzup.php

это не инструкция а так..
1 Проблемы растут пропорционально количеству человек в базе и ее "нетиповости"..Проблемы обычно сугубо индивидуальные по лицам (кому и как что начисляли) все можно решить документами переноса. Из глобальных сталкивался с проблемами если есть подразделения выведенные на отдельный баланс
2 Если большая организация то могут возникнуть сложности со здачей годовой отчетности (не сможите осилить все проблемы допустим с НДФЛ к этому отчету)

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

НДФЛ нужно будет проверять усиленно не всегда хорошо переносяться вычеты по сотудникам (чтобы дальнейшее начисление шло хорошо)

задолженость нужно проверять, все остальное хорошо встает

не факт что лучше переносить по частям

аналогичные 7-ым отчеты имеются

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

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

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

переносили следующим образом:
1. ндфл и есн за первые полгода перенесли типовым документом "Корректировка учета по НДФЛ, страховым взносам и ЕСН" (имя в конфигурации НДФЛиЕСНДоходыИНалоги)
2. для корректного расчета среднего заработка перенесли доходы документом "регистрация разовых начислений", для этого ввели новый вид расчет, который входит в базу среднего, но вид дохода - натуральный, чтобы не повлиял на задолженность
3. остаток на начало второго полугодия также внесли регистрацией разовых начислений другим введеным видом расчета, который не входит в базу среднего :)
4. ну справочники физлиц, должностей и прочие перенесли обработками
5. принимали на работу в полуавтоматическом режиме силами кадровиков, всякие данные по окладам и прочим начислениям перенесли, принимали на работу не с начала полугодия, а с даты фактической работы в компании. Полуавтоматически - потому что справочники подразделений поменялись, кадровики выбирали подразделение для сотрудника.

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

как-то так. переход осуществили за месяц. 3 недели на написание обработок, параллельно нам ОК и Бухгалтерия в сжатые сроки закрывала полугодие, + 1 неделя на перенос и контроль. в конце года все отчетности сдали из восьмёрки без заглядывания в семёрку :)

минус нашей методики только один - отсутствие кадровой истории - но вобщем-то она никому так и не понадобилась :)

Начинайте учет с начала года. Подводные камни :
Некорректно велись выплаты в 7.7, соответственно начальное сальдо по сотрудникам может немного разлететься.
Некорректно вносились Пособия по уходу за ребенком в 7.7, тоже проблемы будут.
Разные базы, разные проблемы. Главное, как велся учет в 7.7. Если любили ручками баловаться в 7.7, то хоть свои правила пишите, будут проблемы. У меня клиенты, кто более менее корректно работал, переносы практически без проблем.

Я переходил в середине года
Именно на корп
В целом все нормально
Но кое-где кое-что вылазило - документы остатков корректировали, и все в поряде

Всего из 300 человек может по 4-5 людям вылезло
Так что не бойтесь

1) да вообще практически ничего не дорабатывал
Но правда и зарплата простая - без наворотов
2)ms sql само собой

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

а можно поподробнее

подробно это надо как в 1с мануал на 50 страниц
если коротко
1) ставишь sql. Пароль запоминаешь
2) ставишь сервер 1с предприятия. Пароль запоминаешь.
3) на сервере SQL создаешь базу, создаешь пользователя на базу, пароль запоминаешь, пользователю права дб-овнер даешь.
4) на сервере 1с создаешь базу, прописываешь путь к базе SQL, пользователя SQL базы и пароль.
5) все - в базу можно загружать данные из файловой выгрузки

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

Да, бэкап делать безусловно, это не обсуждается даже, чем чаще тем лучше.
Скрипты это актуально для SQL 2000 было, на 2005 там можно мэйтэнс план прописать, заодно ставить реиндексацию, оптимизацию и расписание бэкапа указывать - и все отлично работает, 2005 в этом плане намного более дружественный.

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

http://infostart.ru/public/58333/

Можно перенести и не с начала года. Все переносится и садиться в регистры (с полугодия переносили). Переноситься все один в один (расчетная ведомость, налоги, персонифицированный сформировался за полгода корректно), но один нюанс, если пользователь захочет исправить какой-нибудь расчет за перенесенный период, будут трудности с исправлением, нужно будет править в регистрах. По обучению: обучали на месте, конкретно по документам. По времени: зависит от пользователя по разному. Вообще практикуем такую методику: Перенесли, показываем (обязательно заставляем все записывать) как с кадровыми документами работать (основными), расчетчику методику начисления, проходимся по нескольким сложным расчетам. Зарплатиста самого сажаем и под нашим чутким руководством проходимся по самому навороченному сотруднику (у которого больше всего разных начислений)создаем ВР, проверяем на сотруднике (Т.Е. в основном достаточно показать рабочий стол и где какие документы). На это уходит примерно часа 4-5 (может и меньше). Дальше клиент расчитывает зарплату и налоги за месяц. Приезжаем,показываем косяки, исправляем их, создаем проводки(на базу в 250 чел, на это уходит часа 2). Ну, а все остальное уже по ходу.
По поводу центров, есть примеры 50% прекрасно все усваивают и здесь конечно очень быстро идет внедрение, ну а 50% просто лентяи (самим лень думать, им легче вызвать нас)

переходили не с начала года. база около 1000 человек. Семерку можно считать типовой, доработки не касаются принципиальных вещей. Семерка ведется очень скурпулезно, в базе минимум ошибок. Много подразделений, баланс общий. переходили стандартными обработками. все перенеслось отлично. Единственно после по людям со скользящим графиком не заполнились Дни отработанные, проставились только по пятидневке(Если не ошибаюсь, но все легко видно по среднему и по своду по ЗП). Их можно приравнять элементарной обработкой. И еще у нескольких людей пришлось в регистрах править период регистрации больничного- его подали сильно позже. Это опять же легко видится. Учитывая количество сотрудников "косяки" были минимальны, я считаю. Средний, Ндфл - все нормально.
Но если в семерке учет велся криво или было много доработок, то переходить будет сложнее.

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

Если правильно велась база и без изменения конфы, то все нормально переносится, так что не надо тут.

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

Подскажите, как исправить и где искать ошибку!
Стандартным переносом выгрузила все данные из ЗиК в ЗУП. все начисления вроде корректны, но есть одно НО. непонятно откуда тянет задолженность предприятия перед работниками за дек 2008 года! хотя данные переносила с 2009 года.

Обратить внимание: данные нужны за 2 календарных!!!! года и отредактировать остатки отпусков. Все.

Как сохранить историю для расчета среднего заработка при переносе из ЗИК в ЗУП 2.5, для отпусков, б.листов?

Головняки :
1) Штатно начисления и удержания переносятся кое как, пришлось прописывать обработку самому.
2) Конфликты кадровых документов. В какой то момент пишет : сотрудник еще не принят, и спокойно проводит перемещение, в какой то момент падает с ошибкой.

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

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

Я переписывал правила под себя, так легче и удобнее было для меня. Т.к. не все учитывает стандартные правила от 1С, да и некоторые есть свои особенности ведения учета и самое главное что база на 7.7 была конфигуренная, поэтому некоторые правила писать с нуля, чтобы переносились как мне нужно.

Для начала можно поставить и бесплатный вариант сервера. Или заказать установку за минимальные деньги как например http://www.sparta-online.ru/content/articles/928/

Подскажите, за какой период переносить данные из ЗИК в ЗУП? Предположим, что я хочу перейти в ЗУП с 1 июля 2013 года. И чем обусловлен выбор периода переноса?

Доброго времени суток!
Переносил несколько раз и в разных организациях. В принципе всегда переносилось все нормально.
Иногда возникали небольшие проблемы по определенным людям (но там надо разбираться в индивидуальном порядке).