Ни в ЗУП ногой!? А мне нравится! Часть 4. Главное - правильный перенос данных!

05.08.22

Интеграция - Перенос данных 1C

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

Ссылки на остальные части статьи:

1. Главные сложности решения, что отталкивает?

2. Плюсы решения, где они прячутся?

3. Как меня туда занесло?

 

В этой статье рассмотрим задачу, с которой начинаются практически все проекты. Многие из этих проектов становятся проблемными. Причина - неверно выполненный перенос данных. В статье будут рассмотрены способы исключить проблемы при переходе на новую систему. Рассказ будет про переход на ЗУП 3, причем неважно с какой исходной системы. Однако, применить эти подходы можно к любой конфигурации.

 

1. Определяем заранее цели переноса данных.

Казалось бы... Что может быть непонятного? Цель одна - работа в новой системе! Вести кадровый учет, считать зарплату да налоги, сдавать отчетность.

Всё дело в том, что понятие "вести кадровый учет" в каждой организации своё, как и остальные понятия! Значит и цели у каждого свои. Следовательно их нужно описать заранее. Лучше всего описать, как говорится, "полный фарш". Если какая-то цель для текущей организации будет неактуальна - просто пропускаем. При описании целей переноса данных отвечаем на простой вопрос: "Что и зачем, иногда почему мы хотим делать в новой системе"?

Какие примеры можно здесь привести:

  • Все организации ведут штатное расписание. Однако, не во всех организациях есть вредные условия труда, далеко не все организации находятся в условиях МКС/РКС. Некоторые организации используют разъездной характер работы или вахтовый метод работы. Что от этого зависит в штатном расписании:
    • Необходимость заполнения полей "Код позиции списка" и "Основание досрочного назначения пенсии".
    • Наличие надбавки и дополнительного отпуска за вредные условия труда
    • Необходимость учесть в ФОТ позиции Районный коэффициент и Северную надбавку, а также дополнительный отпуск за работу в условиях МКС/РКС и т.д.
  • В каждой организации ведется кадровый учет. Но в некоторых организациях работают инвалиды, или иностранцы, в т.ч. не  резиденты. Это также накладывает определённые особенности:
    • Необходимо корректно заполнить статус налогоплательщика по НДФЛ, иначе неверно будет исчислен налог и страховые взносы!
    • Если это не гражданин РФ, он не имеет права на вычеты.
    • Инвалиды имеют право на дополнительные 3 дня к основному отпуску. Это необходимо учитывать при заполнении и переносе кадровых приказов. 
  • Все ведут табель учета рабочего времени. Однако, при наличии вахтового метода работы возникают трудности с назначением и заполнение графиков работы. В периоды междувахтового отдыха у работника не идёт северный стаж и не начисляются соответствующие надбавки. Необходимо продумать, как будет решаться этот вопрос, какие и где данные необходимо для этого заполнить.
  • Все считают зарплату. Но у некоторых есть управленческая часть зарплаты со сложным расчетом. Часто из предыдущей учетной системы необходимо перенести какие-то данные для расчета премий или доплат. Иногда, сначала нужно доработать систему, добавить нужные справочники/регистры и только потом переносить данные!

Для каждой цели необходимо указать, какие объекты метаданных необходимо заполнить, чтоб достичь поставленную цель. Прорабатывать данный пункт нужно с учетом особенностей организаций. Приведу "простой" пример: организация работает в Сургуте или Мурманске. Что необходимо заполнить, чтоб учесть территориальные условия:

  • В справочнике "Виды стажа" должен быть элемент "Северный" с указанной категорией стажа "Северный".
  • Регистр сведений "Виды стажа трудовой деятельности физических лиц" указывают виды стажа, которые требуется считать по работнику.
  • Регистр сведений "Накопленные стажи физических лиц". В этом регистре хранятся сведения о стаже с даты приёма по текущий день (или на дату переноса). Если у работника есть стаж до даты приема, необходимо увеличить количество лет и месяцев данного стажа.
  • Регистр сведений "Стажи физических лиц". По своей сути он дублирует предыдущий регистр.
  • Регистр сведений "Проценты северной надбавки физических лиц". Именно в этом регистре хранится размер этой доплаты. Схема немного отличается от остальных плановых начислений.
  • Регистр сведений "Параметры исчисления процента северной надбавки физических лиц". По этому регистру определяется, размер северной надбавки ещё увеличивается от стажа, или уже зафиксирован в максимальном значении.
  • В справочнике "Подразделения" или "Территории" необходимо указать территориальные условия ПФР и размер районного коэффициента федерального и регионального.

