Как организовать работу пользователя в 15 базах одновременно?
Всем доьрового воемени суток!
У нас 15 юр лиц, 15 альф 5.1, платформа 8.3 свежая.
В каждой альфе работает от 30 до 100 человек.
И тут у нас появился человек, который отвечает за оптовый отдел, один на все юр лица.
Поставили мне задачу организовать его работу во всех базах одновременно.
У кого какие идеи есть как это можно было бы сделать?
(Работа его это продажа, резервирование товара)
Вопрос не в смысле как завести учетки, а как сделать одно общее рабочее место, чтоб ему не блуждать в куче окон.
У нас 15 юр лиц, 15 альф 5.1, платформа 8.3 свежая.
В каждой альфе работает от 30 до 100 человек.
И тут у нас появился человек, который отвечает за оптовый отдел, один на все юр лица.
Поставили мне задачу организовать его работу во всех базах одновременно.
У кого какие идеи есть как это можно было бы сделать?
(Работа его это продажа, резервирование товара)
Вопрос не в смысле как завести учетки, а как сделать одно общее рабочее место, чтоб ему не блуждать в куче окон.
По теме из базы знаний
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Как построить микросервисную инфраструктуру
- 1С, Linux, облака…
- Интеграции с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али, ЛаМода для 1С:УНФ, УТ, КА, ERP
- Подкапотное пространство веб-клиента
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) TimofeySin, сливать все в единую нормальную базу.
Не сразу, постепенно причесать.
Такой учет, - это просто рассадник беспредела и хаоса.
а учет вести в 15 базах, это намного трудозатратнее. И в плане самих пользователей, и в плане обслуживания этих баз (программисты).
Мне страшно представить, как там все обменивается и выгружается.
А работа по причесыванию, в итоге намного снизит труд программиста, и позволит вести учет более четко и грамотно гораздо меньшим количеством персонала.
Руководы это должны понимать )) а если нет, то не знаю...Мне бы не хотелось в такой конторе работать.
По теме )) Любое решение в данном случае - будет через задницу. К уже предложенным, можно завести еще одну базу, для этого пользователя, выгрузить в нее только - то, что нужно из других баз, и сделать обмен с каждой из 15 базами. )))
Не сразу, постепенно причесать.
Такой учет, - это просто рассадник беспредела и хаоса.
наводить порядок некому
а учет вести в 15 базах, это намного трудозатратнее. И в плане самих пользователей, и в плане обслуживания этих баз (программисты).
Мне страшно представить, как там все обменивается и выгружается.
А работа по причесыванию, в итоге намного снизит труд программиста, и позволит вести учет более четко и грамотно гораздо меньшим количеством персонала.
Руководы это должны понимать )) а если нет, то не знаю...Мне бы не хотелось в такой конторе работать.
По теме )) Любое решение в данном случае - будет через задницу. К уже предложенным, можно завести еще одну базу, для этого пользователя, выгрузить в нее только - то, что нужно из других баз, и сделать обмен с каждой из 15 базами. )))
У 1С когда-то была "1С Консолидация", правда, я не видел, чтобы кто-нибудь ей пользовался. А так прямо писать обработку, как в (2) сказали. Если версии конфигураций идентичные, можно даже заполнение документов сделать через СОМ. Это если базы на одном сервере. Если много филиалов со своими серверами, тут сложнее.
Мне кажется, что прежде чем что-то делать, нужно понять что этому сотруднику нужно для работы и насколько это реально реализовать. М.б. действительно сделать для него отдельную базульку, в которую выгружать информацию из 15 разрозненных альф. А может быть ему подойдёт работа как в (2) - каждая база в своём окне.
Опять же, не очень ясно почему все 15 юрлиц работают каждое в своей базе и почему бы не замутить одну (или чуть больше) общую базу, ведь в этой альфе вроде можно в разрезе неск-х организаций вести учёт?
В общем, как решите задачу, отпишитесь пожалуйста (всем наверное было бы интересно).
Опять же, не очень ясно почему все 15 юрлиц работают каждое в своей базе и почему бы не замутить одну (или чуть больше) общую базу, ведь в этой альфе вроде можно в разрезе неск-х организаций вести учёт?
В общем, как решите задачу, отпишитесь пожалуйста (всем наверное было бы интересно).
(9) Готовой в наличии нет.
При запуске получаешь PID текущего процесса и сохраняешь его в файлик для данной базы.
При переключении пытаешься переключиться по PID, если не получилось - запускаешь базу.
При закрытии удаляешь информацию о PID.
Остальное на первой странице гугла.
При запуске получаешь PID текущего процесса и сохраняешь его в файлик для данной базы.
При переключении пытаешься переключиться по PID, если не получилось - запускаешь базу.
При закрытии удаляешь информацию о PID.
Остальное на первой странице гугла.
Утром (с учётом восточных филиалов, т.е. в 2 часа ночи) сохраняй свободные остатки. Грузи ему в базу центрального филиала (там обычно самая движуха) или в отдельную базу/таблицу excel etc эти ПРЕДВАРИТЕЛЬНЫЕ остатки, ещё их можно уменьшить на среднедневную продажу (приход реже, поэтому пессимистично, снизу, оценим). Потом смотри - насколько ему хватает данных с опозданием максимум на день, и что он хочет делать. Если собрать всю зимнюю резину в филиалах и продать на сторону - не вижу вариантов, всё очень динамично и много коллизий, если сводная закупка машин - там тоже всё по-своему специфично. Ещё к каждой строке таблицы можно добавить 15 кнопок для актуализации свободного остатка, ещё 15 для резервирования, цветом показывать давность обновления остатка...
Блин. Классная задача. Если это не ???б?????авто, то готов помочь идеями или реализацией по выходным. (Если они, то они про меня плохо думают).
Блин. Классная задача. Если это не ???б?????авто, то готов помочь идеями или реализацией по выходным. (Если они, то они про меня плохо думают).
(14) AHDP, во-первых, там могут быть посторонние базы типа бухгалтерии, для справочника же можно сделать хоть даже и булевый реквизит. Во-вторых, если авторизация не по домену, а логином-паролем, то каждый раз вводить придется, а в справочнике можно под звездочками хранить.
(17) Если под http сервисом подразумевается одноименный объект 1С, то в данной задаче использовать его неудобно. Данные будут не только читаться, но и записываться в другие базы, а через http сервис нельзя передать xml объект с данными. А если имелся ввиду стандартный rest интерфейс, то использовать можно, но гибкости будет не хватать. Этот вариант имеет смысл только если все базы стоят на поддержке и снимать её не хочется.
Всего у нас 6 площадок, от 1 базы до 3 баз на одной площадке.
(ну то есть 6 разных 1с серверов, между ними стабильный VPN)
Оптовик будет делать:
Поступления товаров (смотреть и создавать)
реализации товаров (смотреть и создавать)
Создавать контрагентов, номенклатуру
Создавать Заказы покупателей (снятие/резервирование)
создавать заказы поставщиков
перемещения товаров.
те данные требуются реального времени. (чтоб не было того, что он сделал реализацию на товар, который только только продали)
Начальство требует чтоб он делал Заказ покупателя в одном окне, но чтоб он создавался во многих базах.
те 5 позиций из одной базы, 3 позиции из другой и 1 позиция из третей. При нажатии провести создался заказ покупателя в каждой базе с нужным количеством в каждом. тож самое и реализацией и остальным документами.
(ну то есть 6 разных 1с серверов, между ними стабильный VPN)
Оптовик будет делать:
Поступления товаров (смотреть и создавать)
реализации товаров (смотреть и создавать)
Создавать контрагентов, номенклатуру
Создавать Заказы покупателей (снятие/резервирование)
создавать заказы поставщиков
перемещения товаров.
те данные требуются реального времени. (чтоб не было того, что он сделал реализацию на товар, который только только продали)
Начальство требует чтоб он делал Заказ покупателя в одном окне, но чтоб он создавался во многих базах.
те 5 позиций из одной базы, 3 позиции из другой и 1 позиция из третей. При нажатии провести создался заказ покупателя в каждой базе с нужным количеством в каждом. тож самое и реализацией и остальным документами.
(18) TimofeySin, каким образом для
Номенклатура имеет какой-то признак, привязывающий ее к конкретной базе?
Начальство требует чтоб он делал Заказ покупателя в одном окне, но чтоб он создавался во многих базах.
те 5 позиций из одной базы, 3 позиции из другой и 1 позиция из третей.
будет определяться, в какой базе происходит резервирование?
те 5 позиций из одной базы, 3 позиции из другой и 1 позиция из третей.
Номенклатура имеет какой-то признак, привязывающий ее к конкретной базе?
Веб-сервисы - это, конечно, круто. Но поскольку есть VPN, я бы делал через СОМ. Заполнял бы справочники и документы в формах текущей базы, а потом передавал бы данные в нужную. Только вот разбивка по базам еще. Колонка табчасти с базой в основной конфигураци?
(26) TimofeySin, как будет определяться, какая номенклатура в каком количестве в какой базе резервируется?
Иначе говоря, при резервировании
2630053503 - 100 шт
6640025020 - 15 шт
как определить, в какой базе и в каком количестве нужно делать резерв?
Номенклатура в базах синхронизирована по гуиду, или по артикул/производитель?
Иначе говоря, при резервировании
2630053503 - 100 шт
6640025020 - 15 шт
как определить, в какой базе и в каком количестве нужно делать резерв?
Номенклатура в базах синхронизирована по гуиду, или по артикул/производитель?
(26) А тут просто. Пользователь выбирает в какой базе в данный момент происходит заполнение заказа.
Ну то есть открывает заказ покупателя, выбирает марку авто Honda (что соответствует опред базе) и нажимает заполнить из экселя, потом выбирает Opel и опять заполнить из экселя и так набирает весь заказ покупателя.
Ничего в базах не синхронизировано на данный момент.
каталожный номер условно уникален.
Ну то есть открывает заказ покупателя, выбирает марку авто Honda (что соответствует опред базе) и нажимает заполнить из экселя, потом выбирает Opel и опять заполнить из экселя и так набирает весь заказ покупателя.
Ничего в базах не синхронизировано на данный момент.
каталожный номер условно уникален.
(28) TimofeySin, займись наведением порядка. Пока 95% номенклатуры с одинаковым partnumber не будут иметь одинаковые наименование - думать о сводных инструментах рано. Как наведёшь и сможешь автоматически заводить (НЕ ПРОВОДИТЬ! МОЛ должен проверить!) перемещения - так возьмёшься за эту задачу.
Можешь шепнуть, что за фирма?
Можешь шепнуть, что за фирма?
Со складскими документами все забавней, ибо сборки/не нашли/не то отдали.
Т.е., нельзя сразу проводить созданные документы.
И перемещения вообще непонятно, как сюда вписываются: если товар в базах разный, то из одной в другую не будем же перемещать?
Т.е., нельзя сразу проводить созданные документы.
И перемещения вообще непонятно, как сюда вписываются: если товар в базах разный, то из одной в другую не будем же перемещать?
(34)Пока не будет регламента ввода ТМЦ - ничего не заработает. Проверяй.
5 лет работает, все еще проверяем.
(36)На мой взгляд, задача оптовика не в том
Да наверно. но...
(37)а учет вести в 15 базах, это намного трудозатратнее.
не учет в 15 базах, а 15 разных организаций с полным штатом (не я принимал решение о таком учете, а хозяин холдинга)
(40) РИБ это круто, но история учета в этих базах от 1 года до 8 лет. слить это в РИБ ну практически не возможно. А переход на новую базу не разрешает начальство ни под каким предлогом. Пока что....
Если вообще то ИМХО 1С как платформа упр учета им вообще не подходит, но сейчас пока что есть то что есть.
5 лет работает, все еще проверяем.
(36)На мой взгляд, задача оптовика не в том
Да наверно. но...
(37)а учет вести в 15 базах, это намного трудозатратнее.
не учет в 15 базах, а 15 разных организаций с полным штатом (не я принимал решение о таком учете, а хозяин холдинга)
(40) РИБ это круто, но история учета в этих базах от 1 года до 8 лет. слить это в РИБ ну практически не возможно. А переход на новую базу не разрешает начальство ни под каким предлогом. Пока что....
Если вообще то ИМХО 1С как платформа упр учета им вообще не подходит, но сейчас пока что есть то что есть.
(41) > РИБ это круто, но история учета в этих базах от 1 года до 8 лет. слить это в РИБ ну практически не возможно.
Мы уже решали такие задачи с большими базами. Наш многопоточный обмен данными позволяет в разумные сроки выполнять перекачку больших объемов данных. Можем помочь решить проблему по этому варианту.
Мы уже решали такие задачи с большими базами. Наш многопоточный обмен данными позволяет в разумные сроки выполнять перекачку больших объемов данных. Можем помочь решить проблему по этому варианту.
(33) TimofeySin,
На мой взгляд, задача оптовика не в том, что бы гонять товары внутри базы. Этим специальный кладовщик-комплектовщик должен заниматься. Суть же в том, что бы под заказ оптовика запцацки с разных складов собрать, не? Да и автоматизируется эта задача в рамках одной базы достаточно банально.
Иначе вангую ту еще текучку кадров на должности "оптовика", слишком дофига от него хотите.
А перемещение со склада на склад в рамках одной базы.
На мой взгляд, задача оптовика не в том, что бы гонять товары внутри базы. Этим специальный кладовщик-комплектовщик должен заниматься. Суть же в том, что бы под заказ оптовика запцацки с разных складов собрать, не? Да и автоматизируется эта задача в рамках одной базы достаточно банально.
Иначе вангую ту еще текучку кадров на должности "оптовика", слишком дофига от него хотите.
Думаю самое простое решение это написать обработку не создания ком соединения и отправки данных в нужную базу, а наоборот запуск нужной базы. Т.е. если база не запущена, то обработка запустит базу и переключится на нее, а там уже юзер все сделает сам.
Такое решение мне кажется более адекватным. Данная обработка может быть встроена во все ваши базы как рабочий стол юзера.
Такое решение мне кажется более адекватным. Данная обработка может быть встроена во все ваши базы как рабочий стол юзера.
Сливать рарусовские поделки в одну базу точно не надо.
Никто не тестировал даже возможность открытия таких баз. Закрытые модули элементарно будут так часто обращаться к серверу защиты, что тот будет глючить. Терминалы - нужно, РБД - можно, но целую базу возможно смог бы только софтпоинт настроить и админить, но судя по разной номенклатуре, клиенту до этого ещё долго расти.
Никто не тестировал даже возможность открытия таких баз. Закрытые модули элементарно будут так часто обращаться к серверу защиты, что тот будет глючить. Терминалы - нужно, РБД - можно, но целую базу возможно смог бы только софтпоинт настроить и админить, но судя по разной номенклатуре, клиенту до этого ещё долго расти.
Можно не сливать, но сделать нормальную распределенную базу с одним корнем и 15 филиалами. С одинаковыми ГУИД объектов. С единым справочником. Тогда вся задача будет сведена к тому, что ваш суперпользователь будет работать в корневой базе, и делать свои заказы, которые будут автоматически рассылаться в подчиненные.
На мой взгляд обработка должна делать следующее.
Первый вопрос по поводу просмотра.
Тянуть справочники и документы можно из всех баз разом и объединять по какому-то признаку.
Товары следует тянуть только нужные (есть на остатках и не в резерве и т.д.) и суммировать количество.
Второй вопрос это создание объектов.
НА мой взгляд, следует сделать универсальную форму документа (справочника), который заполняется пользователем и передается в виде xml. В каждой базе есть обработка, которая загружает xml файлы онлайн и пытается это все дело реализовать в своей базе.
Первый вопрос по поводу просмотра.
Тянуть справочники и документы можно из всех баз разом и объединять по какому-то признаку.
Товары следует тянуть только нужные (есть на остатках и не в резерве и т.д.) и суммировать количество.
Второй вопрос это создание объектов.
НА мой взгляд, следует сделать универсальную форму документа (справочника), который заполняется пользователем и передается в виде xml. В каждой базе есть обработка, которая загружает xml файлы онлайн и пытается это все дело реализовать в своей базе.
(50) roman72, согласна... люди сами себе придумывают большой геморрой... с обменом данными... как-то приходилось решать подобную задачу: в одну базу грузили остатки из разных баз, чтобы потом в этой базе принимать заявки от покупателей... проблема именно в актуальности остатков.... и вся дальнейшая работа бессмысленна....
В real time задача в 15 базах решаема, через ws-сервис, но запись/проведение будут подтормаживать ожидая ответа, кроме довольно квалифицированного 1с программирования, потребуется квалифицированное административное сопровождение сервисов. Особенно при смене платформы, не факт, что текущие сисадмины это потянут, надо их тестировать.
Вот только РИБ то не выход, потому, что он подразумевает внесение данных на одном узле, и просмотр данных везде.
То есть если даже будет риб, то мы будем видеть остатки товара на всех складах (с задержкой равной времени обмена), а документы надо будет создавать все равно по отдельности в каждой базе.
У нас сейчас уже реализован механизм онлайн остатков товара на внешних источниках данных. Весь регистр партий товара дублируется в отдельную базу SQL, а между площадками настроена репликация этой базы.
Я все-таки буду делать отдельную базу, расширю функционал внешних источников, чтоб не только партии там были. А создание документов сделаю на WS-сервисе.
То есть если даже будет риб, то мы будем видеть остатки товара на всех складах (с задержкой равной времени обмена), а документы надо будет создавать все равно по отдельности в каждой базе.
У нас сейчас уже реализован механизм онлайн остатков товара на внешних источниках данных. Весь регистр партий товара дублируется в отдельную базу SQL, а между площадками настроена репликация этой базы.
Я все-таки буду делать отдельную базу, расширю функционал внешних источников, чтоб не только партии там были. А создание документов сделаю на WS-сервисе.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот