Реализованные проекты
Какое решение выбрать для автоматизации магазина, если места в кассовой зоне мало? Как внедрить маркировку ювелирных изделий? Почему лучше использовать сканер штрихкодов, даже если в кассе есть встроенная камера? Об этом рассказываем в кейсе автоматизации музейно-храмового комплекса.
С музейно-храмовым комплексом Вооружённых сил Российской Федерации сотрудничаем с 2021 года — сопровождаем 1С. Но в этом кейсе расскажем, как мы автоматизировали торговые точки заказчика.
В октябре 2022 года клиент решил заменить онлайн-кассы Атол Sigma, которые использовал в 5 торговых точках с сувенирной продукцией, потому что у кассовых аппаратов Атол односторонняя синхронизация с 1С. Это значит, что выгрузить продажи с кассы можно, но загрузить новые данные из 1С в кассу уже не получится.
Второй раз клиент обратился к нам в июне 2023 года, когда открывал новую торговую точку с ювелирной продукцией. Нужно было настроить онлайн-кассу под ключ и наладить работу с маркировкой, потому что с 1 марта 2022 года запрещено продавать изделия из драгоценных металлов без маркировки.
Какие задачи перед нами стояли
Найти альтернативное решение для замены онлайн-касс Атол в торговых точках с сувенирной продукцией.
Подобрать решение для автоматизации в торговой точке с ювелирными изделиями.
Настроить работу с маркировкой ювелирных изделий.
Что сделали
Автоматизировали торговые точки с сувенирной продукцией
Когда заказчик работал с онлайн-кассами Атол Sigma, он пользовался браузерной учётной системой Атол, её функционала не хватало, поэтому решили перейти на 1С, но учётной системы на 1С ещё не было.
Поэтому сначала нам нужно было подобрать программу 1С, которая удовлетворяла бы потребности клиента. Мы предложили 1С:Розница, потому что она позволяет вести продажи, товарный учёт, управлять складом и анализировать эффективность как отдельного магазина, так и розничной сети. И опыт работы с 1С:Розница в похожих проектах доказал удобство этого решения.
Дальше нужно было подобрать замену онлайн-кассам Атол Sigma.
В точках продаж мало места, поэтому развернуть полноценное рабочее место кассира было невозможно. Потому что кроме кассы понадобился бы стационарный компьютер с установленной программой 1С. При этом для каждой торговой точки пришлось бы покупать дополнительную лицензию.
Поэтому мы выбрали онлайн-кассу Эвотор СТ2Ф: компактная касса, в которой как и в Атол своя учётная система, но при этом обмен с 1С двухсторонний через облако.
Например, добавили новую номенклатуру в 1С:Розница или поменяли стоимость товаров и по кнопке выгрузили в облако. Из облака также по кнопке, но уже на кассе, все изменения загрузились в учётную систему Эвотор.
Эвотор СТ2Ф
Приложение Эвотор для обмена с 1С
И последний этап по этой задаче — настройка онлайн-касс под ключ.
Купили онлайн-кассы Эвотор СТ2Ф.
Зарегистрировали их в налоговой.
Зарегистрировали в личном кабинете оператора фискальных данных.
Активировали коды ОФД, которые позволяют отправлять данные о продажах в налоговую.
Установили и настроили на кассе все необходимые для работы приложения.
Настроили синхронизацию 1С:Розница и онлайн-касс Эвотор СТ2Ф.
За 4 дня мы перевели работу 5 торговых точек с онлайн-касс Атол Sigma на онлайн-кассы Эвотор и настроили обмен с учётной системой 1С:Розница. Позже в 2 торговых точках решили поставить дополнительные кассы.
На данный момент в музейно-храмовом комплексе работает 7 касс, все они управляются с одного компьютера, на котором установлена 1С:Розница. В этом решении дополнительные клиентские лицензии 1С не понадобились.
Эвотор СТ2Ф в торговой точке с сувенирной продукцией
Подобрали решение для автоматизации торговой точки с ювелирной продукцией
Нужна была касса на том же ПО, что и кассы в сувенирных магазинах, но с возможностью работать через кабель, а не через Wi-Fi, потому что интернет-соединение через кабель надёжнее.
Мы предложили Эвотор СТ3Ф, потому что в ней:
Есть отдельный Ethernet порт — даёт доступ в интернет через кабель;
Есть 4 аккумулятора — онлайн-касса может работать без электричества до 14 часов. Это важно, потому что при продаже маркированной продукции нужно обязательно отсканировать код Data Matrix, чтобы потом отправить данные в ГИИС ДМДК (Государственная интегрированная информационная система в сфере контроля за оборотом драгоценных металлов, драгоценных камней и изделий из них).
То есть даже без электричества и интернета Эвотор СТ3Ф отсканирует код Data Matrix, проведёт продажу и выдаст чек.
В комплект к онлайн-кассе мы предложили сканер штрих-кодов Honeywell 1450G.
Да, в Эвотор СТ3Ф есть встроенная фронтальная камера, но:
она считывает только одномерные коды, например, штрихкоды, а коды Data Matrix, которые используют для маркировки ювелирных изделий, двухмерные,
даже одномерные коды сканер считывает точнее, чем встроенная камера,
для того, чтобы использовать встроенную камеру для сканирования кодов, нужно подключить платное приложение от Эвотор.
Эвотор СТ3Ф
Настроили работу с маркировкой ювелирных изделий
Раньше у нас не было опыта работы с маркировкой ювелирной продукции. Поэтому мы с нуля изучали работу ГИИС ДМДК и требования к продавцу ювелирными украшениями.
Хотелось найти такое решение, при котором не пришлось бы докупать лишнего оборудования или программ. Обратились к разработчикам Эвотор и выяснили, что у них есть приложение для работы с ювелирной продукцией, поэтому остановились на этом варианте.
Как строится работа с ГИИС ДМДК
Поставщик отправляет накладную в ГИИС ДМДК, например, 500 крестиков из серебра: наименование и уникальный идентификационный номер (УИН).
Покупатель, в нашем случае музейно-храмовый комплекс, получает эту продукцию в своей точке продаж: всё сверяет и взвешивает.
Если всё верно, то покупатель заходит в свой личный кабинет в ГИИС ДМДК и подписывает накладную электронной подписью, то есть принимает товар.
Из ГИИС ДМДК выгружает номенклатуру в Эвотор.
После синхронизации с 1С данные о новой накладной попадают в 1С:Розница.
Сложность была в том, что файл с номенклатурой, который выгружался из ГИИС ДМДК не получалось сразу загружать в учётную систему Эвотор.
Поэтому мы разработали шаблон Excel, в который сотрудники музейно-храмового комплекса переносят данные из ГИИС ДМДК: наименование и УИН. А потом загружают этот файл в Эвотор. То есть приводят данные из ГИИС ДМДК в такой вид, который Эвотор может считать. Разработчики планируют автоматизировать этот процесс, но точные сроки пока неизвестны.
Список номенклатуры в учётной системе Эвотор
Так выглядят кассовые чеки в учётной системе Эвотор
Раз в 3 дня нужно подавать в ГИИС ДМДК данные о проданных ювелирных изделиях. Для этого нужно:
сформировать отчёт для ювелиров в учётной системе Эвотор: там указаны проданные позиции с наименованием и УИН.
отправить этот отчёт в ГИИС ДМДК по кнопке из Эвотор.
К 2024-2025 годам планируют разработать УТМ (Универсальный транспортный модуль), который будет автоматически отправлять данные о продажах ювелирной продукции в ГИИС ДМДК.
Отчёт по продажам за смену, где прошла успешная передача информация о выбытии товара
После обращения к нам Музейно-храмовый комплекс Вооружённых сил Российской Федерации получил:
готовую к работе онлайн-кассу Эвотор СТ3Ф и сканер для считывания штрихкодов, которые соответствовали их требованиям: доступ в интернет через кабель, возможность работы без электричества, работа с маркировкой;
настроенные алгоритмы взаимодействия с ГИИС ДМДК: синхронизированное с ГИИС ДМДК приложение Эвотор, шаблон документа для выгрузки данных из ГИИС ДМДК в Эвотор;
двусторонний обмен учётной системы Эвотор и 1С:Розница.
Эвотор СТ3Ф в торговой точке с ювелирной продукцией
Какое решение выбрать для автоматизации магазина, если места в кассовой зоне мало? Как внедрить маркировку ювелирных изделий? Почему лучше использовать сканер штрихкодов, даже если в кассе есть встроенная камера? Об этом рассказываем в кейсе автоматизации музейно-храмового комплекса.
С музейно-храмовым комплексом Вооружённых сил Российской Федерации сотрудничаем с 2021 года — сопровождаем 1С. Но в этом кейсе расскажем, как мы автоматизировали торговые точки заказчика.
В октябре 2022 года клиент решил заменить онлайн-кассы Атол Sigma, которые использовал в 5 торговых точках с сувенирной продукцией, потому что у кассовых аппаратов Атол односторонняя синхронизация с 1С. Это значит, что выгрузить продажи с кассы можно, но загрузить новые данные из 1С в кассу уже не получится.
Второй раз клиент обратился к нам в июне 2023 года, когда открывал новую торговую точку с ювелирной продукцией. Нужно было настроить онлайн-кассу под ключ и наладить работу с маркировкой, потому что с 1 марта 2022 года запрещено продавать изделия из драгоценных металлов без маркировки.
Какие задачи перед нами стояли
Найти альтернативное решение для замены онлайн-касс Атол в торговых точках с сувенирной продукцией.
Подобрать решение для автоматизации в торговой точке с ювелирными изделиями.
Настроить работу с маркировкой ювелирных изделий.
Что сделали
Автоматизировали торговые точки с сувенирной продукцией
Когда заказчик работал с онлайн-кассами Атол Sigma, он пользовался браузерной учётной системой Атол, её функционала не хватало, поэтому решили перейти на 1С, но учётной системы на 1С ещё не было.
Поэтому сначала нам нужно было подобрать программу 1С, которая удовлетворяла бы потребности клиента. Мы предложили 1С:Розница, потому что она позволяет вести продажи, товарный учёт, управлять складом и анализировать эффективность как отдельного магазина, так и розничной сети. И опыт работы с 1С:Розница в похожих проектах доказал удобство этого решения.
Дальше нужно было подобрать замену онлайн-кассам Атол Sigma.
В точках продаж мало места, поэтому развернуть полноценное рабочее место кассира было невозможно. Потому что кроме кассы понадобился бы стационарный компьютер с установленной программой 1С. При этом для каждой торговой точки пришлось бы покупать дополнительную лицензию.
Поэтому мы выбрали онлайн-кассу Эвотор СТ2Ф: компактная касса, в которой как и в Атол своя учётная система, но при этом обмен с 1С двухсторонний через облако.
Например, добавили новую номенклатуру в 1С:Розница или поменяли стоимость товаров и по кнопке выгрузили в облако. Из облака также по кнопке, но уже на кассе, все изменения загрузились в учётную систему Эвотор.
Эвотор СТ2Ф
Приложение Эвотор для обмена с 1С
И последний этап по этой задаче — настройка онлайн-касс под ключ.
Купили онлайн-кассы Эвотор СТ2Ф.
Зарегистрировали их в налоговой.
Зарегистрировали в личном кабинете оператора фискальных данных.
Активировали коды ОФД, которые позволяют отправлять данные о продажах в налоговую.
Установили и настроили на кассе все необходимые для работы приложения.
Настроили синхронизацию 1С:Розница и онлайн-касс Эвотор СТ2Ф.
За 4 дня мы перевели работу 5 торговых точек с онлайн-касс Атол Sigma на онлайн-кассы Эвотор и настроили обмен с учётной системой 1С:Розница. Позже в 2 торговых точках решили поставить дополнительные кассы.
На данный момент в музейно-храмовом комплексе работает 7 касс, все они управляются с одного компьютера, на котором установлена 1С:Розница. В этом решении дополнительные клиентские лицензии 1С не понадобились.
Эвотор СТ2Ф в торговой точке с сувенирной продукцией
Подобрали решение для автоматизации торговой точки с ювелирной продукцией
Нужна была касса на том же ПО, что и кассы в сувенирных магазинах, но с возможностью работать через кабель, а не через Wi-Fi, потому что интернет-соединение через кабель надёжнее.
Мы предложили Эвотор СТ3Ф, потому что в ней:
Есть отдельный Ethernet порт — даёт доступ в интернет через кабель;
Есть 4 аккумулятора — онлайн-касса может работать без электричества до 14 часов. Это важно, потому что при продаже маркированной продукции нужно обязательно отсканировать код Data Matrix, чтобы потом отправить данные в ГИИС ДМДК (Государственная интегрированная информационная система в сфере контроля за оборотом драгоценных металлов, драгоценных камней и изделий из них).
То есть даже без электричества и интернета Эвотор СТ3Ф отсканирует код Data Matrix, проведёт продажу и выдаст чек.
В комплект к онлайн-кассе мы предложили сканер штрих-кодов Honeywell 1450G.
Да, в Эвотор СТ3Ф есть встроенная фронтальная камера, но:
она считывает только одномерные коды, например, штрихкоды, а коды Data Matrix, которые используют для маркировки ювелирных изделий, двухмерные,
даже одномерные коды сканер считывает точнее, чем встроенная камера,
для того, чтобы использовать встроенную камеру для сканирования кодов, нужно подключить платное приложение от Эвотор.
Эвотор СТ3Ф
Настроили работу с маркировкой ювелирных изделий
Раньше у нас не было опыта работы с маркировкой ювелирной продукции. Поэтому мы с нуля изучали работу ГИИС ДМДК и требования к продавцу ювелирными украшениями.
Хотелось найти такое решение, при котором не пришлось бы докупать лишнего оборудования или программ. Обратились к разработчикам Эвотор и выяснили, что у них есть приложение для работы с ювелирной продукцией, поэтому остановились на этом варианте.
Как строится работа с ГИИС ДМДК
Поставщик отправляет накладную в ГИИС ДМДК, например, 500 крестиков из серебра: наименование и уникальный идентификационный номер (УИН).
Покупатель, в нашем случае музейно-храмовый комплекс, получает эту продукцию в своей точке продаж: всё сверяет и взвешивает.
Если всё верно, то покупатель заходит в свой личный кабинет в ГИИС ДМДК и подписывает накладную электронной подписью, то есть принимает товар.
Из ГИИС ДМДК выгружает номенклатуру в Эвотор.
После синхронизации с 1С данные о новой накладной попадают в 1С:Розница.
Сложность была в том, что файл с номенклатурой, который выгружался из ГИИС ДМДК не получалось сразу загружать в учётную систему Эвотор.
Поэтому мы разработали шаблон Excel, в который сотрудники музейно-храмового комплекса переносят данные из ГИИС ДМДК: наименование и УИН. А потом загружают этот файл в Эвотор. То есть приводят данные из ГИИС ДМДК в такой вид, который Эвотор может считать. Разработчики планируют автоматизировать этот процесс, но точные сроки пока неизвестны.
Список номенклатуры в учётной системе Эвотор
Так выглядят кассовые чеки в учётной системе Эвотор
Раз в 3 дня нужно подавать в ГИИС ДМДК данные о проданных ювелирных изделиях. Для этого нужно:
сформировать отчёт для ювелиров в учётной системе Эвотор: там указаны проданные позиции с наименованием и УИН.
отправить этот отчёт в ГИИС ДМДК по кнопке из Эвотор.
К 2024-2025 годам планируют разработать УТМ (Универсальный транспортный модуль), который будет автоматически отправлять данные о продажах ювелирной продукции в ГИИС ДМДК.
Отчёт по продажам за смену, где прошла успешная передача информация о выбытии товара
После обращения к нам Музейно-храмовый комплекс Вооружённых сил Российской Федерации получил:
готовую к работе онлайн-кассу Эвотор СТ3Ф и сканер для считывания штрихкодов, которые соответствовали их требованиям: доступ в интернет через кабель, возможность работы без электричества, работа с маркировкой;
настроенные алгоритмы взаимодействия с ГИИС ДМДК: синхронизированное с ГИИС ДМДК приложение Эвотор, шаблон документа для выгрузки данных из ГИИС ДМДК в Эвотор;
двусторонний обмен учётной системы Эвотор и 1С:Розница.
Эвотор СТ3Ф в торговой точке с ювелирной продукцией
23 июня 2023
Клиент: Музейно-храмовый комплекс Вооружённых сил Российской Федерации
Внедренный продукт: 1С:Розница
Отрасль: Бюджетные организации
Содержание:
В кейсе рассказываем, как работа с терминалами сбора данных сокращает ошибки при сборке, и в чём преимущество динамического адресного склада по сравнению со статическим адресным складом.
О заказчике
Наш клиент — магазин спортивных товаров go-to-sport, который продаёт костюмы для сноуборда, комбинезоны и куртки для горных лыж, одежду для плавания, фитнеса, спортивную обувь и аксессуары. Заказы поступают с сайта компании и с маркетплейсов. В базе около 10 000 номенклатурных позиций. В сезон на складе хранится до 300 000 товаров.
С go-to-sport мы сотрудничаем с 2019 года. За это время мы провели уже 3 волны автоматизации.
Первая волна автоматизации: внедрение статического адресного склада и работы с помощью сканеров
Сроки: 2021 год.
Адресный склад — когда все пространства для хранения товаров делятся на полки и ячейки. Каждому месту хранения присваивается свой адрес: штрихкод или символьное обозначение — цифры, буквы.
Статический адресный склад — когда за каждым товаром закреплено определённое место хранения на складе. Например, комбинезоны для горных лыж всегда хранятся в ячейке 001.
На складе компании адрес хранения был указан в описании товара, как дополнительный реквизит:
когда поступал товар, его сканировали,
описание товара выводилось на рабочее место кладовщика, где он видел, в какой ячейке хранится такой товар.
До автоматизации сотрудники склада работали только по бумажкам: получали распечатанную накладную, визуально сравнивали артикул из заказа и на товаре. Никакого контроля сборки не было.
После внедрения сканеров кладовщики продолжили работать с распечатанными заказами, но теперь сканировали штрихкод товара при сборке. Информация мгновенно оказывалась в 1С, и таким образом происходил контроль того, что собрал сотрудник.
Также в рамках первой волны мы:
перенесли базу с устаревшей версии Торговля и склад 7.7 на 1С:Управление торговлей 11.4,
интегрировали сайт и 1С:УТ,
автоматизировали работу с заказами: от клика клиента на сайте или маркетплейсе до оформления закрывающих документов.
Подробнее про этот этап мы уже писали здесь.
А в этом кейсе мы расскажем о второй и третьей волнах автоматизации: какие задачи стояли, что сделали, и как склад работает теперь.
Вторая волна автоматизации: переход со сканеров на терминалы сбора данных (ТСД)
Сроки: март 2022 года.
При работе со сканером информация попадала в базу, где менеджерам нужно было её обработать, создать соответствующие документы. Это трата рабочего времени сотрудников.
Поэтому решили перейти на ТСД:
не нужно распечатывать заказы — они отображаются непосредственно на экране терминала,
в терминале можно создавать документы прямо в процессе сборки, приёмки и инвентаризации, а не тратить на это время после завершения процесса,
если отсканировали не тот штрихкод, на ТСД выйдет сообщение об ошибке — полный контроль работы сотрудников на всех этапах.
Какой терминал сбора данных выбрали для работы?
Изначально закупили терминалы АТОЛ Smart.Slim Plus, потому что это легкий и недорогой аппарат. Мы уже работали с такими терминалами на других проектах и знали, что он удобен на складе — небольшой, поэтому легко помещается в карман и не мешает в процессе сборки, приёмки.
Также закупили терминалы АТОЛ Smart.Pro — они более защищённые, потому что оборудование должно выдерживать падения на бетонный пол. Такое часто происходит на складах.
Но кладовщикам больше понравилась компактная модель АТОЛ Smart.Slim Plus, поэтому во время новой закупки оборудования таких моделей было больше.
АТОЛ Smart.Pro и АТОЛ Smart.Slim Plus — тот, что меньше
Результат второй волны автоматизации
Практически устранили ошибки при сборке: кладовщик сканировал каждый товар из заказа. Даже если в заказе несколько единиц одного товара, он должен был просканировать всё, что берёт — мы заблокировали возможность вводить количество вручную.
Поэтому процесс сборки выглядел так:
кладовщик брал товар,
сканировал его штрихкод,
перемещал в коробку, в которую собирал весь этот заказ,
брал следующий товар и т.д.
Третья волна автоматизации: переход на динамический адресный склад
Сроки: ноябрь 2022 года — май 2023 года.
Динамический адресный склад — когда за товарами не закреплен конкретный адрес.
Стандартный алгоритм работы динамического адресного склада:
товар поступает на склад,
кладовщик определяет, в какую ячейку его разместить: по степени заполненности ячеек, по степени востребованности товара — чем чаще заказывают, тем ближе к зоне сборки заказов и т.д.
сканирует товар,
сканирует ячейку, куда он разместил товар,
в 1С отображается, что этот товар лежит в этой ячейке.
В статическом складе адрес товара был прописан в описании товара, как дополнительный реквизит: мы не могли посмотреть в 1С, какой товар лежит в ячейке, и сколько его — в базе не было разбивки на ячейки. Все товары поступали и отгружались с Основного склада, без детализации по местам хранения. Нельзя было сделать фильтр по реквизиту Адрес хранения.
В динамическом складе наоборот — 1С разбита на ячейки. Мы в любой момент можем посмотреть, что лежит в конкретной ячейке, и в каком количестве.
Почему решили перейти на динамический адресный склад?
При статическом хранении бывали ситуации, когда приходит много товара одного вида, места в выделенной для него ячейке не хватает и приходится размещать его в другие.
Дальше кладовщик должен был сообщить менеджеру, что такой товар лежит ещё и вот по этому адресу. А менеджер должен был внести эти данные в описание товара. И если кто-то что-то забыл, то поиск товара был длительным и сложным.
Не было возможности делать инвентаризацию по ячейке, только по всему складу. И если что-то где-то не сошлось с базой, то трудно найти ошибку.
Переход со статического адресного склада на динамический адресный склад
Все остатки в базе изначально были на Основном складе, нам нужно было перенести их на склад Адресное хранение, то есть на новую систему хранения. Поэтому в базе мы одновременно создали 2 склада: Основной и Адресное хранение. Физически у нас как был один склад, так и остался.
Мы сделали виртуальное перемещение с Основного склада на склад Адресное хранение:
сначала создали документ Перемещение товаров, где отправитель Основной склад, а получатель — Адресное хранение.
менеджер отсканировал весь товар на основном складе и на этом основании создал Приходный ордер — будто этот товар поступил на склад Адресное хранение,
дальше Приходный ордер выгрузился на терминал кладовщика, чтобы он разместил весь «поступивший» товар на складе Адресное хранение,
кладовщик второй раз прошёл с ТСД по складу: сканировал ячейку и товар в ней,
таким образом мы одновременно провели инвентаризацию и перемещение на склад Адресное хранение с закреплением товаров по адресам в 1С.
Переход на склад Адресное хранение — разовая операция, которая длилась около недели. При этом работа склада не останавливалась: отгружали товар с Основного склада, а принимали уже на склад Адресное хранение.
Как сейчас работает склад?
Сборка заказов
Менеджер генерирует в 1С этикетки с номером заказа и клеит их на собранные упаковки. В 1С менеджер видит номера заказов, которые нужно отправить в этот день, сканирует их и отгружает.
Приёмка товаров
Создаём Заказ поставщику,
Когда товары поступают, создаём на основании Заказа поставщику документ Приобретение товаров и услуг,
Если в нём указан склад Адресное хранение, документ автоматически выгружается на ТСД кладовщику,
Кладовщик сначала сканирует все товары, чтобы сверить количество с заказом,
Далее кладовщик переключается в режим Размещение и разносит товары по складу: сканирует ячейку и помещает в неё товар,
После завершения сборки в 1С выгружается Приходный ордер, который переводит товары в ячейку Приёмка,
На основании этого документа создается Отбор (размещение) товаров: документ перемещает товары из ячейки Приёмка в ячейки, которые отсканировал кладовщик при размещении товаров на складе.
Инвентаризация
Есть два варианта проведения инвентаризации:
Создаём вручную на ТСД:
кладовщик с ТСД создаёт документ,
сканирует выбранную ячейку и сканирует весь товар в ней,
и переходит к следующей ячейке,
после завершения кладовщик выгружает документ, и он автоматически создаётся в 1С,
менеджер оформляет все необходимые документы.
Создаём в 1С
менеджер создаёт инвентаризацию с заданным отбором и выгружает документ на ТСД вручную,
кладовщик получает задание на ТСД: сканирует товары и ячейки, где они находятся.
Создаём в 1С документ на инвентаризацию. Поскольку статус документа «В работе», он выгружается на ТСД.
Менеджер видит расхождение.
Инвентаризация перезаполняет количество «По факту» на загруженное с ТСД
Работа с возвратами
Один из каналов продаж — маркетплейсы. Часто бывают ситуации, когда заказ не подошёл и его возвращают. Поэтому мы разработали сценарий для работы с возвратами:
возвраты загружаются из маркетплейса на склад Возврата, чтобы они не выгружались снова на сайт, ведь если товар вернули, он может быть бракованный,
менеджер проверяет товар на брак,
если всё нормально, то менеджер создаёт документ Перемещение товара со склада Возврата на склад Адресное хранение,
на ТСД кладовщика приходит задание на возврат, где указаны товары и места, куда их нужно разместить,
товары размещаются в те ячейки, где лежат такие же товары, если таких товаров нет на складе, то кладовщик размещает их в любую свободную ячейку и сканирует её, чтобы показать 1С, где теперь хранится этот товар.
Результат автоматизации: переход на работу с ТСД и на динамическое адресное хранение
После внедрения динамического адресного хранения и перехода на ТСД:
ошибки при сборке практически свелись к нулю, потому что каждый товар в заказе проходит подтверждение сканированием,
сотрудники стали быстрее собирать заказы — теперь все документы оформляются в процессе складских операций, а не обрабатываются после их завершения,
инвентаризация стала проще и быстрее — теперь можно проводить инвентаризацию по ячейке, значит в 1С можно в любой момент времени посмотреть что и в каком количестве хранится в каждой ячейке,
можно отследить работу сотрудников — перед началом работы в ТСД все сотрудники авторизуются по логину и паролю, если заказ собрали с ошибкой, легко отследить, кто её допустил.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
Содержание:
В кейсе рассказываем, как работа с терминалами сбора данных сокращает ошибки при сборке, и в чём преимущество динамического адресного склада по сравнению со статическим адресным складом.
О заказчике
Наш клиент — магазин спортивных товаров go-to-sport, который продаёт костюмы для сноуборда, комбинезоны и куртки для горных лыж, одежду для плавания, фитнеса, спортивную обувь и аксессуары. Заказы поступают с сайта компании и с маркетплейсов. В базе около 10 000 номенклатурных позиций. В сезон на складе хранится до 300 000 товаров.
С go-to-sport мы сотрудничаем с 2019 года. За это время мы провели уже 3 волны автоматизации.
Первая волна автоматизации: внедрение статического адресного склада и работы с помощью сканеров
Сроки: 2021 год.
Адресный склад — когда все пространства для хранения товаров делятся на полки и ячейки. Каждому месту хранения присваивается свой адрес: штрихкод или символьное обозначение — цифры, буквы.
Статический адресный склад — когда за каждым товаром закреплено определённое место хранения на складе. Например, комбинезоны для горных лыж всегда хранятся в ячейке 001.
На складе компании адрес хранения был указан в описании товара, как дополнительный реквизит:
когда поступал товар, его сканировали,
описание товара выводилось на рабочее место кладовщика, где он видел, в какой ячейке хранится такой товар.
До автоматизации сотрудники склада работали только по бумажкам: получали распечатанную накладную, визуально сравнивали артикул из заказа и на товаре. Никакого контроля сборки не было.
После внедрения сканеров кладовщики продолжили работать с распечатанными заказами, но теперь сканировали штрихкод товара при сборке. Информация мгновенно оказывалась в 1С, и таким образом происходил контроль того, что собрал сотрудник.
Также в рамках первой волны мы:
перенесли базу с устаревшей версии Торговля и склад 7.7 на 1С:Управление торговлей 11.4,
интегрировали сайт и 1С:УТ,
автоматизировали работу с заказами: от клика клиента на сайте или маркетплейсе до оформления закрывающих документов.
Подробнее про этот этап мы уже писали здесь.
А в этом кейсе мы расскажем о второй и третьей волнах автоматизации: какие задачи стояли, что сделали, и как склад работает теперь.
Вторая волна автоматизации: переход со сканеров на терминалы сбора данных (ТСД)
Сроки: март 2022 года.
При работе со сканером информация попадала в базу, где менеджерам нужно было её обработать, создать соответствующие документы. Это трата рабочего времени сотрудников.
Поэтому решили перейти на ТСД:
не нужно распечатывать заказы — они отображаются непосредственно на экране терминала,
в терминале можно создавать документы прямо в процессе сборки, приёмки и инвентаризации, а не тратить на это время после завершения процесса,
если отсканировали не тот штрихкод, на ТСД выйдет сообщение об ошибке — полный контроль работы сотрудников на всех этапах.
Какой терминал сбора данных выбрали для работы?
Изначально закупили терминалы АТОЛ Smart.Slim Plus, потому что это легкий и недорогой аппарат. Мы уже работали с такими терминалами на других проектах и знали, что он удобен на складе — небольшой, поэтому легко помещается в карман и не мешает в процессе сборки, приёмки.
Также закупили терминалы АТОЛ Smart.Pro — они более защищённые, потому что оборудование должно выдерживать падения на бетонный пол. Такое часто происходит на складах.
Но кладовщикам больше понравилась компактная модель АТОЛ Smart.Slim Plus, поэтому во время новой закупки оборудования таких моделей было больше.
АТОЛ Smart.Pro и АТОЛ Smart.Slim Plus — тот, что меньше
Результат второй волны автоматизации
Практически устранили ошибки при сборке: кладовщик сканировал каждый товар из заказа. Даже если в заказе несколько единиц одного товара, он должен был просканировать всё, что берёт — мы заблокировали возможность вводить количество вручную.
Поэтому процесс сборки выглядел так:
кладовщик брал товар,
сканировал его штрихкод,
перемещал в коробку, в которую собирал весь этот заказ,
брал следующий товар и т.д.
Третья волна автоматизации: переход на динамический адресный склад
Сроки: ноябрь 2022 года — май 2023 года.
Динамический адресный склад — когда за товарами не закреплен конкретный адрес.
Стандартный алгоритм работы динамического адресного склада:
товар поступает на склад,
кладовщик определяет, в какую ячейку его разместить: по степени заполненности ячеек, по степени востребованности товара — чем чаще заказывают, тем ближе к зоне сборки заказов и т.д.
сканирует товар,
сканирует ячейку, куда он разместил товар,
в 1С отображается, что этот товар лежит в этой ячейке.
В статическом складе адрес товара был прописан в описании товара, как дополнительный реквизит: мы не могли посмотреть в 1С, какой товар лежит в ячейке, и сколько его — в базе не было разбивки на ячейки. Все товары поступали и отгружались с Основного склада, без детализации по местам хранения. Нельзя было сделать фильтр по реквизиту Адрес хранения.
В динамическом складе наоборот — 1С разбита на ячейки. Мы в любой момент можем посмотреть, что лежит в конкретной ячейке, и в каком количестве.
Почему решили перейти на динамический адресный склад?
При статическом хранении бывали ситуации, когда приходит много товара одного вида, места в выделенной для него ячейке не хватает и приходится размещать его в другие.
Дальше кладовщик должен был сообщить менеджеру, что такой товар лежит ещё и вот по этому адресу. А менеджер должен был внести эти данные в описание товара. И если кто-то что-то забыл, то поиск товара был длительным и сложным.
Не было возможности делать инвентаризацию по ячейке, только по всему складу. И если что-то где-то не сошлось с базой, то трудно найти ошибку.
Переход со статического адресного склада на динамический адресный склад
Все остатки в базе изначально были на Основном складе, нам нужно было перенести их на склад Адресное хранение, то есть на новую систему хранения. Поэтому в базе мы одновременно создали 2 склада: Основной и Адресное хранение. Физически у нас как был один склад, так и остался.
Мы сделали виртуальное перемещение с Основного склада на склад Адресное хранение:
сначала создали документ Перемещение товаров, где отправитель Основной склад, а получатель — Адресное хранение.
менеджер отсканировал весь товар на основном складе и на этом основании создал Приходный ордер — будто этот товар поступил на склад Адресное хранение,
дальше Приходный ордер выгрузился на терминал кладовщика, чтобы он разместил весь «поступивший» товар на складе Адресное хранение,
кладовщик второй раз прошёл с ТСД по складу: сканировал ячейку и товар в ней,
таким образом мы одновременно провели инвентаризацию и перемещение на склад Адресное хранение с закреплением товаров по адресам в 1С.
Переход на склад Адресное хранение — разовая операция, которая длилась около недели. При этом работа склада не останавливалась: отгружали товар с Основного склада, а принимали уже на склад Адресное хранение.
Как сейчас работает склад?
Сборка заказов
Менеджер генерирует в 1С этикетки с номером заказа и клеит их на собранные упаковки. В 1С менеджер видит номера заказов, которые нужно отправить в этот день, сканирует их и отгружает.
Приёмка товаров
Создаём Заказ поставщику,
Когда товары поступают, создаём на основании Заказа поставщику документ Приобретение товаров и услуг,
Если в нём указан склад Адресное хранение, документ автоматически выгружается на ТСД кладовщику,
Кладовщик сначала сканирует все товары, чтобы сверить количество с заказом,
Далее кладовщик переключается в режим Размещение и разносит товары по складу: сканирует ячейку и помещает в неё товар,
После завершения сборки в 1С выгружается Приходный ордер, который переводит товары в ячейку Приёмка,
На основании этого документа создается Отбор (размещение) товаров: документ перемещает товары из ячейки Приёмка в ячейки, которые отсканировал кладовщик при размещении товаров на складе.
Инвентаризация
Есть два варианта проведения инвентаризации:
Создаём вручную на ТСД:
кладовщик с ТСД создаёт документ,
сканирует выбранную ячейку и сканирует весь товар в ней,
и переходит к следующей ячейке,
после завершения кладовщик выгружает документ, и он автоматически создаётся в 1С,
менеджер оформляет все необходимые документы.
Создаём в 1С
менеджер создаёт инвентаризацию с заданным отбором и выгружает документ на ТСД вручную,
кладовщик получает задание на ТСД: сканирует товары и ячейки, где они находятся.
Создаём в 1С документ на инвентаризацию. Поскольку статус документа «В работе», он выгружается на ТСД.
Менеджер видит расхождение.
Инвентаризация перезаполняет количество «По факту» на загруженное с ТСД
Работа с возвратами
Один из каналов продаж — маркетплейсы. Часто бывают ситуации, когда заказ не подошёл и его возвращают. Поэтому мы разработали сценарий для работы с возвратами:
возвраты загружаются из маркетплейса на склад Возврата, чтобы они не выгружались снова на сайт, ведь если товар вернули, он может быть бракованный,
менеджер проверяет товар на брак,
если всё нормально, то менеджер создаёт документ Перемещение товара со склада Возврата на склад Адресное хранение,
на ТСД кладовщика приходит задание на возврат, где указаны товары и места, куда их нужно разместить,
товары размещаются в те ячейки, где лежат такие же товары, если таких товаров нет на складе, то кладовщик размещает их в любую свободную ячейку и сканирует её, чтобы показать 1С, где теперь хранится этот товар.
Результат автоматизации: переход на работу с ТСД и на динамическое адресное хранение
После внедрения динамического адресного хранения и перехода на ТСД:
ошибки при сборке практически свелись к нулю, потому что каждый товар в заказе проходит подтверждение сканированием,
сотрудники стали быстрее собирать заказы — теперь все документы оформляются в процессе складских операций, а не обрабатываются после их завершения,
инвентаризация стала проще и быстрее — теперь можно проводить инвентаризацию по ячейке, значит в 1С можно в любой момент времени посмотреть что и в каком количестве хранится в каждой ячейке,
можно отследить работу сотрудников — перед началом работы в ТСД все сотрудники авторизуются по логину и паролю, если заказ собрали с ошибкой, легко отследить, кто её допустил.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
8 июня 2023
Клиент: ИП Суханов А.А.
Внедренный продукт: 1С:Управление торговлей
Отрасль: Торговля
В кейсе рассказываем, как не стоит дорабатывать программы 1С, и в каких ситуациях лучше восстановить учёт, чем создавать его с нуля.
Содержание:
Управляющая компания ООО «Комплект Плюс» обратилась к нам, чтобы мы навели порядок в их программе 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Какие проблемы были в учёте
Жильцы в справочниках были прописаны по несколько раз из-за орфографических ошибок, двойных пробелов и т.д.
Например, есть жилец Иванов Александр Сергеевич. Один сотрудник опечатался и добавил его в базу не как Иванова, а как Ионова, другой сотрудник начал его искать, не нашёл и завёл новую карточку на Иванова А.С. Третий сотрудник снова не нашёл его в базе и добавил Иванова Александра Сергеевича.
Не было разделения прав доступа для разных сотрудников.
Например, сотрудники, плохо разбираясь в программе, могли случайно внести изменения в разделы, которые влияют на корректность формирования отчётов.
К тому же если не настроен вход под собственным логином и паролем, нельзя отследить, кто работал в программе, кто допустил ошибку. Можно было зайти в программу под чужой учётной записью и создать любые документы, внести корректировки и даже удалить.
База была снята с обновления.
Предыдущий программист вносил все изменения непосредственно в конфигурацию программы. Мы стараемся менять конфигурацию в самых редких случаях, а весь дополнительный функционал делаем в форме внешних обработок и приложений. Потому что программа остаётся типовой и обновляется легко и быстро.
Большое количество расширений.
Кроме изменённой конфигурации в программе было 10 расширений, за которыми было сложно следить и обновлять.
Неудобная иерархия в системе.
Предыдущие специалисты создали множество папок, которые казались сотрудникам УК ненужными, созданными по непонятной логике.
Задачи автоматизации
Восстановить учёт или создать базу с нуля, чтобы работа в программе была понятной и удобной.
Настроить базу с учётом всех пожеланий, но так, чтобы она могла обновляться.
Что сделали
ООО «Комплект Плюс» хотели, чтобы мы создали новую базу. Но мы отговорили их от этого, потому что:
В программе было много доработок, и клиенты сами не знали, какие из доработок нужны, а какие нет. Могла возникнуть ситуация: мы перенесём данные в новые базу без доработок, а потом выяснится, что они необходимы. Тогда пришлось бы создавать их заново. Так в итоге и оказалось — часть доработок была нужна.
Пока мы наводили порядок в старой базе, сотрудники продолжали в ней работать — не было простоев. А переход на новую базу занял бы много времени: нужно смотреть, как было, как стало, всё проверять и подгонять.
Настроили разделение по пользователям с ограничением по правам
Теперь все сотрудники заходят в программу только под своей учётной записью, потому что у всех есть логин и пароль.
У каждого пользователя свои права доступа, чтобы сотрудник мог работать в программе только в рамках своих обязанностей и в зоне своей ответственности. Теперь не будет ситуации, что кто-то куда-то зашёл, что-то где-то исправил, и в итоге отчёты формируются некорректно, и в документах ошибки.
Ввели разные сроки запрета на редактирование документов
У отдела ЖКХ и у отдела бухгалтерии разные периоды, когда можно вносить изменения в документы.
Например, главный бухгалтер может редактировать документы в течение квартала, а бухгалтер-расчётчик выдал квитанции раз в месяц и уже не может их менять.
Это сделано для того, чтобы сотрудник, который случайно зашёл в документы, не смог внести лишние корректировки.
Удалили дубли жильцов в справочниках
Изначально мы думали, что сможем почистить базу стандартным механизмом 1С, который предназначен для удаления дублей. Но оказалось, что программно это сделать невозможно, потому что только человек поймёт, что Иванов А.С. и Иванов Александр Сергеевич — это один и тот же жилец. Только человек увидит, что программа не может найти контрагента, потому что между его именем и фамилией поставлено 2 пробела. Поэтому пришлось чистить базу вручную.
Но если бы мы переходили на новую базу, то эту работу всё равно пришлось бы делать. Так что решение восстанавливать учёт в старой базе было верным.
Настроили отражение начислений ЖКХ по каждому дому отдельно
Стандартный функционал программы 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК предполагает, что при отражении начислений из коммунального учёта в бухгалтерский учёт всё переносится на один счёт. Все дома на этом счёте.
Главбуху для управленческого учёта нужно было понимать, сколько начислено на каждый дом и сколько оплаты с каждого дома пришло.
Для этого мы создали субсчета для каждого дома и закрепили всех жильцов этого дома за этим субсчетом.
Чтобы сразу было понятно, какой дом закреплён за субсчетом, придумали добавлять к номеру субсчёта первую букву улицы, на которой этот дом стоит. Например, к счёту, за которым закреплён дом на Домодедовской, добавляется буква Д.
Настроили отчёты для сверки отражения данных из коммунального учёта в бухгалтерский учёт
Стандартно это происходит так: в коммунальном учёте мы насчитали этому дому столько, этому столько, а потом перенесли эти данные в бухгалтерский учёт реализациями или проводками. Чтобы главный бухгалтер увидел, сколько начислено по каждому дому.
Но недостаточно просто отразить начисления из КУ в БУ, нужно проверить, корректно ли всё отразилось, чтобы не было начального и конечного остатков.
Бывают ситуации, когда главбух вносит корректировку в БУ: перекинуть долг с этого жильца на этого. В КУ сделали свою корректировку, и если эта корректировка попадёт в БУ, то долг спишется дважды.
Поэтому главбух строит отчёт по специальному регистру, который показывает, где данные расходятся.
Разбили контрагентов по группам
Справочник Контрагенты разбит по группам, к каждой группе привязан субсчёт.
Сначала сотрудникам организации приходилось каждого контрагента привязывать к субсчёту вручную. Мы предложили поместить контрагентов в группы по домам и настроить алгоритм, который будет подцеплять группы к субсчёту.
Например, при добавлении нового контрагента его сразу помещают в группу, откуда он автоматически прикрепляется к определённому субсчёту.
Привязали в базе индивидуальные приборы учёта к помещениям
Изначально в системе индивидуальные приборы учёта (ИПУ) были привязаны к лицевым счетам. Но расчетчик попросила привязать ИПУ к помещениям: в таком случае нет зависимости от лицевых счетов.
Например, супруги развелись и хотят раздельно платить за свои части квартиры. Если ИПУ привязан к лицевому счёту, то счётчик нужно привязать к лицевым счетам обоих супругов. Если этого не сделать, то по одному лицевому счёту услуги будут начисляться по показаниям, а по второму — по нормативам. И мы всегда должны следить, сколько собственников в квартире, чтобы вовремя вносить изменения в лицевые счета.
А когда ИПУ привязан к помещению, то просто задаём в настройках программы, как будут делиться показания счётчика: поровну или пропорционально долям. Например, начислено 3 куба воды, у бывших супругов доли распределены так: ⅓ и ⅔, соответственно, первый жилец будет оплачивать 1 куб, а второй — 3.
Нужно было привязать заводские номера счётчиков к помещениям. Вручную это делать долго и сложно. Поэтому мы постарались автоматизировать процесс:
рассказали расчётчику, какие данные нужны и в каком формате, чтобы их можно было загружать в 1С,
загрузили в программу счётчики, чтобы сотрудникам не пришлось вручную вводить новые номера счётчиков,
автоматизировали загрузку ежемесячных показаний по одной кнопке в 1С.
Привязка ИПУ на помещения была трудозатратной, зато теперь коммунальный учёт будет более точным и корректным.
Добавили возможность прикреплять документы, на основании которых были корректировки
Расчётчик делает корректировки на основании какого-то документа. Например:
заявление от собственника,
внутренние документы о том, что было отключение отопления и т.д.
Заказчик хотел, чтобы ко всем документам можно было прикрепить документ, который является причиной корректировки.
Задача выглядела простой, но оказалось, что расширениями и доработками её не решить. Пришлось незначительно менять конфигурацию, зато клиенту теперь удобно: всегда видит причину изменений документов.
Добавили расширение, чтобы определять плательщика из назначения платежа
Когда жильцы оплачивают квитанции через Сбербанк, то платёж автоматически зачисляется на лицевой счёт плательщика. Но если оплачивают через другие банки, то в УК приходит платёж с текстовой строкой, в которой указаны данные плательщика, назначение платежа, лицевой счёт.
Приходилось искать в базе контрагента и вручную заносить данные о платеже на его лицевой счёт. В УК более 1500 апартаментов, соответственно, может быть 1500 оплат через другие банки. Вносить платежи вручную — это работа на несколько часов.
Поэтому мы добавили расширение, которое автоматически определяет лицевой счёт из назначения платежа и заносит данные о платеже на этот счёт.
Подробнее об этом расширении мы писали здесь.
Удалили некорректные доработки и настроили учёт типовыми средствами
Как мы уже писали, на момент обращения к нам конфигурация программы была настолько изменена, что обновления не происходили: было непонятно, как будет работать база с таким количеством доработок после обновления.
Отключили ненужные доработки
Поэтому вместе с нашими программистами мы разбирались, какие доработки нужны, а какие нет.
Одна из таких доработок выводила в документ площадь апартаментов. При этом самому клиенту эта настройка была не нужна, поэтому мы её отключили. И как потом выяснилось — вовремя отключили.
У другого нашего клиента аналогичная доработка была активна. Но после того, как разработчики обновили типовой функционал 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК — поменяли наименования в своих регистрах — начались некорректные начисления.
Что произошло? Например, когда жилец долго не подавал показания ИПУ, ему начислялось по среднему, потом норматив. Но когда человек всё-таки подал показания ИПУ, программа должна убрать начисления по среднему и нормативу и пересчитать оплату по показаниям. В одном месяце программа работала корректно, но на следующий месяц повторно минусовала ту же сумму перерасчёта.
Оказалось, что было дописано наименование вида сторна, которое минусовало среднюю и норматив. В документе отображается корректно, но в регистре, который программа использует для формирования документов и отчётов на следующий месяц, не отображается.
Сократили количество расширений
10 расширений, которые были в базе, мы свернули до 2, чтобы было удобнее и проще их обновлять.
Настроили базу для автоматических обновлений
В процессе работы над проектом мы убрали практически все изменения конфигурации, поэтому программа могла обновляться в штатном режиме без рисков, что доработки после обновления повлияют на её работу.
До того, как мы объединили расширения, обновление занимало 4 часа, сейчас — около 2.
Результат автоматизации
Сроки реализации проекта: январь 2022 года — декабрь 2022 года.
За это время мы:
1. Восстановили учёт на старой базе:
удалили дубли из справочников — учёт стал понятнее и легче,
настроили разделение по пользователям с разграничением прав и сроков редактирования документов — меньше ошибок из-за незнания программы,
настроили отчёты для сверки из коммунального учёта в бухгалтерский — теперь видно, всё ли корректно перенесено из коммунального учёта в бухгалтерский учёт,
настроили отражение начислений ЖКХ по каждому дому — понятная картинка начислений и оплат по каждому дому помогает принимать управленческие решения,
удалили ненужные доработки из конфигурации программы, которые тормозили работу программы и могли стать причиной ошибок,
объединили 10 расширений в 2, чтобы проще их контролировать и обновлять.
2. Разработали новый функционал:
добавили возможность прикреплять документы, на основании которых сделаны изменения, — у расчётчиков уходит меньше времени на поиск нужных документов,
добавили расширение, которое определяет плательщика из назначения платежа — экономия нескольких часов работы сотрудников УК ежемесячно.
В результате всех выполненных работ база 1С в УК ООО «Комплект Плюс» снова обновляется в штатном режиме, при этом обновление занимает всего 2 часа.
Сейчас мы продолжаем сотрудничество с ООО «Комплект Плюс» по текущим вопросам.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
В кейсе рассказываем, как не стоит дорабатывать программы 1С, и в каких ситуациях лучше восстановить учёт, чем создавать его с нуля.
Содержание:
Управляющая компания ООО «Комплект Плюс» обратилась к нам, чтобы мы навели порядок в их программе 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Какие проблемы были в учёте
Жильцы в справочниках были прописаны по несколько раз из-за орфографических ошибок, двойных пробелов и т.д.
Например, есть жилец Иванов Александр Сергеевич. Один сотрудник опечатался и добавил его в базу не как Иванова, а как Ионова, другой сотрудник начал его искать, не нашёл и завёл новую карточку на Иванова А.С. Третий сотрудник снова не нашёл его в базе и добавил Иванова Александра Сергеевича.
Не было разделения прав доступа для разных сотрудников.
Например, сотрудники, плохо разбираясь в программе, могли случайно внести изменения в разделы, которые влияют на корректность формирования отчётов.
К тому же если не настроен вход под собственным логином и паролем, нельзя отследить, кто работал в программе, кто допустил ошибку. Можно было зайти в программу под чужой учётной записью и создать любые документы, внести корректировки и даже удалить.
База была снята с обновления.
Предыдущий программист вносил все изменения непосредственно в конфигурацию программы. Мы стараемся менять конфигурацию в самых редких случаях, а весь дополнительный функционал делаем в форме внешних обработок и приложений. Потому что программа остаётся типовой и обновляется легко и быстро.
Большое количество расширений.
Кроме изменённой конфигурации в программе было 10 расширений, за которыми было сложно следить и обновлять.
Неудобная иерархия в системе.
Предыдущие специалисты создали множество папок, которые казались сотрудникам УК ненужными, созданными по непонятной логике.
Задачи автоматизации
Восстановить учёт или создать базу с нуля, чтобы работа в программе была понятной и удобной.
Настроить базу с учётом всех пожеланий, но так, чтобы она могла обновляться.
Что сделали
ООО «Комплект Плюс» хотели, чтобы мы создали новую базу. Но мы отговорили их от этого, потому что:
В программе было много доработок, и клиенты сами не знали, какие из доработок нужны, а какие нет. Могла возникнуть ситуация: мы перенесём данные в новые базу без доработок, а потом выяснится, что они необходимы. Тогда пришлось бы создавать их заново. Так в итоге и оказалось — часть доработок была нужна.
Пока мы наводили порядок в старой базе, сотрудники продолжали в ней работать — не было простоев. А переход на новую базу занял бы много времени: нужно смотреть, как было, как стало, всё проверять и подгонять.
Настроили разделение по пользователям с ограничением по правам
Теперь все сотрудники заходят в программу только под своей учётной записью, потому что у всех есть логин и пароль.
У каждого пользователя свои права доступа, чтобы сотрудник мог работать в программе только в рамках своих обязанностей и в зоне своей ответственности. Теперь не будет ситуации, что кто-то куда-то зашёл, что-то где-то исправил, и в итоге отчёты формируются некорректно, и в документах ошибки.
Ввели разные сроки запрета на редактирование документов
У отдела ЖКХ и у отдела бухгалтерии разные периоды, когда можно вносить изменения в документы.
Например, главный бухгалтер может редактировать документы в течение квартала, а бухгалтер-расчётчик выдал квитанции раз в месяц и уже не может их менять.
Это сделано для того, чтобы сотрудник, который случайно зашёл в документы, не смог внести лишние корректировки.
Удалили дубли жильцов в справочниках
Изначально мы думали, что сможем почистить базу стандартным механизмом 1С, который предназначен для удаления дублей. Но оказалось, что программно это сделать невозможно, потому что только человек поймёт, что Иванов А.С. и Иванов Александр Сергеевич — это один и тот же жилец. Только человек увидит, что программа не может найти контрагента, потому что между его именем и фамилией поставлено 2 пробела. Поэтому пришлось чистить базу вручную.
Но если бы мы переходили на новую базу, то эту работу всё равно пришлось бы делать. Так что решение восстанавливать учёт в старой базе было верным.
Настроили отражение начислений ЖКХ по каждому дому отдельно
Стандартный функционал программы 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК предполагает, что при отражении начислений из коммунального учёта в бухгалтерский учёт всё переносится на один счёт. Все дома на этом счёте.
Главбуху для управленческого учёта нужно было понимать, сколько начислено на каждый дом и сколько оплаты с каждого дома пришло.
Для этого мы создали субсчета для каждого дома и закрепили всех жильцов этого дома за этим субсчетом.
Чтобы сразу было понятно, какой дом закреплён за субсчетом, придумали добавлять к номеру субсчёта первую букву улицы, на которой этот дом стоит. Например, к счёту, за которым закреплён дом на Домодедовской, добавляется буква Д.
Настроили отчёты для сверки отражения данных из коммунального учёта в бухгалтерский учёт
Стандартно это происходит так: в коммунальном учёте мы насчитали этому дому столько, этому столько, а потом перенесли эти данные в бухгалтерский учёт реализациями или проводками. Чтобы главный бухгалтер увидел, сколько начислено по каждому дому.
Но недостаточно просто отразить начисления из КУ в БУ, нужно проверить, корректно ли всё отразилось, чтобы не было начального и конечного остатков.
Бывают ситуации, когда главбух вносит корректировку в БУ: перекинуть долг с этого жильца на этого. В КУ сделали свою корректировку, и если эта корректировка попадёт в БУ, то долг спишется дважды.
Поэтому главбух строит отчёт по специальному регистру, который показывает, где данные расходятся.
Разбили контрагентов по группам
Справочник Контрагенты разбит по группам, к каждой группе привязан субсчёт.
Сначала сотрудникам организации приходилось каждого контрагента привязывать к субсчёту вручную. Мы предложили поместить контрагентов в группы по домам и настроить алгоритм, который будет подцеплять группы к субсчёту.
Например, при добавлении нового контрагента его сразу помещают в группу, откуда он автоматически прикрепляется к определённому субсчёту.
Привязали в базе индивидуальные приборы учёта к помещениям
Изначально в системе индивидуальные приборы учёта (ИПУ) были привязаны к лицевым счетам. Но расчетчик попросила привязать ИПУ к помещениям: в таком случае нет зависимости от лицевых счетов.
Например, супруги развелись и хотят раздельно платить за свои части квартиры. Если ИПУ привязан к лицевому счёту, то счётчик нужно привязать к лицевым счетам обоих супругов. Если этого не сделать, то по одному лицевому счёту услуги будут начисляться по показаниям, а по второму — по нормативам. И мы всегда должны следить, сколько собственников в квартире, чтобы вовремя вносить изменения в лицевые счета.
А когда ИПУ привязан к помещению, то просто задаём в настройках программы, как будут делиться показания счётчика: поровну или пропорционально долям. Например, начислено 3 куба воды, у бывших супругов доли распределены так: ⅓ и ⅔, соответственно, первый жилец будет оплачивать 1 куб, а второй — 3.
Нужно было привязать заводские номера счётчиков к помещениям. Вручную это делать долго и сложно. Поэтому мы постарались автоматизировать процесс:
рассказали расчётчику, какие данные нужны и в каком формате, чтобы их можно было загружать в 1С,
загрузили в программу счётчики, чтобы сотрудникам не пришлось вручную вводить новые номера счётчиков,
автоматизировали загрузку ежемесячных показаний по одной кнопке в 1С.
Привязка ИПУ на помещения была трудозатратной, зато теперь коммунальный учёт будет более точным и корректным.
Добавили возможность прикреплять документы, на основании которых были корректировки
Расчётчик делает корректировки на основании какого-то документа. Например:
заявление от собственника,
внутренние документы о том, что было отключение отопления и т.д.
Заказчик хотел, чтобы ко всем документам можно было прикрепить документ, который является причиной корректировки.
Задача выглядела простой, но оказалось, что расширениями и доработками её не решить. Пришлось незначительно менять конфигурацию, зато клиенту теперь удобно: всегда видит причину изменений документов.
Добавили расширение, чтобы определять плательщика из назначения платежа
Когда жильцы оплачивают квитанции через Сбербанк, то платёж автоматически зачисляется на лицевой счёт плательщика. Но если оплачивают через другие банки, то в УК приходит платёж с текстовой строкой, в которой указаны данные плательщика, назначение платежа, лицевой счёт.
Приходилось искать в базе контрагента и вручную заносить данные о платеже на его лицевой счёт. В УК более 1500 апартаментов, соответственно, может быть 1500 оплат через другие банки. Вносить платежи вручную — это работа на несколько часов.
Поэтому мы добавили расширение, которое автоматически определяет лицевой счёт из назначения платежа и заносит данные о платеже на этот счёт.
Подробнее об этом расширении мы писали здесь.
Удалили некорректные доработки и настроили учёт типовыми средствами
Как мы уже писали, на момент обращения к нам конфигурация программы была настолько изменена, что обновления не происходили: было непонятно, как будет работать база с таким количеством доработок после обновления.
Отключили ненужные доработки
Поэтому вместе с нашими программистами мы разбирались, какие доработки нужны, а какие нет.
Одна из таких доработок выводила в документ площадь апартаментов. При этом самому клиенту эта настройка была не нужна, поэтому мы её отключили. И как потом выяснилось — вовремя отключили.
У другого нашего клиента аналогичная доработка была активна. Но после того, как разработчики обновили типовой функционал 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК — поменяли наименования в своих регистрах — начались некорректные начисления.
Что произошло? Например, когда жилец долго не подавал показания ИПУ, ему начислялось по среднему, потом норматив. Но когда человек всё-таки подал показания ИПУ, программа должна убрать начисления по среднему и нормативу и пересчитать оплату по показаниям. В одном месяце программа работала корректно, но на следующий месяц повторно минусовала ту же сумму перерасчёта.
Оказалось, что было дописано наименование вида сторна, которое минусовало среднюю и норматив. В документе отображается корректно, но в регистре, который программа использует для формирования документов и отчётов на следующий месяц, не отображается.
Сократили количество расширений
10 расширений, которые были в базе, мы свернули до 2, чтобы было удобнее и проще их обновлять.
Настроили базу для автоматических обновлений
В процессе работы над проектом мы убрали практически все изменения конфигурации, поэтому программа могла обновляться в штатном режиме без рисков, что доработки после обновления повлияют на её работу.
До того, как мы объединили расширения, обновление занимало 4 часа, сейчас — около 2.
Результат автоматизации
Сроки реализации проекта: январь 2022 года — декабрь 2022 года.
За это время мы:
1. Восстановили учёт на старой базе:
удалили дубли из справочников — учёт стал понятнее и легче,
настроили разделение по пользователям с разграничением прав и сроков редактирования документов — меньше ошибок из-за незнания программы,
настроили отчёты для сверки из коммунального учёта в бухгалтерский — теперь видно, всё ли корректно перенесено из коммунального учёта в бухгалтерский учёт,
настроили отражение начислений ЖКХ по каждому дому — понятная картинка начислений и оплат по каждому дому помогает принимать управленческие решения,
удалили ненужные доработки из конфигурации программы, которые тормозили работу программы и могли стать причиной ошибок,
объединили 10 расширений в 2, чтобы проще их контролировать и обновлять.
2. Разработали новый функционал:
добавили возможность прикреплять документы, на основании которых сделаны изменения, — у расчётчиков уходит меньше времени на поиск нужных документов,
добавили расширение, которое определяет плательщика из назначения платежа — экономия нескольких часов работы сотрудников УК ежемесячно.
В результате всех выполненных работ база 1С в УК ООО «Комплект Плюс» снова обновляется в штатном режиме, при этом обновление занимает всего 2 часа.
Сейчас мы продолжаем сотрудничество с ООО «Комплект Плюс» по текущим вопросам.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
6 июня 2023
Клиент: ООО «Комплект Плюс»
Внедренный продукт: 1С для ЖКХ (ТСЖ, ЖСК)
Отрасль: Жилищно-коммунальное хозяйство
В мае 2022 года к нам обратилось ООО «Гамма-Теплосервис» — управляющая компания, которая только начала свою деятельность. Им нужно было создать базу с нуля в 1С и настроить работу программы, чтобы формировать квитанции жильцам.
Все данные хранились в файле Excel, откуда их нужно было перенести в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК — специальное решение 1С для сферы ЖКХ.
Ещё одна задача, которую поставил клиент, — автоматизация передачи данных из квитанций в соцзащиту. В 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК такая возможность реализована, но не для всех регионов РФ. Для Липецкой области, где находится ООО «Гамма-Теплосервис», нам нужно было самостоятельно разработать этот функционал.
Если не автоматизировать подачу данных в соцзащиту, то придётся это делать вручную:
найти лицевой счёт жильца,
найти начисленную сумму,
перенести эти данные в файл и отправить в соцзащиту.
Это долго, сложно и можно легко ошибиться.
Задачи автоматизации
Перенос данных из Excel в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Настройка программы 1С для формирования квитанций.
Автоматизация подачи данных в соцзащиту.
Как решили задачи
Перенесли данные из Excel и создали базу в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Можно самостоятельно перенести данные из Excel в 1С, но из-за того, что опыта работы с программой мало или совсем нет, можно внести данные не в те разделы. Тогда отчёты и документы будут формироваться с ошибками.
Мы разработали специальную обработку, в которую загрузили файл Excel, и все данные оттуда автоматически перешли в нужные разделы программы 1С:
здания,
помещения,
лицевые счета,
общая и жилая площадь,
количество проживающих и зарегистрированных,
ответственные собственники.
А также:
перенесли остатки,
сгенерировали счётчики,
загрузили начальные показания.
Настроили учёт в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Мы проанализировали услуги, которые прописаны в договоре управления, и настроили программу так, чтобы:
все начисления производились в соответствии с Постановлением Правительства РФ № 365,
количество услуг в справочнике начислений не было раздутым, но при этом, чтобы их хватало для быстрого и простого начисления,
создали нормативы и назначили лицевые счета.
После настройки программы, мы провели начисления и выпустили квитанции в типовой форме «Плат. документ (приказ № 454 в соответ. с пост. № 354)».
Автоматизировали подачу данных в соцзащиту.
Доработали функционал 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК так, что нужные для соцзащиты данные автоматически выгружаются в файл, который потом отправляют в соцзащиту.
Результат автоматизации
Мы завершили проект за 2 месяца. Но УК смогла сформировать и распечатать квитанции для жильцов в тот же месяц, в который обратились к нам. Потому что мы специализируемся на учёте ЖКХ и многие типовые процессы автоматизировали, чтобы быстрее решать задачи клиентов.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
В мае 2022 года к нам обратилось ООО «Гамма-Теплосервис» — управляющая компания, которая только начала свою деятельность. Им нужно было создать базу с нуля в 1С и настроить работу программы, чтобы формировать квитанции жильцам.
Все данные хранились в файле Excel, откуда их нужно было перенести в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК — специальное решение 1С для сферы ЖКХ.
Ещё одна задача, которую поставил клиент, — автоматизация передачи данных из квитанций в соцзащиту. В 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК такая возможность реализована, но не для всех регионов РФ. Для Липецкой области, где находится ООО «Гамма-Теплосервис», нам нужно было самостоятельно разработать этот функционал.
Если не автоматизировать подачу данных в соцзащиту, то придётся это делать вручную:
найти лицевой счёт жильца,
найти начисленную сумму,
перенести эти данные в файл и отправить в соцзащиту.
Это долго, сложно и можно легко ошибиться.
Задачи автоматизации
Перенос данных из Excel в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Настройка программы 1С для формирования квитанций.
Автоматизация подачи данных в соцзащиту.
Как решили задачи
Перенесли данные из Excel и создали базу в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Можно самостоятельно перенести данные из Excel в 1С, но из-за того, что опыта работы с программой мало или совсем нет, можно внести данные не в те разделы. Тогда отчёты и документы будут формироваться с ошибками.
Мы разработали специальную обработку, в которую загрузили файл Excel, и все данные оттуда автоматически перешли в нужные разделы программы 1С:
здания,
помещения,
лицевые счета,
общая и жилая площадь,
количество проживающих и зарегистрированных,
ответственные собственники.
А также:
перенесли остатки,
сгенерировали счётчики,
загрузили начальные показания.
Настроили учёт в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК.
Мы проанализировали услуги, которые прописаны в договоре управления, и настроили программу так, чтобы:
все начисления производились в соответствии с Постановлением Правительства РФ № 365,
количество услуг в справочнике начислений не было раздутым, но при этом, чтобы их хватало для быстрого и простого начисления,
создали нормативы и назначили лицевые счета.
После настройки программы, мы провели начисления и выпустили квитанции в типовой форме «Плат. документ (приказ № 454 в соответ. с пост. № 354)».
Автоматизировали подачу данных в соцзащиту.
Доработали функционал 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК так, что нужные для соцзащиты данные автоматически выгружаются в файл, который потом отправляют в соцзащиту.
Результат автоматизации
Мы завершили проект за 2 месяца. Но УК смогла сформировать и распечатать квитанции для жильцов в тот же месяц, в который обратились к нам. Потому что мы специализируемся на учёте ЖКХ и многие типовые процессы автоматизировали, чтобы быстрее решать задачи клиентов.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
31 мая 2023
Клиент: ООО «Гамма-Теплосервис»
Внедренный продукт: 1С для ЖКХ (ТСЖ, ЖСК)
Отрасль: Жилищно-коммунальное хозяйство
Наш клиент — московская компания ООО «Интерсервис», которая оказывает услуги по уборке помещений.
В организации не планируют подключать электронный документооборот, обмен документами происходит традиционно:
распечатывают документы из базы 1С:Бухгалтерия,
отправляют по почте контрагентам,
получают подписанные.
Если контрагенты не вернут свои подписанные экземпляры, то ООО «Интерсервис» останется без первичных документов, а без них компания не сможет подтвердить факт хозяйственной операции.
Наша задача — разработать систему, которая позволила бы контролировать, пришёл ответ от контрагента или нет, и, если не пришёл, отправить напоминание.
Как решили задачу
В функционале 1С:Бухгалтерия есть типовая галочка, которую нужно ставить после получения от контрагентов подписанных документов. Эту галочку мы использовали в нашей обработке — программа формирует список контрагентов, у которых не проставлена галочка, то есть тех, от кого не пришли документы, и отправляет им напоминание по электронной почте.
Автоматическая рассылка напоминаний
Задаём регламентное задание, в котором указываем, как часто делается рассылка.
Программа автоматически формирует пакет документов для отправки по электронной почте. Пакет документов для каждого контрагента формируется свой — подтягивается из базы. Если отправили акты сверки и не получили ответ, то к электронному письму будет прикреплен этот акт сверки и первичные документы, которые указаны в этом акте.
Если нужно напомнить вернуть документ, то к письму прикладываются печатные формы в архиве.
Ручная рассылка напоминаний
1. Выбираем документы, по которым нужно сделать рассылку:
поступления,
реализации,
акты сверки,
счета на оплату.
2. Далее программа сформирует письма для рассылки.
Как формируется письмо с напоминанием?
Текст письма генерируется программой автоматически в зависимости от того, какие документы к нему прикреплены.
Но с счетами на оплату немного другой алгоритм:
сначала обработка анализирует период, до которого счёт должен быть оплачен,
если ещё не последний день оплаты, рассылка не отправится,
если документ уже оплачен, то рассылка тоже не отправится.
Отправка напоминаний вручную.
В таком формате приходят напоминания контрагентам.
Результаты внедрения обработки
Раньше приходилось формировать письма с напоминанием вручную: готовить пакет документов, писать текст письма — на эту работу уходило 3 часа в неделю. В год и вовсе получалось 156 часов (3 часа в неделю * 52 недели в году), это 19,5 рабочих дней.
Сейчас это происходит автоматически. Соответственно, у сотрудников появилось 156 дополнительных рабочих часов, в которые они могут решать более важные задачи.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
Наш клиент — московская компания ООО «Интерсервис», которая оказывает услуги по уборке помещений.
В организации не планируют подключать электронный документооборот, обмен документами происходит традиционно:
распечатывают документы из базы 1С:Бухгалтерия,
отправляют по почте контрагентам,
получают подписанные.
Если контрагенты не вернут свои подписанные экземпляры, то ООО «Интерсервис» останется без первичных документов, а без них компания не сможет подтвердить факт хозяйственной операции.
Наша задача — разработать систему, которая позволила бы контролировать, пришёл ответ от контрагента или нет, и, если не пришёл, отправить напоминание.
Как решили задачу
В функционале 1С:Бухгалтерия есть типовая галочка, которую нужно ставить после получения от контрагентов подписанных документов. Эту галочку мы использовали в нашей обработке — программа формирует список контрагентов, у которых не проставлена галочка, то есть тех, от кого не пришли документы, и отправляет им напоминание по электронной почте.
Автоматическая рассылка напоминаний
Задаём регламентное задание, в котором указываем, как часто делается рассылка.
Программа автоматически формирует пакет документов для отправки по электронной почте. Пакет документов для каждого контрагента формируется свой — подтягивается из базы. Если отправили акты сверки и не получили ответ, то к электронному письму будет прикреплен этот акт сверки и первичные документы, которые указаны в этом акте.
Если нужно напомнить вернуть документ, то к письму прикладываются печатные формы в архиве.
Ручная рассылка напоминаний
1. Выбираем документы, по которым нужно сделать рассылку:
поступления,
реализации,
акты сверки,
счета на оплату.
2. Далее программа сформирует письма для рассылки.
Как формируется письмо с напоминанием?
Текст письма генерируется программой автоматически в зависимости от того, какие документы к нему прикреплены.
Но с счетами на оплату немного другой алгоритм:
сначала обработка анализирует период, до которого счёт должен быть оплачен,
если ещё не последний день оплаты, рассылка не отправится,
если документ уже оплачен, то рассылка тоже не отправится.
Отправка напоминаний вручную.
В таком формате приходят напоминания контрагентам.
Результаты внедрения обработки
Раньше приходилось формировать письма с напоминанием вручную: готовить пакет документов, писать текст письма — на эту работу уходило 3 часа в неделю. В год и вовсе получалось 156 часов (3 часа в неделю * 52 недели в году), это 19,5 рабочих дней.
Сейчас это происходит автоматически. Соответственно, у сотрудников появилось 156 дополнительных рабочих часов, в которые они могут решать более важные задачи.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
31 мая 2023
Клиент: ООО «Интерсервис»
Внедренный продукт: 1С:Бухгалтерия
Отрасль: Услуги
Содержание:
В декабре 2022 года к нам обратилась управляющая компания, которая тратила до 2 недель на подготовку первичных бухгалтерских документов и хотела ускорить этот процесс.
Проблемы в учёте
Больше всего времени бухгалтер тратила на следующие задачи:
Формирование первичных бухгалтерских документов на основе данных из квитанций.
Существует стандартный функционал, который автоматизирует эту задачу, но в данном случае он не подходил, потому что:
в организации вели две базы: расчётный отдел работал в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК, а бухгалтерия в 1С:Бухгалтерия, и типовой выгрузки между базами не было,
справочники в базах отличались.
Например, в базе ЖКХ 100 договоров на 100 квартир, но все они принадлежат одному юрлицу, и это юрлицо просит оформить все 100 квартир в 1 документ или в 2–3, как ему удобнее.
Раньше бухгалтер формировала специальные отчёты, из которых вручную переносила нужные данные в базу бухгалтерии.
Корректировка реализаций из-за перерасчёта услуг ЖКХ.
Например, выставили счёт на 100 рублей, но потом выяснилось, что в тот период должны были выставить счёт на 50 рублей, потому что:
некачественно оказали услугу: была плохая вода,
оказали услугу не в том объёме: несколько дней не было отопления,
начисляли по среднему значению, потому что жилец не подавал показания приборов учёта, а потом нужно пересчитать по показаниям счётчиков,
провели ежегодные перерасчёты по отоплению и содержанию общего имущества,
расчётчик ошибся,
по другим причинам, которые указаны в Постановлении №354.
Нужно скорректировать реализацию, но типовой функционал решал эту проблему так: просто сокращал текущую реализацию на сумму перерасчёта. В нашем примере в текущей реализации было бы –50 рублей: 50 – 100 = –50.
Но по закону нельзя выставлять реализации с отрицательным значением, налоговая такие документы не примет.
Раньше бухгалтер вручную вносила изменения в нужные реализации: уменьшала до нуля текущую реализацию и распределяла остаток суммы для корректировки на корректировки реализаций за предыдущие месяцы.
Создание сводной реализации на помещения по запросу контрагентов.
В типовой версии 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК на каждое помещение генерируется своя реализация. Контрагенты просили делать сводную реализацию на все помещения, которые им принадлежат, или делить реализации по виду помещения.
Например, клиент просит сделать одну реализацию на паркинги и автоместа, а вторую на торговый центр.
И снова бухгалтер вручную формировала нужные документы для клиентов.
Задачи автоматизации
Сопоставить справочники.
Объединить базы, если есть техническая возможность, или настроить выгрузку.
Автоматизировать формирование первичных бухгалтерских документов на основе данных из квитанций.
Настроить автоматическую корректировку реализаций из-за перерасчёта услуг ЖКХ.
Автоматизировать создание сводных реализаций в разных разрезах.
Как решили задачи
1. Сопоставили справочники в базах.
Чтобы было понятно, какой контрагент из базы ЖКХ соответствует контрагенту в базе бухгалтерии. А также сопоставили справочники Номенклатуры и подразделений.
2. Настроили выгрузку из базы 1С:Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК в 1С:Бухгалтерия.
Клиент решил не объединять базы, потому что огромная база ЖКХ будет усложнять работу бухгалтера. Поэтому мы настроили выгрузку из базы ЖКХ в базу бухгалтерии по такому принципу:
открываем специальную обработку в программе 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК,
нажимаем кнопку «Выгрузить» — формируется файл,
загружаем этот файл в 1С:Бухгалтерия.
Выгрузку данных можно сделать в любое время и за любой период.
Так выглядит документ Отражения начислений в регламентированном учете после наших доработок:
1. Есть возможность видеть все сгенерированные документы.
2. Есть возможность отразить документы только по выбранному подразделению (начисления появляются постепенно, не все сразу). Чтобы быстрее отдать документы покупателям мы реализовали пожелание заказчика и добавили на типовую форму документа отображение по подразделению.
3. Автоматизировали формирование первичных бухгалтерских документов на основе данных из квитанций.
Полностью автоматизировать процесс невозможно, потому что каждый случай уникален: один контрагент просит оформлять его недвижимость в один договор, другой — в 3, потому что всем удобно по-разному.
Поэтому мы вручную сопоставили договоры из ЖКХ с договорами в бухгалтерии. А потом прописали алгоритм, который создаёт из заданных договоров ЖКХ нужные договоры в бухгалтерии.
Если появится новый контрагент с таким запросом, то УК «Высота 4884. Сервис» своими силами сможет сопоставить договоры из ЖКХ с договорами в бухгалтерии, а в дальнейшем разработанный нами алгоритм будет автоматически формировать нужные документы.
Дополнительный реквизит для объединения реализаций на один договор.
4. Настроили автоматическую корректировку реализаций из-за перерасчёта услуг ЖКХ
Сделали доработку, которая:
уменьшает текущую реализацию до нуля, если сумма перерасчёта больше, чем сумма реализации,
создает корректировки на реализации за прошлые периоды, пока сумма перерасчёта не распределится полностью.
Например, нужно сделать перерасчёт на 100 рублей в мае:
Реализация за май равна 50 рублям. Доработка уменьшает текущую, майскую, реализацию до 0.
Но остается ещё 50 рублей перерасчёта.
Тогда доработка создает корректировку реализации на реализацию за предыдущий период на сумму перерасчёта. Предположим, в апреле была реализация на 40 рублей. Наша доработка генерирует корректировку апрельской реализации и уменьшает сумму по услуге на 40 рублей.
Остаётся ещё 10 рублей для перерасчёта — доработка создает корректировку мартовской реализации и уменьшает сумму по услуге на 10 рублей.
Сгенерированные корректировки реализации выводятся в табличную часть документа Отражение начислений в регламентированном учёте.
5. Автоматизировали создание сводной реализации для контрагентов.
Доработали функционал программы 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК так, что по запросу клиента бухгалтер нажатием нескольких кнопок формирует сводную реализацию в нужном разрезе: на все помещения, по виду и т.д.
В договоре сделали табличную часть для сопоставления вида помещения и комментария, который должен заполняться в Реализации услуг, Счёт на оплату.
Дополнительный реквизит для группировки помещений для отражения в одну Реализацию услуг.
Результаты автоматизации учёта
Запрос, с которым к нам обратился клиент: сократить время на подготовку первичных бухгалтерских документов.
Если раньше на эту задачу уходило 10 рабочих дней, то после автоматизации не больше 1 дня.
Сроки выполнения проекта: декабрь 2022 года — май 2023 года.
Планы на дальнейшее сотрудничество
1. Настроить выгрузку из базы ЖКХ в базу бухгалтерии в автоматическом режиме или по кнопке: бухгалтер будет нажимать кнопку «Синхронизировать», и нужные документы из одной базы будут выгружаться в другую базу.
В автоматическом режиме можно будет настроить расписание выгрузок, чтобы к моменту, когда бухгалтер начнёт готовить документы, в его базе уже были все необходимые сведения.
2. Доработать автоматическую генерацию сводной реализации по физлицам.
Например, в базе ЖКХ 50 000 жильцов, всем выставляем квитанции. Но для удобства бухучёта решили, что будем вести сводную реализацию по всем жильцам.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
Содержание:
В декабре 2022 года к нам обратилась управляющая компания, которая тратила до 2 недель на подготовку первичных бухгалтерских документов и хотела ускорить этот процесс.
Проблемы в учёте
Больше всего времени бухгалтер тратила на следующие задачи:
Формирование первичных бухгалтерских документов на основе данных из квитанций.
Существует стандартный функционал, который автоматизирует эту задачу, но в данном случае он не подходил, потому что:
в организации вели две базы: расчётный отдел работал в 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК, а бухгалтерия в 1С:Бухгалтерия, и типовой выгрузки между базами не было,
справочники в базах отличались.
Например, в базе ЖКХ 100 договоров на 100 квартир, но все они принадлежат одному юрлицу, и это юрлицо просит оформить все 100 квартир в 1 документ или в 2–3, как ему удобнее.
Раньше бухгалтер формировала специальные отчёты, из которых вручную переносила нужные данные в базу бухгалтерии.
Корректировка реализаций из-за перерасчёта услуг ЖКХ.
Например, выставили счёт на 100 рублей, но потом выяснилось, что в тот период должны были выставить счёт на 50 рублей, потому что:
некачественно оказали услугу: была плохая вода,
оказали услугу не в том объёме: несколько дней не было отопления,
начисляли по среднему значению, потому что жилец не подавал показания приборов учёта, а потом нужно пересчитать по показаниям счётчиков,
провели ежегодные перерасчёты по отоплению и содержанию общего имущества,
расчётчик ошибся,
по другим причинам, которые указаны в Постановлении №354.
Нужно скорректировать реализацию, но типовой функционал решал эту проблему так: просто сокращал текущую реализацию на сумму перерасчёта. В нашем примере в текущей реализации было бы –50 рублей: 50 – 100 = –50.
Но по закону нельзя выставлять реализации с отрицательным значением, налоговая такие документы не примет.
Раньше бухгалтер вручную вносила изменения в нужные реализации: уменьшала до нуля текущую реализацию и распределяла остаток суммы для корректировки на корректировки реализаций за предыдущие месяцы.
Создание сводной реализации на помещения по запросу контрагентов.
В типовой версии 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК на каждое помещение генерируется своя реализация. Контрагенты просили делать сводную реализацию на все помещения, которые им принадлежат, или делить реализации по виду помещения.
Например, клиент просит сделать одну реализацию на паркинги и автоместа, а вторую на торговый центр.
И снова бухгалтер вручную формировала нужные документы для клиентов.
Задачи автоматизации
Сопоставить справочники.
Объединить базы, если есть техническая возможность, или настроить выгрузку.
Автоматизировать формирование первичных бухгалтерских документов на основе данных из квитанций.
Настроить автоматическую корректировку реализаций из-за перерасчёта услуг ЖКХ.
Автоматизировать создание сводных реализаций в разных разрезах.
Как решили задачи
1. Сопоставили справочники в базах.
Чтобы было понятно, какой контрагент из базы ЖКХ соответствует контрагенту в базе бухгалтерии. А также сопоставили справочники Номенклатуры и подразделений.
2. Настроили выгрузку из базы 1С:Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК в 1С:Бухгалтерия.
Клиент решил не объединять базы, потому что огромная база ЖКХ будет усложнять работу бухгалтера. Поэтому мы настроили выгрузку из базы ЖКХ в базу бухгалтерии по такому принципу:
открываем специальную обработку в программе 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК,
нажимаем кнопку «Выгрузить» — формируется файл,
загружаем этот файл в 1С:Бухгалтерия.
Выгрузку данных можно сделать в любое время и за любой период.
Так выглядит документ Отражения начислений в регламентированном учете после наших доработок:
1. Есть возможность видеть все сгенерированные документы.
2. Есть возможность отразить документы только по выбранному подразделению (начисления появляются постепенно, не все сразу). Чтобы быстрее отдать документы покупателям мы реализовали пожелание заказчика и добавили на типовую форму документа отображение по подразделению.
3. Автоматизировали формирование первичных бухгалтерских документов на основе данных из квитанций.
Полностью автоматизировать процесс невозможно, потому что каждый случай уникален: один контрагент просит оформлять его недвижимость в один договор, другой — в 3, потому что всем удобно по-разному.
Поэтому мы вручную сопоставили договоры из ЖКХ с договорами в бухгалтерии. А потом прописали алгоритм, который создаёт из заданных договоров ЖКХ нужные договоры в бухгалтерии.
Если появится новый контрагент с таким запросом, то УК «Высота 4884. Сервис» своими силами сможет сопоставить договоры из ЖКХ с договорами в бухгалтерии, а в дальнейшем разработанный нами алгоритм будет автоматически формировать нужные документы.
Дополнительный реквизит для объединения реализаций на один договор.
4. Настроили автоматическую корректировку реализаций из-за перерасчёта услуг ЖКХ
Сделали доработку, которая:
уменьшает текущую реализацию до нуля, если сумма перерасчёта больше, чем сумма реализации,
создает корректировки на реализации за прошлые периоды, пока сумма перерасчёта не распределится полностью.
Например, нужно сделать перерасчёт на 100 рублей в мае:
Реализация за май равна 50 рублям. Доработка уменьшает текущую, майскую, реализацию до 0.
Но остается ещё 50 рублей перерасчёта.
Тогда доработка создает корректировку реализации на реализацию за предыдущий период на сумму перерасчёта. Предположим, в апреле была реализация на 40 рублей. Наша доработка генерирует корректировку апрельской реализации и уменьшает сумму по услуге на 40 рублей.
Остаётся ещё 10 рублей для перерасчёта — доработка создает корректировку мартовской реализации и уменьшает сумму по услуге на 10 рублей.
Сгенерированные корректировки реализации выводятся в табличную часть документа Отражение начислений в регламентированном учёте.
5. Автоматизировали создание сводной реализации для контрагентов.
Доработали функционал программы 1С:Учёт в управляющих компаниях ЖКХ, ТСЖ и ЖСК так, что по запросу клиента бухгалтер нажатием нескольких кнопок формирует сводную реализацию в нужном разрезе: на все помещения, по виду и т.д.
В договоре сделали табличную часть для сопоставления вида помещения и комментария, который должен заполняться в Реализации услуг, Счёт на оплату.
Дополнительный реквизит для группировки помещений для отражения в одну Реализацию услуг.
Результаты автоматизации учёта
Запрос, с которым к нам обратился клиент: сократить время на подготовку первичных бухгалтерских документов.
Если раньше на эту задачу уходило 10 рабочих дней, то после автоматизации не больше 1 дня.
Сроки выполнения проекта: декабрь 2022 года — май 2023 года.
Планы на дальнейшее сотрудничество
1. Настроить выгрузку из базы ЖКХ в базу бухгалтерии в автоматическом режиме или по кнопке: бухгалтер будет нажимать кнопку «Синхронизировать», и нужные документы из одной базы будут выгружаться в другую базу.
В автоматическом режиме можно будет настроить расписание выгрузок, чтобы к моменту, когда бухгалтер начнёт готовить документы, в его базе уже были все необходимые сведения.
2. Доработать автоматическую генерацию сводной реализации по физлицам.
Например, в базе ЖКХ 50 000 жильцов, всем выставляем квитанции. Но для удобства бухучёта решили, что будем вести сводную реализацию по всем жильцам.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
31 мая 2023
Внедренный продукт: 1С для ЖКХ (ТСЖ, ЖСК)
Отрасль: Жилищно-коммунальное хозяйство
Рассказываем, как без внедрения дорогостоящих WMS-систем автоматизировать складской учёт с помощью терминала сбора данных и удалённого доступа к 1С.
Содержание:
В 2014 году к нам обратилась производственная компания «Алвид». Мы автоматизировали складской учёт предприятия в 2 этапа: в 2014 и в 2022 годах.
О клиенте
С 2011 года завод «Алвид» производит алюминиевый профиль под заказ:
— для изготовления корпусной мебели,
— для изготовления шкафов-купе,
— для изготовления торгово-выставочного оборудования,
— потолочный профиль и т.д.
Работает по России, имеет большие доли рынка в Казахстане, замещая китайский профиль и корейскую фурнитуру.
Алгоритм работы компании «Алвид»
На предприятии много нестандартных складских операций, которые нужно было автоматизировать. Покажем весь алгоритм работы компании «Алвид», чтобы были понятны проблемы и задачи нашего клиента.
— Отдел продаж: менеджер вносит заявку от клиента в 1С:УНФ и передаёт на производство маршрутный лист с информацией о заказе:
контрагент,
какой профиль: тип профиля, длина, цвет, декор,
в каком количестве,
к какому сроку нужно изготовить.
Большинство заказов крупные, на их выполнение уходит 30–90 дней.
— Производство отдаёт выполненный заказ на склад готовой продукции вместе с маршрутным листом.
— Упаковка: сотрудник склада пересчитывает профиль, упаковывает его в соответствии с маршрутным листом и наклеивает на каждую пачку этикетку, в которой зашифрована информация:
название профиля, например, АВД-0506
длина,
вид покрытия,
количество профиля в пачке,
кто заказчик.
— Приёмка: упакованную продукцию вводят в систему, как оприходованную, и размещают на складе.
Поскольку завод производит профиль преимущественно под заказчика, на складе не стали вводить систему адресного хранения, вся готовая продукция по конкретному заказу просто собирается в одном месте.
— Отгрузка: готовый заказ собирают и отгружают клиенту.
Проблемы, с которыми обратился клиент
1. Большое количество ошибок на всех этапах
Например, на этапе упаковки наклейки печатали вручную: сотрудник склада открывал готовый шаблон для наклейки и вносил информацию из заказа. Это было медленно и с большим количеством ошибок: опечатался в названии, указал не те данные и т.д.
А когда приходило время собрать заказ, сотрудник склада:
— распечатывал себе накладную со списком того, что должно быть в заказе,
— визуально сравнивал названия из накладной и на этикетке,
— вручную вычёркивал то, что уже собрал.
Заказы большие, запутаться просто, поэтому часто случалось так, что кому-то из клиентов не отгрузили весь заказ, а кому-то положили лишнего. В итоге рекламация и дополнительные расходы на то, чтобы довезти остаток заказа.
2. Не было прозрачности работы склада:
— Какие заказы уже готовы к отгрузке?
— Сколько осталось произвести по заказам?
— Если произошла ошибка, кто из сотрудников её допустил?
У руководства компании не было этих данных.
3. Медленная инвентаризация
На проведение инвентаризации уходило более суток.
Задачи автоматизации
Снизить количество ошибок на этапах упаковки, приёмки на склад, отгрузки.
Ускорить сборку заказов.
Сделать работу склада более контролируемой.
Ускорить процесс инвентаризации.
Автоматизировать этапы упаковки, приёмки и отгрузки так, чтобы не пришлось менять алгоритмы работы предприятия.
Как клиент пытался решить свои задачи до обращения к нам
Руководство компании «Алвид» рассматривало варианты внедрения WMS-систем.
Но у типовых WMS-систем был ограниченный функционал, который не справлялся со всеми задачами склада. А разработка WMS под ключ значительно превышала бюджет, который выделили на автоматизацию.
Поэтому решили доработать существующую базу 1С и обратились к нам.
Решение, которое мы внедрили
1. Автоматизировали печать наклеек на упаковки с профилем
Если раньше данные этикеток приходилось вносить вручную, то сейчас кладовщик просто вносит в 1С номер заказа и указывает количество этикеток, система сама выводит на печать этикетки со всей необходимой информацией.
2. Внедрили историю движения каждой этикетки
Система генерирует уникальный номер для каждой этикетки. По этому номеру можно отследить всю историю перемещения пачки с этой этикеткой:
— статус «Печать» этикетка получает после того, как её распечатали и наклеили на упаковку,
— статус «Оприходование» — на этапе приёмки на склад готовой продукции,
— статус «Отгружена» — когда отгрузили заказ клиенту.
3. Внедрили работу с помощью терминалов сбора данных (ТСД)
Обычно системы управления складом (WMS) предполагают, что нужно дорабатывать базу 1С и отдельно разрабатывать приложение для терминала сбора данных. Это дорого и долго.
Наше решение для складского учёта предполагает, что ТСД используется просто как удалённый доступ к базе 1С, поэтому разработка нужна только в 1С.
Как это работает?
Первый этап автоматизации: 2014 год
Мы настроили ТСД CipherLab 8230 так, чтобы он при помощи специального протокола в режиме реального времени обращался к базе 1С и получал ответ.
На участке приёмки:
— сотрудник склада выбирает номер заказа в 1С,
— считывает штрихкод каждой упаковки терминалом сбора данных,
— все просканированные номера упаковок закрепляются сразу в 1С за выбранным заказом.
В процессе сборки заказов:
— сотрудник склада выбирает на стационарном компьютере заказ, который будет собирать,
— 1С выдаёт ему форму, в которой указаны все номера пачек, которые привязаны к этому заказу,
— с распечатанными номерами заказа сборщик идёт на склад, туда, где собиралась вся продукция по этому заказу,
— считывает штрихкод пачки с помощью ТСД,
— ТСД отправляет данные в 1С,
— если номер пачки из этого заказа, то 1С помечает этот номер зелёным и отправляет на ТСД сигнал, что номер корректный,
— если же 1С не нашла номер в этом заказе, то на ТСД придёт сообщение об ошибке: звуковое и текстовое.
Сборщик возвращается к компьютеру и смотрит, почему произошла ошибка: дважды просканировали номер или номер с другого заказа. Если нужно перезакрепить пачку с одного заказа на другой, это можно сделать вручную — зайти в номер пачки и указать другого заказчика.
Если сборщик запутался в сборке, то может распечатать на компьютере список того, что ещё не собрал: список формируется автоматически 1С. До внедрения ТСД он вычёркивал собранные позиции вручную.
Второй этап автоматизации: декабрь 2022 года
Спустя 8 лет ТСД CipherLab устарели, их перестали выпускать. Нужно было перейти на новые модели ТСД, выбрали Cipherlab 9730 и Urovo rt40, но для этого потребовалось доработать систему.
С новыми моделями ТСД мы пошли по тому же принципу: не стали писать приложение для терминала, а используем его как удалённое рабочее место. Отличие в том, что новые терминалы обращаются не к компьютеру, а к базе 1С, которая опубликована в собственной сети предприятия. Когда сотрудник начинает работать с ТСД, он переходит по ссылке и запускает базу 1С. Вне сети предприятия подключиться к этой базе невозможно.
Для того чтобы использовать ТСД, как удалённое рабочее место, нужны:
— 1С, подойдёт любая конфигурация,
— ТСД,
— удалённый доступ к рабочему столу (RDP от Microsoft),
— терминальные лицензии Microsoft для каждого терминала.
Если старый ТСД работал в режиме запрос-ответ и не мог давать команды 1С, то новые терминалы — это полноценное рабочее место, потому что кладовщики работают с ТСД непосредственно в базе 1С.
Теперь, если отсканирован не тот номер, не нужно идти к компьютеру: на экране ТСД можно посмотреть, в чём ошибка, и, если надо, перезакрепить номер пачки за другим заказом, это делается в несколько кликов.
Ещё один плюс перехода на новые ТСД — масштабируемость. Когда работали со старыми ТСД, была жёсткая привязка терминала к компьютеру, на котором запускалась база 1С. Если нужно было 2 терминала на складе, то нужно было и 2 компьютера. У новых ТСД такой проблемы нет: работать в опубликованной базе можно с любого количества терминалов.
Результаты автоматизации
После первого этапа автоматизации:
— заказы стали собирать в 2 раза быстрее,
— количество ошибок заметно сократилось: до автоматизации не велась статистика по ошибкам, поэтому мы не можем назвать точные данные,
— появился контроль за работой сотрудников склада: если кто-то совершил ошибку, в 1С видно, кто занимался упаковкой, приёмкой и сборкой этого заказа, потому что перед началом работы все сотрудники входят в систему под своим именем.
— увеличилась скорость проведения инвентаризации: до автоматизации это занимало больше суток, а сейчас полная инвентаризация проводится за 10–14 часов в зависимости от загруженности склада.
Автоматизировали участки упаковки, приёмки и сборки без изменений существующих складских процессов. Это было важным пунктом для нашего заказчика, потому что для внедрения некоторых WMS-систем приходится подстраивать бизнес-процессы под алгоритмы программы, это усложняет и затягивает автоматизацию.
О результатах второго этапа автоматизации говорить пока рано — он начался в декабре 2022 года, на данный момент на стадии тестовой эксплуатации и окончательной доработки.
Прогнозируем значительное ускорение сборки заказов, потому что все операции, для которых раньше нужно было возвращаться к компьютеру, теперь можно совершать на экране терминала.
Кому подойдёт автоматизация складского учёта с помощью ТСД и удалённого доступа
Такое решение подойдёт организациям с нестандартными складскими операциями. Потому что типовые коробочные WMS-системы не смогут учесть всю специфику, а разработка WMS под ключ выйдет на 30% дороже, чем ТСД с удалённым доступом.
Поддерживать функционирование системы смогут штатные программисты 1С, потому что все доработки ведутся непосредственно в базе 1С, не нужно отдельно разрабатывать приложение для терминалов и настраивать обмен между ТСД и учётной системой.
Отзыв клиента
Рассказываем, как без внедрения дорогостоящих WMS-систем автоматизировать складской учёт с помощью терминала сбора данных и удалённого доступа к 1С.
Содержание:
В 2014 году к нам обратилась производственная компания «Алвид». Мы автоматизировали складской учёт предприятия в 2 этапа: в 2014 и в 2022 годах.
О клиенте
С 2011 года завод «Алвид» производит алюминиевый профиль под заказ:
— для изготовления корпусной мебели,
— для изготовления шкафов-купе,
— для изготовления торгово-выставочного оборудования,
— потолочный профиль и т.д.
Работает по России, имеет большие доли рынка в Казахстане, замещая китайский профиль и корейскую фурнитуру.
Алгоритм работы компании «Алвид»
На предприятии много нестандартных складских операций, которые нужно было автоматизировать. Покажем весь алгоритм работы компании «Алвид», чтобы были понятны проблемы и задачи нашего клиента.
— Отдел продаж: менеджер вносит заявку от клиента в 1С:УНФ и передаёт на производство маршрутный лист с информацией о заказе:
контрагент,
какой профиль: тип профиля, длина, цвет, декор,
в каком количестве,
к какому сроку нужно изготовить.
Большинство заказов крупные, на их выполнение уходит 30–90 дней.
— Производство отдаёт выполненный заказ на склад готовой продукции вместе с маршрутным листом.
— Упаковка: сотрудник склада пересчитывает профиль, упаковывает его в соответствии с маршрутным листом и наклеивает на каждую пачку этикетку, в которой зашифрована информация:
название профиля, например, АВД-0506
длина,
вид покрытия,
количество профиля в пачке,
кто заказчик.
— Приёмка: упакованную продукцию вводят в систему, как оприходованную, и размещают на складе.
Поскольку завод производит профиль преимущественно под заказчика, на складе не стали вводить систему адресного хранения, вся готовая продукция по конкретному заказу просто собирается в одном месте.
— Отгрузка: готовый заказ собирают и отгружают клиенту.
Проблемы, с которыми обратился клиент
1. Большое количество ошибок на всех этапах
Например, на этапе упаковки наклейки печатали вручную: сотрудник склада открывал готовый шаблон для наклейки и вносил информацию из заказа. Это было медленно и с большим количеством ошибок: опечатался в названии, указал не те данные и т.д.
А когда приходило время собрать заказ, сотрудник склада:
— распечатывал себе накладную со списком того, что должно быть в заказе,
— визуально сравнивал названия из накладной и на этикетке,
— вручную вычёркивал то, что уже собрал.
Заказы большие, запутаться просто, поэтому часто случалось так, что кому-то из клиентов не отгрузили весь заказ, а кому-то положили лишнего. В итоге рекламация и дополнительные расходы на то, чтобы довезти остаток заказа.
2. Не было прозрачности работы склада:
— Какие заказы уже готовы к отгрузке?
— Сколько осталось произвести по заказам?
— Если произошла ошибка, кто из сотрудников её допустил?
У руководства компании не было этих данных.
3. Медленная инвентаризация
На проведение инвентаризации уходило более суток.
Задачи автоматизации
Снизить количество ошибок на этапах упаковки, приёмки на склад, отгрузки.
Ускорить сборку заказов.
Сделать работу склада более контролируемой.
Ускорить процесс инвентаризации.
Автоматизировать этапы упаковки, приёмки и отгрузки так, чтобы не пришлось менять алгоритмы работы предприятия.
Как клиент пытался решить свои задачи до обращения к нам
Руководство компании «Алвид» рассматривало варианты внедрения WMS-систем.
Но у типовых WMS-систем был ограниченный функционал, который не справлялся со всеми задачами склада. А разработка WMS под ключ значительно превышала бюджет, который выделили на автоматизацию.
Поэтому решили доработать существующую базу 1С и обратились к нам.
Решение, которое мы внедрили
1. Автоматизировали печать наклеек на упаковки с профилем
Если раньше данные этикеток приходилось вносить вручную, то сейчас кладовщик просто вносит в 1С номер заказа и указывает количество этикеток, система сама выводит на печать этикетки со всей необходимой информацией.
2. Внедрили историю движения каждой этикетки
Система генерирует уникальный номер для каждой этикетки. По этому номеру можно отследить всю историю перемещения пачки с этой этикеткой:
— статус «Печать» этикетка получает после того, как её распечатали и наклеили на упаковку,
— статус «Оприходование» — на этапе приёмки на склад готовой продукции,
— статус «Отгружена» — когда отгрузили заказ клиенту.
3. Внедрили работу с помощью терминалов сбора данных (ТСД)
Обычно системы управления складом (WMS) предполагают, что нужно дорабатывать базу 1С и отдельно разрабатывать приложение для терминала сбора данных. Это дорого и долго.
Наше решение для складского учёта предполагает, что ТСД используется просто как удалённый доступ к базе 1С, поэтому разработка нужна только в 1С.
Как это работает?
Первый этап автоматизации: 2014 год
Мы настроили ТСД CipherLab 8230 так, чтобы он при помощи специального протокола в режиме реального времени обращался к базе 1С и получал ответ.
На участке приёмки:
— сотрудник склада выбирает номер заказа в 1С,
— считывает штрихкод каждой упаковки терминалом сбора данных,
— все просканированные номера упаковок закрепляются сразу в 1С за выбранным заказом.
В процессе сборки заказов:
— сотрудник склада выбирает на стационарном компьютере заказ, который будет собирать,
— 1С выдаёт ему форму, в которой указаны все номера пачек, которые привязаны к этому заказу,
— с распечатанными номерами заказа сборщик идёт на склад, туда, где собиралась вся продукция по этому заказу,
— считывает штрихкод пачки с помощью ТСД,
— ТСД отправляет данные в 1С,
— если номер пачки из этого заказа, то 1С помечает этот номер зелёным и отправляет на ТСД сигнал, что номер корректный,
— если же 1С не нашла номер в этом заказе, то на ТСД придёт сообщение об ошибке: звуковое и текстовое.
Сборщик возвращается к компьютеру и смотрит, почему произошла ошибка: дважды просканировали номер или номер с другого заказа. Если нужно перезакрепить пачку с одного заказа на другой, это можно сделать вручную — зайти в номер пачки и указать другого заказчика.
Если сборщик запутался в сборке, то может распечатать на компьютере список того, что ещё не собрал: список формируется автоматически 1С. До внедрения ТСД он вычёркивал собранные позиции вручную.
Второй этап автоматизации: декабрь 2022 года
Спустя 8 лет ТСД CipherLab устарели, их перестали выпускать. Нужно было перейти на новые модели ТСД, выбрали Cipherlab 9730 и Urovo rt40, но для этого потребовалось доработать систему.
С новыми моделями ТСД мы пошли по тому же принципу: не стали писать приложение для терминала, а используем его как удалённое рабочее место. Отличие в том, что новые терминалы обращаются не к компьютеру, а к базе 1С, которая опубликована в собственной сети предприятия. Когда сотрудник начинает работать с ТСД, он переходит по ссылке и запускает базу 1С. Вне сети предприятия подключиться к этой базе невозможно.
Для того чтобы использовать ТСД, как удалённое рабочее место, нужны:
— 1С, подойдёт любая конфигурация,
— ТСД,
— удалённый доступ к рабочему столу (RDP от Microsoft),
— терминальные лицензии Microsoft для каждого терминала.
Если старый ТСД работал в режиме запрос-ответ и не мог давать команды 1С, то новые терминалы — это полноценное рабочее место, потому что кладовщики работают с ТСД непосредственно в базе 1С.
Теперь, если отсканирован не тот номер, не нужно идти к компьютеру: на экране ТСД можно посмотреть, в чём ошибка, и, если надо, перезакрепить номер пачки за другим заказом, это делается в несколько кликов.
Ещё один плюс перехода на новые ТСД — масштабируемость. Когда работали со старыми ТСД, была жёсткая привязка терминала к компьютеру, на котором запускалась база 1С. Если нужно было 2 терминала на складе, то нужно было и 2 компьютера. У новых ТСД такой проблемы нет: работать в опубликованной базе можно с любого количества терминалов.
Результаты автоматизации
После первого этапа автоматизации:
— заказы стали собирать в 2 раза быстрее,
— количество ошибок заметно сократилось: до автоматизации не велась статистика по ошибкам, поэтому мы не можем назвать точные данные,
— появился контроль за работой сотрудников склада: если кто-то совершил ошибку, в 1С видно, кто занимался упаковкой, приёмкой и сборкой этого заказа, потому что перед началом работы все сотрудники входят в систему под своим именем.
— увеличилась скорость проведения инвентаризации: до автоматизации это занимало больше суток, а сейчас полная инвентаризация проводится за 10–14 часов в зависимости от загруженности склада.
Автоматизировали участки упаковки, приёмки и сборки без изменений существующих складских процессов. Это было важным пунктом для нашего заказчика, потому что для внедрения некоторых WMS-систем приходится подстраивать бизнес-процессы под алгоритмы программы, это усложняет и затягивает автоматизацию.
О результатах второго этапа автоматизации говорить пока рано — он начался в декабре 2022 года, на данный момент на стадии тестовой эксплуатации и окончательной доработки.
Прогнозируем значительное ускорение сборки заказов, потому что все операции, для которых раньше нужно было возвращаться к компьютеру, теперь можно совершать на экране терминала.
Кому подойдёт автоматизация складского учёта с помощью ТСД и удалённого доступа
Такое решение подойдёт организациям с нестандартными складскими операциями. Потому что типовые коробочные WMS-системы не смогут учесть всю специфику, а разработка WMS под ключ выйдет на 30% дороже, чем ТСД с удалённым доступом.
Поддерживать функционирование системы смогут штатные программисты 1С, потому что все доработки ведутся непосредственно в базе 1С, не нужно отдельно разрабатывать приложение для терминалов и настраивать обмен между ТСД и учётной системой.
Отзыв клиента
21 апреля 2023
Клиент: ООО «Алвидпроф»
Внедренный продукт: 1С:УНФ
Отрасль: Производство
Содержание статьи:
Наш клиент производит, поставляет и обслуживает дизельные электростанции по России. Учёт ведут в программе 1С:УНФ. Основные инструменты — Заказы покупателей, Заказы поставщикам, Производство и Заказ-наряды.
Клиент купил расширение Экспресс проверка ведения учета в УНФ, с помощью которого выявил множество проблем в учёте.
Это расширение часто покупают клиенты, у которых есть проблемы в учёте: расширение помогает исправить запущенный учет и дает руководителю уверенность в цифрах. Недавно мы писали кейс, в котором руководитель решил большинство проблем сам. Тогда исправили ошибок в учёте на 19 миллионов рублей =)
Какие проблемы были
Самые большие проблемы в учёте были с себестоимостью — тысячи проблем на много миллионов рублей:
отрицательные остатки на складе
зависшая себестоимость — нулевое количество на складе, а себестоимость зависает
проблемы с резервами
расхождения между данными по складу между регистрами себестоимости и складскими остатками
Из-за этих проблем невозможно понять сумму валовой прибыли компании, непонятно, в какой плюс (или минус!) выполняются заказы.
Так выглядели результаты проверки после того, как исправили примерно половину проблем в учете (изначальные результаты, к сожалению, не сохранились)
Из-за чего появились проблемы?
В процессе общения выяснилось, что подобные проблемы появились из-за нескольких факторов:
С 2016 года вели учёт в программе 1С:Управление торговлей, при этом особого контроля за остатками и резервами не было
С начала 2022 года решили перейти на 1С:УНФ. При этом разработчики перенесли все документы из 1С:УТ в 1С:УНФ с начала деятельности компании
Получилось так, что перенесенные в 1С:УНФ документы ломали себестоимость, не получалось понять валовую прибыль
Чтобы навести порядок в учёте и исправить ошибки на миллионы рублей, нужно было решить несколько задач:
исправить прошлые периоды
наладить учет, чтобы ошибки не допускались в текущем периоде
научить пользователей клиента принципам работы с себестоимостью в 1С:УНФ
получить достоверную валовую прибыль
Ход проекта
Ход проекта можно отобразить простой картинкой =)
Отрицание
Изначально нам и клиенту казалось, что больших проблем нет и всё можно легко исправить. Например, достаточно грамотно перепровести Закрытие месяца. Исходили из предположения, что в учете все в порядке, достаточно автоматических типовых алгоритмов, которые легко и быстро исправят все проблемы. К сожалению, это не помогло.
Закрытие месяца решало далеко не все проблемы. Более того, в какой-то момент Закрытие месяца просто переставало работать и ругалось ошибкой на английском языке.
Такая ошибка возникает, если в учете есть отрицательные остатки. Без исправления этих остатков алгоритм не может отработать на уровне Базы данных (SQL-сервера).
Гнев
Конечно, и у заказчика, и у нас первая реакция — поругаться.
Как можно было так вести учет и ничего не контролировать?
Как можно было просто перенести все документы с 2016 года? Это явно сложная операция, типовых переносов нет, был заказан перенос у 1С программистов за сотни тысяч рублей.
Как сейчас исправить учет за 6 лет в УНФ? Получить нормальный учет в 2022 году нельзя без исправления всех проблем себестоимости.
Но гнев непродуктивен, поэтому начали думать, что делать дальше.
Торг
Когда мы погрузились в проблему, стало понятно, что вручную ситуацию не исправить. Требуется корректировка первичных документов, исправление дат, резервов и т.п.
Попутно мы выявили проблемы в доработках и переносе данных. Некоторые перенесенные документы нельзя было перепровести: возникала ошибка. Приходилось писать обработки, использовать хитрые обработки документов и даже корректировки движений документов.
Поэтому возникла мысль каким-то образом автоматически исправить проблемы до 2022 года и с 2022 уже аккуратно налаживать учет.
Что не помогло решить проблему?
Свертка базы
Первая и простая мысль — сделать свертку данных. То есть обрезать базу и на начало 2022 года оставить только остатки. А дальше все будет хорошо.
К сожалению, свертка базы часто не помогает решить проблему. При свёртке все проблемы учета, минуса и прочее заносятся в один общий документ «Корректировка регистров», в котором потом просто не разобраться. Более подробно о проблемах свертки мы разбирались в нашей статье.
Что будет если свернуть базу?
Магии не случится
Будет огромный документ со всеми остатками
Остатки будут на тех же кривых аналитиках. Чтобы их исправить, надо будет как-то править документ остатков, а там будет 10-20 тысяч строк — вручную не исправишь
Будет куча старых документов с 2016 года, помеченных на удаление, которые потом нельзя удалить. Они сохраняются, чтобы сохранилась аналитика
«Обнулить» остатки, сделать инвентаризацию и начать аккуратный учет — нереально. Инвентаризация может занять месяцы, слишком много остатков
Непонятно, какую себестоимость поставить на получившиеся остатки
От этой идеи пришлось отказаться: итоге свертки мы бы получили те же самые проблемы, только исправить их было бы сложнее.
Написать магическую обработку, которая все исправит
Следующая мысль — написать хитрый алгоритм, который сделает документ Корректировка регистров и все исправит «хирургическим путём».
Мы изучали проблемы по отчетам себестоимости и придумали алгоритмы, которые исправляли много проблем. Но в процессе исправлений выяснилось, что вариантов проблем слишком много. Придумать алгоритм, который все исправит сразу, невозможно.
А то, что мы исправляли автоматически — ломалось при исправлении других проблем. А если тронешь задний период, все исправления текущим периодом становятся неактуальны.
От обработки тоже пришлось отказаться.
Поэтому мы пошли старым проверенным путем — анализировать и исправлять проблемы вручную. В ходе исправления проблем смогли сделать несколько обработок, которые помогали автоматически исправлять некоторые ситуации и облегчить дальнейшую работу.
Депрессия
Итак, мы начали исправлять проблемы вручную.
У нас был проверенный инструмент — Экспресс проверка учета, который показывает проблемы, которые нужно поправить, и делает это удобнее, чем просто анализ проблем в Закрытии месяца.
Мы выявляли проблемы отчетом, из него переходили в типовой отчет Запасы и там уже исправляли остатки:
снимали или ставили резервы
меняли даты документов, например, даты Приходных накладных от поставщиков, это не хорошо, но других приемлемых вариантов исправлений не было
исправляли счета учета в документах
исправляли ошибки логики и доработок
делали оприходование товаров, которые на текущий момент так и оставались в минусах
получали новые проблемы, которых раньше не было из-за хитросплетений цепочек документов.
С удивлением пришлось узнать, что в типовой УНФ в документ Инвентаризация не попадают Номенклатуры у которых установлен признак Недействительная. А у нас как раз тысячи недействительной номенклатуры с минусами. пришлось дорабатывать этот момент.
перезакрывали месяцы по 10 раз (кстати, в этом нам помогала наша разработка, которая позволяет закрывать месяца за период)
Не знаю, чтобы мы делали без Экспресс проверки (но сам себя не похвалишь, никто не похвалит =))). Наверное, пришлось бы потратить раза в 3 больше времени или в 10. Причем, пришло в голову много идей по доработке Экспресс проверки, которые тоже позволили ускорить процесс.
Я просидел несколько ночей и выровнял 2016 год =)
Это уже была некоторая победа, Закрытие месяца заработало, я увидел заветное «Ошибок не обнаружено» в исправленных периодах.
Но какой ценой =(
Казалось, что если исправление нескольких месяцев 2016 года занимает несколько дней работы специалиста-эксперта, то исправить все данные до 2022 года — не понятно как.
Оператора не посадишь, заниматься исправлением самому — звучит удручающе и расточительно.
Мы погрузились в депрессию.
Принятие
Никакого другого выхода не было — только исправлять ошибки вручную. Нужно засучить рукава и продолжать работать.
разделили работы на несколько человек
подключили к исправлению бухгалтерию заказчика
взяли в команду разработчиков, которые помогали с локальными исправлениями и придумывали небольшие алгоритмы оптимизации
стали дорабатывать Экспресс-проверку для более удобной и быстрой работы
Алгоритм, довольно банальный:
Берем месяц
Делаем его закрытие
Строим Экспресс-проверку
Выявляем проблемы и исправляем
Делаем закрытие
Строим Экспресс-проверку…
Выявляем и исправляем следующие проблемы, в том числе привнесенные исправлениями (из-за сложных цепочек документов)
И так пока все проблемы не будут решены
Да, это неприятно, дорого, но волшебной пилюли нет. Если много лет учет не велся и его никто не контролировал в какой-то момент нужно хорошо поработать.
Грубо говоря, на исправление одного месяца требовалось 2-3 часа внимательной работы экспертов УНФ. Крик души! Пожалуйста, не запускайте учет, не выключайте контроль отрицательных остатков =)
Мы все понимаем, на старте бизнеса важен сам бизнес, а не его корректный учет, но когда-то придется все же учет налаживать. Просто к этому надо быть готовым.
Стадии автоматизации мы подробно рассматривали на нашем вебинаре.
Что сейчас?
Мы выровняли себестоимость, взаиморасчеты, баланс и прочие проблемы на начало 2022 года.
Что мы сделали, чтобы не допустить беспорядка в будущем
Самое важное — мы настроили строгий контроль остатков при проведении документов.
УНФ в типовом варианте контролирует остатки только на текущую дату. Мы установили собственную доработку, которая позволяет контролировать остатки на дату документа (как в 1С:Бухгалтерии)
Дальше мы пересмотрели некоторые процессы и доработки, убрали лишние, доделали свои.
Сколько времени и денег на это ушло
Основные работы по исправлению себестоимости у нашего ведущего специалиста заняли примерно 3 недели и 100 часов работ. Исправили больше 6 000 документов — руками и специально написанными доработками, перезакрывали месяца и были исправлены сопутствующие проблемы (разнесение первички по счетам учета затрат, закрытие финансового результата, выравнивание баланса и т.п.).
В результате получили вот такую картину.
Кроме этого мы серьезно доработали механизмы автоматических проверок, для быстрого выявления проблем.
100 часов, это примерно 250 000 рублей. Много это или мало? Для текущей задачи — скорее мало. В нашем случае работы выполнялись экспертом по УНФ, нормальная трудоемкость для подобной работы с учетом выравнивания 5 лет работы может быть и 200 и 300 часов.
Конечно, если включить в работу сотрудников заказчика, то бюджет будет соразмерно уменьшаться, но сроки будут скорее всего сильно больше.
Какая следующая задача?
После успешного решения проблем себестоимости перед нами стоят следующие сложные задачи
наладить обмен с 1С:Бухгалтерией
дальше выстраивать управленческий учет
улучшать процессы и повышать доверие к цифрам УНФ.
Тут, к сожалению, тоже типовой инструкцией не обойтись. Нужно будет дополнительно пересматривать процессы работы в УНФ, сделать некоторые доработки-исправления данных, налаживать инструменты контроля.
Но нам не страшно, это наша работа =)
Содержание статьи:
Наш клиент производит, поставляет и обслуживает дизельные электростанции по России. Учёт ведут в программе 1С:УНФ. Основные инструменты — Заказы покупателей, Заказы поставщикам, Производство и Заказ-наряды.
Клиент купил расширение Экспресс проверка ведения учета в УНФ, с помощью которого выявил множество проблем в учёте.
Это расширение часто покупают клиенты, у которых есть проблемы в учёте: расширение помогает исправить запущенный учет и дает руководителю уверенность в цифрах. Недавно мы писали кейс, в котором руководитель решил большинство проблем сам. Тогда исправили ошибок в учёте на 19 миллионов рублей =)
Какие проблемы были
Самые большие проблемы в учёте были с себестоимостью — тысячи проблем на много миллионов рублей:
отрицательные остатки на складе
зависшая себестоимость — нулевое количество на складе, а себестоимость зависает
проблемы с резервами
расхождения между данными по складу между регистрами себестоимости и складскими остатками
Из-за этих проблем невозможно понять сумму валовой прибыли компании, непонятно, в какой плюс (или минус!) выполняются заказы.
Так выглядели результаты проверки после того, как исправили примерно половину проблем в учете (изначальные результаты, к сожалению, не сохранились)
Из-за чего появились проблемы?
В процессе общения выяснилось, что подобные проблемы появились из-за нескольких факторов:
С 2016 года вели учёт в программе 1С:Управление торговлей, при этом особого контроля за остатками и резервами не было
С начала 2022 года решили перейти на 1С:УНФ. При этом разработчики перенесли все документы из 1С:УТ в 1С:УНФ с начала деятельности компании
Получилось так, что перенесенные в 1С:УНФ документы ломали себестоимость, не получалось понять валовую прибыль
Чтобы навести порядок в учёте и исправить ошибки на миллионы рублей, нужно было решить несколько задач:
исправить прошлые периоды
наладить учет, чтобы ошибки не допускались в текущем периоде
научить пользователей клиента принципам работы с себестоимостью в 1С:УНФ
получить достоверную валовую прибыль
Ход проекта
Ход проекта можно отобразить простой картинкой =)
Отрицание
Изначально нам и клиенту казалось, что больших проблем нет и всё можно легко исправить. Например, достаточно грамотно перепровести Закрытие месяца. Исходили из предположения, что в учете все в порядке, достаточно автоматических типовых алгоритмов, которые легко и быстро исправят все проблемы. К сожалению, это не помогло.
Закрытие месяца решало далеко не все проблемы. Более того, в какой-то момент Закрытие месяца просто переставало работать и ругалось ошибкой на английском языке.
Такая ошибка возникает, если в учете есть отрицательные остатки. Без исправления этих остатков алгоритм не может отработать на уровне Базы данных (SQL-сервера).
Гнев
Конечно, и у заказчика, и у нас первая реакция — поругаться.
Как можно было так вести учет и ничего не контролировать?
Как можно было просто перенести все документы с 2016 года? Это явно сложная операция, типовых переносов нет, был заказан перенос у 1С программистов за сотни тысяч рублей.
Как сейчас исправить учет за 6 лет в УНФ? Получить нормальный учет в 2022 году нельзя без исправления всех проблем себестоимости.
Но гнев непродуктивен, поэтому начали думать, что делать дальше.
Торг
Когда мы погрузились в проблему, стало понятно, что вручную ситуацию не исправить. Требуется корректировка первичных документов, исправление дат, резервов и т.п.
Попутно мы выявили проблемы в доработках и переносе данных. Некоторые перенесенные документы нельзя было перепровести: возникала ошибка. Приходилось писать обработки, использовать хитрые обработки документов и даже корректировки движений документов.
Поэтому возникла мысль каким-то образом автоматически исправить проблемы до 2022 года и с 2022 уже аккуратно налаживать учет.
Что не помогло решить проблему?
Свертка базы
Первая и простая мысль — сделать свертку данных. То есть обрезать базу и на начало 2022 года оставить только остатки. А дальше все будет хорошо.
К сожалению, свертка базы часто не помогает решить проблему. При свёртке все проблемы учета, минуса и прочее заносятся в один общий документ «Корректировка регистров», в котором потом просто не разобраться. Более подробно о проблемах свертки мы разбирались в нашей статье.
Что будет если свернуть базу?
Магии не случится
Будет огромный документ со всеми остатками
Остатки будут на тех же кривых аналитиках. Чтобы их исправить, надо будет как-то править документ остатков, а там будет 10-20 тысяч строк — вручную не исправишь
Будет куча старых документов с 2016 года, помеченных на удаление, которые потом нельзя удалить. Они сохраняются, чтобы сохранилась аналитика
«Обнулить» остатки, сделать инвентаризацию и начать аккуратный учет — нереально. Инвентаризация может занять месяцы, слишком много остатков
Непонятно, какую себестоимость поставить на получившиеся остатки
От этой идеи пришлось отказаться: итоге свертки мы бы получили те же самые проблемы, только исправить их было бы сложнее.
Написать магическую обработку, которая все исправит
Следующая мысль — написать хитрый алгоритм, который сделает документ Корректировка регистров и все исправит «хирургическим путём».
Мы изучали проблемы по отчетам себестоимости и придумали алгоритмы, которые исправляли много проблем. Но в процессе исправлений выяснилось, что вариантов проблем слишком много. Придумать алгоритм, который все исправит сразу, невозможно.
А то, что мы исправляли автоматически — ломалось при исправлении других проблем. А если тронешь задний период, все исправления текущим периодом становятся неактуальны.
От обработки тоже пришлось отказаться.
Поэтому мы пошли старым проверенным путем — анализировать и исправлять проблемы вручную. В ходе исправления проблем смогли сделать несколько обработок, которые помогали автоматически исправлять некоторые ситуации и облегчить дальнейшую работу.
Депрессия
Итак, мы начали исправлять проблемы вручную.
У нас был проверенный инструмент — Экспресс проверка учета, который показывает проблемы, которые нужно поправить, и делает это удобнее, чем просто анализ проблем в Закрытии месяца.
Мы выявляли проблемы отчетом, из него переходили в типовой отчет Запасы и там уже исправляли остатки:
снимали или ставили резервы
меняли даты документов, например, даты Приходных накладных от поставщиков, это не хорошо, но других приемлемых вариантов исправлений не было
исправляли счета учета в документах
исправляли ошибки логики и доработок
делали оприходование товаров, которые на текущий момент так и оставались в минусах
получали новые проблемы, которых раньше не было из-за хитросплетений цепочек документов.
С удивлением пришлось узнать, что в типовой УНФ в документ Инвентаризация не попадают Номенклатуры у которых установлен признак Недействительная. А у нас как раз тысячи недействительной номенклатуры с минусами. пришлось дорабатывать этот момент.
перезакрывали месяцы по 10 раз (кстати, в этом нам помогала наша разработка, которая позволяет закрывать месяца за период)
Не знаю, чтобы мы делали без Экспресс проверки (но сам себя не похвалишь, никто не похвалит =))). Наверное, пришлось бы потратить раза в 3 больше времени или в 10. Причем, пришло в голову много идей по доработке Экспресс проверки, которые тоже позволили ускорить процесс.
Я просидел несколько ночей и выровнял 2016 год =)
Это уже была некоторая победа, Закрытие месяца заработало, я увидел заветное «Ошибок не обнаружено» в исправленных периодах.
Но какой ценой =(
Казалось, что если исправление нескольких месяцев 2016 года занимает несколько дней работы специалиста-эксперта, то исправить все данные до 2022 года — не понятно как.
Оператора не посадишь, заниматься исправлением самому — звучит удручающе и расточительно.
Мы погрузились в депрессию.
Принятие
Никакого другого выхода не было — только исправлять ошибки вручную. Нужно засучить рукава и продолжать работать.
разделили работы на несколько человек
подключили к исправлению бухгалтерию заказчика
взяли в команду разработчиков, которые помогали с локальными исправлениями и придумывали небольшие алгоритмы оптимизации
стали дорабатывать Экспресс-проверку для более удобной и быстрой работы
Алгоритм, довольно банальный:
Берем месяц
Делаем его закрытие
Строим Экспресс-проверку
Выявляем проблемы и исправляем
Делаем закрытие
Строим Экспресс-проверку…
Выявляем и исправляем следующие проблемы, в том числе привнесенные исправлениями (из-за сложных цепочек документов)
И так пока все проблемы не будут решены
Да, это неприятно, дорого, но волшебной пилюли нет. Если много лет учет не велся и его никто не контролировал в какой-то момент нужно хорошо поработать.
Грубо говоря, на исправление одного месяца требовалось 2-3 часа внимательной работы экспертов УНФ. Крик души! Пожалуйста, не запускайте учет, не выключайте контроль отрицательных остатков =)
Мы все понимаем, на старте бизнеса важен сам бизнес, а не его корректный учет, но когда-то придется все же учет налаживать. Просто к этому надо быть готовым.
Стадии автоматизации мы подробно рассматривали на нашем вебинаре.
Что сейчас?
Мы выровняли себестоимость, взаиморасчеты, баланс и прочие проблемы на начало 2022 года.
Что мы сделали, чтобы не допустить беспорядка в будущем
Самое важное — мы настроили строгий контроль остатков при проведении документов.
УНФ в типовом варианте контролирует остатки только на текущую дату. Мы установили собственную доработку, которая позволяет контролировать остатки на дату документа (как в 1С:Бухгалтерии)
Дальше мы пересмотрели некоторые процессы и доработки, убрали лишние, доделали свои.
Сколько времени и денег на это ушло
Основные работы по исправлению себестоимости у нашего ведущего специалиста заняли примерно 3 недели и 100 часов работ. Исправили больше 6 000 документов — руками и специально написанными доработками, перезакрывали месяца и были исправлены сопутствующие проблемы (разнесение первички по счетам учета затрат, закрытие финансового результата, выравнивание баланса и т.п.).
В результате получили вот такую картину.
Кроме этого мы серьезно доработали механизмы автоматических проверок, для быстрого выявления проблем.
100 часов, это примерно 250 000 рублей. Много это или мало? Для текущей задачи — скорее мало. В нашем случае работы выполнялись экспертом по УНФ, нормальная трудоемкость для подобной работы с учетом выравнивания 5 лет работы может быть и 200 и 300 часов.
Конечно, если включить в работу сотрудников заказчика, то бюджет будет соразмерно уменьшаться, но сроки будут скорее всего сильно больше.
Какая следующая задача?
После успешного решения проблем себестоимости перед нами стоят следующие сложные задачи
наладить обмен с 1С:Бухгалтерией
дальше выстраивать управленческий учет
улучшать процессы и повышать доверие к цифрам УНФ.
Тут, к сожалению, тоже типовой инструкцией не обойтись. Нужно будет дополнительно пересматривать процессы работы в УНФ, сделать некоторые доработки-исправления данных, налаживать инструменты контроля.
Но нам не страшно, это наша работа =)
14 февраля 2023
Как в 1С:УНФ восстановить учет с 2016 года, исправить миллионы рублей неверных остатков и не умереть
Клиент: —
Внедренный продукт: Расширение Экспресс-проверка учета
Содержание статьи:
Наш клиент — ООО «Славяна», занимается оптовой продажей молочной продукции. Компания ведёт учёт в 1С:Комплексной автоматизации 2.5, в серверном режиме. С 1С работают примерно 50 пользователей.
Ситуация
При работе в серверном режиме вся информация и базы данных физически хранятся на сервере. Если с сервером что-то случается, данные можно потерять. Например:
физическая поломка
перепады напряжения
потоп или пожар в здании, где хранится сервер
вирусы
Восстановление сервера может затянуться и занять несколько недель.
«На нашем опыте, практически всегда, когда в систему проникал вирус-шифровальщик, клиент платил 50 000–200 000 ₽ за расшифровку данных. Если сделать это было невозможно, искали случайно завалявшуюся копию базы данных 2-3-летней давности и восстанавливали данные в ручном режиме. Бухгалтеры или операторы переносили информацию с бумажных документов в 1С.
Ещё может быть поломка диска, на котором хранятся базы данных. При этом резервное копирование не выполняется (например, повреждена какая-то таблица в базе данных). К моменту, когда диск окончательно выходит из строя, оказывается, что резервных копий нет за последние несколько месяцев.»
Антон Терехов, технический специалист
Для компании критичен простой в работе, поэтому решили действовать «на опережение» и сделать работу с 1С отказоустойчивой: даже если с сервером что-то случится, можно восстановить базу и продолжить работу с 1С уже через 10–15 минут после поломки.
Решение: два физических сервера в разных офисах
Построили работу так, чтобы всегда иметь актуальную копию базы данных и при необходимости быстро ввести её в работу.
На уровне системы управления базами данных PostgreSQL построили кластер из двух физических серверов. На каждом из них установили сервер 1С и добавили информационные базы.
сервер master — основной. На нем работают пользователи в привычном режиме;
второй сервер — slave, резервный. Он находится в другом офисе, обычно пользователи в нём не работают.
Каждое действие в базе на основном сервере в режиме реального времени переносится и в базу на втором сервере.
Если основной сервер выходит из строя, резервный сервер переключают в режим основного. Пользователи, которые работали в базе, перезаходят по адресу второго сервера и продолжают работать с теми же данными, что и раньше.
Когда основной сервер восстанавливают, его возвращают в кластер и обновляют базу до актуального состояния. Сервер переключают в режим основного, а второй сервер снова становится резервным.
Решили проблему с производительностью и блокировками
У клиента большие базы данных, поэтому создание резервной копии обычно идёт больше часа. Раньше при создании резервной копии падала производительность дисковой системы и проскакивали ошибки блокировок. Подобрать оптимальное время для резервного копирования тоже не получалось, так как пользователи работают с базой почти постоянно.
Мы перенесли резервное копирование на реплику базы данных, это решило все проблемы.
Какие затраты на настройку отказоустойчивости
Для такой настройки понадобится два сервера и часы работы наших специалистов. Серверы будут стоить примерно 80-100 000 ₽, зависит от производителя и мощности.
Наши специалисты потратили около 10 часов на подключение и настройку всей системы. Ещё около 15 часов — на доработку резервного копирования под нужды клиента.
Настроим отказоустойчивую работу с 1С или поможем решить другие задачи:
поможем подобрать оборудование для работы
настроим обмены между программами 1С или сторонними программами
будем ежемесячно помогать с серверами: следить за программным обеспечением и нагрузкой на оборудование, предотвращать проблемы и поломки
Обсудить со специалистом
Содержание статьи:
Наш клиент — ООО «Славяна», занимается оптовой продажей молочной продукции. Компания ведёт учёт в 1С:Комплексной автоматизации 2.5, в серверном режиме. С 1С работают примерно 50 пользователей.
Ситуация
При работе в серверном режиме вся информация и базы данных физически хранятся на сервере. Если с сервером что-то случается, данные можно потерять. Например:
физическая поломка
перепады напряжения
потоп или пожар в здании, где хранится сервер
вирусы
Восстановление сервера может затянуться и занять несколько недель.
«На нашем опыте, практически всегда, когда в систему проникал вирус-шифровальщик, клиент платил 50 000–200 000 ₽ за расшифровку данных. Если сделать это было невозможно, искали случайно завалявшуюся копию базы данных 2-3-летней давности и восстанавливали данные в ручном режиме. Бухгалтеры или операторы переносили информацию с бумажных документов в 1С.
Ещё может быть поломка диска, на котором хранятся базы данных. При этом резервное копирование не выполняется (например, повреждена какая-то таблица в базе данных). К моменту, когда диск окончательно выходит из строя, оказывается, что резервных копий нет за последние несколько месяцев.»
Антон Терехов, технический специалист
Для компании критичен простой в работе, поэтому решили действовать «на опережение» и сделать работу с 1С отказоустойчивой: даже если с сервером что-то случится, можно восстановить базу и продолжить работу с 1С уже через 10–15 минут после поломки.
Решение: два физических сервера в разных офисах
Построили работу так, чтобы всегда иметь актуальную копию базы данных и при необходимости быстро ввести её в работу.
На уровне системы управления базами данных PostgreSQL построили кластер из двух физических серверов. На каждом из них установили сервер 1С и добавили информационные базы.
сервер master — основной. На нем работают пользователи в привычном режиме;
второй сервер — slave, резервный. Он находится в другом офисе, обычно пользователи в нём не работают.
Каждое действие в базе на основном сервере в режиме реального времени переносится и в базу на втором сервере.
Если основной сервер выходит из строя, резервный сервер переключают в режим основного. Пользователи, которые работали в базе, перезаходят по адресу второго сервера и продолжают работать с теми же данными, что и раньше.
Когда основной сервер восстанавливают, его возвращают в кластер и обновляют базу до актуального состояния. Сервер переключают в режим основного, а второй сервер снова становится резервным.
Решили проблему с производительностью и блокировками
У клиента большие базы данных, поэтому создание резервной копии обычно идёт больше часа. Раньше при создании резервной копии падала производительность дисковой системы и проскакивали ошибки блокировок. Подобрать оптимальное время для резервного копирования тоже не получалось, так как пользователи работают с базой почти постоянно.
Мы перенесли резервное копирование на реплику базы данных, это решило все проблемы.
Какие затраты на настройку отказоустойчивости
Для такой настройки понадобится два сервера и часы работы наших специалистов. Серверы будут стоить примерно 80-100 000 ₽, зависит от производителя и мощности.
Наши специалисты потратили около 10 часов на подключение и настройку всей системы. Ещё около 15 часов — на доработку резервного копирования под нужды клиента.
Настроим отказоустойчивую работу с 1С или поможем решить другие задачи:
поможем подобрать оборудование для работы
настроим обмены между программами 1С или сторонними программами
будем ежемесячно помогать с серверами: следить за программным обеспечением и нагрузкой на оборудование, предотвращать проблемы и поломки
Обсудить со специалистом
14 февраля 2023
Клиент: Эксимторг
Внедренный продукт: —
Отрасль: Торговля
Содержание:
Наш клиент — книжный портал БукРивер. Это портал для авторов и читателей. Авторы могут быстро зарегистрироваться и продавать свои произведения. Читатели — заводят на портале кошелёк и из него оплачивают книги, которые хотят читать.
Проблема: данные о взаиморасчетах БукРивера и автора не переносились в бухучет
БукРивер работает по принципу маркетплейса:
читатель платит автору вознаграждение за книгу, которую хочет читать
автор получает вознаграждение, когда его книгу купили
портал берет комиссию за вознаграждение
При этом важно учитывать взаиморасчеты между порталом и автором, комиссию с вознаграждения автора.
В конце каждого отчетного периода БукРиверу нужно подсчитать доходы и уплатить налоги только с части своих доходов — то есть с комиссии за продажу книг.
Проблема заключалась в том, у клиента не было учетной системы для ведения бухгалтерского учета, а транзакций на покупку книг было слишком много, чтобы вводить эту информацию вручную.
Настроили интеграцию маркетплейса БукРивер и 1С:Бухгалтерии
В качестве учетной системы выбрали 1С:Бухгалтерию 3.0.
Нам нужно было «подружить» портал клиента и 1С:Бухгалтерию: настроить интеграцию, чтобы загружать данные о продажах книг, собирать отчетность и учитывать комиссию с продаж.
По каждому автору можно посмотреть расшифровку продаж и % удержанной комиссии.
Интеграцию БукРивера и 1С:Бухгалтерии настроили по API
Для этого мы сделали модуль интеграции книжного маркетплейса и 1С с загрузкой данных по API. БукРивер предоставил нам API портала, мы изучили его работу и настроили интеграцию
В 1С загружаются не все операции происходящие на торговой площадке, а только те, которые необходимы для корректного отображения доходов.
Этапы разработки и интеграции модуля
Процесс разработки и интеграции модуля можно разделить на несколько этапов:
1. Определили правила сопоставления справочной информации.
Чтобы интегрировать данные правильно, нужно было сопоставить авторов и читателей на портале с контрагентами в базе 1С. Для этого разработали совместные правила сопоставления справочников с порталом.
2. Определили виды операций для загрузки в 1С:Бухгалтерию. На этом этапе мы работали вместе с разработчиками клиента по API.
Совместно разрабатывали правила и идентификаторы полей, которые было важно загрузить в 1С.
3. Составлили ТЗ для разработки модуля интеграции на основании изученной информации от портала.
4. Тестирование, выявление багов, исправление.
5. Загрузка данных о продажах в 1С.
В результате, мы получили модуль загрузки данных по API. Чтобы не загружать данные вручную, настроили автозагрузку продаж по расписанию. Во время загрузки происходит сопоставление справочников, что позволяет избежать дублей.
Клиент в любой момент может получить в 1С:Бухгалтерии актуальную информацию по продажам и предварительно рассчитать налоги.
Содержание:
Наш клиент — книжный портал БукРивер. Это портал для авторов и читателей. Авторы могут быстро зарегистрироваться и продавать свои произведения. Читатели — заводят на портале кошелёк и из него оплачивают книги, которые хотят читать.
Проблема: данные о взаиморасчетах БукРивера и автора не переносились в бухучет
БукРивер работает по принципу маркетплейса:
читатель платит автору вознаграждение за книгу, которую хочет читать
автор получает вознаграждение, когда его книгу купили
портал берет комиссию за вознаграждение
При этом важно учитывать взаиморасчеты между порталом и автором, комиссию с вознаграждения автора.
В конце каждого отчетного периода БукРиверу нужно подсчитать доходы и уплатить налоги только с части своих доходов — то есть с комиссии за продажу книг.
Проблема заключалась в том, у клиента не было учетной системы для ведения бухгалтерского учета, а транзакций на покупку книг было слишком много, чтобы вводить эту информацию вручную.
Настроили интеграцию маркетплейса БукРивер и 1С:Бухгалтерии
В качестве учетной системы выбрали 1С:Бухгалтерию 3.0.
Нам нужно было «подружить» портал клиента и 1С:Бухгалтерию: настроить интеграцию, чтобы загружать данные о продажах книг, собирать отчетность и учитывать комиссию с продаж.
По каждому автору можно посмотреть расшифровку продаж и % удержанной комиссии.
Интеграцию БукРивера и 1С:Бухгалтерии настроили по API
Для этого мы сделали модуль интеграции книжного маркетплейса и 1С с загрузкой данных по API. БукРивер предоставил нам API портала, мы изучили его работу и настроили интеграцию
В 1С загружаются не все операции происходящие на торговой площадке, а только те, которые необходимы для корректного отображения доходов.
Этапы разработки и интеграции модуля
Процесс разработки и интеграции модуля можно разделить на несколько этапов:
1. Определили правила сопоставления справочной информации.
Чтобы интегрировать данные правильно, нужно было сопоставить авторов и читателей на портале с контрагентами в базе 1С. Для этого разработали совместные правила сопоставления справочников с порталом.
2. Определили виды операций для загрузки в 1С:Бухгалтерию. На этом этапе мы работали вместе с разработчиками клиента по API.
Совместно разрабатывали правила и идентификаторы полей, которые было важно загрузить в 1С.
3. Составлили ТЗ для разработки модуля интеграции на основании изученной информации от портала.
4. Тестирование, выявление багов, исправление.
5. Загрузка данных о продажах в 1С.
В результате, мы получили модуль загрузки данных по API. Чтобы не загружать данные вручную, настроили автозагрузку продаж по расписанию. Во время загрузки происходит сопоставление справочников, что позволяет избежать дублей.
Клиент в любой момент может получить в 1С:Бухгалтерии актуальную информацию по продажам и предварительно рассчитать налоги.
14 февраля 2023
Клиент: Маркетплейс БукРивер
Внедренный продукт: 1С:Бухгалтерия
Отрасль: Торговля
Задать вопрос