Вот так, простая казалось бы задача превращается в сложную. Поэтому мною разработана подробная концепция с указанием целей переноса данных, списка метаданных, который нужно заполнить и объёма переносимых данных. Ознакомиться можно по ссылке (ВСТАВИТЬ ССЫЛКУ).

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

Для таких ситуаций пришлось написать обработку, которая основываясь на настройках подразделений автоматически генерирует все данные по надбавкам, стажам, дополнительным отпускам, связанным с условия труда в МКС/РКС. Данные генерируются как в штатном расписании, так и в кадровых приказах. Подробнее можно прочитать об этом по ссылке (ВСТАВИТЬ ССЫЛКУ).

Повторюсь, от того на сколько Вы проработаете цели и концепцию переноса, зависит успешность Вашего проекта! На этот этап рекомендую не экономить никаких ресурсов.

 

2. Корректные данные  исходной системе - залог успешного переноса.

В предыдущих статьях уже писал о существующих заблуждениях при ведении проектов по ЗУП... Одним из главных считаю такое: "За данные отвечает заказчик, разработчик отвечает только за инструмент". Предлагаю разобраться в этом вопросе и устранить заблуждение. 

Совместимость ЗУП с некорректными данными:

Сначала предлагаю ответить на такой вопрос: "Будет ли работать ЗУП 3 с некорректными данными?". Мой ответ - точно НЕТ! Это в ЗУП 2.5 мы могли перенести всё что угодно и сохранить возможность нормальной работы. Почему так? Причина в том, что в ЗУП 2.5 многие бизнес-процессы не связаны между собой.

Например, если штатное расписание велось криво, это никак не влияло на все остальные процессы, т.к. регистр сведений "Штатное расписание" нужен был только для одной цели - печатная форма Т-3. С этой целью он успешно справлялся... В ЗУП 3 тоже есть лишняя функциональная опция "Использовать штатное расписание". Все годы работы с ЗУП не понимал, как могут быть штатное расписание или табель не обязательными!?! При всём при этом если неверно заполнить надбавки, оклад, дополнительные отпуска в штатном расписании, то заполнять их придётся руками во всех приказах на прием/перевод. 

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

Посмотрим с позиции заказчика:

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

Практически на всех моих проектах постановка задачи выглядит так: нам нужно сделать проект. Вот и вся постановка! Дальше есть только одно уточнение: скажите нам что нужно сделать. Здесь никто не обсуждает, что исходные данные находятся в плачевном состоянии. Чаще всего пользователи и не готовы даже их исправлять! Все ж заняты!

Поэтому правильная позиция звучит примерно так: проверим текущие данные , постараемся исправить ошибки, определим что необходимо переносить, подумаем над тем, как проверить результат переноса. 

Тем кто до сих пор считает, что за данные отвечает заказчик могу сказать так: Грош цена инструменту, который переносит некорректные данные!

Выполняем детальную проверку предоставленных данных:

Рассмотрим способы проверки данных в исходной системе. Продолжу придерживаться позиции, что перенос данных может происходить из любой системы. Поэтому проверочные механизмы будут лишь частично описаны с ориентиром на ЗУП 2.5/УПП. Что проверяем:

  • Полноту персональных данных. Вроде бы фраза общая... Какие данные надо проверить: информацию, которая попадает в регламентированную отчетность. Ведь это одна из целей перехода на новую систему. Часто встречаю, что вместо отчества для иностранцев ставят прочерк "-". Где-то ставят более одного пробела в ФИО, названиях должностей и подразделений. Орфографические ошибки также не редкость! Адреса, телефоны, место рождения должны быть введены в формате ФИАС. 
  • Если штатное расписание ведется вне системы, то стоит сверить наименования подразделений и должностей, как бы много их не было! Переносить в новую систему некорректные названия точно не стоит!
  • Учтены ли условия труда в кадровой информации. 
  • Если кадровый учет и расчет зарплаты ведется в разных системах, необходимо провести работу по сопоставлению данных. Проверить, можно ли их объединить? Все ли сотрудники введены, все ли приказы отражены в нужные даты и т.д.
  • Как введены данные об отпусках по уходу за ребенком. Для ЗУП 3 важно наличие документа Возврат из отпуска по уходу за ребенком, даже если он закончился в запланированную дату. В ЗУП 2.5 такой документ требовался только при досрочном завершении отпуска по уходу. 
  • Правильность налогов. Есть такое заблуждение, что в старой системе мы отчетность делаем руками, а в новой Вы нам сделайте обязательно автоматически! Дело в том, что это зависит от качества данных, а не от способностей внедренцев! Поэтому налоги выравниваем ДО переноса! Если в старой системе расчет верный - 99% что он будет верный и в ЗУП 3. Равно как и наоборот!
  • Стоит обратится к своему опыту! Ответить на вопрос: "Где прошлый раз были проблемы с переносом?". Опыт - главный помощник при решении таких задач. Если уже наступили на грабли, стоит предпринять все возможные действия, чтоб больше этого не делать.
  • Исправление известных "типовых" ошибок можно и нужно автоматизировать! 

 

