7.7 ЗиК: перенос сотрудников

Тема в разделе "Типовые решения "1С:Предприятие 7.7"", создана пользователем Gulf_Stream, 2 июн 2009.

  1. TopicStarter Overlay
    Gulf_Stream
    Offline

    Gulf_Stream Опытный в 1С

    Регистрация:
    4 янв 2009
    Сообщения:
    71
    Симпатии:
    0
    Баллы:
    26
    Приветствую!
    Ситуация такая - на предприятии ведётся учёт в нескольких базах ЗиК, теперь в связи с массовым перемещением сотрудников из одного подразделения в другое, возникла задача, переместить сотрудников из одной базы в другую, при этом нужно забить для них базы для расчёта больничных листов, отпусков, оплаты по среднему и т.д.
    Подскажите как лучше сделать? Или может есть обработки которые решают эту задачу?

    Забыл добавить - конфигурации идентичны
  2. Бухгалтерский угодник
    Offline

    Бухгалтерский угодник Администраторы Команда форума Администратор

    Регистрация:
    29 дек 2008
    Сообщения:
    21.520
    Симпатии:
    407
    Баллы:
    104
    Довольно странно почему учет ведется в нескольких ЗиК (разные предприятия что-ли?). Можно было "разделить" базы (скопировав и удалив лишнее), но ты говоришь что в другой базе уже есть данные... Стандарного отбена данными нет (за всю практику не встечал). Только писать самому или обратиться за помощию..... Подводных каменй куча: начиная с одинаковых табельных номеров (если базы различны это возможно) кончая правильноым переносом периодических реквизитов, а их в спраочнике сотрудников достаточно + еще данные за предыдущие периоды.....
  3. TopicStarter Overlay
    Gulf_Stream
    Offline

    Gulf_Stream Опытный в 1С

    Регистрация:
    4 янв 2009
    Сообщения:
    71
    Симпатии:
    0
    Баллы:
    26
    Опишу подробней - есть довольно крупное предприятие, филиалы раскиданы по всей области, каждому территориальному филиалу соответствует база ЗиК, так сделано чтобы каждым филиалом мог заниматься кадровик и бухгалтер расчётчик, который отвечает за этот филиал. Достоинства и недостатки этого подхода можно обсудить отдельно, жить такой системе осталось не долго - через пол года будет закончено внедрение подходящей ЕРП системы. И собственно наметился массовый перевод сотрудников из одного филиала в другой, в связи с реорганизацией. Переносом сотрудников будут вероятно заниматься кадровики, т.е. вбивать всё вручную, хотя это тоже под вопросом. Во всех базах поддерживаются идентичные конфигурации, так же не может быть проблем совпадения табельных номеров. Мне надо обеспечить правильный расчёт оплаты БЛ, отпусков , оплаты по среднему для переведённых сотрудников.
    т.е. забить для каждого сотрудника Базу для расчёта БЛ, Базу для расчёта отпусков и Базу для расчёта оплаты по среднему за последний год.

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

    Может кто знает ещё варианты?
  4. Бухгалтерский угодник
    Offline

    Бухгалтерский угодник Администраторы Команда форума Администратор

    Регистрация:
    29 дек 2008
    Сообщения:
    21.520
    Симпатии:
    407
    Баллы:
    104
    Как бы делал я: Написал обработку по переносу сотрудников М/Д базами по ОЛЕ.

    Переносим Сотрудника и все его реквизиты + все документы вызвавшие движение истории (прием на работу, кадровое перемещение и т.д.) Контроль нумерации в данном сдучае смотри сам - надо ли? (если номера в базах совпадают - не позаботились о префиксе по подразделениям) - создай префиск ОБЯЗАТЕЛЬНО.

    Что касается базы... Вопрос спорный.

    а) Удобнее конечно суммировать данные из ЖР и переность в справочник 1НДФЛ. В этом случае есть обалденный минус - правильность расчета среднего (что вкючать/не включать в базу расчета по месяцу - есть одна сумма в справочнике... ее и получишь). Причем у нас же сейчас 6 видов расчета среднего... Зато в ЖР красота. Свод не меняется (записей в ЖР то нет)

    б) Переносить все в ЖР. с базой тогда будет все ок. Но "вылазит" другое - СВОД ПО З/П. за выгруженый период возрастет на сумму выгрузки.... А если придется "тьфу-тьфу" возвращаться и что-то править? Как ориентироваться? Всвязи с этим предложение - выгружай всех за прошлый год в новую базу в ОТДЕЛЬНОЕ подразделение. Чтобы не поиметь потом "грабли", а после перевода можно автоматом создать кадровое перемещение - и перевести сотрудника кудЫ надо. Лишь бы за выгруженный период он бы особнячком.

    Может у гкого другие мысли, но я бы переносил по способу "Б"
  5. TopicStarter Overlay
    Gulf_Stream
    Offline

    Gulf_Stream Опытный в 1С

    Регистрация:
    4 янв 2009
    Сообщения:
    71
    Симпатии:
    0
    Баллы:
    26
    В варианте "б" дельные мысли, так и сделаю =)
  6. Бухгалтерский угодник
    Offline

    Бухгалтерский угодник Администраторы Команда форума Администратор

    Регистрация:
    29 дек 2008
    Сообщения:
    21.520
    Симпатии:
    407
    Баллы:
    104
    Наше вам искренне сочувствие.... Работа адская...... И еще момент. Подумай. Наверное лучше сделать Отдельный документ ПЕРЕНОСА записей ВР (Сотрудник, ВР, Сумма) . Иначе если вернешься назад - весь твой перенос полетит к черту. А так - при перепроведении документа восстановится
  7. XXL
    Offline

    XXL Опытный в 1С Команда форума

    Регистрация:
    22 янв 2007
    Сообщения:
    1.159
    Симпатии:
    19
    Баллы:
    29
    Если еще надо. Я делала такое 2 года назад - ситуация совершенна идентична.
    После долгих размышлений сделала так (расскажу примерный алгоритм, если надо, то подробнее потом, надо дома посмотреть):
    1. написала обработки по выгрузке из баз необходимых данных в ДБФ и разослла по филиалам. Мне вернули файлы с данными. Помойму за каждый месяц была одна сумма, которая складывалась из всех необходимых для расчета ЗП.
    2. Сделала подчиненный справочник СправочникуСтрудников и в него загрузила данные из ДБФ с необходимыми для расчета ЗП данными по месяцам.
    3. При расчете например отпуска, если нет данных журнале зарплаты, данные выбираются из подчиненного справочника.
    Как-то так.
  8. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    Добрый день. Подскажите пожалуйста - у меня идентичная ситуация, можно узнать подробнее алгоритм? Спасибо.
  9. XXL
    Offline

    XXL Опытный в 1С Команда форума

    Регистрация:
    22 янв 2007
    Сообщения:
    1.159
    Симпатии:
    19
    Баллы:
    29
    Добрый день.
    Что именно вам нужно, опишите ситуацию. Если схожа, то поищу дома обработки.
  10. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    в филиал в г. Красноярске перевели Андреева А.П. с филиала в г. Новосибирске.
    При начислении ему зарплаты за июнь возникли проблемы со страховыми взносами.
    У Андреева А.П. страховые взносы должны считаться согласно шкалы регрессии, но мы не можем это сделать в ЗиК, она считает по основному тарифу.

    Буду материально признателен за помощь.
  11. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    в филиал в г. Красноярске перевели Андреева А.П. с филиала в г. Новосибирске.
    При начислении ему зарплаты за июнь возникли проблемы со страховыми взносами.
    У Андреева А.П. страховые взносы должны считаться согласно шкалы регрессии, но мы не можем это сделать в ЗиК, она считает по основному тарифу.

    Буду материально признателен за помощь.
  12. XXL
    Offline

    XXL Опытный в 1С Команда форума

    Регистрация:
    22 янв 2007
    Сообщения:
    1.159
    Симпатии:
    19
    Баллы:
    29
    т.е. вы хотите перекинуть всю предыдущую ЗП в новую базу?
  13. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    Наверное - я как раз и не знаю как такое можно реализовать в ЗиК.. ))
  14. XXL
    Offline

    XXL Опытный в 1С Команда форума

    Регистрация:
    22 янв 2007
    Сообщения:
    1.159
    Симпатии:
    19
    Баллы:
    29
    По способу реализации не подскажу, т.к. с 7.7 уже давно не работаю, но обработки по загрузке дома погляжу, если остались, может подойдут.
  15. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    Спасибо большое, буду ждать.
  16. Бухгалтерский угодник
    Offline

    Бухгалтерский угодник Администраторы Команда форума Администратор

    Регистрация:
    29 дек 2008
    Сообщения:
    21.520
    Симпатии:
    407
    Баллы:
    104
    Все намного проще.... Базу и начисленные налоги введите ручками. В карточке кн. ввод данных
  17. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    Я вчера набросал алгоритм - думаю он правильный.
    1 Отмена по сотру всех доков в новой базе
    2 Завести обособленное подразделение (старое)
    3 Принять его на работу с начала года
    4 Последовательно отменить закрытые периоды до января
    5 Заводить документы по месячно по сотру(сначало январь)
    6 пересчитать всех по январю(и его тоже)
    7 налоговые доки тоже по нему считать(а то база не увидит налоговую базу)
    и так последовательно до месяца принятия его на работу
    8 Перевести сотра документом перевода
  18. Бухгалтерский угодник
    Offline

    Бухгалтерский угодник Администраторы Команда форума Администратор

    Регистрация:
    29 дек 2008
    Сообщения:
    21.520
    Симпатии:
    407
    Баллы:
    104
    зачем такие сложности?
  19. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    Доброе утро! Может подскажите более легкий путь - нам необходимо получить именно регресс по переведенному сотруднику, но он переводится из другой базы получается и поэтому при его приеме не с начала года программа считает по основному тарифу. Я уже всю голову сломал))
  20. jurist80
    Offline

    jurist80

    Регистрация:
    11 авг 2014
    Сообщения:
    13
    Симпатии:
    0
    Баллы:
    1
    Просто думаем, а если придется таким образом не одного человека переводить, а сто? ))) Никто не сталкивался с похожей ситуацией?

Поделиться этой страницей