Приветствую. Вопрос к спецам, ситуация следующая: есть основная база 1С (Комп1),в неё постоянно заносятся данные (расходы,приходы), и ещё есть периферийная база (Комп2),в неё так же заносятся данные (расходы,приходы). Необходимо из периферийной базы (Комп2) передавать данные в основную базу, т.е. чтобы накладные,остатки и прочие документы из периферийной базы отображались в основной.
[URL=http://fastpic.ru/view/57/2013/0923/3437ab0b6c19dcf272b30f1eb2998513.jpg.html][IMG]http://i57.fastpic.ru/thumb/2013/0923/13/3437ab0b6c19dcf272b30f1eb2998513.jpeg[/IMG][/URL]
Возможна ли реализация такой задачи в 1Cv7,7 ? В любом случае прошу подсказать хотя бы направление в котором смотреть,чтобы решить её. очень нужно.
Спасибо.

РБД

обменники (туева хуча)

(2) "шо, опять?"©

(3) шо? опять "криво"? дя бл шож такое сегодня

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

(5) т.е. РБД подходит все априори и остальная шняга даже рассмотрению не подлежит. и только потому что УРБД - написана 1С?

(6) для данного решения - практически наверняка РБД лучше.
в принципе, при доработке руками РБД в 95% случаев будет лучше.

(7) У тебя в углу кабинета не стоит икона Нуралиева? ;)

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

(8) нет. более того, меня очень часто упрекают, что я пользую вези, неблагославленные нуралиевым напрямую.
но практика показала, что РУБД+прямые руки покрывают 99% потребностей.
(у меня пользователь в пользовательском режиме может определить миграцию документа, миграцию документов в зависимости от склада или контрагента, миграцию самих элементов справочников)

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

стоит только 25к

(12) ну, это да. Хотя потеря данных при переносе "обработками" может обойтись дороже..

(13) не фантазируй

(14) за месяц через автообмен проходят порядка 40 тыс. документов и элементов. потерь практически не помню за прошедшие 7 лет.

Предлагаю перейти на 8ку ))

(0) И звать сего коня "УРБД", гугли слово УРБД :)

(16) А там чем лучше? :)

(15) ты не поверишь - но тот клиент которого мы обсуждали утром так вот необходимые данные сливаются со всех баз (какими бы они разными небыли) в одну "бухгалтерскую". обмен моим универсальным обменником. настройка под базу - 10 минут. из добавок к базе два справочника и три общих реквизита. за 5 лет ни одной потери небыло

(18) РИБ встроенный, бесплатны

На счет УРБД не поспоришь.
Хотя у меня еще и МОД допилиный (тригерами для регистрации изменений) в связке с УРБД.
Все пашет как часики.

(19)поверю. только это обмен в одну сторону. И, скорее всего, без квитирования. При работе "в пределах сервера" скорее всего, работоспособен.

(22) два разных сервера разнесённых в пространстве. обмен в обе стороны (из бухгалтерии оплаты безнал летают по базам)

(21)Время вы видимо по плугу определяете. 1Сники такие 1Сники

а что такое "квитирование"? подтверждение обмена удачного?

(25) да.
(23) после того, что ты нарассказывал сегодня - в устойчивую работу на разнесенных серверах в обес тороны верится слабо...

(24) ой вот только не надо про новизну говорить. на днях звонит админ клиента и начинает втирать что собирается менять железо на серваке типа "что ставить". я ему 2003+2000 скуль. это чудо лупит 2008+2008 скуль. результат - фирма два дня не могла работать нормально. админ потом признал что был неправ. а вначале кричал тоже "хватит на старье работать развитие надо"

(26)не верь ;) оно конечно сложно....

Аааа предать Стрелка анафеме. он не юзает внешние печатные формы и базы для удобства работы разделил по направлениям деятельности! Ааааа кошмар на костёр его :0 ;)

смешной ты чесслово

(28) дык оно несложно... просто ты как то делаешь все... скажем так - "странным образом"

(11) а причем тут пушка? странное сравнение. механизм УРБД легче и проще.

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

(22) так и в (0) вроде как тоже в одну сторону обмен. на проклабе валялась давно отличная бесплатная обработка для таких случаев. смысл тратиться на УРБД или МОД?

(32) надо использовать ПиВО (Присоединенные и Встроенные Объекты)... OLE на буржуйском

У УРБД еще плюс, что если человек уволится, то потом найти того кто с УРБД разберется просто, да там и разбираться особо не надо. А вот со всякими поделками потом приходится часто голову ломать наследника.

*наследникаМ

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

(37) в одну сторону?
а о синхронизации номенклатуры/контрагентов/и т.п. - не думали?

(38) изначально в базу источник заливаются справочники, вновь создаваемые в источнике с проверкой льются в центр. хотя о созданных в центре лить в источник тоже стоит. но это решаемо. УРБД конечно лучший вариант, но в условиях ограниченного бюджета можно и обработкой. И ни в коем случае не связываться с МОДом. Хотя может просто я его готовить не умею.

Да, УРБД избавляет хотя бы от одной головной боли - с синхронизацией справочников.  За одно это можно простить ему все. Не говоря уж об его надежности. Хотя читал про битые базы УРБД, но сам лично не сталкивался ни разу, хотя юзаю довольно плотно.

(39) решений - вагон и маленькая тележка.
УРБД - самое простое и устойчивое. стандартное, документрованное, известное  практически всем 1с-никам (т.е. легкоподдерживаемое,  переносимое и воспроизводимое). Внедряемое за минуты. хотя и имеющее некоторые ограничения. И не самое дешевое.

(38) хммм... нда, это будет полезно. значит все-таки нужна синхронизация в обе стороны.ок. Спасибо =))