3. Определяем объём переносимых данных. Составляем концепцию переноса на основе целей.

Определимся теперь с вопросом: "Какие данные необходимо перенести?". При обсуждении этого вопроса с заказчиком обычно звучит так: "Нам надо всё переносить! Вдруг надо что-то посмотреть, мы не хотим туда сюда заходить в разные базы!" Уверен, что именно этот вариант является самым часто озвучиваемым со стороны заказчика. Но является ли он правильным? На мой взгляд нет! И вот почему:

  • Если организация существует уже более 15 лет, а для крупных заводов и компаний это норма, она пережила уже не одну миграцию данных! Это значит, что данные, перенесенные из совсем старых учетных систем (ЗиК 7.7, старые версии Паруса, самописные, что не редкость) уже содержат в себе кучу ошибок! Более того, эти данные давно неактуальны! Люди уволены, подразделения расформированы.
  • Какова вероятность, что эти данные понадобятся? Практически нулевая! К этим данным обращаются, если приходит запрос из ПФР на подтверждение стажа работы. Персональные данные понадобятся, если работник через много лет опять трудоустроится в эту компанию! Значит необходимо перенести справочник "Физические лица", заполнить по максимуму данные. Вторую потребность можно закрыть другим способом: либо обмен со старой базой, либо перенос информации для справки в сокращенном виде (что предусмотрено типовой конфигурацией!).
  • Ещё раз повторюсь, что данные с прошлого переноса требуют корректировок для того, что перенести в ЗУП 3. Т.к. для обеспечения работоспособности ЗУП 2.5 нужно гораздо меньше данных, чем для той же цели в ЗУП 3.
  • Некоторые заказчики ещё просят перенести расчетные данные за прошлые периоды. Кто-то просит за последние 2 года, чтоб можно было по расчетному листку проверить расчет среднего заработка. Кто-то просит вообще за весь период... Вот этого делать категорически нельзя! Следом за данными начислений потянутся данные по взаиморасчетам, налогам, взносам. Зачем они Вам? Поверьте в них много ошибок! При большой численности никто это не станет выверять и уж тем более исправлять! Период то закрыт, зарплата выплачена, налоги и взносы исчислены и уплачены. Налоги и взносы в ЗУП 3 частенько цепляют прошлые периоды, если есть перерасчет декабря в январе. И так по цепочке может зацепить несколько лет! И доначислит или сторнирует всё что посчитает нужным. Для корректного расчета НДФЛ потребуются данные о правах на вычеты и об использованных вычетах за эти годы. Если у Вас данных не будет, то ждите доначисления НДФЛ. 

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

От даты старта сильно зависит объём переносимых данных. Проще всего начать работу в новой системе с начала года. Но не всегда так получается сделать! Иногда требуется старт с начала квартала, или с начала любого месяца, иногда даже с середины месяца! Да, такой вариант есть и уже дважды встречался в моей практике.

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

Представьте себе, Вы запланировали старт с начала года. Допустим, разработчик сделал правила конвертации или обработку написал для старта с нового года. У Вас есть список доработок, которые требуется выполнить до начала работы в новой системе. И вот этот список сделать не успели! А заказчик не хочет стартовать без указанных доработок. И что Вы делать будете? Уверен будет много проблем в такой ситуации. Если у Вас правила или обработка позволяет стартовать с любой даты, Вы спокойно переносите дату старта, доделываете требования заказчика и в спокойном режиме начинаете работу в новой системе.

 

