Обратный звонок
Отправляя данные, вы соглашаетесь на обработку персональных данных
Переход с 1С 7.7 на 1С 8 и УТ 11
Изначально клиент к нам обратился за покупкой наших коробочных решений под отдельные задачи (рабочее место менеджера по продажам, логистика).
В процессе общения выяснилось, что клиент находится на этапе подготовки перехода с их существующей системы на базе 1С старой версии 7.7 на новую версию 1С 8Управление торговлей и выбирает подрядчика для реализации этого проекта. После предварительного общения стало понятно, что мы можем реализовать этот проект в приемлемые сроки и бюджет.
Проект начался в июле 2023 г.
В процессе общения выяснилось, что клиент находится на этапе подготовки перехода с их существующей системы на базе 1С старой версии 7.7 на новую версию 1С 8Управление торговлей и выбирает подрядчика для реализации этого проекта. После предварительного общения стало понятно, что мы можем реализовать этот проект в приемлемые сроки и бюджет.
Проект начался в июле 2023 г.
Зачем переходить с 1С 7.7 на 1С 8?
Минусы системы на базе платформы 1С 7.7:
Минусы системы на базе платформы 1С 7.7:
- сложно поддерживать (мало специалистов ее знают, изменения в законодательстве не поддерживаются)
- медленно работает
- сложно проводить интеграции с различными сервисами (маркетплейсы, интернет-магазины, маркировка товаров)
Цель проекта
✔ Переход на современную учетную систему
1С УТ 11 по сути является отраслевым стандартом и для нее существует множество готовых плагинов и доработок под различные задачи и интеграции
1С УТ 11 по сути является отраслевым стандартом и для нее существует множество готовых плагинов и доработок под различные задачи и интеграции
Этапы проекта
Обследование и моделирование
2 месяца (июль-август) / 150 часов.
Программирование
3 месяца (сентябрь-ноябрь) / 500 часов
Тестирование и обучение
1 месяц (декабрь) / 100 часов
Запуск в эксплуатацию
2 месяца (январь-февраль) / 300 часов
Оперативная техническая поддержка
2 месяца (март-апрель) / 150 часов
1
Сделали предварительное обследование по всем бизнес-процессам клиента
- Закупки
- Импортные - Учет ГТД
- Российские
- Механизм планирования закупок
- Продажи
- Крупные сетевые магазины
- Мелкий опт
- Маркетплейсы
- Интернет-магазин
- Складской учет
- Интеграция с WMS системой на базе 1С
- Механизм контроля идентичности данных в учетной системе и WMS
- Механизм сборки/разборки товаров на комплектующие
- Управленческая отчетность
- Расчет сдельной части ЗП для сотрудников
- Сервисная служба
- Заявки на запчасти от сервисных центров
- Выполнение ремонтов
- Другое
- Интеграция с системой 1С Бухгалтерия
- Механизм переноса данных из старой учетной системы
2
Составили предварительный график работ по проекту
3
В сентябре 2023 г. начали дорабатывать недостающий функционал
4
В ноябре начали проводить сквозные тестирования всего функционала системы
- Проверяли корректность переноса данных из старой системы
- Отражали все обычные операции, которые делали в старой системе в новой и смотрели как они отражаются в учете
- В тех местах, где типовой функционал оказывался не удобным или сложным, придумывали способы для упрощения, не ломая типовой логики работы программы, или меняли процессы в компании, чтобы они лучше ложились на типовой функционал программы
- Тестировали обмены данными:
— маркетплейсы
— ЭДО
— сайт
— бухгалтерия
5
Под конец декабря весь основной функционал, необходимый для запуска, был подготовлен и протестирован
- Запуск новой системы был запланирован на 31.12.23, когда пройдут последние отгрузки на складе
- Был составлен подробный чек-лист, кто, что и когда делает и проверяет. Это нужно было, т.к. на старой системе было завязано множество интеграций с внешними системами, каждую из которых надо отключить от старой системы и переключить на новую. Сделать это нужно было максимально оперативно и слаженно, т.к. через управленческую систему проходит более 2000 заказов в день, то любые задержки и ошибки очень болезненно отражаются на работе компании.
- В новогодние праздники интенсивность работы компании заметно снижается, поэтому и было выбрано это время
Сразу после переключения всех интеграций на новую базу в ней началась полноценная обработка заказов. Параллельно с этим велась активная работа по выверке данных в новой системе, чтобы убедиться, что ничего не забыли и все перенеслось правильно.
Тайминг запуска
19 декабря, вторник
- Протестировать обмен УТ11-WMS в рабочих базах
- Догрузка товаров из 7.7
- История изменения цен
- Сопоставление с товарами в WMS
- После этого в 1С 7.7 новые товары не создаются и цены не меняются
23 декабря, суббота
- Перепроведение 7.7 по партиям
26 декабря,
вторник
вторник
- Полностью подготовлена база УТ 11
- Настроены права доступа пользователей
- База очищена от лишних документов
- Настроены все основные рабочие места пользователей
- Написаны пользовательские инструкции для основных процессов
- К базе подключено торговое оборудование
27 декабря,
среда
среда
- Полная проверка всеми пользователями работоспособности программы
- Могут войти
- Видят все нужные данные в базе
28 декабря, четверг
- Контрагенты + торговые точки + договоры + банковские счета + номенклатура контрагентов
- Сопоставление справочников товаров и контрагентов с WMS
29 декабря, пятница
- Последние отгрузки клиентам
- Загрузка из 7.7
- Разделить документы ввода остатков по верхнему уровню иерархии в 77 контрагентов
30 декабря, суббота
1. Отключить обмены с 7.7 в 9.30
3. После 15.00 можно выгонять всех пользователей
5. Запуск загрузки данных из 7.7 из копии
6. Получить эксель со списком бронирования и загрузить в 1С
7. Отключить на сайте оформление новых заказов. Включаем 02.01.23
- Маркетплейсы
- Сайт
- WMS остается включенным
3. После 15.00 можно выгонять всех пользователей
- Отключить обмен 7.7 и WMS (16-00)
- Сделать копию рабочей базы (для загрузки в 11 и для выгрузки в БП)
5. Запуск загрузки данных из 7.7 из копии
6. Получить эксель со списком бронирования и загрузить в 1С
7. Отключить на сайте оформление новых заказов. Включаем 02.01.23
31 декабря, воскресенье
- Сверка остатков по складам после переноса.
- Подключить обмен WMS с новой базой (предварительно почистить очередь выгрузки из WMS в УТ, т.к. они накопятся)
- Подключить обмен с сайтом по заказам
- Загрузка из 7.7
- Остатки по партиям + свести их с остатками ГТД из Бухгалтерии (решили ГТД ввести вначале января)
- Остатки по складам
- Переданные на комиссии (данных в 7.7 еще не будет актуальных. загрузим их позже)
- Позже догрузить из 7.7
- Остатки по дням
- Загрузить резервы из Excel
- Включить обмен с Маркетплейсами
1 января, понедельник
- Тестирование функционала и обменов
- Сверка остатков
2 января, вторник
- В новую базу падают заказы с маркетплейсов и отгружаются в ней же (включить регл.задачу в 11 - в настройках есть константа о дате отсечки загрузки)
- В новую базу падают заказы с интернет-магазина. На сайте включить возможность оформлять заказы
4 января, четверг
- Отгрузка в маркетплейсы
5 января, пятница
- Бухгалтерия выдает остатки по ГТД по данным БП, которые мы используем при загрузке данных из 7.7
6 января, суббота
- Отгрузка в маркетплейсы
9 января, вторник
- В базу падают заказы из интеграций и обрабатываются там
- ЭДО
- Сайт
- Все пользователи могут выполнять свои повседневные дела
10 января, среда
- Начало обмена данными за 24 год между УТ и базами БП
Хотите получить консультацию?
Оставьте заявку, с вами свяжется менеджер и ответит на все вопросы
Первые дни после старта работы в новой базе всегда очень напряженные. У сотрудников возникает много вопросов по функционалу, т.к. в реальной жизни всегда вылезают не стандартные моменты, которых не было при тестировании и обучении. Поэтому приходилось постоянно находиться на связи и помогать пользователям.
В течение первых 2-х недель все "пожары" были потушены и начали копиться новые вопросы, которые были не очевидны вначале пути. Их оперативно разбирали, решали как с ними быть, находили типовые решения или дорабатывали недостающий функционал. На это ушло еще около 3-х месяцев в обычном режиме работы.
После того, как первичный контур учета более менее успокоился и стал работать в штатном режиме, внимание переключили на правильность учета в системе и управленческую отчетность. Начали закрывать месяца, считать себестоимость товаров. На этом этапе стали вылезать множество ошибок, которые на первый взгляд были не видны в базе. С каждыми типами ошибок разбирались отдельно, находили их причины (технические, организационные или человеческие) и пытались устранять. Процесс двигался не очень быстро из-за большого объема документов в базе. Пока устраняли одни ошибки, в базе начинали копиться другие. К весне удалось более менее выправить ситуацию с ошибками в базе и работа системы началась в штатном режиме.
В течение первых 2-х недель все "пожары" были потушены и начали копиться новые вопросы, которые были не очевидны вначале пути. Их оперативно разбирали, решали как с ними быть, находили типовые решения или дорабатывали недостающий функционал. На это ушло еще около 3-х месяцев в обычном режиме работы.
После того, как первичный контур учета более менее успокоился и стал работать в штатном режиме, внимание переключили на правильность учета в системе и управленческую отчетность. Начали закрывать месяца, считать себестоимость товаров. На этом этапе стали вылезать множество ошибок, которые на первый взгляд были не видны в базе. С каждыми типами ошибок разбирались отдельно, находили их причины (технические, организационные или человеческие) и пытались устранять. Процесс двигался не очень быстро из-за большого объема документов в базе. Пока устраняли одни ошибки, в базе начинали копиться другие. К весне удалось более менее выправить ситуацию с ошибками в базе и работа системы началась в штатном режиме.
Интересные технические решения
1
Резервирование под направления деятельности
Удобного решения в типовом функционале для этого нет. Суть в том, что ходовые товары почти всегда в дефиците на складе. Поэтому когда приходят новые поставки необходимо сразу распределить их под конкретных крупных клиентов под маркетплейсы
Причем разные направления имеют разные приоритет. Т. е., например, на маркетплейсах есть штрафы за отказы по заказам, поэтому у них самый высокий приоритет. Когда приходит заказ с маркетплейса то сначала смотрятся свободные остатки по группе резервирования Маркетплейсы. Если там нет, тогда проверяются свободные остатки и если они есть, берутся из них. Если и там нет, тогда можно взять из группы для крупных клиентов (т.к. эти резервы не под конкретные заказы, а по сути предварительные, которые прописываются в соглашениях с ними без четкой даты отгрузки), Причем для каждого конкретного клиента приоритеты отбора по группам могут быть разными.
Сильно ломать типовой функционал не хотелось, поэтому стали думать как реализовать это «малой кровьюˮ.
Сильно ломать типовой функционал не хотелось, поэтому стали думать как реализовать это «малой кровьюˮ.
Решили использовать типовой функционал резервирования под назначение с небольшой его доработкой
- Суть в том, что «Назначение» — это отдельный справочник, который создается системой автоматически. И это назначение уже указывается в документах движения товаров и резервирует товар. Мы убрали проверку на обязательное заполнение заказа в карточке назначения и под каждую группу резервирования сделали руками отдельный элемент справочника «Назначение».
- Далее типовым документом «Корректировка назначения» менеджеры ставили в нужные товары под группы резервирования (назначения) или снимали эти резервы
- В карточке партнера добавили вкладку с таблицей порядка резервирования
- При поступлении заказа от клиента выполняется резервирование товаров на складе и при необходимости автоматически создаются документы "Корректировка назначения", которые снимают резерв с назначения и ставят на свободный остаток и текущий заказ сразу “подбираетˮ этот резерв
- В такой схеме проблемы возникают только если заказ клиента отменяется или изменяется. В этих случаях сложно реализовать четкую логику возврата резерва под назначение. Но таких случаев в общем объеме мало и ими решили пренебречь
2
Торговые точки
- Суть задачи сводится к тому, что есть клиенты, у которых много торговых точек. У этих точек могут быть одно и тоже юр.лицо (контрагент) или разные, одинаковые реквизиты для оплаты или разные и т.д.
- Перебрав все типовые способы, доступные в УТ 11 поняли, что удобных простых механизмов нет. Поэтому пришлось сделать новый справочник Торговые точки, подчиненный справочнику Партнеры. В карточке торговой точки указываются все необходимые данные (юр.лицо/контрагент, адрес доставки, реквизиты для оплаты, грузополучатель для печати ТТН и прочая информация
- В документе Заказ клиента добавили соответствующее новое поле. Менеджер может выбрать сразу торговую точку, а партнер, контрагент и прочая информация подставляется автоматически. Это оказалось очень удобным в работе
Неожиданные сложности на проекте
- Оказалось, что в версии УТ 11.5.12 не реализован ввод начальных остатков комиссионного товара по новой схеме учета 2.5. Т. е. весь документооборот был переделан под новую схему, а остатки ввести по этой схеме нельзя. В результате пришлось немного схитрить.
Оприходовали товар как свой на обычный склад и затем сразу передали его на комиссию типовым функционалом. - Оказалось, что на релизе, который мы поставили изначально при начале проекта были проблемы с расчетом себестоимости. Долго бились об стену пытаясь понять почему она у нас не считается, пока не решили обновиться до последнего актуального релиза. После чего все начало считаться. Потратили на это много сил и нервов зря.
- Изначально, когда делали интеграцию с WMS не предусмотрели хорошей системы контроля того, чтобы в обоих системах были идентичные
данные. В результате на начальном этапе, когда было много ошибок в учете, отмены документов в УТ и прочих проблемах, которые усугубляются большим количеством документов, поняли, что данные в системах начали разъезжаться с угрожающей скорость. Хорошо, что на этапе проектирования был сделан подробный лог всех ответов от WMS системы, где она присылает данные что конкретно там было обработано по позициям товаров. В УТ сделали отдельные документы зеркальные для основных операций в WMS и заполнили их по историческим данным из логов. Это позволило в УТ построить отчеты, к которых сразу было видно все расхождения по документам-распоряжениям (которые в УТ формируются и отправляются в WMS) и документы-подтверждения (которые присылает WMS после факта отбора или отгрузки товара на складе). Это позволило оперативно исправить ошибки и стабилизировать работу двух систем вместе.
Результаты проекта
- 10 месяцеввнедрение проекта длилось с июля по апрель
- 1200 часовобщий бюджет проекта
- 40рабочих мест 1С
- ≈6000документов в день оформляется в системе
На текущий момент с клиентом работаем по договору технической поддержки.
В результате заказчик получил:
В результате заказчик получил:
- современную учетную систему, которая отвечает всем текущим запросам
- учетная система поддерживается вендором (1С) в соответствии с законодательными требованиями
- повышение скорости разработки функционала системы под новые бизнес задачи
Предлагаем посмотреть наши готовые решения:
Проектное внедрение 1С
Комплекс работ, в результате которых приобретенная «коробка» 1С с типовой конфигурацией превращается в эффективную информационную систему, обеспечивающую ведение учета с учетом специфики вашей компании
Попробуйте бесплатно весь функционал системы в демонстрационной тестовой базе 1С!
Быстрый запуск за 1 рабочий день
Оптимизированный пользовательский интерфейс
Есть демо-версия, можно протестировать весь функционал
Получить демо-доступ
Укажите адрес электронной почты и мы отправим вам параметры подключения к тестовой базе 1С.
Отправляя данные, вы соглашаетесь на обработку персональных данных