Есть два магазина,как сделать чтобы один смотрел остатки другого #443190

Общаются через сервер по фтп. Являются узлами РИБ базы 1С УТ 8.1. В узлах хранятся только "свои" документы(которые влияют на остатки соответствующего магазина). Вся картина хранится только на центральной базе на сервере. Как сделать так чтобы один кассир видел остатки другого магазина? Это можно сделать при полном обмене(обмениваться раз в 10 минут например), но не хотелось бы..... Как сделать по другому?

вариантов много

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

8.2 + Apache.

Ivan093: Твоя мысля наводит на след. мысль: Перед выгрузкой данных делать документ ОприходованиеТоваров, в котором выгружать свои остатки, но не проводить(иначе твои остатки задвоятся), когда другая аптека загружает из сервера этот не проведенный документ, он у себя проводит этот документ, и кассир увидит остатки:)) Как Вам такая идея skunk? Можете еще предложить варианты? Вариантов же много:)) Но каждый раз заполнять перед выгрузкой остатки и обмениваться - мне кажется не лучшее решение. 8.2 + Apache -и плюс еще использовать тонкий клиент? Тогда нужно будет перевести все на 8.2. и изучить как работает тонкий клиент, потом переписывать форму элемента номенклатуры, чтобы остатки по другим складам брались запросом из сервера, итд итп. И кстати вышло уже УТ 8.2? И переводить с 8.1 на 8.2 сложно или нет?

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

Извини за ОФФ. А как сделал в магазине только свои документы? В частности интересует перемещение товаров (с центрального склада или магазина1 в магазин2) как в магазине2 проводиться? А по поводу остатков, тоже стоит проблема, решил создать регистр сведений и заполнять его. Т.к. смотреть остатки удобнее в одной программе.

Перед выгрузкой данных делать документ Оприходование Товаров, в котором выгружать свои остатки, но не проводить- по идеи эта мысль верна .. потому что это как метод переливания в стаканы .. чтоб перелить из одного в другой . нужен третий стакан _________________ [url= посуточно     [/url]

А сделать например полный обмен по регистру Товары на складах не вариант? да ссылки на регистраторы будут кривыми, но это же не беда.

2Alexor Это делается как описано в толстой такой книжке Габец, Гончаров... Добавляется реквизит склад узлам планов обмена и в модуле плана обмена меняется процедура ПриОТправкеДанныхПодчиненному. 2Pashkaa Это идея аха, надо попробовать, но... Метод хорош тем наверно что будут обмены только измененных остатков... Я правильно предполагаю? Но на сервере мы хотим поставить MS SQL SERVER, потому что данных и проводок уже очень много, и файловая 1Совская база уже не справляется.. А в каждом магазине ставить MS SQL SERVER не хочется чтобы видеть остатки.

Ну если так то как вариант уже предлагаемый РС. Только надо в него писать на момент выгрузки не все остатки полностью а только измененные относительно прошлого обмена. Тогда в магазах потом пишешь отчет через СрезПоследних и теоретически всё заработает.

(не по делу) Реализовал обмен "по магазинам"? Молодец. Возьми с полки пирожок. И получи кучу... проблем. Чем раньше думал? Не знал, что магазины товаром обмениваются? Почему бы не сделать обмен всеми документами-регистраторами нужного регистра?

Потому что нехер видеть другим магазинам оборот других.

Не беда, говоришь? Предлагаешь регистр в обмен направить без регистраторов? Тогда забудь навсегда про ТИИ ;) RLS, а не "неполноценный" обмен, помогают не видить то, что не положено :(

И нечего его делать в распределенных базах :) Возникли сложности, создал новый образ. Да и давай поставим в каждый филиал по серверу что бы фильтровать RLS-ом. Можно вообще полный обмен запустить и не париться. Тогда у тебя на случай чего всегда будет бэкап удаленный :) Даже если бомба в центральный сервер попадет. Вон в соседней ветке один уже мучается.