4. До переноса нормализуем и обновляем ключевые справочники и классификаторы.

Для того, чтоб начать перенос данных, необходимо подготовить "пустую" базу. Возникают вопросы:

  • Где её взять? 
  • Какое состояние можно считать "пустым"? 
  • Какими данными её необходимо наполнить?

На практике встречал разные варианты: кто-то брал СФ и создавал пустую базу, кто-то брал демо-версию, чистил её от сотрудников и документов, и вот она пустая. На самом деле оба варианта неверные! Первый вариант верный частично. 

Понимание правильного варианта появляется при описании целей переноса данных. Также задаём себе вопрос: какие данные нужно внести 1 раз и больше не запускать их повторную загрузку? Ведь финальный перенос данных - это примерно 15-я попытка загрузить данные). Если коротко, то нужны следующие данные:

1. Классификаторы. Самый простой пример банки и ФИАС.

2. Справочники, отражающие структуру и особенности предприятия: Организации, план видов расчета, графики работы.

3. Настройки учета. 

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

Для чего нужны настройки? Например, загружать кадровые приказы необходимо с выключенной функциональной опцией "Используется штатное расписание". Штатное расписание и все позиции штатного расписания будут сгенерированы автоматически на основании штатной расстановки. Если есть МКС/РКС - это настраивается в справочнике "Организации". Без этой настройки в план видов расчета не будут добавлены районный коэффициент и северная надбавка. 

После всех проверок и настроек сохраняем файл ДТ - это и есть та самая "пустая база"! 

 

5. Выверяем перенесенные данные.

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

Приведу другой пример из жизни. Дали, к примеру, задание: переложить бананы из картонной коробки в ящик для овощей в холодильнике. Какова вероятность накосячить в таком задании? Если только человек не съест по пути полкоробки... Надо ли выполнять проверку в такой задаче? Мне кажется нет, т.к. нет смысла пересчитывать бананы. 

Все уж наверняка приготовили помидоры в меня кидаться... а рано! Вот что предлагаю проверить:

  • Уже не раз говорилось о целях переноса данных. Так если мы поставили цели, значит надо проверить, достигли мы их или нет?
  • Каждая цель отвечает за какой-то участок учёта. Каждый участок учета - это набор сценариев. Значит проверить каждую цель означает проверить все сценарии в этом блоке учета. Если все сценарии сработали - мы достигли нашу цель. Если какой-то сценарий не сработал - это повод для проверки объёма и качества перенесённых данных.
  • Проверить правильность данных можно с помощью стандартных отчетов. Например, унифицированная форма Т-3 и штатная расстановка дают нам понимание о правильности перенесенных данных в этом блоке. Если не сходится численность или количество ставок или ФОТ - проверяем исходные данные и алгоритмы их переноса.
  • Многие крупные компании используют этап "тестовый запуск". Его планируют за месяц или два до ввода системы в промышленную эксплуатацию. На этом этапе есть возможность ознакомиться с функционалом новой системы и оценить правильность и достаточность перенесенных данных. Выявленные ошибки быстро исправляются и тестирование продолжается/повторяется.
  • Обычно тестовый запуск проводят на ограниченном наборе данных. Однако набор этих данных должен быть максимально сложным! Нет смысла тестировать начисление оклада. Есть смысл проверить расчет сдельной оплаты труда, разъездной характер работы, вахтовый метод работы и прочие сложности учета. На этом же этапе тестируем печатные формы приказов, трудовых договоров и дополнительных соглашений. В стадии промышленной эксплуатации придётся руками править тексты приказов и договоров, если не проверить заранее.
  • Всё написанное не означает, что не нужно автоматизировать сверку. Должен быть чёткий алгоритм проверки, основанных на "узких местах" либо исходной программы, либо ЗУП 3. Когда есть чёткий алгоритм - проверочный отчет нам явно поможет! Но сравнивать бананы до перекладки в холодильник и после бессмысленно!

 

Вот, собственно, и всё! Описали цели переноса данных, составили концепцию, проверили исходные данные, перенесли, выполнили проверку данных - значит вероятность успешного переноса данных близка к 100%. Пропуск описанных этапов грозит проблемами на старте. Помните: ЗУП 3 не умеет обрабатывать некорректные данные! Есть ошибка в данных, значит, будет ошибка в работе ЗУП 3!

