Доброе время суток!)
Можно узнать ваши мнения Гуру
планируется открытие торговой точки а точнее стола заказа в другом городе.
у них будет свой учет товарооборота в ут 10.3
им нужна будет возможность просматривать наши АКТУАЛЬНЫЕ остатки со специальной их ценой и только с одного из наших многочисленных складов.
и нужна будет возможность в нашей базе самостоятельно создавать заявку на товар чтобы у нас этот товар сразу вставал в резерв,

далее обмен накладными а сами розничные продажи это уже пусть будет в их базе.


наша номенклатура порядка 400 тысяч позиций  им предлагать необходимо всю нашу номенклатуру но работать они будут максимум с 20 процентами от нее...

подскажите что проще настроить?
1 вариант удаленный доступ но с максимальной защитой т.к у нас очень сложное распределение прав доступа

2 вариант сделать им копию базы и настроить регулярную выгрузку остатков?

Вот вы как думаете от чего будет зависить решение? Вы же по делу нечего не сказали. Какой интернет, переживут ли потерю связи?

Затащит ли их железо вашу базу?

(1) потерю связи переживут, т.к. сейчас мы в очень заторможенном ржиме работаем. они нам присылают запрос по почте мы им отвечаем что есть на складе.. потом от них заявка а у нас товар уже ушел..опять согласование ит.д

(2) железо конечно базу не втянет... им тогда придеться прилипнуть на приобретение помощнее да и версию уже придеться ставить серверную а не файловую...

Как по мне ответ очевиден, RDP + не плохо бы резервный канал связи. А настройка супер секьюрных наборов прав я бы даже не рассматривал как сложность.

!!!!!!!!!!!! Спасибо Вам большое!!!!!!!!!!!!!! Очень важно мнение сторонее)

Слабо план обмена и выгружать остатки по расписанию? Правила через КД пишем и грузим их в их базу... И они видят ваши "остатки" прямо в своей базе.

(7)+ Главный плюс это тут же встроенный штатный обмен доками отгрузки/приемки/возврата.

главный плюс обмена доками сильно уменьшается учитывая что их объем продаж и работы составит ли вообще процент от всего нашего, т.е. разовую выгрузку их накладной можно сделать как раз таки и через почту, а вот приобретение для них нового железа плюс всех лицензий на серверный вариант сильно ударит им по карману

(9) Гы для начала посчитайте кол-во юзеров удаленных по RDP * ширину канала для каждого = ?

И сравните с пропускной способностью каналов и тут и там. И стоит ли запрет сожрать весь канал торрентами/кошечками или хотя бы QoS тогда настроить.

(7) остатки в своей базе - как сказала выше их объем номенклатуры с которой они реально будут работать процентов 20 от нашей, спорно нужна ли им в их базе вся! наша номенклатура, им необходимо только для клиента озвучить что у нас есть а у себя держать всю эту информацию возможно смысла нет

(10) юзер один будет
формат "стол заказов"

обмены 1с = проблемы. Я помню ад из 30 узлов с приличным документооборотом и больше 100 торговых. Причем на узлах были только документы этого узла. Там даже приходилось буферные узлы создавать. Я проклинал обмены. А тут и минимального канал хватит и никаких проблем. 1 лицензия на терминал + 3г модем.
Мне кажется 1сники просто любят доставлять себе боль.

(11) Объясните науя им вся ваша номенклатура в своей базе? Как раз в правилах как угодно настроить.

(12) Ничего не понял, что у них тогда будет за "своя база"?

(13) Прикинь было 160+ узлов и никакого ада причем еще в 2007-2008 годах с теми смешными каналами.

(14) подозреваю чужие доки видеть не будут

(13) Кстати насчет 3Г модема, ладно если печать документов/отчетов не нужна. Но печать по VPN огромных доков это конечно редкий изврат )).

(16) Писец... Как бы в 1С давно уже все есть для разграничения прав.

(15) уверен документооборот меньше. Я видел 250 баз, на семерочном обмене (мод кажись), но там доков мало и 1 человек все время тратил на поддержку обменов

(17) я не против, я подразумевал, что в случае РДП отдельная база создаватся не будет

(18) Да маловат был оборот... всего то несколько лямов документов в год... причем с ТЧ некоторые (1/20) по 500 позиций.

(20) значит обманываете, что не было проблем. Там за 2 с половиной года база была 1.6ТБ

Спасибо большое за участие в разговоре! как раз интересны обе стороны решения вопроса
успеть хоть слово вставить)

на их точке есть своя база 1с с нее там локально продажи розничные идут, а товаров которых у них нет в наличии они клиенту смогли бы с нашей базы предлагать.
на чем клиент остановит свой выбор только то и будет оформлено в заказ.

естественно это только данные

уухх.. от размеров баз с которыми вы работали просто "дух сводит"

(24) там и разработчиков много было, да и пожалуй один из самых сильных коллективов в котором я работал с 1с. Как говорил начальник у нас стаж по северным год за три )

(21) Поймите проблемы которые можно сложно или невозможно решать админами... часто легко решаются программистами.