Сделал также. Вопрос как летят регистры? В частности регистр партий и остатков? При проведении реализации в переферии, в регистре партий Ссылка на документ оприходования <Объект не найден> При выгрузке в центр, база центра вывалилась с ошибкой.

""Юпитер, ты злишься? Значит ты не прав"(с)

что такое ТИИ?:)

А у тебя стоит ведение Партий по складам? Если стоит тогда откуда такие трудности Я не не прав. Я за комплексное решение проблемы. Всё что можно не отправлять в периферийную должно остаться в центре. Всё без чего нельзя нужно отправлять. Если надо ограничить до лишнего доступ, ограничиваем RLS.Но ты же не будешь спорить что это под нагрузка на базу.

Тестирование и исправление конфигурации

вообще-то если они будут видеть остатки друг друга, то быстро передерутся.

К сожалению, ты прав. Но и я не предлагал "полный" обмен, а только тем, что нужно для функционирования типовой конфы в штатном режиме... Регистр сведений остатков - да, как вариант - решение. Но представь сколько времени будет уходить на поддержание его в актуальном состоянии. И какая альтернатива? Заново перезаполнять его перед каждой отправкой в обмен? Как-то не фонтан всё это :(

регистр сведений правильно предложили, доработок минимум

Проведение партий стоит. Документ оприходования не летит в переферийку. Соответственно в регистре в поле документ прихода битая ссылка. Дополнительно, хотят отказаться вообще, что бы партии летели в переферию, что бы не знали закуп.

(мысли вслух) Видить остатки, формировать и обмениваться перемещениями... Это значит в настройке базы должно быть "списывать партии документами" и "партии по складам"... а "это" всё так сильно тормозит... Озвучь "минимум". Интересно стало. Пока только, на вскидку, потребуется организовать "паралельность" с изменением регистра. Или в модулях документов (не формах!) при проведении, или в модуле самого регистра забабахать...

делаешь подписку на событие проведения товарных документов и по нему переписываешь остатки в регистре.

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

Угу. Ничего нового :) Подписка на событие (подправлю чуток) ко всем документам-регистраторам регистра. Ну там ещё мелочи остались: корректировка регистра; ОбменДанными.Загрузка...

Я не про проведение спрашивал а про ведение учета по партиям в разрезе складов. Если бы оно стояло то и Оприходование если оно проводилось по переф базе попадало бы к ним, тогда бы при списании их партии всё было бы ок. Зачем вам подписки при каждом движении Регистра накопления. По-моему достаточно при выгрузки Получать остаток по Регистру накопления, соединяете его тут же с Регистром сведений, выбираете записи по которым изменились остатки и их пуляете в переф.

А чем плохо все-таки что бы регистр остатков полностью мигрировал? пофик что без регистратора. Пофик на ТИИ в периферийных базах. в центральной все будет норм по идее

И еще не понятно, как автор победил перемещение. ведь оно должно быть в 2-х базах. иначе те же проблемы с движениями регистров

остатки <=> партии

Как оприходование попадет в переферию, если оно проходит по другому складу и не выгружается туда. Отсекается ПриОтправкеДанныхПодчиненному

а представьте 4х уровневую РБД :)

Ага, особенно, если рухнет база по середине.

(для обсуждения) Я бы предложил "прямое" перемещение заменить на пару складских ордеров (по рдерной схеме работать магазинам). Само перемещение по ордеру -делать в центральной. Но и это как-то... Уж лучше бы они внутренними заказами обменивались, а вся работа на центальной базе выполнялась бы. Можно и "автомат" наладить в ЦБ...

Если оно по другому складу, с какого перепугу оно участвует в проведении по партиям в переф базе? Если рухнет, есть бэкапы. Если у вас есть такое дерево из баз значит у вас есть мозги, значит бэкапы у вас 100% есть.

а я чё то проследил где речь шла о проблемах с доком перемещения?

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

