РИБ Розница 2.2 - на работающей сети магазинов
Добрый день.
Стоит задача:
Есть действующая сеть розничных магазинов (27 точек). Учет ведется на Рознице 2.2. В каждом магазине своя собственная ИБ, т.е. свой собственный состав справочников, документов, настройка ЕГАИС и пр. Базы вообще никак между собой не коррелируют. Данные по продажам, взаиморасчетам и пр. в полуручном режиме выгружаются и как-то сводятся в УТ 10.3
Поставлена задача объединить все магазины в одну РИБ. Сохранить данные по остаткам и взаиморасчетам в каждом магазине
Пока придумали следующее:
Загрузка базы с наиболее полными по составу справочниками в центральный узел. Загрузка данных текущего магазина, подключаемого к РИБ в подчиненный узел, свертка, перед первой выгрузкой отключить регистрацию для данных подчиненной базы.
Не уверен что это правильное направление решения задачи.
Может быть кто-то уже решал подобную задачу, буду признателен если укажете наиболее правильное направление.
Стоит задача:
Есть действующая сеть розничных магазинов (27 точек). Учет ведется на Рознице 2.2. В каждом магазине своя собственная ИБ, т.е. свой собственный состав справочников, документов, настройка ЕГАИС и пр. Базы вообще никак между собой не коррелируют. Данные по продажам, взаиморасчетам и пр. в полуручном режиме выгружаются и как-то сводятся в УТ 10.3
Поставлена задача объединить все магазины в одну РИБ. Сохранить данные по остаткам и взаиморасчетам в каждом магазине
Пока придумали следующее:
Загрузка базы с наиболее полными по составу справочниками в центральный узел. Загрузка данных текущего магазина, подключаемого к РИБ в подчиненный узел, свертка, перед первой выгрузкой отключить регистрацию для данных подчиненной базы.
Не уверен что это правильное направление решения задачи.
Может быть кто-то уже решал подобную задачу, буду признателен если укажете наиболее правильное направление.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)Самый простой вариант загрузить полный справочник в ЦБ. После загрузки через оприходование ввести нач остатки по магазину.
Если есть одна ЦБ в виде УТ10(11) то попробовать сделать обмен с ЦБ розницы, загрузить остатки из УТ на магазин....
После трёх недельных обновлений РИБов от 10 до 150 узлов в каждом вообще думаю что РИБ не самое правильное направление... Накипело :)
Если есть одна ЦБ в виде УТ10(11) то попробовать сделать обмен с ЦБ розницы, загрузить остатки из УТ на магазин....
Не уверен что это правильное направление решения задачи.
После трёх недельных обновлений РИБов от 10 до 150 узлов в каждом вообще думаю что РИБ не самое правильное направление... Накипело :)
(3)Полный справочник - это куча дублей в ЦУ, ну условных дублей (нет единого стандарта наименования). Если почистить и причесать то получим битые ссылки в регистрах. Загрузка из УТ - там тоже каша.
Ну а какие еще есть варианты при узких и не стабильных каналах связи, с учетом что логически это должна быть одна ИБ? Обычные обмены?
После трёх недельных обновлений РИБов от 10 до 150 узлов в каждом вообще думаю что РИБ не самое правильное направление... Накипело :)
Ну а какие еще есть варианты при узких и не стабильных каналах связи, с учетом что логически это должна быть одна ИБ? Обычные обмены?
(6)Да дело не в том что глаза боятся, хочется сделать сразу правильно. РИБ с нуля развернуть не особо сложно, а вот в моем случае (действующие магазины с рабочими ИБ) возможны всяческие грабли. Я просто думал - может быть кто-то уже решал подобную задачу и может поделиться практическим опытом.
(7) Ну а какие есть варианты?
1. Он же правильный. Берешь пустую базу, заливаешь туда всю номенклатуру, делаешь узлы, вводишь остатки по узлам и начинаешь работать. Вопрос, насколько этот вариант допустим при 27-ми работающих магазинах?
2. Уже мной предлагался. Делаешь центр вливанием базы одного из магазинов, далее добавляешь узлы и данные по магазинам, чистишь дубли + перенос ссылок и таким образом потихоньку переводишь все магазины к одной системе. Попробуй на тестовых базах - объедини 3-4 магазина. посмотри на возникающие траблы....и все должно получиться. на 8-ке объединял так 2 магазина - все получилось....сейчас в системе под 20 узлов, все работает. (тьфу 3 раза) и в т.ч. при узких каналах..Большее количество точек объединял на 7.7, но это было давно и все позабылось уже...но принцип примерно тот же был...
1. Он же правильный. Берешь пустую базу, заливаешь туда всю номенклатуру, делаешь узлы, вводишь остатки по узлам и начинаешь работать. Вопрос, насколько этот вариант допустим при 27-ми работающих магазинах?
2. Уже мной предлагался. Делаешь центр вливанием базы одного из магазинов, далее добавляешь узлы и данные по магазинам, чистишь дубли + перенос ссылок и таким образом потихоньку переводишь все магазины к одной системе. Попробуй на тестовых базах - объедини 3-4 магазина. посмотри на возникающие траблы....и все должно получиться. на 8-ке объединял так 2 магазина - все получилось....сейчас в системе под 20 узлов, все работает. (тьфу 3 раза) и в т.ч. при узких каналах..Большее количество точек объединял на 7.7, но это было давно и все позабылось уже...но принцип примерно тот же был...
(11)Ну примерно так и планирую. Сейчас делаю правила конвертации для номенклатуры, контрагентов и пр. Попробую сопоставить номенклатуру по штрихкоду, вроде используется штрихкод поставщика, по крайней мере на некоторых магазинах. Соберу наиболее полную базу, потом буду потихоньку переводить на риб. В ручную чистить дубли не вариант, там под 100 тыс. позиций
(12) м.б. имеет смысл сделать какой то реквизит уникальный и по нему делать сопоставления? например артикул? ШК не всегда бывает уникальным, сам натыкался что у 3-х позиций разной развесовки ШК был один и тот же....То ли производитель ошибся при нанесении маркировки, то ли просто не озадачился для разных упаковок регистрировать свой ШК...
Тут основная проблема то, что при слиянии данные будут задвоены - они же будут получены из разных баз. Думаю надо все подгружать в центр, потом удалять дубли номенклатуры и прочих справочников(переносить ссылки), а затем создавать периферийный узел для магазина....и так по очереди все магазины...
(8)В моем случае штрихкод не уникальный реквизит. Но предположим что удалось сопоставить номенклатуру по штрихкоду в двух разных базах. Что далее? Если подменить УИД получим битые ссылки в документах и регистрах, если не подменять - дубль. Если вы уже обдумывали план объединения, поделитесь мыслями, если не трудно.
План простой - выгрузка из периферийной БД в текстовые файлы - 1. код номенклатуры, номенклатура, цена, остаток, 2. код номенклатуры, штрихкод
Можно и в xml
В центральной БД обработка этих файлов с поиском по штрихкоду, что не загрузилось автоматом, добавляется или автоматом или делается ручное сопоставление
Да пришлось писать 2 обработки - выгрузка, загрузка. Эта операция делалась перед ревизией в периферийной точке, и все что не загрузилось или загрузилось не так, вручную оформлялось в процессе ревизии.
так что автоматизация + административные мероприятия
Это я делал когда в одной организации был переход с УТ на розницу, причем в рознице уже работало 3 магазина с нуля, а 4-ый (УТ+фронтол) работал с 2011г. Но решили от УТ отказаться, чтобы все было одинаково
Можно и в xml
В центральной БД обработка этих файлов с поиском по штрихкоду, что не загрузилось автоматом, добавляется или автоматом или делается ручное сопоставление
Да пришлось писать 2 обработки - выгрузка, загрузка. Эта операция делалась перед ревизией в периферийной точке, и все что не загрузилось или загрузилось не так, вручную оформлялось в процессе ревизии.
так что автоматизация + административные мероприятия
Это я делал когда в одной организации был переход с УТ на розницу, причем в рознице уже работало 3 магазина с нуля, а 4-ый (УТ+фронтол) работал с 2011г. Но решили от УТ отказаться, чтобы все было одинаково
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот