Реализованные проекты
Содержание кейса:
Наш клиент — компания Аспект. Клиент производит игрушки, и продаёт их оптом и в розницу.
Учёт ведут в программах 1С:Розница, 1С:Управление торговлей 11, 1С:Бухгалтерия и КАМИН:Расчёт заработной платы.
У клиента несколько информационных баз 1С разного объёма — 30–400 ГБ и с разным количеством пользователей — 20–90.
С программами 1С в компании работают в серверном режиме: есть пул серверов на Windows Server, сервер 1С и сервер с системой управления базами данных — СУБД MS SQL.
Клиент обратился с проблемой
Купить лицензии «Майкрософт» сейчас проблематично, поэтому нужно быть заменить СУБД MS SQL на другое программное обеспечение.
Для перехода выбрали бесплатные версии PostgreSQL и «Линукс», что позволило сэкономить на лицензиях. Для перехода нужно было установить операционную систему и перенести информационные базы 1С.
Что мы сделали
Помогли клиенту выбрать операционную систему — Ubuntu Server 22.04 LTS. Эту ОС выбрали, потому что система активно поддерживается разработчиками, в интернете есть масса информации по подключению, настройке и работе с Ubuntu. К тому же, клиент уже использовал серверы на этой операционной системе для других задач.
Перенесли информационные базы с MS SQL на серверы PostgreSQL
Сначала на новые серверы поставили ту же платформу, что была раньше — 8.3.17.1851. Позже обновили платформу 1С — до свежего релиза 8.3.21.1624.
Были два варианта для системы управления базами данных:
Сборка PostgreSQL 14.5-3.1C от 1С
Сборка от команды Postgres Professional PostgreSQL 1C-15.1.
Выбрали этот вариант. Его удобнее устанавливать, можно почти автоматически настроить СУБД под аппаратное обеспечение сервера.
Сначала решили настроить изолированные сервер 1С и сервер СУБД — так у клиента было до переноса.
Для сервера 1С определили аппаратное оснащение: выбрали 12 CPU, максимально доступное для ПРОФ лицензии 1С, 64 ГБ ОЗУ и 150 ГБ дискового пространства. Этого должно было хватить для операционной системы, сервера 1С, кэша и журналов регистрации.
Для СУБД выделили 16 CPU, 64 ГБ ОЗУ, 30 ГБ под системный раздел и 300 ГБ накопителя, чтобы дальше можно было расширить файловую систему для новых информационных баз.
При переносе столкнулись с проблемой
Изначально была информация, что база данных у клиента 30 ГБ, оказалось — 250. При переносе сначала база помещается во временную папку сервера 1С, а уже потом в СУБД.
Так сделать не получалось, потому что на системном диске сервера 1С не хватало места.
Проблему решили так:
временно добавили ещё один жёсткий диск на сервер 1С
переписали юнит запуска службы 1С и перенаправили папку TEMP на временный диск
загрузили ДТ и отмонтировали диск. То есть это пространство на диске мы не используем постоянно, а добавляем лишь когда загружаем или выгружаем данные — это происходит редко
Следующая проблема, с которой мы столкнулись — «исторический опыт», который был у клиента при работе с Майкрософт. Если сотрудникам нужно было создать новую базу или копию текущей, они просто добавляли новый диск и на нём размещали базу.
На PostgreSQL так не получается — каждый кластер сервера инициализируется в одну директорию. Разделить кластер по разным дискам прямым способом невозможно.
Предложили два варианта, чтобы решить эту проблему:
Установить на одном сервере несколько копий СУБД, каждая копия бы работала на своём порте и с отдельным каталогом баз.
При этом пришлось бы вручную настраивать каждый экземпляр сервера — необходимое количество памяти, доступных процессов и так далее. Отказоустойчивость тоже была бы ниже — при отключении сервера стали недоступны все информационные базы.
Для каждой информационной базы создавать отдельный сервер.
Этот вариант проще реализовать и поддерживать, поэтому выбрали его.
Шаблон для новой базы сотрудники создавали по одной схеме:
выбирали количество процессоров и памяти под нужные мощности
добавляли диск нужного размера под базу данных
указывали имя и адрес сервера
добавляли диск в систему и запускал кластер с минимальными настройками.
Так как процесс был повторяющимся, мы написали скрипт — всё происходит автоматически и с минимальными затратами времени. Пользователю остаётся только ввести имя и ip-адрес сервера. Остальное система делает автоматически.
У клиента была ещё одна проблема
Программные лицензии 1С при установке «запоминают» параметры сервера, на котором они установлены: объём памяти, количество процессоров и так далее. Если сервер 1С «мигрировал» внутри системы виртуализации, эти параметры могут измениться — тогда придётся заново активировать программные лицензии, в это время работать в 1С не получится.
Мы предложили такое решение: разместить отдельный сервер 1С со статическими характеристиками, который раздавал лицензии. Для этого мы развернули ещё один виртуальный сервер 1С и добавили его в кластер к основному серверу. Так отдельный сервер 1С отвечает за выдачу лицензий и при этом его параметры никогда не изменяются.
На все работы у нас ушло 10 часов.
Какой результат получил клиент
перешли на серверы PostgreSQL — они проще в обслуживании и поддержке, дешевле, чем MS SQL
сократили время на создание новой копии для базы — автоматический скрипт делает всё сам, пользователю остаётся только ввести имя и адрес сервера
лицензии перестали «слетать» — работа стала проще и стабильнее
Что дальше
Дальше планируем расширить мощности кластера сервера 1С и внедрить туда ещё один сервер 1С, чтобы обрабатывать клиентские запросы.
Помогаем в работе с 1С в серверном режиме:
поможем подобрать оборудование для работы
перенесём информационные базы на серверы
по договору администрирования серверов ежемесячно следим за программным обеспечением и нагрузкой на серверы, настраиваем программы под оборудование, контролируем резервное копирование
Оставить заявку
Содержание кейса:
Наш клиент — компания Аспект. Клиент производит игрушки, и продаёт их оптом и в розницу.
Учёт ведут в программах 1С:Розница, 1С:Управление торговлей 11, 1С:Бухгалтерия и КАМИН:Расчёт заработной платы.
У клиента несколько информационных баз 1С разного объёма — 30–400 ГБ и с разным количеством пользователей — 20–90.
С программами 1С в компании работают в серверном режиме: есть пул серверов на Windows Server, сервер 1С и сервер с системой управления базами данных — СУБД MS SQL.
Клиент обратился с проблемой
Купить лицензии «Майкрософт» сейчас проблематично, поэтому нужно быть заменить СУБД MS SQL на другое программное обеспечение.
Для перехода выбрали бесплатные версии PostgreSQL и «Линукс», что позволило сэкономить на лицензиях. Для перехода нужно было установить операционную систему и перенести информационные базы 1С.
Что мы сделали
Помогли клиенту выбрать операционную систему — Ubuntu Server 22.04 LTS. Эту ОС выбрали, потому что система активно поддерживается разработчиками, в интернете есть масса информации по подключению, настройке и работе с Ubuntu. К тому же, клиент уже использовал серверы на этой операционной системе для других задач.
Перенесли информационные базы с MS SQL на серверы PostgreSQL
Сначала на новые серверы поставили ту же платформу, что была раньше — 8.3.17.1851. Позже обновили платформу 1С — до свежего релиза 8.3.21.1624.
Были два варианта для системы управления базами данных:
Сборка PostgreSQL 14.5-3.1C от 1С
Сборка от команды Postgres Professional PostgreSQL 1C-15.1.
Выбрали этот вариант. Его удобнее устанавливать, можно почти автоматически настроить СУБД под аппаратное обеспечение сервера.
Сначала решили настроить изолированные сервер 1С и сервер СУБД — так у клиента было до переноса.
Для сервера 1С определили аппаратное оснащение: выбрали 12 CPU, максимально доступное для ПРОФ лицензии 1С, 64 ГБ ОЗУ и 150 ГБ дискового пространства. Этого должно было хватить для операционной системы, сервера 1С, кэша и журналов регистрации.
Для СУБД выделили 16 CPU, 64 ГБ ОЗУ, 30 ГБ под системный раздел и 300 ГБ накопителя, чтобы дальше можно было расширить файловую систему для новых информационных баз.
При переносе столкнулись с проблемой
Изначально была информация, что база данных у клиента 30 ГБ, оказалось — 250. При переносе сначала база помещается во временную папку сервера 1С, а уже потом в СУБД.
Так сделать не получалось, потому что на системном диске сервера 1С не хватало места.
Проблему решили так:
временно добавили ещё один жёсткий диск на сервер 1С
переписали юнит запуска службы 1С и перенаправили папку TEMP на временный диск
загрузили ДТ и отмонтировали диск. То есть это пространство на диске мы не используем постоянно, а добавляем лишь когда загружаем или выгружаем данные — это происходит редко
Следующая проблема, с которой мы столкнулись — «исторический опыт», который был у клиента при работе с Майкрософт. Если сотрудникам нужно было создать новую базу или копию текущей, они просто добавляли новый диск и на нём размещали базу.
На PostgreSQL так не получается — каждый кластер сервера инициализируется в одну директорию. Разделить кластер по разным дискам прямым способом невозможно.
Предложили два варианта, чтобы решить эту проблему:
Установить на одном сервере несколько копий СУБД, каждая копия бы работала на своём порте и с отдельным каталогом баз.
При этом пришлось бы вручную настраивать каждый экземпляр сервера — необходимое количество памяти, доступных процессов и так далее. Отказоустойчивость тоже была бы ниже — при отключении сервера стали недоступны все информационные базы.
Для каждой информационной базы создавать отдельный сервер.
Этот вариант проще реализовать и поддерживать, поэтому выбрали его.
Шаблон для новой базы сотрудники создавали по одной схеме:
выбирали количество процессоров и памяти под нужные мощности
добавляли диск нужного размера под базу данных
указывали имя и адрес сервера
добавляли диск в систему и запускал кластер с минимальными настройками.
Так как процесс был повторяющимся, мы написали скрипт — всё происходит автоматически и с минимальными затратами времени. Пользователю остаётся только ввести имя и ip-адрес сервера. Остальное система делает автоматически.
У клиента была ещё одна проблема
Программные лицензии 1С при установке «запоминают» параметры сервера, на котором они установлены: объём памяти, количество процессоров и так далее. Если сервер 1С «мигрировал» внутри системы виртуализации, эти параметры могут измениться — тогда придётся заново активировать программные лицензии, в это время работать в 1С не получится.
Мы предложили такое решение: разместить отдельный сервер 1С со статическими характеристиками, который раздавал лицензии. Для этого мы развернули ещё один виртуальный сервер 1С и добавили его в кластер к основному серверу. Так отдельный сервер 1С отвечает за выдачу лицензий и при этом его параметры никогда не изменяются.
На все работы у нас ушло 10 часов.
Какой результат получил клиент
перешли на серверы PostgreSQL — они проще в обслуживании и поддержке, дешевле, чем MS SQL
сократили время на создание новой копии для базы — автоматический скрипт делает всё сам, пользователю остаётся только ввести имя и адрес сервера
лицензии перестали «слетать» — работа стала проще и стабильнее
Что дальше
Дальше планируем расширить мощности кластера сервера 1С и внедрить туда ещё один сервер 1С, чтобы обрабатывать клиентские запросы.
Помогаем в работе с 1С в серверном режиме:
поможем подобрать оборудование для работы
перенесём информационные базы на серверы
по договору администрирования серверов ежемесячно следим за программным обеспечением и нагрузкой на серверы, настраиваем программы под оборудование, контролируем резервное копирование
Оставить заявку
30 января 2023
Клиент: Аспект
Внедренный продукт: Серверы PostgreSQL
Отрасль: Производство
Содержание кейса:
Наш клиент — компания ЮгАвтоХолдинг. Компания продаёт дорожную технику и занимается её гарантийным и постгарантийным обслуживанием. В штате 15 сотрудников, оборот компании — больше 300 миллионов рублей.
Управленческий учёт в Word и Excel
К автоматизации компания пришла не сразу. Долго гарантийное обслуживание и услуги для клиентов учитывали в MS Word и MS Excel. Бухгалтерский учет вели в базовой 1С:Бухгалтерии.
Росла клиентская база, услуги по гарантийному обслуживанию выделили в отдельное направление. Поэтому нужно было подобрать удобную CRM-систему, в которой можно было бы учитывать оказание услуг и производственные работы.
Какие были задачи?
создать общую базу контактов по стандарту. Важно было, чтобы хранилась история взаимодействий с клиентом: от звонков для заключения договоров и продаж
учитывать работы по гарантийному и постгарантийному обслуживанию проданной техники
учитывать складские остатки основных товаров и запчастей
создать унифицированный документооборот с контрагентами
Как изменилась работа с переходом на 1С:УНФ
Ускорили оформление документов для продажи
В зависимости от вариантов оплаты отличаются условия договора. До работы в программе менеджеры часто допускали ошибки, составляя в MS Word договор и копируя отдельные его пункты. Эту проблему решили при помощи «Платежного календаря» в документе «Заказ покупателя» и добавления реквизита «Условия оплаты».Теперь форма договора формируется в автоматическом режиме.
На базе документа «Заказ покупателя» мы разработали процедуру оформления документов, начиная от выставления коммерческого предложения до заключения договора и заканчивая оформлением акта приема-передачи товара.
В документе «Расходная накладная» добавили реквизит «Лизингополучатель». Часто в нашей сфере в сделке выступает покупателем лизинговая организация, но для нас важно знать конечного потребителя
Разграничили доступ менеджеров к клиентской базе
В компании за каждым менеджером закреплены разные категории клиентов. Раньше у каждого менеджера был доступ ко всей клиентской базе. Это создавало путаницу и усложняло работу с клиентами.
В 1С:УНФ менеджеру видны только его клиенты и история работы с ними. Это повышает безопасность и снижает риск увода клиентской базы.
Поскольку менеджеры не видят всю базу клиентов, они могут пытаться создать нового контрагента, который уже существует в базе, но с другим правом доступа. Чтобы исключить дубли контрагентов, поставили категорический запрет на подобные операции.
«Заказ-наряд» сделали универсальным документом
для работы с клиентом
Гарантийное и сервисное обслуживание проданного товара отражается в системе с помощью документа «Заказ-наряд». Он одновременно является документом планирования работ, актом выполненных работ, документом реализации и документом списания.
Гарантийный период предполагает прохождение технического обслуживания. Его состав работ и требуемые материалы зависят от наработки моточасов дорожной техники.
Нужно было, чтобы клиент видел состав работ, перечень материалов и их стоимость. Чтобы каждый раз не вносить одни и те же материалы, создали наборы с перечнем и количеством используемых материалов. Для наборов предусмотрены вариации отражения в печатных формах цены и состава набора.
Стали быстрее вести бухгалтерский учёт с ЭДО
Электронные документы поступают непосредственно в базу 1С, бухгалтеру нужно только сопоставить номенклатуру поставщика и нашу, и нужный документ создается автоматически с заполненной информацией.
Все электронные документы хранятся в базе данных 1С. Это оказалось вовремя — товары компании попали в категорию прослеживаемых товаров, поэтому обмениваться с поставщиками и покупателями электронными документами — обязательно.
Упростили налоговый и бухгалтерский учёт
с синхронизацией 1С:УНФ и 1С:Бухгалтерии
Настроили автоматический обмен: все операции отражаются в 1С:УНФ и по настроенному сценарию переносятся в 1С:Бухгалтерию с заполненной информацией для отображения в бухгалтерском учете и составления налоговой отчетности.
Главным преимуществом синхронизации стало то, что теперь абсолютно все операции отражаются в «1С:УНФ», и она стала первичной, а «1С:Бухгалтерия» — вторичной. Это означает то, что теперь можно формировать множество отчетов для руководителя, а не для бухгалтера: о деловой активности фирмы, объемах продаж, доходах и расходах организации, товарных и финансовых запасах, взаиморасчетах и прочих показателях.
Мобильное приложение 1С:УНФ
Для управления компанией из любой точки подключили мобильное приложение 1С:УНФ. В нём можно в любой момент просмотреть управленческую отчётность о компании. Единственное требование для работы в мобильном приложении — чтобы база была опубликована на веб-сервере.
Автоматически учитываем топливо и штрафы ГИБДД
С помощью внешних доработок добавили в 1С:УНФ новые функции: автоматизировали ведение путевых листов, учет штрафов ГИБДД и формирование платежных поручений для оплаты этих штрафов.
У менеджеров и сервисных инженеров преимущественно разъездной характер работы. В служебном автопарке больше 10 машин. Ручное заполнение путевых листов и учета ГСМ при таком количестве машин было проблемой. Теперь каждый сотрудник самостоятельно заполняет путевые листы, а расход топлива рассчитывается, исходя из нормы. Руководитель всегда в курсе текущих расходов на ГСМ, а информация по штрафам учитывается при расчете заработной платы сотрудников.
Использование платежного календаря
Мы создали документы «Заявка на расход денег» по всем ежемесячным платежам и добавляем заявки на незапланированные предстоящие расходы.
Документы «Заказ покупателя» и «Заказ-наряд» отражают в платежном календаре ожидаемые поступления.
Заявки на расход денег утверждает руководитель, после чего бухгалтер на их основании формирует платежные поручения и выгружает их в банк-клиент. После исполнения платежа загружаем банковскую выписку в «1С:УНФ». Так мы видим всю цепочку платежа: от заявки до исполнения, а платежный календарь наглядно показывает ежемесячные платежи и ожидаемые поступления, что позволяет не допускать кассовых разрывов.
Уменьшили затраты на бухучёт и работу с клиентами
С помощью 1С:УНФ стали тратить меньше труда и времени на учёт и работу с клиентами. Каждый отдел работает со своей зоной ответственности: менеджеры продаж ведут клиентскую базу
оформляют заявки на продажи
сервисный отдел отвечает за оформление заказ-нарядов
бухгалтер отвечает за финансовую составляющую и выполняет контрольные функции
Исключили дублирование операций и сократили ручной труд. Так освободились ресурсы на решение задач по развитию компании. Как результат — рост продаж, несмотря на непростой с экономической точки зрения период.
Вот затраты на автоматизацию с 2017 по 2020 год:
Если пересчитать эту сумму на месяцы, получится примерно 6780 р. в месяц. Зарплата для одного работника получится больше, а в нашем случае программа заменяет как минимум двух работников.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить для работы. Если потребуется, доработаем их под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
Содержание кейса:
Наш клиент — компания ЮгАвтоХолдинг. Компания продаёт дорожную технику и занимается её гарантийным и постгарантийным обслуживанием. В штате 15 сотрудников, оборот компании — больше 300 миллионов рублей.
Управленческий учёт в Word и Excel
К автоматизации компания пришла не сразу. Долго гарантийное обслуживание и услуги для клиентов учитывали в MS Word и MS Excel. Бухгалтерский учет вели в базовой 1С:Бухгалтерии.
Росла клиентская база, услуги по гарантийному обслуживанию выделили в отдельное направление. Поэтому нужно было подобрать удобную CRM-систему, в которой можно было бы учитывать оказание услуг и производственные работы.
Какие были задачи?
создать общую базу контактов по стандарту. Важно было, чтобы хранилась история взаимодействий с клиентом: от звонков для заключения договоров и продаж
учитывать работы по гарантийному и постгарантийному обслуживанию проданной техники
учитывать складские остатки основных товаров и запчастей
создать унифицированный документооборот с контрагентами
Как изменилась работа с переходом на 1С:УНФ
Ускорили оформление документов для продажи
В зависимости от вариантов оплаты отличаются условия договора. До работы в программе менеджеры часто допускали ошибки, составляя в MS Word договор и копируя отдельные его пункты. Эту проблему решили при помощи «Платежного календаря» в документе «Заказ покупателя» и добавления реквизита «Условия оплаты».Теперь форма договора формируется в автоматическом режиме.
На базе документа «Заказ покупателя» мы разработали процедуру оформления документов, начиная от выставления коммерческого предложения до заключения договора и заканчивая оформлением акта приема-передачи товара.
В документе «Расходная накладная» добавили реквизит «Лизингополучатель». Часто в нашей сфере в сделке выступает покупателем лизинговая организация, но для нас важно знать конечного потребителя
Разграничили доступ менеджеров к клиентской базе
В компании за каждым менеджером закреплены разные категории клиентов. Раньше у каждого менеджера был доступ ко всей клиентской базе. Это создавало путаницу и усложняло работу с клиентами.
В 1С:УНФ менеджеру видны только его клиенты и история работы с ними. Это повышает безопасность и снижает риск увода клиентской базы.
Поскольку менеджеры не видят всю базу клиентов, они могут пытаться создать нового контрагента, который уже существует в базе, но с другим правом доступа. Чтобы исключить дубли контрагентов, поставили категорический запрет на подобные операции.
«Заказ-наряд» сделали универсальным документом
для работы с клиентом
Гарантийное и сервисное обслуживание проданного товара отражается в системе с помощью документа «Заказ-наряд». Он одновременно является документом планирования работ, актом выполненных работ, документом реализации и документом списания.
Гарантийный период предполагает прохождение технического обслуживания. Его состав работ и требуемые материалы зависят от наработки моточасов дорожной техники.
Нужно было, чтобы клиент видел состав работ, перечень материалов и их стоимость. Чтобы каждый раз не вносить одни и те же материалы, создали наборы с перечнем и количеством используемых материалов. Для наборов предусмотрены вариации отражения в печатных формах цены и состава набора.
Стали быстрее вести бухгалтерский учёт с ЭДО
Электронные документы поступают непосредственно в базу 1С, бухгалтеру нужно только сопоставить номенклатуру поставщика и нашу, и нужный документ создается автоматически с заполненной информацией.
Все электронные документы хранятся в базе данных 1С. Это оказалось вовремя — товары компании попали в категорию прослеживаемых товаров, поэтому обмениваться с поставщиками и покупателями электронными документами — обязательно.
Упростили налоговый и бухгалтерский учёт
с синхронизацией 1С:УНФ и 1С:Бухгалтерии
Настроили автоматический обмен: все операции отражаются в 1С:УНФ и по настроенному сценарию переносятся в 1С:Бухгалтерию с заполненной информацией для отображения в бухгалтерском учете и составления налоговой отчетности.
Главным преимуществом синхронизации стало то, что теперь абсолютно все операции отражаются в «1С:УНФ», и она стала первичной, а «1С:Бухгалтерия» — вторичной. Это означает то, что теперь можно формировать множество отчетов для руководителя, а не для бухгалтера: о деловой активности фирмы, объемах продаж, доходах и расходах организации, товарных и финансовых запасах, взаиморасчетах и прочих показателях.
Мобильное приложение 1С:УНФ
Для управления компанией из любой точки подключили мобильное приложение 1С:УНФ. В нём можно в любой момент просмотреть управленческую отчётность о компании. Единственное требование для работы в мобильном приложении — чтобы база была опубликована на веб-сервере.
Автоматически учитываем топливо и штрафы ГИБДД
С помощью внешних доработок добавили в 1С:УНФ новые функции: автоматизировали ведение путевых листов, учет штрафов ГИБДД и формирование платежных поручений для оплаты этих штрафов.
У менеджеров и сервисных инженеров преимущественно разъездной характер работы. В служебном автопарке больше 10 машин. Ручное заполнение путевых листов и учета ГСМ при таком количестве машин было проблемой. Теперь каждый сотрудник самостоятельно заполняет путевые листы, а расход топлива рассчитывается, исходя из нормы. Руководитель всегда в курсе текущих расходов на ГСМ, а информация по штрафам учитывается при расчете заработной платы сотрудников.
Использование платежного календаря
Мы создали документы «Заявка на расход денег» по всем ежемесячным платежам и добавляем заявки на незапланированные предстоящие расходы.
Документы «Заказ покупателя» и «Заказ-наряд» отражают в платежном календаре ожидаемые поступления.
Заявки на расход денег утверждает руководитель, после чего бухгалтер на их основании формирует платежные поручения и выгружает их в банк-клиент. После исполнения платежа загружаем банковскую выписку в «1С:УНФ». Так мы видим всю цепочку платежа: от заявки до исполнения, а платежный календарь наглядно показывает ежемесячные платежи и ожидаемые поступления, что позволяет не допускать кассовых разрывов.
Уменьшили затраты на бухучёт и работу с клиентами
С помощью 1С:УНФ стали тратить меньше труда и времени на учёт и работу с клиентами. Каждый отдел работает со своей зоной ответственности: менеджеры продаж ведут клиентскую базу
оформляют заявки на продажи
сервисный отдел отвечает за оформление заказ-нарядов
бухгалтер отвечает за финансовую составляющую и выполняет контрольные функции
Исключили дублирование операций и сократили ручной труд. Так освободились ресурсы на решение задач по развитию компании. Как результат — рост продаж, несмотря на непростой с экономической точки зрения период.
Вот затраты на автоматизацию с 2017 по 2020 год:
Если пересчитать эту сумму на месяцы, получится примерно 6780 р. в месяц. Зарплата для одного работника получится больше, а в нашем случае программа заменяет как минимум двух работников.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить для работы. Если потребуется, доработаем их под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
14 января 2022
Клиент: ЮгАвтоСервис
Внедренный продукт: 1С:УНФ
Отрасль: Автосервис
Содержание:
Наш клиент — книжный портал БукРивер. Это портал для авторов и читателей. Авторы могут быстро зарегистрироваться и продавать свои произведения. Читатели — заводят на портале кошелёк и из него оплачивают книги, которые хотят читать.
Проблема: данные о взаиморасчетах БукРивера и автора не переносились в бухучет
БукРивер работает по принципу маркетплейса:
читатель платит автору вознаграждение за книгу, которую хочет читать
автор получает вознаграждение, когда его книгу купили
портал берет комиссию за вознаграждение
При этом важно учитывать взаиморасчеты между порталом и автором, комиссию с вознаграждения автора.
В конце каждого отчетного периода БукРиверу нужно подсчитать доходы и уплатить налоги только с части своих доходов — то есть с комиссии за продажу книг.
Проблема заключалась в том, у клиента не было учетной системы для ведения бухгалтерского учета, а транзакций на покупку книг было слишком много, чтобы вводить эту информацию вручную.
Настроили интеграцию маркетплейса БукРивер и 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С:Бухгалтерия
Отрасль: Торговля
Рассказываем, как без внедрения дорогостоящих 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С:Бухгалтерия,
отправляют по почте контрагентам,
получают подписанные.
Если контрагенты не вернут свои подписанные экземпляры, то ООО «Интерсервис» останется без первичных документов, а без них компания не сможет подтвердить факт хозяйственной операции.
Наша задача — разработать систему, которая позволила бы контролировать, пришёл ответ от контрагента или нет, и, если не пришёл, отправить напоминание.
Как решили задачу
В функционале 1С:Бухгалтерия есть типовая галочка, которую нужно ставить после получения от контрагентов подписанных документов. Эту галочку мы использовали в нашей обработке — программа формирует список контрагентов, у которых не проставлена галочка, то есть тех, от кого не пришли документы, и отправляет им напоминание по электронной почте.
Автоматическая рассылка напоминаний
Задаём регламентное задание, в котором указываем, как часто делается рассылка.
Программа автоматически формирует пакет документов для отправки по электронной почте. Пакет документов для каждого контрагента формируется свой — подтягивается из базы. Если отправили акты сверки и не получили ответ, то к электронному письму будет прикреплен этот акт сверки и первичные документы, которые указаны в этом акте.
Если нужно напомнить вернуть документ, то к письму прикладываются печатные формы в архиве.
Ручная рассылка напоминаний
1. Выбираем документы, по которым нужно сделать рассылку:
поступления,
реализации,
акты сверки,
счета на оплату.
2. Далее программа сформирует письма для рассылки.
Как формируется письмо с напоминанием?
Текст письма генерируется программой автоматически в зависимости от того, какие документы к нему прикреплены.
Но с счетами на оплату немного другой алгоритм:
сначала обработка анализирует период, до которого счёт должен быть оплачен,
если ещё не последний день оплаты, рассылка не отправится,
если документ уже оплачен, то рассылка тоже не отправится.
Отправка напоминаний вручную.
В таком формате приходят напоминания контрагентам.
Результаты внедрения обработки
Раньше приходилось формировать письма с напоминанием вручную: готовить пакет документов, писать текст письма — на эту работу уходило 3 часа в неделю. В год и вовсе получалось 156 часов (3 часа в неделю * 52 недели в году), это 19,5 рабочих дней.
Сейчас это происходит автоматически. Соответственно, у сотрудников появилось 156 дополнительных рабочих часов, в которые они могут решать более важные задачи.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
Наш клиент — московская компания ООО «Интерсервис», которая оказывает услуги по уборке помещений.
В организации не планируют подключать электронный документооборот, обмен документами происходит традиционно:
распечатывают документы из базы 1С:Бухгалтерия,
отправляют по почте контрагентам,
получают подписанные.
Если контрагенты не вернут свои подписанные экземпляры, то ООО «Интерсервис» останется без первичных документов, а без них компания не сможет подтвердить факт хозяйственной операции.
Наша задача — разработать систему, которая позволила бы контролировать, пришёл ответ от контрагента или нет, и, если не пришёл, отправить напоминание.
Как решили задачу
В функционале 1С:Бухгалтерия есть типовая галочка, которую нужно ставить после получения от контрагентов подписанных документов. Эту галочку мы использовали в нашей обработке — программа формирует список контрагентов, у которых не проставлена галочка, то есть тех, от кого не пришли документы, и отправляет им напоминание по электронной почте.
Автоматическая рассылка напоминаний
Задаём регламентное задание, в котором указываем, как часто делается рассылка.
Программа автоматически формирует пакет документов для отправки по электронной почте. Пакет документов для каждого контрагента формируется свой — подтягивается из базы. Если отправили акты сверки и не получили ответ, то к электронному письму будет прикреплен этот акт сверки и первичные документы, которые указаны в этом акте.
Если нужно напомнить вернуть документ, то к письму прикладываются печатные формы в архиве.
Ручная рассылка напоминаний
1. Выбираем документы, по которым нужно сделать рассылку:
поступления,
реализации,
акты сверки,
счета на оплату.
2. Далее программа сформирует письма для рассылки.
Как формируется письмо с напоминанием?
Текст письма генерируется программой автоматически в зависимости от того, какие документы к нему прикреплены.
Но с счетами на оплату немного другой алгоритм:
сначала обработка анализирует период, до которого счёт должен быть оплачен,
если ещё не последний день оплаты, рассылка не отправится,
если документ уже оплачен, то рассылка тоже не отправится.
Отправка напоминаний вручную.
В таком формате приходят напоминания контрагентам.
Результаты внедрения обработки
Раньше приходилось формировать письма с напоминанием вручную: готовить пакет документов, писать текст письма — на эту работу уходило 3 часа в неделю. В год и вовсе получалось 156 часов (3 часа в неделю * 52 недели в году), это 19,5 рабочих дней.
Сейчас это происходит автоматически. Соответственно, у сотрудников появилось 156 дополнительных рабочих часов, в которые они могут решать более важные задачи.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
10 июня 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 часа.
Сейчас мы продолжаем сотрудничество с ООО «Комплект Плюс» по текущим вопросам.
10 июня 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С можно в любой момент времени посмотреть что и в каком количестве хранится в каждой ячейке,
можно отследить работу сотрудников — перед началом работы в ТСД все сотрудники авторизуются по логину и паролю, если заказ собрали с ошибкой, легко отследить, кто её допустил.
10 июня 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 месяца. Но УК смогла сформировать и распечатать квитанции для жильцов в тот же месяц, в который обратились к нам. Потому что мы специализируемся на учёте ЖКХ и многие типовые процессы автоматизировали, чтобы быстрее решать задачи клиентов.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
10 июня 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 жильцов, всем выставляем квитанции. Но для удобства бухучёта решили, что будем вести сводную реализацию по всем жильцам.
Поможем упростить работу и ускорить бизнес-процессы
Подберём программы для вашей компании, поможем внедрить и настроить. Если потребуется, доработаем программы под ваши задачи: напишем новые функции или печатные формы.
Связаться со специалистом
10 июня 2023
Клиент:
Внедренный продукт: 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С или сторонними программами
будем ежемесячно помогать с серверами: следить за программным обеспечением и нагрузкой на оборудование, предотвращать проблемы и поломки
Обсудить со специалистом
Содержание статьи:
Наш клиент — ООО «Славяна», занимается оптовой продажей молочной продукции. Компания ведёт учёт в 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
Клиент: Эксимторг
Внедренный продукт: —
Отрасль: Торговля
Задать вопрос