Проблемы будут. ибо остатков как таковых нету. И партий - ку-ку. Перепроводить в центре придется. А магазинам - разрешить отрицательные остатки делать... Это так, на вскидку. Будут проблемы... Почему это "никогда не встретятся"? Им "встречу" надо организовать в ЦБ.

в ЦБ все будет гут, а вот в периферийке будет кривизна в регистрах, как ни крути

(для обсуждения) БП надо обдумывать. Есть так, как ниже указал, - кривизна :( Магазин "А" (видя остатки) - заказывает товар. Документ - внутренний заказ; Магазин "Б" (получив заказ) - отгружает товар. Документ - перемещение товаров...

А зачем? Самый прсто вариант - звонит продавец одного магазина другому и спрашивает :)

по первой части поста. А почему остатков то как таковых нету? Есть первоначальное перемещение товара в магазин. Оно к ним само собой попадает т.к. движение по их складу, далее идут продажи, идет следующие перемещения, которые к ним опять таки попадают (т.к. склад их) Партии настроены на учет в разрезе складов. Соответственно при списании товара в магазине алгоритм проведения по партиям видит доки партий (т.к. перемещения есть) и всё корректно проводит. Все проводки после выгрузки попадут в ЦБ. Зачем что то проводить, т.к. движения по магазинам сформированы в перф базе и корректны. Или я чё то не догоняю?

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

а понял про что вы. Но ведь сложность возникнет если вдруг в переф решат перепровести это перемещение. А иначе сложностей не возникает. Т.к. на складе получателе перемещение всё корректно прибавило. Если запретить в переф перепроводить документы владельцами которых являются не они то и проблемы не будет.

Посмотри как работает пара приходный и расходный складские ордера. Ну и перемещение по ордеру заодно посмотри :) Чисто формально можно сделать так: первый магазин (от имени второго), создаёт (но не проводит!) перемещение - это своеобразная заявка на товары. Второй магазин (получив с обменом) изменяет документ (если надо) и проводит перемещение "от себя". Но партии-то! Партии-то зависают у него за первым магазином. А подумайте какая хня начнется если возврат потребуется оформить... Нет. Всё-таки схема не рабочая :(

Сорри... хвост поста для . Не для :)

Ыыыы фот уж эти партии, ну да получается что переф всегда будут виснуть остатки если они со своего склада будут перемещать товар обратно. Т.е. по партии будет расход и тут же Приход уже по другому складу. Ну а если как ты предлагаешь. Если допустим магазину надо вернуть товар в ЦБ он делает перемещение но не проводит. Перемещение попадает в ЦБ, там его проводят. В магаз выгружаются только проводки по их складу по партиям. В магазе вроде все впрорядке. В центре тоже, т.к. там все движения по всем складам. Если магазин делает возврат товара, он делает его по своему складу соответственно приход по партиям падает на них. Всё это перегружается в центр.

Воот... Теперь, наверное, всем стало понятно почему перемещение, возврат и прочая нельзя проводить в магазинах, а только в ЦБ. Магазинам - обмениваться ордерами. И только ордерами! Потому что у них нет партионных хвостов :)

(в заключение) А теперь вернемся к и заново расмотрим вопрос "Почему бы не сделать обмен всеми документами-регистраторами нужного регистра?"... Я не считаю что обсуждение закончено и/или последнее слово за мной. Когда-то и мне с такой темой пришлось столкнуться. Я выбрал "полный" обмен как "минимальное неизбежное зло"... PS: Сорри. Свободное время закончилось :(

Жаль Сергей что пришлось прерваться. Появилась такая мысль. Если не использовать ордерную схему, а просто в ПБ не делать проводки в Партиях (и прочих регистрах где есть склад) по складам отличным от того что указан в настройках Узла. Тогда не будет оставаться хвостов в регистрах. Реализовать это так же не сложно как регистрацию для обмена. Вставить проверку в событие ПриЗаписи нужных регистров, если Узел не главный, и если Склад <> ТекущийУзел.Склад тогда Отказ = Истина;