Напомню о наличии других полезных статей:

Часть 1. Общие вопросы. Доработка чужого кода. Code review.

Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации.

Часть 3. Разбор и доработка запросов

Часть 4. Программный интерфейс. Исправление чужих доработок.

Также напомню о статье про архитектора. Некоторые подходы, позволяющие решать сложные задачи, описаны в ней:

Кто такой архитектор. Редакция 2!

См. также

SALE! 10%

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

55778 50200 руб.

04.08.2015    167277    340    278    

376

SALE! 15%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

26280 руб.

12.06.2017    142250    803    297    

423

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.236.x) и БП 3.0 (3.0.164.x). Правила подходят для версии ПРОФ и КОРП.

35000 руб.

15.12.2021    24363    172    51    

131

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.88.x) и УТ 11.5 (11.5.20.x).

35000 руб.

23.07.2020    51989    229    72    

187

Перенос данных 1C Программист Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет НДФЛ ФОМС, ЕФС Платные (руб)

Обработки для быстрого перехода с конфигураций «КАМИН:Расчет заработной платы 3.0», «КАМИН:Зарплата для бизнеса 4.0» и «КАМИН:Зарплата 5.0» на конфигурацию «Зарплата и управление персоналом» версии 3.1.

12000 руб.

25.09.2016    81028    315    250    

268

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Платформа 1C v8.2 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)

Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 2, УНФ 1.6 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.

15300 руб.

18.02.2016    187210    591    513    

529

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    10949    13    8    

15

Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    25283    22    1    

25
Отзывы
21. Ulfhedhinn 250 15.08.22 05:43 Сейчас в теме
Сам работаю именно с ЗУПом уже почти 20 лет и навидался всякого. Очень интересно прочитать структурированное мнение про свою сферу деятельности и послушать про интересные проекты и решения.

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

Очень часто встречаю ситуацию, когда расчетчики живут в своей древней программе (есть у нас тут региональный монстр, который 25 лет держал весь рынок на своем продукте - причем продукт по своему хорош!), а кадры при этом живут в ЗУПе (чаще всего старом 2.5) и задача перевести кадры на свежий ЗУП, а потом туда перетащить расчетчиков. Давно пришел к мнению, что кадрам нужно бросить свою базу и забыть. Делаем перенос в чистый ЗУП 3.1 из базы расчетчиков, по необходимости дополняем данными из старого ЗУПа кадровиков. Опыт показал, что это единственный верный вариант для организаций с численностью больше тысячи сотрудников. Если меньше, еще как-то можно попробовать вырулить при наличии неглупого и трудолюбивого коллектива, но как правило дело дрянь и проект будет мертворожденным или затяжным года на 2-3.

На практике встречал разные варианты: кто-то брал СФ и создавал пустую базу, кто-то брал демо-версию, чистил её от сотрудников и документов, и вот она пустая. На самом деле оба варианта неверные! Первый вариант верный частично.

Понимание правильного варианта появляется при описании целей переноса данных. Также задаём себе вопрос: какие данные нужно внести 1 раз и больше не запускать их повторную загрузку?

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

Цикл статей весьма неплохой! Жду продолжения! =)
asupsam; Lartchik; RibD; biimmap; +4 Ответить
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Kamilla_Tas 30.05.22 10:09 Сейчас в теме
Ознакомиться можно по ссылке (ВСТАВИТЬ ССЫЛКУ)


Ссылки нет((

За статью -спасибо!
2. biimmap 2022 30.05.22 10:11 Сейчас в теме
(1) да ещё не готов материал) Это будет платная публикация.
Kamilla_Tas; +1 Ответить
3. Kamilla_Tas 30.05.22 10:13 Сейчас в теме
(2) Я просто из тех, кого тяжело представить)) Начинающий аналитик, который по собственной воле решил заняться ЗУПом))
5. aleks.public 30.05.22 13:10 Сейчас в теме
4. biimmap 2022 30.05.22 10:19 Сейчас в теме
(3) да, редкий "зверь")) сочувствую. В первой статье написано, какой материал Вам нужно изучить) Потом ещё в одной статье будет про подходы к обучению.
Kamilla_Tas; +1 Ответить
6. smit1c 106 30.05.22 14:32 Сейчас в теме
ЗУП - это для аналитика, но не для программиста... ))
8. biimmap 2022 30.05.22 20:00 Сейчас в теме
(6) Это лишь отчасти верное утверждение. Работа в ЗУП требует знания предметной области и умения копаться в данных. Это собственно и есть навыки аналитика.
9. laperuz 47 31.05.22 04:13 Сейчас в теме
(6)Для программиста ЗУП, кстати, хорош наличием программного интерфейса и отсутствием необходимости самому писать значительные участки кода.
10. smit1c 106 31.05.22 08:32 Сейчас в теме
(9) зато если надо найти откуда данные берутся, приходится прыгать по пяти промежуточным процедурам и потом найти простыню-запрос из временных таблиц....
11. Aftee 31.05.22 08:40 Сейчас в теме
(10) Это только первые раз пять :) Дальше втягиваешься, и, вроде, все не так уж плохо
12. biimmap 2022 31.05.22 09:15 Сейчас в теме
(10) нужно уметь искать) Прыгать по процедурам так себе затея. Отладчик в качестве поисковика плохой помощник. Глобальный поиск рулит)
chiki-79; +1 Ответить
7. RustRR 30.05.22 14:39 Сейчас в теме
Краткое содержание статьи: Если перенести много данных - в них будет много ошибок, если мало - то мало, а ЗУП 3 не умеет обрабатывать некорректные данные! Понятненько.
13. cdiamond 236 31.05.22 15:00 Сейчас в теме
В ЗУПе главное расколоть МенеджерРасчетаЗарплаты. Большинство костылей по зарплате вставляются туда.
14. biimmap 2022 31.05.22 16:17 Сейчас в теме
(13) Предпочитаю костыли не вставлять никуда! Кстати этот комментарий актуален для первой части статьи. В ней об этом написано. Есть ещё МенеджерДанныхУчетаВремениСотрудников) Он кстати сложнее в понимании и доработке. В нём ещё более универсальные алгоритмы. Дописал 2 строчки, а сломаться может пол конфигурации)
15. Vinzor 107 02.06.22 07:31 Сейчас в теме
В целом неплохо. Но вот убеждённость, что "Табель" обязательно нужен, меня удручает.
Он нужен только если:
- было такое, что не запланировано графиком (например, ночные часы)
- при суммированном учёте времени
- если это предусмотрено распоряжением по организации, чтобы были ответственные лица, вносящие данные по отработанному времени (зона ответственности за эти данные)
Других причин обязательного внесения табеля, при достаточности "График минус отклонения" , нет.
_DaFNa_; user1668778; +2 Ответить
16. biimmap 2022 02.06.22 11:46 Сейчас в теме
(15) у каждого своё сочетание мнение+опыт. У меня не было проектов, где можно было бы его не вести. Работаю только на крупных проектах.
17. Vinzor 107 02.06.22 14:37 Сейчас в теме
(16) Неконкретно Вы как-то ответили. По сути "У нас так принято".

Тоже в крупных проектах работаю. Причины, по которым у нас "Табель" ведут обязательно, изложил ранее :)
Причины 1,2 - технического плана (ЗУП), 3 -управленческое требование бизнеса.
SERGEJ64; +1 Ответить
18. biimmap 2022 02.06.22 14:52 Сейчас в теме
(17) На моих проектах от табеля много чего зависит. Где-то табель является источником доп. информации, где-то наоборот он формируется каким-то необычным способом на основании чего-то...

Проектов без суммированного учета времени тоже не припомню. Ночные часто встречаются в моей практике. Поэтому все озвученные Вами причины актуальны.