Если конечно перед ними задачу поставить правильно ))

Если им нужно видеть остатки, то или допиливать УТ до состояния удалённый сайт или давать доступ.
Если делают заказы, то тоже - или на сайте выбирают, или подключаются и в УТ колбасят.
Отдельную базу создавать смысла нет - если только выгружать данные для "посмотреть пока нет связи", но в этом случае им нужно будет покупать конфигурацию.
P.S. для просмотра остатков в Offline вполне подходит Excel.

(26)+ К примеру что полный обмен в центральной шел очень долго со всеми этими 160+ базами - несколько часов и сильно нагружал базу.
Решили очень легко, просто центральный склад работал не в центральной базе самой, а в специальной складской периферии.
Которая обычно штатно обменивалась с настоящей центральной базой, несколько раз в сутки.

(26) (28) Вы наверное меня не слушаете(читаете).
1. Самая сильная команду которую я встречал/работал (17 програмистов). Под стречал подразумевается встречал в улсовиях что бы оценить скилл. Админы там просто отдавали права на севера связанные с 1с, так как некоторые ребята шарили больше в этих темах.
2. Для оптимизации работы базы (не только вопросах обменов) применялось все, что угодно. И ВК и оптимизация типовых механизмов и программаная и аппаратная оптимизация БД. Для обменов испоьзовались буферные узлы, то еть 4 базы которы агрегировали в себе данные и потом сливали в ценральную базу. В  буферных базах периодически удалялись все данные.

уточнил у бывшего сотрудника торговых было 300+

Если складской запас не покрывает прогноз спроса хотя бы на плечо доставки к точкам - то имхается что все обмены идут лесом ибо не онлайн. А если на складе товара много то и офлайны покатят, но я сильно сомневаюсь что склад с 400 номенклатуры будет держать запас большой

(29) поймите что база 1С в 1.6 терабайт это из разряда сказок и идиотизмов

(32) Если в скуль красивые картинки товара добавить, а ещё если пользователи сканы хранить захотят - то база распухнет и более того. Только вот на скорости работы такой размер сильно не скажется.

(33) ну если эти картинки и сканы начать перезаписывать и гонять туды-сюды то влегкую тормоза будут...

(34) Это не тормоза - это будет полный п-ц.

Интересно почему 1С-ники до сих пор не сделали в типовых возможность загружать остатки поставщиков и делать заявки по этим остаткам, и чтобы автоматом формировался заказ поставщику

(36) Гы...давно есть... в типовых в т.ч.

И в https://ru.wikipedia.org/wiki/CommerceML выгружается, причем с "номенклатура поставщика" и там поставщик получив его может к себе штатно в конфу загрузить.

(37) Что есть? И куда я этот файл загружу?

Я про функционал когда мне поставщик присылает файлик с остатками, я загружаю его к себе в программу и далее могу работать с ним так же как если бы этот товар был у меня на складе, т.е. типа как сайты сделаны, я вижу товар от разных поставщиков выбираю понравившийся по цене/сроку доставки и бью заказ на клиента. Далее снабженец формирует заказ поставщику на основании этих заявок и отсылает заказ поставщику. Поставщик загружает к себе в виде заявки формирует отгрузку на меня и присылает мне файлик с отказом и/или файлик с тем что едет. Я это загружаю себе, после прихода товара на мой склад провожу поступления, которая автоматом завесила резервы по покупателям и дала сигнал менеджер, что товар пришел можно отгружать. Менеджер видит в отчете, что есть товар готовый к отгрузке (полной или частичной) и уже на основании заявки отгружает товар клиенту.

В какой типовой есть возможность загрузить номенклатуру поставщика, расценить её, и дать менеджер возможность видить что есть у поставщика (количество), по какой цене он может продать и забить заявку?

(38) http://easyprog.ru/index.php?option=com_content&task=view&id=952&Itemid=48

(39) я как бы про это речь и веду... в типовых УТ есть номенклатура поставщиков с остатками и вот как сказал так оно и работает ))
только там прайсы не факт что с кол-вом у поставщика, только номенклатура и цены

Пипец в очередной раз убедился что 1С-ники даже штатного типового функционала не знают...

http://v8.1c.ru/trade/vendors/analyz_i_v.htm

(41) Во первых тот функционал подразумевает что мы заведем все 400 тысяч позиции у себя в базе и проставим соответствие, а зачем мне это если менеджер закажет в лучщем случае процентов 10 от этого ассортимента?

Во вторых по картинкам непонятно что потом с этой позицией делать, т.е. позволяет ли программа отслеживать чья это позиция и формировать заказ на конкретного поставщика, или по каждому поставщику я должен бить отдельную заявку?

(44) такую хрень как ты описал я делал 10 лет назад, на фармопте.

(44)  вдобавок к описанному такой блок автоматом вычвлял у поставщика новинки и автоматом деактивировал выражающий ассортимент

(39)  и все именно так и происходило как ты описал с тем уточнением что менеджер к формированию заказов практически не допускался ибо они косячили больше чем сама прога

(39)  расценкам происходила автоматически, автоматом определялся лучший поставщик и иерархия остальных

Был также монитор заявок который позволял делать то что ты описал, только отгрузки на потоке выписывал оператор

(39)  причём это все по поставщикам велось по прайсам на отсрочку и предоплату отдельно

(39)  количества из поставщиков почти никто не давал, а кто и давал то имело импло смысла ибо неактульные были

(39)  дерево подчиненности по крупным сделкам могло занимать до 30-40 страниц

Самый тяжёлый участок был на стыке закупов и продаж ибо связан юыд с отказами поставщиков и необходимостью передавать инфу в контур продаж

А так как поставщики нормой много не удовлетворяли из своих прайсов то по отказам росла новая подсветка уже га новых ценовых условиях

Поэтому мне 8-ка мадоинтересна смайл

Очень многое из того что там есть уже было пройдено

Да, в снеговике это где-то сделано более аккуратно, есть что-то сего не было раньше, но концептуально это все неинтересно

А вариант с web интерфейсом и выгрузкой в CommerceML для своей базы не рассматриваете?
Будут заказ формировать в web, и получать его уже с документами для загрузки себе?

(55) да web интерфейс хороший вариант, что то пока у нас только с сайтом ничего не вышло..но возможно это стоит рассмотреть как основное решение задачи

(32) (33) (34) (35) Вы сами как думаете были там в базе картинки?

(56) хороший но не быстро реализуемый. По этому, лучше сделать быстрый вариант в виде RDP доступа и дальше без горячки реализовывать вэб интерфейс.

(45) Понятно, что и у меня на 7-ке это реализовано. Просто если переходить на 8-ке, то на какую конфу с меньшими затратами

(47) Ну у меня менеджер на этапе формирования должен по новым позициям принять решения завести новую позицию или выбрать из справочника, а так естественнно, далее, далее, далее (ну не доверяю я автомату, иногда откашивает он в плане, на транзакцию нарвался или не провелся, поэтому полуавтомат)

(50) Ну у меня пока соотношение 70/30, т.е. 30 % пока не дают остатки, остальные без проблем прайс с остатками дают. А смысл есть. Заказывая ты понимаешь вероятность подтверждения. Т.е. если ты видишь что у поставщика на остатке 3 штуке, а тебе надо 10 штук заказать, то какая вероятность что поставщик отгрузить 10 штук? Практически нулевая, Хотя согласен, что с другой стороны если заказать 1 штуку вероятность отгрузки тоже отличается от 100% в меньшую сторону

(59) ну и у меня аналогично. автоматом грузились прайсы поставщиков. новые позиции - откидывались в "хранилище" - по ним менеджеры делали такую же привязку (большую часть работы делали неквалифицированные менеджеры, бо 90% случаев - вполне тривиальные). Привязки делались (полу)автоматом (strmatch) - самый неквалифицированный менеджер просто подтверждал привязку или нет, или сомневался (тогда она шла к более квалифицированному)... то есть тупо шел по списку - и жмакал три кнопки да,да, нет, нет, да, да, не знаю,

(60) да, но ряд поставщиков давали вполне приличные остатки, а по факту подтверждали минимум, поэтому вообщем надежность поставщика определялась скорее не количеством в прайсе, а "качеством" поставщика...

после этого, все манины загрузки всяких прайсов мну неинтересны.. ;-)

(62) Ну мы обычно таких поставщиков отключаем

(64) вы изобрели что нить новое? нет! мы их тоже "отключали"...

(65) Ну так просто менеджер перестает заказывать товар принадлежащий такому поставщику и вопрос сам решается

И вообще я здесь не для того чтобы письками мериться, а узнать как это же самое можно сделать в УТ11, а то тут некоторые утверждают, что это всё давно в типовых реализовано. Если там это есть, то надо срочно на 8-ку переходить

(67) возьми http://trade.demo.1c.ru/trade/ru_RU/ да посмотри что там есть...

(68) Ну если бы нашел бы там, то не писал бы что жду

(69) Не знаю что ждете... Может что за Вас кто то работу сделает... Причем именно Вашу как ИТ специалиста некой конторы ))

(70) Ну так если там этого нет, то жду когда 1С добавит

(70)
Из описания
"Эта информация может быть использована при подборе товаров в заказа поставщику, при формировании печатной формы заказа поставщику, а также при выборе поставщика для закупок в рабочем месте Формирование заказов по потребностям."


Так что как мне менеджеру дать возможность бить заявку по покупателю по прайсу поставщика?

Типовой сценарий подразумевает что мы заводим номенклатуру у себя в программе, загружаем прайс поставщика и проставляем соответствие

Далее менеджер бъёт заказ по нашей номенклатуре и все что нет на остатки попадает в потребность. Программа,с учетом ранее проставленного соответствия предлагает снабженцу того или иного поставщика (точнее показывает у каких поставщиков есть этот товар и по какой цене).

Согласись это совсем не тот сценарий что я описал. Или хочешь сказать, что я что-то путаю и в типовых совсем не так? Ну так просвяти нас недалеких, как реализовать описанный выше сценарий, раз он уже есть в программе?