Не буду расписывать детально, введу в курс дела по проекту кратко, расскажу, как проходил перевод заказчика с УПП на ЕРП.
Заказчик является крупнейшим предприятием пищевой отрасли. До начала проекта у заказчика было УПП 1.2 (даже не 1.3). В 2021-м перешли на ERP 2.4. В целом по проекту делали переход с УПП + ДО с большим количеством внешних интеграций. Переходили на связку ERP + ЗУП + ДО.
Начали с августа 2020 года.
Порекомендовали ИТ-специалистам заказчика пройти курсы 1С. В ноябре, после обучения, специалисты присоединились к проекту (кто не потянул — уволился). Учет проектных задач велся в информационной системе «Канбан» и Google.Docs, использовали встраиваемую справку в ERP, информационную систему поддержки, встроенную прямо в ERP, стандартное хранилище 1С. В обязательном порядке проводили еженедельные планерки с фиксацией задач и прогресса.
Стандартный перенос из УПП в ERP пришлось переделать. Перенос остатков делали в январе. До апреля учет вели в двух системах в УПП и в ERP, обменивались оперативными документами и НСИ по правилам обмена (чтобы снять нагрузку с работающих пользователей т.к. они все-таки бизнесом занимаются и не являются каторжниками).
Перенос справочников 1С в идентичную конфигурацию
За время учета в двух системах адаптировали интеграции и нестандартные подсистемы УПП, модифицировали железо и инфраструктуру серверов, настраивали права доступа, адаптировали мышление пользователей к проверкам данных и закрытию в ERP и ЗУП (не было обрубания канатов на 01.01). Гладко перешли с системы на систему без привязки к началу года. (Кому нужно обращайтесь, внедряли и УПП и ЕРП, понимаем и там и там).
В условиях пандемии проект на 98% реализовывался удаленно, без посещения заказчика.
О задаче переноса остатков и параллельной работе пользователей в двух системах
Речь пойдет об особенности организации двух последовательно идущих этапов проекта: «Переносе начальных остатков из УПП в ЕРП» и «Начале работы пользователей в новой системе ЕРП и отказа от УПП».
Большинство из нас знает, что в самом распространенном случае после переноса остатков в начале января пользователи короткое время параллельно работают и в старой, и в новой системах, а не сразу в новой. Многие взяли за правило не рубить канаты сразу, чтобы:
- в течение некоторого стартового периода иметь возможность откатиться в старую базу в случае неудачного запуска новой базы, например, из-за технических проблем;
- постепенно переключить интеграции с другими системами со старой на новую базу;
- откорректировать предыдущий период в старой базе при подготовке отчетности и правке остатков в новой;
- и т.п.
На этом проекте с этапом «Переноса остатков» всё складывалось близко к стандартному сценарию (шли тестовые переносы и выверки, планировался итоговый перенос в январе и расчет на небольшие догрузки исправлений). И это не смотря на то, что переходили с «перепиленной» вдоль и поперёк УПП 1.2 (даже не УПП 1.3, а 1.2) с серьезными отличиями логики учета УПП, допиленной силами заказчика, от логики зашитой в типовые правила переноса остатков из УПП в ЕРП по большинству блоков (продажи и покупки, НМА и ОС, оплаты, складской учет количества и др.). Свет в конце туннеля к январю всё же был виден. Про сам процесс переноса остатков кратко опишу в отдельной главе ниже.
Перенос справочников и документов между одинаковыми конфигурациями 1с 8.х
Чрезвычайная ситуация со сроками
А вот с этапом начала работы в новой системе возникла чрезвычайная ситуация: не успевали к январю «ну ни как, хоть ножом режь»…. Проявилась она заблаговременно, за 2 месяца до январского запуск, в ходе составления и обсуждения на планерках так называемой Таблицы переключения выявили критичные моменты, такие как:
- текущая организация серверного ландшафта не подходит (сервера не тянут, несмотря на стартовые заверения в надлежащей мощности);
- интеграции с внешними системами (сайтами KPI и заказов, системой производства, электронного документооборота) не готовы и прогнозируемо не будут готовы еще несколько месяцев после начала нового года.
Без реализации этих задач отказ от УПП был физически невозможен. Отмечу, важно в таких случаях не упустить момент управленческого решения, оно должно четко и оперативно прийти со стороны тимлидов проекта, т.к. остальные участники (ресурсы проекта) находятся под нагрузками или не имеют нужного опыта, чтобы осознать и принять меры закрытия риска. Благодаря такому подходу мы в итоге выкрутились и сделали переход не только безболезненным, но и более качественным.
Перенос остатков
При начале разработки за основу взяли типовую перегрузку остатков в ЕРП из других конфигураций. Инструмент и его описание находится в установленном каталоге конфигурации ЕРП по примерному пути «….1СEnterprise202_5_7_193AddFilesПереходы с других конфигурацийУПП_КА1».
В этой папке в файле «Руководство по переходу с УПП 1.3 и КА 1.1.htm» содержится подробное описание того что и как нужно выполнить.
По факту нам нужно было переносить данные из Источника УПП 1.2 (сами типовые правила изначально для УПП 1.3) в Приемник Бета версии ЕРП 2.5 (еще не было официального релиза, но был получен «сверху» совет, входить в проект именно на 2.5 и, вероятно, правила переноса не адаптировались самой фирмой 1С), поэтому типовые правила потребовалось дорабатывать.
Входные параметры проекта, предопределили необходимость адаптации/доработки типовых правил переноса под другие условия:
- Источник — «перепиленная» УПП 1.2 (даже не УПП 1.3) с отклонениями/нарушениями типовой логики учета 1С
- Приемник — ЕРП 2.5 Бета-версия без официального релиза (для котят), но рекомендованная для входа в проект
Сами исходные правила переноса из УПП в ЕРП мы забрали из типовой обработки «Выгрузка данных.epf» открыв её в конфигураторе и сохранив текст макета в текстовый файл с расширением XML.
Полученный файл залили в 1С:Конвертация данных 2 (далее 1СКД2), затем выгрузили файлы со структурами метаданных Источника и Приемника и также залили их в 1СКД2 (Обработками получения структур метаданных MD82Exp.epf, MD83Exp.epf).
Глобальные различия типовых правил и структур реальных баз сразу убирали через меню 1СКД2 — Сервис – Проверка. Остальное локально дорабатывали почти по каждому блоку. Я уже акцентировал ваше внимание в разделе «Введение» на том, что логика учета в УПП заказчика в значительной степени не совпадала с логикой, заложенной для сбора остатков в типовом переносе, и многие правила адаптировались.
В дальнейшем саму выгрузку из УПП делали по доработанным правилами с помощью стандартной обработки «V8Exchan82.epf», а загрузку в ЕРП обработкой «V8Exchan83.epf». Они более известны по наименованию «Универсальный обмен данными XML.epf» и находятся в составе как УПП, так и ЕРП.
Примечание: Замечу что типовые правила 1С были не без сюрпризов, например, осуществлялся перенос ставки НДС 0% в ставку Без НДС, может из-за того, что работали с Бета 2.5.
В итоге, несмотря на специфические для перехода с УПП на ЕРП базы Источника и Приемника (УПП 1.2 и бета ЕРП 2.5), сам этап ввода начальных остатков прошел по стандартной схеме:
- были подготовлены и одобрены списки необходимых срезов остатков и НСИ для переноса из УПП;
- написаны правила переноса, смоделированы и выверены с ключевыми ответственными лицами заказчика результаты тестовых переносов между Источником и Приемником.
В начале января нового года выполнили реальный перенос, который в дальнейшем потребовал небольших корректировочных догрузок и ручных исправлений, выявленных в ходе сверки данных Источника и Приемника.
Начало работы в новой системе
Для примера, на параллельно идущем проекте нашей компании, люди последние две трети января просто параллельно «вколачивали» данные и в УПП, и в ЕРП, а в феврале перешли на работу только в ЕРП. Это привычная практика, и мы изначально предполагали сделать ровно также, но….
Но, как описано во введении, на проекте за пару месяцев до запуска выявились критичные факторы:
- невозможность в срок подготовить все интеграции с ЕРП (70% объема интеграций модифицировали ИТ Заказчика, 30% мы как интегратор,
- Неготовность серверного ландшафта для работы в ЕРП нужного количества онлайн-пользователей (хотя на этапе запуска необходимые серверные мощности нам обещали).
Именно эти проблемы не позволили применить привычную схему перехода. Ситуация сложилась критическая для всего проекта…
Но выход был найден. Было принято решение по удлинению периода параллельной работы в 2-х системах с января, до нескольких месяцев. Пользователи и все интеграции должны работать с УПП, но учет в ЕРП должен начаться с января нового года (остатки + ввод оперативных данных). Это давало проектной команде необходимое время для подтягивания отстающих задач.
Обычно «крайними» на этапе параллельного учета в двух системах становятся пользователи. Но в данном случае для этого не хватало ресурсов — сама компания была коммерческой с рыночными зарплатами и оптимизированным штатом сотрудников, которые были максимально загружены основной работой, и поэтому работать в 2-х системах ни физически, ни морально длительный период не могли…
Если 2-3 недели? — Да, пожалуйста. — А 2-3 месяца? — Категорически — нет!
Сотрудникам надо было помочь, а нам экстренно, в течение месяца, разработать регулярную подкачку НСИ и оперативной информации из УПП 1.2 в ЕРП 2.5.
Все, кто занимался обменами, представляют, что организация нового обмена данными — это объемная комплексная задача для группы специалистов. Выдернуть на неё дополнительные ресурсы перед январём очень сложно, и при этом надо сделать работающий вариант.
Тут выполнялся пошаговый поиск решений с упрощением, чтобы сэкономить время и трудозатраты. Для этого нам надо было минимизировать список того, что требуется перегружать из УПП и выбрать максимально простой способ передачи данных в ЕРП. При этом надо гарантировать, чтобы перегружались как новые данные выбранные за период, так и точечно изменяемые пользователями.
Шаг № 1: Определение данных для переноса
Чтобы ограничить список перегружаемых из УПП объектов, мы собрали статистику за прошлый квартал и свели её в таблицу. Обработки по сбору статистики были найдены на стороне, они по сути делятся на нескольких видов: сбор данных по журналу регистрации, сбор данных по метаданным в 1С, сбор данных по таблицам SQL (подойдет не каждая, т.к. какие-то работают неприемлемо долго на объемных базах, какие-то не имеют нужных отборов, например за период или выдают плохое представление результатов), в общем, пришлось поискать, а найденные «допиливать».
Лучше остальных подошла обработка сбора статистики по Журналу регистрации, в ней мы добавили вывод ответственных за объект, чтобы знать ФИО: кого со стороны пользователей Заказчика назначить ответственным за сверку данных объекта между УПП И ЕРП (разобрали по контролёрам).
В таблице статистики члены команды и ключевые пользователи проголосовали за объекты переносимые из УПП в ЕРП согласно критериям:
- ЗА – большой вес объекта, т.е. большое число созданных объектов данного типа за период ИЛИ большое число строк в объекте ИЛИ отметка ответственного консультанта или ключевого пользователя об обязательности переноса данного типа объектов,
- ПРОТИВ – малое количество объектов данного типа или сложность создания правил для обмена объекта.
По самим объектам перенос указывался:
- ПОЛНЫЙ (программист должен проработать перенос максимально возможного количества реквизитов объекта);
- ЧАСТИЧНЫЙ (перенос ключевых реквизитов объекта — Номер, Дата, Код, Наименование, Организация — остальное заполнялось пользователем вручную);
- ВРУЧНУЮ (объект УПП полностью заводился пользователем вручную в ЕРП).
Также в таблице статистики напротив каждого объекта УПП консультантами были указаны его образы в ЕРП. Связи были не только 1 в 1, а несколько типов объектов УПП в один и тот же тип объекта ЕРП, или 1 тип объекта УПП в несколько типов объектов ЕРП. Основную сложность вызвали Взаиморасчеты со сверками, Оплаты по разным видам операций, Перенос производства.
ИТОГИ по Шагу № 1:
- программисты получили минимизированный список объектов, который был одобрен пользователями;
- определили ответственных за каждый объект УПП и его образ в ЕРП со стороны пользователей заказчика.
Шаг № 2: Выбор схемы переноса, подготовка набора инструментов и организация работы
На время параллельной работы в 2-х системах сначала рассматривали разработку стандартной схемы синхронизации 2-х баз (2 плана обмена + пакеты правил), но от неё было решено отказаться по нескольким причинам:
- нам требовался только односторонний обмен из УПП в ЕРП,
- синхронизации работает согласно регистрации изменений и не тянет по умолчанию объекты по ссылке,
- трудно установить произвольные фильтры на выгрузки,
- трудно совместить работу нескольких программистов в рамках 1СКД2 над одним и тем же экземпляром правил, которые включали бы и перенос остатков и будущий обмен (правила надо было бы делить на 2 экземпляра).
В итоге упростили схему обмена, таким образом:
План обмена создали, но только на стороне УПП, определили его состав согласно таблице статистики (из шага 1 см. выше) создали 1 узел для регистрации изменений.
Для выгрузки из УПП использовали обработку с опцией выбора узла обмена и с возможностью установки произвольных фильтров (что позволяло выгружать данные зарегистрированные на узле плана обмена, а также выполнять выгрузки данных за период и точечные догрузки). Выгрузка больших пакетов выполнялась по COM с очисткой регистрации на узле обмена выгруженных данных. В обработке прописали все нужные настройки по умолчанию для облегчения регулярных запусков. Запускали каждый день вечером.
Конвертации делить между разработчиками не стали, работа 2-ух программистов (красный остатки, синий обмен) велась в одной базе 1СКД2 над одним и тем же экземпляром правил.
Отмечу, в разработке очень помогла одна публикация коллег.
Объекты переносили из УПП длительный период. Важно было сохранить нумерацию. Ручное создание новых номеров в ЕРП было по многим типам запрещено. Также проработали нумерацию, чтобы где-то разделить префиксом, и в общем случае прописать продолжение нумерации объектов по закона УПП (в ЕРП убрать префиксы ЕРП 0000-, повторив работу нумерации УПП).
Пользователи проводили выверку данных объектов и ручную корректировку, и чтобы защитить их труд, т.е. уже проверенные и дозаполненные объекты от изменений ежедневного обмена, разработали расширение позволяющее пользователю точечно закрыть нужный документ от изменения обменом. Также в этом расширении можно было администратору указывать закрытые от обмена периоды и типы метаданных – это нужно было после закрытия месяца в ЕРП (запретить изменения данных месяца).
Итоги по шагу № 2
- Мы начали учет в ЕРП с января успешным переносом остатков. Регулярным обменом сняли нагрузку с пользователей по дублированию информации в обеих базах. Пользователи продолжали работать в УПП и проводили сверку своих объектов в ЕРП (частично дозаполняли данные, проверяли печатные формы, отчеты и тем самым учились понимать, как трансформировалась их система, адаптировались к интерфейсу). Финансисты проводили закрытия месяца, выявляя и принимая глобальные цифры, например, различия методик по себестоимости.
- Программисты подтянули хвосты по интеграциям и спокойно их подключили.
- Системные администраторы с нашей помощью и c помощью известной команды по подбору оборудования для 1С апгрейдили оборудование до нужной мощности.
Отказ от УПП произошел без стресса 1 апреля. Я это называю «на лайте». ))) Далее в течение нескольких месяцев шел процесс постепенного уменьшения поддержки со стороны нашей компании и вывод ИТ-отдела заказчика на самостоятельную поддержку своей системы ЕРП. К августу мы практически не участвовали в процессах закрытия и сопровождения.
- 1с
- erp-системы
- проект
- автоматизация предприятий
- внедрение 1с erp
- переход с упп на erp
- ERP-системы
- Управление разработкой
- Управление проектами
- 1С
Источник: habr.com
Ввод начальных остатков в 1С:ЗУП 8.3
Компании, которые работали определенное время без программы кадрового учета или принявшие решение, например, перенести данные из 1С:ЗУП 2.5 в 1С:ЗУП 3.1, нуждаются в настройке системы, после чего станет возможным введение остатков. Поэтому цель данной статьи — раскрыть вопрос внесения остатков, а также особенности настройки программы.
Введение начальных остатков. Когда нужно?
Вводить начальные остатки необходимо после создания организации и ведения ею хозяйственной деятельности до того, как произошло внедрение программы 1С:ЗУП — в данном случае имеют место остатки, а не только настройки системы.
Используем настройки расчета зарплаты и кадрового учета, где вводим данные по организациям, настраиваем учетную политику, заполняем производственный календарь и вносим данные в справочники.
Данные операции обязательны к выполнению, в противном случае система не будет работать корректно.
Меню “Все функции” в системе ЗУП 3.1
Меню “Все функции” могут воспользоваться все пользователи, для чего потребуется такая настройка:
В окне, которое откроется, присваиваем флаг “Отображать команду “Все функции””.
Данная команда дает возможность видеть все объекты конфигурации.
С помощью Ctrl + F находим нужный журнал документов или обработку по названию.
Помощник начальной настройки
Пройдя по следующим опциям “Все функции — Обработки — Помощник перехода с прежних программ” настраиваем основные параметры. Начальная страница “Помощник” позволяет осуществить перенос данных из программ, которые используются ранее.
Возможно переносить данные из других программ.
При работе в одной из таких программ, удобно использовать встроенную обработку переноса данных: сначала определяем необходимую конфигурацию, а потом выбираем ее из списка имеющихся баз.
В данном окне записывается имя пользователя и пароль. Перенос данных происходит автоматически, может быть долго, это нормально. Если невозможно напрямую подключиться к базе или база сильно доработана, желательно обратиться к специалистам за консультацией, чтобы не потерять важные данные.
Внесение остатков в 1С:ЗУП 8.3
Оформляем штатное расписание. Здесь используется документ “Утверждение штатного расписания”.
Определяем вид и размер начисления.
И наличие отпусков
Сотрудники
В справочнике “Физические лица” вносим данные по сотрудникам, создавая отдельные физлица. Документ “Начальная штатная расстановка” применяется для ввода как физлица, так и сотрудника. Для этого нажимаем “Показать все”, затем “Создать”. После этого будет предложено ввести список сотрудников, где нужно заполнить ФИО, пол, дату рождения, и затем сохранить.
Так физлица и сотрудники будут сгенерированы. В дальнейшем можно добавлять данные по физлицам.
Штатная расстановка
Из позиции штатного расписания подтягиваются данные по начислениям, по отпускам и по графику работы. Дату, когда сотрудник был принят на работу, нужно установить как дату приема вручную.
Договоры ГПХ
Документы вводятся с помощью “Договора (работы, услуги)” при наличии на предприятии работников по договору гражданско-правового характера.
Отпуск по уходу за ребенком
В данном аспекте используем одноименный документ.
Плановые удержания
Для того, чтобы ввести данные по удержаниям из зарплаты применяем документы “Исполнительный лист”.
Задолженность по зарплате
Здесь используем документ “Начальная задолженность по зарплате”. Переплата сотрудника отображается отрицательным значением.
Остатки по оценочным обязательствам
Для ввода начальной информации об остатках необходимо открыть документ “Резервы отпусков” в режиме “Корректировка остатков”. В “Обязательствах и резервах по сотрудникам” вводим суммы по каждому работнику по БУ и НУ. Данные в “Обязательствах и резервах текущего месяца” отображаются по подразделениям автоматически.
Данные для расчета по НДФЛ
Введение данных по вычетам, а в некоторых случаях и начальной задолженности на начало эксплуатации (при переходе в середине года) необходимо для расчета НДФЛ. Нажимаем “Налог на доходы” в справочнике “Сотрудники”.
Также важно внести информацию о доходах, в случае работы сотрудника в другом месте в учитываемый период. Вводим стандартные вычеты ( нажимаем “Ввести новое заявление на стандартные вычеты”) имущественные вычеты ( “Ввести заявление на вычеты”).
Документ “Операции учета НДФЛ” позволяет фиксировать доходы текущего года, подлежащие учету в форме 2-НДФЛ.
Если переход осуществляется в начале года, то нет необходимости вводить данные НДФЛ, но нужно заполнить все закладки по каждому виду исчисленного дохода за все месяцы, за которые начислялся НДФЛ. Проводим по каждому сотруднику, а при различных видах доходов, и по каждому виду доходов.
Данные, чтобы рассчитать средний заработок
Автоматический расчет неявок также необходимо учитывать. Тут анализируются данные для расчета среднего заработка, используемые при расчете отпусков, командировок и больничных. Стоит отметить достаточно непростой процесс, так как вводятся данные по начислениям сотрудникам и отработанное время за 2 последних года работы.
Первый способ — это введение данных по мере необходимости непосредственно в документ неявки.
Для ускорения процесса ввода данных, нужно заполнить производственный календарь и графики работы сотрудника за год, предшествующий году начала эксплуатации системы. Можно напечатать “Расчет среднего заработка” и проверить введенную информацию:
Эти данные остаются в системе и могут быть использованы в следующий раз.
Второй способ — введение данных всех сразу используя регистры. Регистр накопления “Данные о времени для расчета среднего” содержат информацию об отработанном времени, “Данные о начислениях для расчета среднего заработка” — сведения о начислениях в регистре накопления. В документа “Перенос данных” выбираем необходимые регистры, после чего вносим данные.
Стоит отметить трудоемкость этого способа при проведении вручную, поэтому проще использовать либо первый способ либо обратиться к нашим специалистам за помощью.
Источник: 42clouds.com
Настройка переноса данных из 1С:КА в 1С:БП
Перенос данных из 1С:Комплексная автоматизация в 1С:Бухгалтерия может понадобиться в разных случаях, например, когда КА претерпела некоторые доработки, возникли сложности с ее обновлением, а регламентированную отчетность сдавать нужно, при этом решение должно соответствовать требованиям законодательства
В этом случае внедрение 1С:Бухгалтерии и перенос остатков менее затратное мероприятие, чем регулярное обновление нетипового продукта. А если речь идет о постоянном обмене данными, то он обеспечит совместную работу менеджеров и бухгалтеров в одном пространстве, но таким образом, чтоб они не мешали друг другу.
Выполнять любой перенос данных стоит после завершения периода (например, квартала), когда все операции по регламенту уже были проведены. В процессе такой синхронизации будут использованы только штатные возможности программ – не придется что-либо скачивать и инсталлировать.
Какие данные можно перенести?
Согласно правилам обмена из 1С:Комплексная автоматизация в 1С:Бухгалтерия можно перенести следующие типы данных:
- Остатки денежных средств на счетах компании (бухучет и информационная база);
- Справочники;
- Документы.
При переносе остатков будут соблюдены правила обмена документами, которые использовались при вводе начальных справочников и остатков, а при переносе конкретных данных после ввода остатков будут соблюдены правила обмена документацией.
Вышеописанный процесс включает:
- Выгрузку данных из 1С:КА в файл с данными;
- Загрузку данных в виде полученного файла на 1С:БП.
Варианты переноса
Можно выделить 4 варианта переноса данных из КА в БП:
- Перенос данных за указанный временной отрезок. Если уже начался новый период и есть остатки, важно не забыть перенести и их;
- Перенос всей базы с вводом остатков в КА (если учет начался не в момент создания компании). Переноситься будут не документы ввода остатков, а исключительно информация по ним;
- Перенос документов по конкретным периодам (временным отрезкам). Такой обмен должен быть односторонним;
- Облегченные варианты переноса. Справедливы для случаев, когда нужно перенести, например, лишь несколько справочников.
Перенос данных из 1С:Комплексная автоматизация в 1С:Бухгалтерия пошагово
Предварительно нужно настроить и выгрузить данные из продукта 1С:Комплексная автоматизация, после чего выполнить загрузку данных в 1С:Бухгалтерия предприятия. Разберемся с каждым этапом подробнее. Отметим, что на нашем сайте вы можете найти подробную информацию о всех функциональных возможностях решения 1С:Комплексная автоматизация 2 в соответствующей статье.
Выгрузка данных из 1С:Комплексная автоматизация
В основном интерфейсе 1С:КА необходимо открыть меню «Сервис» – «Прочие обмены данными».
Окно включает 4 вкладки, но нас интересует «Выгрузка данных». Здесь необходимо отметить галочкой пункт «Выгрузка в файл обмена», после чего нужно загрузить файл с правилами обмена. Чуть ниже можно выбрать правила выгрузки данных.
После того как 1С:КА проанализирует правила выгрузки, будут заполнены таблицы с данными и параметры выгрузки. Все эти настройки при необходимости можно изменить до начала выгрузки. На вкладке «Параметры выгрузки» проверим, соответствуют ли установленные конфигурации учетным настройкам. Список этих параметров стоит изучить максимально внимательно, так как эти настройки выставлены по умолчанию и не всегда совпадают с вашими предпочтениями относительно выгрузки.
Касаемо периода выгрузки – здесь необходимо прописывать первое и последнее число того года, за который нужно получить выгрузку. Если вам нужны данные, например, за месяц, нужно просто прописать первое и последнее число этого месяца. Если база довольно большая и содержит много документов, пока не стоит выгружать «Справочники» и «Документы», так как обработка большого объема информации займет слишком много времени.
Чтобы максимально упростить процедуру обмена данными, лучше для начала отметить выгрузку «Учетной политики организации», в рамках которой будет выполнена выгрузка справочника «Организация».
Каждый документ из базы имеет свои правила выгрузки, но определенные элементы выгружаются вместе с дополнительными элементами (по ссылкам). И если в базе, в которую будет выполняться загрузка данных, будут прописаны лишь те элементы, которые используются для учета, то вышеописанный подход поможет убрать ненужные (неиспользуемые) справочники. Если же необходимо получить выгрузку с абсолютно всеми элементами из справочников, лучше выбирать правила выгрузки для таких справочников.
С переносом документов дела обстоят так же, как и с выгрузкой справочников: мы указываем период, за который мы хотим получить выгрузку данных, и отмечаем перечень документов, которые нужно получить.
После проверки всех данных можно переходить к следующему шагу обмена – отправке выгруженных данных в 1С:БП.
Загрузка данных в 1С:Бухгалтерия предприятия
В продукте 1С:Бухгалтерия предприятия необходимо открыть «Универсальный обмен данными в формате XML» и активировать вкладку «Загрузка данных».
По клику на значок «. » около поля «Имя файла для загрузки на сервер» указываем файл, который мы получили после выгрузки из 1С:КА, после чего нажимаем на кнопку «Загрузить данные». Как только процедура завершится, все полученные документы, справочники и прочие данные необходимо провести повторно. Чтобы выполнить эту операцию, перейдем в «Администрирование» – «Сервис».
Если в меню вашей 1С:Бухгалтерия нет «Группового перепроведения документов», этот пункт нужно активировать, для чего кликнуть по иконке в виде большой и маленькой шестеренки в панели «Администрирование», открыть раздел «Настройка действий», найти там необходимый пункт и отправить его на панель нажатием кнопки «Добавить».
Важные моменты при загрузке данных в 1С:БП
Учетные счета в 1С:БП должны быть правильно сформированы по отношению к регистрам бухгалтерии, поэтому важно правильно заполнить все авансы, траты, расчеты и т.д. Эти данные легко найти в 1С:БП, ведь они есть в самих документах. Но в 1С:КА используется другой алгоритм определения учетных счетов и показа документации в учете. При проведении счетов учета КА вызывает «Настройки отражения документов», где есть эти счета, и выводит их в виде списков по группам.
Чтобы импортировать в БП учетные счета из КА, можно использовать два метода переноса данных:
- Первый вариант. Учетный счет определяется так, как это было прописано в «Настройке отражения документов». Такой метод подразумевает следование своеобразному стандарту, который содержится в настройках и имеет данные для корректного отображения различных документов.
- Второй вариант используется, если проводки документа не соответствуют настройкам. Подразумевает перенос фактических учетных счетов, которые есть в документе. Метод позволяет добиться максимального соответствия информации из выгрузки КА.
Выбрать конкретный вариант переноса данных можно в пункте «Определять счета учета по данным БУ». Выставив значение «Нет» для конкретных типов счетов, можно использовать второй вариант из вышеописанных, а «Да» приведет к тому, что документы будут сопоставлены по стандартному алгоритму.
Если переносится номенклатура, для нее также задаем тип учетного счета. Определяются эти типы в настройках справочника «Группы финансового учета номенклатуры» или в «Порядке отражения номенклатуры в регламентированном учете».
Некоторые разновидности счетов прописываются в перенесенных документах, но не записываются в справочники. Чтобы все эти счета в будущем определялись автоматически, нужно выполнить настройку учетного счета в справочнике «Номенклатура». Задать учетные счета в 1С:Бухгалтерии можно:
- Путем разделения номенклатуры на различные группы с дальнейшим указанием учетного счета для каждой из этих групп или конкретной номенклатуры;
- Путем указания учетного счета для каждого типа номенклатуры.
Второй метод удобнее, поскольку так намного проще работать с данными в будущем. Кроме того, при помощи такого подхода можно будет разделить номенклатуры на группы по иным признакам (а не по учетному счету).
Если вы собираетесь использовать для переноса данных 1С:Синхронизацию данных между КА и БП, то номенклатура не будет разделена на группы.
В учете тип «Вид» для номенклатуры в 1С:Бухгалтерии и 1С:Комплексной автоматизации имеет различное предназначение. Если в КА он – классификатор для объединения номенклатур в группы по определенным признакам, то в БП он определяет, считается номенклатура услугой или нет. Поэтому стоит использовать «Вид» номенклатуры исключительно для установки учетных счетов этой номенклатуры.
Еще один важный параметр, на который нужно обращать внимание при переносе видов номенклатуры — «Не преобразовывать справочник Виды номенклатуры». Он позволяет переключаться между двумя методами переноса:
- Если параметр не активен, то в процессе переноса номенклатуры справочник «Виды» будет иметь элементы, которые отсутствуют в 1С:Комплексной автоматизации.
- При активном параметре генерируемый вид номенклатуры будет соответствовать учетному счету, который прописан в настройках для конкретного вида номенклатуры.
При втором варианте название номенклатурного вида будет соответствовать названию учетного счета, на базе которого он был сформирован. В 1С:Бухгалтерии предприятия абсолютно все номенклатурные виды, созданные и сгенерированные в процессе переноса данных, автоматически заносятся в справочник «Виды номенклатуры». У каждой номенклатуры, которая в КА имела принадлежность к «Группе финансового учета номенклатуры», будет один из видов, созданных ранее. В будущем эти виды можно будет менять в меню «Счета учета» или «Виды номенклатуры». Но при таком решении номенклатурные группы останутся теми же.
Наши специалисты настраивают любые обмены данными с 1С:Бухгалтерия, а также другими решениями 1С и сторонних разработчиков. Если у вас возникли вопросы в части интеграции, звоните нам или оставляйте заявку на сайте. Мы обязательно вам поможем!
Особенности переноса различных данных из 1С:КА в 1С:БП
Стоит отдельно разобраться с переносом некоторых данных:
- Цены номенклатуры;
- Платежные поручения на уплату налогов;
- Остатки по регистрам УСН;
- Зачет авансов;
- Отчет о розничных продажах.
Перенос номенклатурных цен
Цены номенклатуры записаны в соответствующем регистре «Цены номенклатуры», который есть как в 1С:Бухгалтерия предприятия, так и в 1С:Комплексная автоматизация. Регламенты этих цен находятся регистре сведений.
Ценовые значения в процессе обмена данными отправляются в виде:
- Остатков на конкретный временной отрезок;
- Изменений цен за указанный период.
Группирование остатков цен номенклатуры выполняется в 1С:Бухгалтерии по типу цены, так как в документе «Установка цен номенклатуры» для этого параметра отведен лишь один тип. Поэтому все документы, в которых имеются остатки цен, будут иметь аналогичные значения по типам цен в 1С:Комплексная автоматизация. А число документов, которые показывают динамику изменения цены номенклатуры, может быть разным как в БП, так и в КА, ведь в КА они могут иметь одновременно несколько типов. Исходя из этого, документальные номера могут не совпадать (кроме дат) и для максимальной простоты ссылки на документы из КА прописаны в комментариях к документам в БП. Таким образом, один документ «Установка цен номенклатуры» может одновременно соответствовать разным документам цен в БП.
Перенос поручения для уплаты налогов
Если платежные поручения имеют тип операции «Перечисление налога», то для них в обязательном порядке нужно прописать реквизиты:
- Кто составил;
- КБК и т.д.
При этом структуры таких платежных поручений неодинаковы в 1С:Бухгалтерии и 1С:Комплексной автоматизации, так как в БП некоторые из таких реквизитов обозначены в отдельном справочнике – «Видах налогов и платежей в бюджет». Ссылка на этот справочник будет находиться в поручении платежа. Также в «Видах налогов и платежей в бюджет» есть несколько элементов, которые могут быть внесены в базу в будущем (например, в процессе редактирования политики учета). А во время выгрузки или загрузки этого документа элементы справочника будут брать из КБК, чтобы сопоставить платежное поручение и реквизит «Налог». Поэтому лучше всего при переносе политики учета сразу же выполнять проверку всех налогов, которые прописаны в справочнике, и при необходимости дополнять их данными, чтобы избежать проблем в будущем.
Важные моменты при переносе остатков по УНС
Если предприятие работает согласно упрощенной налогооблагаемой системе, где в качестве объекта налога принимается доход, из которого вычтен расход, то остатки в регистре «Расходы при УСН» необходимы для правильного расчета налога в будущем. Если же есть списанная номенклатура, которая имеет цены, ранее фигурировавшие в расходах при УСН, и какое-либо правило для признания расхода УСН не соблюдено, остаток будет выведен в форме «Ввод остатков» и иметь тип операции «Прочие расходы налогового учета УНС и ИП».
Чтобы максимально корректно перенести остатки этих непризнанных расходов на покупку продукции, которая имеет разную цену в налоговом и бухгалтерском учете, можно воспользоваться настройкой «Отражать остатки по расходам УНС отдельно от остатков БУ». Активировав этот параметр, система сгенерирует дополнительные документы типа «Ввод остатков» для указания разных значений в расходах при УСН и бухгалтерии компании.
Обмен 1С:КА с 1С:Бухгалтерия
Настроим регулярный обмен для ведения регламентированного учета в 1С:Бухгалтерия. Гарантия на услуги
Источник: wiseadvice-it.ru