Хочу рассказать именно об этой автоматизации, т.к. для быстрого достижения результата, (я была сильно ограниченна во времени), мне пришлось искать и скачивать разработки с Инфостарта.
У меня есть клиенты, которых я сопровождаю уже несколько лет. Раньше они являлись четырьмя отдельными юридическими лицами, год назад их объединили в одну организацию. Слияние бухгалтерий произошло в прошлом году, а с начала этого года необходимо было объединить зарплатный блок. Надо сказать, что из четырех контор я работала с двумя, там было все настроено, Бухгалтерия и ЗиК связаны переносами через текстовый файл. В бухгалтерии донастроено вспомогательное производство, основное велось на стандарте.
За неделю перед Новым годом получаю от них задание на слияние данных расчета зарплаты за 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 января я сдала работу. За этот месяц я так привыкла к Инфостарту, что он уже стал мне родным. И я благодарна всем, кто выкладывает здесь свои обработки и особенно тем, кто не закрывает код!
На конкурс к 8 Марта.
См. также
"250+ тысяч, в штат и работу пока не ищу": как изменился типичный 1С-ник в 2023 году
08.02.2024 22453 Neti 85
Адекватность работодателя. Как её определить? Часть 2. Процесс работы, от испытательного срока до увольнения
22.01.2024 3704 biimmap 67
Адекватность работодателя. Как её определить? Часть 1. Собеседование, заключение трудового договора
16.01.2024 5211 biimmap 99
Идеальное место работы для ЗУПера... Какое оно?! Часть 1. Негативные тенденции, ненужные знания.
27.11.2023 4342 biimmap 52