Иногда очевидные решения могут стоить дороже и занимать больше времени, чем альтернативные. У нас был проект, на который изначально требовалось потратить 200 часов, но мы нашли выход и сделали за 40.
История клиента
Сеть ресторанов-пиццерий в ЦФО продала 8 ресторанов франчайзи-партнеру. Надо было разделить базу «1С:Бухгалтерия КОРП», в которой с 2011 года хранились все данные по ресторанам. В одной базе должны быть рестораны партнера, в другой — рестораны основной компании. При этом важно сохранить общую товароучетную систему, а финансовую и расчет зарплаты сделать отдельными.
Очевидный вариант, который обошелся бы заказчику намного дороже. Самым очевидным решением, которое стоило дороже, было бы создание отдельной пустой базы 1С и перенос в нее данных из проданных 8 ресторанов с последующим удалением ненужных файлов из исходной базы. Такой проект потребовал бы больше времени и ресурсов, поскольку необходимо было бы провести дополнительные этапы проверки и корректировки данных. В среднем работа заняла бы около 200 часов.
Мы отказались от этого варианта, поскольку помали, что у нас не будет достаточно времени на работу. Клиент нуждался в доступе к данным каждый день, база данных использовалась компанией для управления платежами.
Варианты решений
1 вариант. Аналитик решил, что можно выделить документы по организациям и оставить удаляться на ночь. Но из-за больших объемов удалить документы таким способом было бы неоправданно долго.
2 вариант. Программист написал обработку для удаления данных средствами 1С и рассчитал необходимое для этого время — 11 дней. Такой срок был неприемлем, поэтому этот вариант тоже пришлось исключить. Остановка бизнеса означала бы потерю примерно 33 % месячной прибыли.
3 вариант. Чтобы минимизировать издержки компании, разделение нужно было провести за два выходных дня. Мы нашли решение: создали обработку, которая сгенерировала скрипт удаления данных по нужным организациям в системе управления базами данных. Это позволило сократить время удаления данных с 11 дней до 6 часов.
Когда все было удалено, оставалось только выполнить проверку логической целостности в 1С, чтобы не получилось так, что где-то данные удалены, а где-то остались. После еще несколько часов ушло на то, чтобы консультант сделал мелкие корректировки.
Результат работы
Мы нашли техническое решение, которое позволило завершить проект всего за 40 часов. Клиент получил две базы «1С:Бухгалтерия КОРП», в которых основная компания отделена от франчайзи-партнера. Кроме того, после всех изменений информационная система была подготовлена к подключению новых партнеров, что дало компании возможность планировать свое развитие.
Комментарии (31)
mixsture
10.10.2024 08:52Что мешало создать 2 новые "разделенные" базы заранее, не останавливая деятельность основной и доставлять туда новые появляющиеся документы? Могли бы и за час тогда перейти.
Ваш путь с прямым удалением в SQL:во-первых, нарушает лицензию 1с у клиента. Сейчас за таким никто не гоняется, но в любой момент могут начать. Донесли ли вы до клиента, что если этот кейс получит юридические претензии, то клиенту потом заново лицензии покупать? Плюс условный миллион рублей на затраты
во-вторых, крайне сложно проверить целостность данных. Тестирование и исправление - не панацея. А последствия этого метода вполне могут выявится не сразу при приемке, а спустя время, чем сильно все осложнить.
SergeySkirdin
10.10.2024 08:52перенос справочников / документов в пустую базу потребовал бы очень серьезной проработки постановки задачи аналитиком по ЗУПу, тут даже предпроект в 40 часов вряд ли уложился бы. Ну и после переноса сверка. Это был бы очень серьезный проект.
Здесь как раз история в том, что было найдено техническое решение которое позволило без потери качества снизить сроки и стоимость.
mixsture
10.10.2024 08:52Я и не предлагаю перенос в пустую базу.
1) добавляете план обмена в основную базу на все документы (один узел = одной новой базе, как-то там деля по организациям между ними)2) Создаете 2 "разделенные базы" копиями с основной.
3) Удаляете в них ненужные части (длительная операция, без прямого доступа к СУБД)
4) Делаете предварительную сверку (данные должны быть актуальными на момент создания копии)
5) Доставляете накопившееся в плане обмена до разделенных баз
6) Допроверяете перенесенное (ориентировочно за 14 дней доки тут будут)
7) Переводите пользователей на разделенные базы
---
С 5 по 7 пункты накрываем блокировкой входа пользователей во все базы - это и будет даунтайм. Если хочется его сократить, то можно сделать эти пункты в 2 итерации: в первую итерацию без блокировки входа перенести за 14 дней и допроверить их, а потом с блокировкой еще накопившийся за это время кусок (врятли он будет больше 2х дней).SergeySkirdin
10.10.2024 08:52первым делом мы пробовали удалять объекты штатными средствами, т.е. обработкой. Запустили обработку на 8 часов, остановили, посчитали процент удаленных. Прикинули линейный прогноз, вышло что до даты х мы точно не успеваем, причем раза в два. Так что такой вариант не подошел бы.
Ну и трудозатраты в вашем варианте в разы больше. Чего ради?
victor_2004
10.10.2024 08:52Можно было наверное в день х закрыть доступ в базу, снять дамп, развернуть дамп на другом сервере, открыть доступ, настроить разграничения по организациям. Или в принципе настроить репликацию средствами СУБД и в день х реплику сделать вторым мастером.
alexhott
10.10.2024 08:52Есть стандартный "Правильный" способ сделать это в 1С но она работает долго? Проблему до конца не локализовали?
Хочется подробностей, а то вдруг у меня тоже будет задача разделить 1С и я такой - давайте в БД скриптом выпилим. А меня спросят почему иммено так? - а я статью на хабре читал там так делали.SergeySkirdin
10.10.2024 08:52Стандартный способ работы 1с с субд - вносить изменения по каждому объекту отдельно. Что тут локализовывать? И это нормально что 1с так делает, не думаю, что в том же SAP или MS Dynamics изменения по-другому вносятся. Я правда не проверял, кто знает, напишите, интересно.
Мы скриптом сделали работу в разы быстрее. Лазить в субд на проектах 1с абсолютно нормально. Если у вас 200+ активных пользователей, по-другому просто не прожить.
Недавно ездили с коллегой на курсы Богачева, по подготовке к эксперту по технологическим вопросам. Так вот он конечно говорил, что индексы лучше руками не делать, искать варианты через платформу, но в целом, вендор с пониманием относится к решению вопросов производительности через субд.
Garykom
10.10.2024 08:52Кто/что помешало не трогать старую базу но настроить РИБ на две новые "разделенные"?
Сначала двусторонний обмен, затем отключаем и все.SergeySkirdin
10.10.2024 08:52Честно, не знаю, есть ли в ЗУПе РИБ с разделением по организациям и как там сотрудники и ФЛ мигрируют. Мы такой вариант кратко обсуждали, решили что скорее всего ФЛ поедут во все базы, их придется все равно вычищать (было требование не передавать лишние перс данные). Решили что проще и быстрее вычистить все скриптом SQL, а базу просто скопировать.
Garykom
10.10.2024 08:52Дописать чтобы сотрудники не выгружались (или наоборот не загружались) куда не надо - 10 минут.
soltyy00
10.10.2024 08:52напрямую через SQL - нарушение лицензии 1С п. 65 (https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/#27). Скопировать 8 раз (или сколько там юр лиц), разделить правами и спокойно удалять по Организации по ночам/выходным недорого и правильно.
SergeySkirdin
10.10.2024 08:52Про ограничение лиц политики 1с знаем и всегда, перед такими работами предупреждаем клиента. Он сам принимает риск. Может выбрать быстро и дешево, может долго и дорого.
Это по сути лишает клиента возможности отправить базу в поддержку 1с, в случае, если мы как партнер не сможем решить их проблему. Точнее так, отправить они могут, но поддержка может отказать в разборе, поскольку в бд вносились изменения. Хотя еще не понятно как это выявить можно.
Случаи обращения за поддержкой к вендору единичны, за свои 25+ лет работы с 1с такое было только на первых версиях и то по пальцам одной руки пересчитать.
wkon
10.10.2024 08:52Это не является нарушением лицензии, поскольку покупатель не использует SQL сервер для иных своих (производственных) задач кроме как взаимодействие с платформой. Так можно дойти до абсурда и объявить нарушением лицензии средства резервного копирования и администрирования сервера SQL в поставках от третьих лиц. Там тоже "напрямую через SQL".
mixsture
10.10.2024 08:52Не той лицензии. Вы пишете о нарушении лицензии бандла SQL - это дешевый вариант лицензии, но привязанный к использованию только платформой 1с.
Но нарушается лицензия на саму 1с:
п.4 Лицензиат обязуется ... не совершать и не допускать совершения третьими лицами ... вносить какие-либо изменения в содержимое баз данных ... за исключением тех изменений, которые вносятся штатными средствами (1с) ... и описанными в сопроводительной документации (1с).
---
Простыми словами - любое изменение данных в обход платформы 1с - это нарушение лицензии.
Ulrih
10.10.2024 08:52200 часов? Смешные вы, да тут 2000 часов на подобную задачу это даже мало по "современным" меркам.
DenisPhilord
10.10.2024 08:52Что мешало удалять параллельно работе? Рассказывайте, что мешало подробнее описать удаление через СУБД
SergeySkirdin
10.10.2024 08:52Как это, удалять параллельно работе?
Упрощенно, есть база, в ней работают бухгалтера из организации 1, ведут учет по организации 1 и 2. В день икс, в понедельник появляются новые бухгалтера и им нужно отдать базу с организацией 2 и без организации 1. На всю процедуру разделения есть только выходные.
Можно было бы заранее сделать две базы, и объяснить бухгалтерам из организации 1 что вы теперь ведете учет по организации 1 в одной базе, по организации 2 в другой. Была бы путаница, истерики и тормоза от удаления документов параллельно с работой пользователей. Это точно было бы дольше и дороже раза в два как минимум.
DenisPhilord
10.10.2024 08:52А в чём истерика? Они все равно будут работать в 2х базах в итоге. Даже если просто пометить организации на удаление, уже будет предупреждение при её использовании. Потом пометить все документы удаляемых организаций в каждой базе. Это всё можно сделать штатными средствами. Рассказывайте, сколько это займёт по времени
SergeySkirdin
10.10.2024 08:52Истерика от путаницы, в какой базе что вести.
Мы избежали работы в двух базах. В пятницу бухгалтерия организации 1 ведет организацию 1 и 2 в одной базе. В понедельник у них останется та же база, они продолжают вести организацию 1. Организацию 2 начинают вести бухгалтера второй организации в отдельной базе.
Gamm
10.10.2024 08:52Текст ни о чём: удаление через субд стандартный инструментарий тех же самых Инструментов Разработчика.
SergeySkirdin
10.10.2024 08:52Текст о том, как при помощи нестандартного подхода можно быстро решить задачу.
sap058
10.10.2024 08:52Мне вот как буху кажется совсем очевидным другое решение
Старую базу оставить у основного юр. лица
А новому юр. лицу начинать с чистого листа, с новой базы. Для чего ему старые данные?
SergeySkirdin
10.10.2024 08:52В данном случае речь не о новых юрлицах. По франшизе были переданы действующие рестораны и соответствующие юрлица с оформленными сотрудниками. Заводить заново данные 500-600 сотрудников кажется плохим решением.
sap058
10.10.2024 08:52тогда нужно больше информации о юр. структуре бизнеса. иначе это все голословно
что значит данные по сотрудникам - справочники или кадровые документы, документы начислений?
это не такой уж и большой объем данных, что бы заморачиваться, как пишет автор
в общем что то не вяжется со смыслом (хотя мы не знаем реальной картины, а судим лишь по описанию задачи)
vladnet1
10.10.2024 08:52Какие то странные люди пишут. Напрямую из SQL удалить основные таблицы, потом почистить. Никто за вами гоняться не будет и отбирать лицензию.
BeLord
Было бы прекрасно, если бы автор дополнил статью техническими подробностями, объем базы, количество документов в базе (интересует порядок, а не с точностью до штуки). Какая именно база используется, потому, что для 1С возможны варианты, какой серверный ресурс. Иначе сложно оценить это история успеха или нет.
SergeySkirdin
Проект давно делали, года три назад. Количество документов не могу сказать. Знаю, что зп считалась по 2000 сотрудников.
Вопрос какая база используется не понял. Конфигурация в статье указана - зуп корп.
Сервер свой использовали, т.к. у клиента dev окружение не очень. Сервер был примерно такой: 128 гигов оперативки, ксеон (точную марку не скажу, с тех пор уже обновились) 6 ядер, по 3 гигагерца, ssd диски.
overslepter
1С работает как на скуле так и на постгре. И даже в случае скуля версия бывает критична.
victor_2004
Для понимания объёма проблемы тот же объем данных в гигабайтах и количестве записей в таблицах сильно бы помог.