Потому и написал, что не было проектов где можно табель не делать. Проекты довольно подробно описаны в моём резюме на hh.ru оно открыто для всех.
26. NikeDyu 29.08.22 09:20 Сейчас в теме
(18) Приветствую, а можно ссылочку на резюме, чёт не могу найти :(
19. biimmap 2022 02.06.22 14:54 Сейчас в теме
(17) Отдельно напишу, что часто приходилось копаться в коде обработки МенеджерДанныхУчетаВремениСотрудников. Могу точно сказать, что сложные расчеты без табеля невозможны! Т.к. в упрощенном варианте данные неверно собираются и подходят только для упрощённых схем расчета.

Код обработки всем также открыт, можно ознакомиться)
20. alisakish 06.06.22 19:44 Сейчас в теме
Я вот тоже почему-то решила, что ЗиК мне роднее чем все остальные 5 продуктов, которые мне приходится поддерживать у нас. И согласна с теми, кто считает, что опыт работы улучшают меня как аналитика. Кстати, если вы были программистом ПАРУСа, то вам будет не так уж и сложно! ЗиК или ЗУП после него уже не страшен!
27. bolikov 20 05.04.23 08:07 Сейчас в теме
(20)100500 Зик лучше, однако монополист решает за нас
21. Ulfhedhinn 250 15.08.22 05:43 Сейчас в теме
Сам работаю именно с ЗУПом уже почти 20 лет и навидался всякого. Очень интересно прочитать структурированное мнение про свою сферу деятельности и послушать про интересные проекты и решения.

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

Очень часто встречаю ситуацию, когда расчетчики живут в своей древней программе (есть у нас тут региональный монстр, который 25 лет держал весь рынок на своем продукте - причем продукт по своему хорош!), а кадры при этом живут в ЗУПе (чаще всего старом 2.5) и задача перевести кадры на свежий ЗУП, а потом туда перетащить расчетчиков. Давно пришел к мнению, что кадрам нужно бросить свою базу и забыть. Делаем перенос в чистый ЗУП 3.1 из базы расчетчиков, по необходимости дополняем данными из старого ЗУПа кадровиков. Опыт показал, что это единственный верный вариант для организаций с численностью больше тысячи сотрудников. Если меньше, еще как-то можно попробовать вырулить при наличии неглупого и трудолюбивого коллектива, но как правило дело дрянь и проект будет мертворожденным или затяжным года на 2-3.

На практике встречал разные варианты: кто-то брал СФ и создавал пустую базу, кто-то брал демо-версию, чистил её от сотрудников и документов, и вот она пустая. На самом деле оба варианта неверные! Первый вариант верный частично.

Понимание правильного варианта появляется при описании целей переноса данных. Также задаём себе вопрос: какие данные нужно внести 1 раз и больше не запускать их повторную загрузку?

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

Цикл статей весьма неплохой! Жду продолжения! =)
asupsam; Lartchik; RibD; biimmap; +4 Ответить
22. biimmap 2022 15.08.22 09:50 Сейчас в теме
(21)
где-же собственно правильный ответ на поставленный вопрос?


1. Пустой релиз
2. Первичное заполнение
3. Обновление классификаторов
4. Первичная настройка базы
5. Загрузка справочников организационной структуры (Организации, Графики работы...)

На Жёлтой субмарине в Нижнем Новгороде выступал с этим докладом. Там голосом эти пункты озвучивал)
23. biimmap 2022 15.08.22 09:51 Сейчас в теме
(21)
Цикл статей весьма неплохой!


Просто ради интереса: почему люди прочитав статью, которая понравилась не ставят плюсы?
24. Ulfhedhinn 250 16.08.22 02:43 Сейчас в теме
(23) я редко пользуюсь Инфостартом, при нажатии на плюс не понятна механика, предлагает добавить "в загрузки" или "в избранное", мне в общем-то не нужно ни то ни другое. Плюса не жалко, пришлось пройти по статьям и добавить в избранное =)
25. biimmap 2022 16.08.22 10:01 Сейчас в теме
(24) я для этого создал новую папку "Просто плюсы". И там где статья нравится ставлю.
_DaFNa_; Ulfhedhinn; +2 Ответить
28. vandalsvq 1592 10.09.23 07:44 Сейчас в теме
Помнится когда мы перевозили заказчика из галактики в зуп, одна из частей «безудержной радости» было конвертировать адреса в фиас. Если кому интересно, могу найти и написать статью. Но блин, я точно не вспомню, но какое то количество нервных клеток оно мне стоило.
А еще там сотрудников было что-то вроде 3 тысяч, проверять это все было тоже крайне забавно.

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

Спасибо за статью. Ее бы мне в 2020м )))))
29. biimmap 2022 10.09.23 10:35 Сейчас в теме
(28) про преобразование адреса тоже есть 2 статьи)
30. vandalsvq 1592 10.09.23 11:02 Сейчас в теме
Оставьте свое сообщение