На конкурс к 8 Марта.

Хочу рассказать именно об этой автоматизации, т.к. для быстрого достижения результата, (я была сильно ограниченна во времени), мне пришлось искать и скачивать разработки с Инфостарта.
У меня есть клиенты, которых я сопровождаю уже несколько лет. Раньше они являлись четырьмя отдельными юридическими лицами, год назад их объединили в одну организацию. Слияние бухгалтерий произошло в прошлом году, а с начала этого года необходимо было объединить зарплатный блок. Надо сказать, что из четырех контор я работала с двумя, там было все настроено, Бухгалтерия и ЗиК связаны переносами через текстовый файл. В бухгалтерии донастроено вспомогательное производство, основное велось на стандарте.
За неделю перед Новым годом получаю от них задание на слияние данных расчета зарплаты за 2008 год в одну базу.
Задача № 1: сдать налоговую отчетность по зарплате до 20 января, моя сдача к 5 - 10 января, чтобы у бухгалтеров было время для проверки и корректировки. Самая большая форма - это налоговый отчет по всем сотрудникам за весь год, с множеством колонок, формируется в 1с оттуда выгружается в xml файл, потом загружается в программу налогового учета (ИСИД) и отправляется в налоговый комитет. Сотрудников примерно 2200 человек.
Задача № 2: начислить зарплату за январь в начале февраля, значит, мой крайний срок к 25 января установить объединенную базу.
Исходные базы:
1. Зарплата и Кадры 77 для Казахстана с индивидуальными настройками.
2. Зарплата и Кадры 77 для Казахстана с индивидуальными настройками, отличающимися от первой.
3. ДОСовская зарплата.
4. Бухгалтерский учет для Казахстана 77.

Составляю такой план:
Использую Конвертацию данных 8.1:
1 правило обмена - приемник ЗиК организации п.1., источник ЗиК организации п.2.
2 правило обмена - приемник тот же, источник dbf файлы зарплаты ДОС.
3 правило обмена - приемник тот же, источник Бухгалтерия п.3

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

Как построены в казахстанском ЗиКе справочники:
Организации подчинен справочник Подразделения - ему подчинен справочник Штатное расписание, в элементе справочника есть реквизит – Должность (из справочника Должности, он является общим). Причем наименование элемента справочника Штатное расписание состоит из наименования должности + (наименование подразделения), примерно так – Начальник участка (Участок №1).

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

Следующий пункт - перенос из dbf. Поиск по Инфостарту приносит результат - нахожу обработку под Конвертацию данных, единственную в своем роде: ( //infostart.ru/projects/2060/ ) и ( //infostart.ru/projects/2804/) , создаю правила обмена, перенести могу только справочники, расчеты там лежат в архивах arj помесячно, и я решила ограничиться переносом только справочников. Правила у меня не заработали, т.к. обработка не воспринимает префикс в коде справочника, пришлось писать свою обработку выгрузки из dbf, которой потом пользовалась и при выгрузке из бухгалтерии.
Кроме того в dbf таблицах оказались строки с пустыми кодами, пришлось почистить их с помощью обработки Абадонны - DBFViewer.ert ( //infostart.ru/projects/786/ ).
Пункт третий Выгрузка из бухгалтерии – новые правила в Конвертации данных: справочники, кадровые документы и документы начисления зарплаты. После этого переноса пришлось добавлять некоторые реквизиты справочника сотрудников тоже напрямую из dbf.

После объединения добавляется 3 организации, надо оставить одну вместо 4, остальные помечаю на удаление, и меняю подчинение у подразделений обработкой EDITREKV.ERT ( //infostart.ru/projects/3072/ ).
Так как названия подразделений одинаковые, надо убирать дубли. Дубли – это отдельная песня, они везде, и самое критичное – в справочнике виды расчета, перебрала несколько обработок, остановилась на следующей - MyReplVal.ERT ( //infostart.ru/projects/1732/ )
Так же пришлось чистить периодические реквизиты и «сворачивать» их на 31 декабря.
Для этого нашла использовала Periodic.ert ( //infostart.ru/projects/1367/ ).
Естественно на Новый год отдыхать особо не пришлось, 1 января я уже работала.

После слияния и расчета января прошлого года понимаю, что не успеваю подготовить всю базу к получению налогового отчета.
А это была первоочередная задача!
Срочно нужно искать методы слияния 3 отчетов, которые формируются в разных базах, и четвертый ручками бухгалтера набирают напрямую в налоговой программе (ИСИД).

Снова иду на Инфостарт и ищу обработки, выгружающие данные в таблицу значений. Нахожу такую: vt_view.ert ( //infostart.ru/projects/664/ ), заимствую оттуда несколько процедур для выгрузки и загрузки и вставляю в свои отчеты. Саму обработку для возможности объединения трех таблиц значений изменяю: вставляю флаг «объединять» и в процедуре Загрузить ТЗ добавляются новые строки в уже существующей на форме, сохраняю в файл, и загружаю снова в отчет и далее - стандартным способом в xml и потом в ИСИД.

Что делать с ДОСовской отчетностью, которую ручками заносили 2 человека в течении 3 дней? При сохранении набранных данных в ИСИДе создается файл наподобие xml, со своим расширением isd. Ну… вобщем я копирую табличную часть из одного файла и вставляю в другой через обычный текстовый редактор, структуру проверяю с помощью программки AKXMLEdit.exe ( //infostart.ru/projects/1612/ ), и потом уже открываю в ИСИДе и о, чудо, программа сама перенумеровала добавленные строки!
Вы бы видели счастливые лица, по меньшей мере, трех избавленных от каторжного ручного набивания женщин, они в этот день ушли домой пораньше!

Далее я продолжаю обрабатывать последствия объединения - пробую рассчитывать записи и понимаю, что нужно сотрудников разделять по расчетчикам, разделять права пользователей, делать отборы, то есть настраивать конфигурацию на новые условия совместного ведения и искать ошибки, при этом отделять ошибки переноса от ошибок пользователей. Ошибки пользователей устранить я уже не успеваю, а если бы и успевала, не смогла бы - они умудрились посчитать зарплату за январь, потом уволить людей в конце месяца, а в начале февраля снова принять на работу. При этом история у сотрудников за январь исчезла – как, установить не удалось, так что взять данные просто неоткуда.
Во всей этой работе мне помогла обработка poppy по мягкой смене периода ( //infostart.ru/projects/908/ ) и написанные в срочном порядке обработки по поиску нерассчитаных, нулевых, ручных записей.
В назначенный срок к 25 января я сдала работу. За этот месяц я так привыкла к Инфостарту, что он уже стал мне родным. И я благодарна всем, кто выкладывает здесь свои обработки и особенно тем, кто не закрывает код!