JohnyDeath писал(а) 11. Декабря 2008 :: 10:51:


Нет. Я делаю сравнение(например спр Номенклатуры) и получение данных(документы) через прямые.
Запись штатно в базе приемнике (кстати родные методы 1С-ки пишут достаточно быстро)
Запросы из базы приемника

JohnyDeath писал(а) 11. Декабря 2008 :: 11:28:


Из второй базы прямые запросы к родительской и к двум одновременно по технологии
http://www.1cpp.ru/forum/YaBB.pl?num=1182497837/19#19
запись здесь же по результатам запроса.
Никаких других баз не открываю.

JohnyDeath писал(а) 11. Декабря 2008 :: 12:22:


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

А может комплексная, одна фирма белый учет, другая фирма - черный учет, причем не нужно ничего дублировать в черной базе, если нужно видеть обороты счетов белая + черная, то по всем фирмам. Такой подход не проще будет ?

JohnyDeath писал(а) 11. Декабря 2008 :: 14:55:


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

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

JohnyDeath писал(а) 11. Декабря 2008 :: 15:21:

пространство guid должно быть непересекающимся по различным учетам  (только белое и только черное) для двух баз. Или это свойство guid ?

Я вроде все прочитал, только не совсем понял чем вариант второго плана счетов не устраивает?
Есть конечно один большой минус, очень много документов надо переписывать и второй - быстродействие. Поскольку все проводки в одной таблице то с ростом количества проводок растет и 1SENTRY и это неприятно сказывается на отчетах которые собираются по "промежуточным" периодам. Т.е. не с нач.кон месяца, а с какой-нить даты по какую-нибудь. Но зато потом и все ОСВ и прочие радости с удовольствием работают без проблем.

Жаль что я сначала в тему не влился... но мне инет отрубили и все тут . Хотя мое мнение наверное и не стали бы особо слушать 

JohnyDeath писал(а) 11. Декабря 2008 :: 18:44:


Если будет 2 и более ПС то:
1. Они всегда будут видимы в окне выбора счета (стандартные отчеты+справочники+документы) если там не указан конкретный ПС
- т.е. это первая доработка. Берем каждый отчет и меняем просто Счет -> Счет.Основной (чтобы другой выбрать не могли)
- далее отчетик пишешь чтобы не все подряд смотреть и по нему по метаданным пробегаешься и везде чтобы пользователи мозг не "тру-ля-ля". Нам же скрыть надо по макс верно?
2. Оба ПС будут видимы в окне которое открывается при нажатии стандартной кнопки ТТ на панели 1С.
- лечится написанием своей обработки и подстановкой
3. Документы которые должны быть во втором плане счетов могут быть как в основном так и во втором плане счетов надо переписывать. Как вариант вот порядок действий:
- добавляешь закладки на которых располагаешь нужные тебе реквизиты. Т.е. одновременно документ для некоторых как и был, а для других он еще и дополнительно проводит то что надо. Правда рулежка правами должна быть хорошая. В проведении кое-где просто задвоение, где то переписать. Советую сразу добавить две переменные глОсновнойПланСчетов, глДополнительныйПланСчетов, чтобы не парится. Счета создаются как обычно через "СчетПоКоду", соответственно проблем нет. Берешь копипастишь или в цикл
Для НомерПС = 1 По КолПлановСчетов Цикл

- Что касается прав на закладки, инсентером по конфе пробежаться везде одну процедурку для контроля поставить... но это на вскидку. Отдельные проблемы чуточку сложнее наверное будут в плане реализации управления правами.
- поскольку документы по двум ПС оба будут в движениях и операциях то: 1. Меняешь форму проводок 2. Форму журнала операций прийдется закрыть. Или писать аналогичную но свою собственную. Что собственно не очень сложно. Даже прямым запросом две таблицы понадобиться всего (и работать будет вполне норм). 3. все формы которые так или иначе дают доступ к информации. Их не много.
(как изменить форму просмотра проводок тебе решать или RWidjets ловишь выбор команды и свою подсовываешь, или стандартную форму многострочную часть прячешь, располагаешь ТЗ, колонки аналогично расставляешь (Fromex рулит), заполняешь только по одному плану счетов + привязка. Т.к. ТЗ почему то сама не изменяет размер, благо подправили этот косяк)
- написать пару обработок для просмотра движений по двум ПС.

Есть проблемы с производительностью, т.к. тут в формат хранения вопрос упирается. 1С хранит проводки в одной таблице по всем ПС, соответственно объем проводок увеличится, а значит и увеличится объем таблицы и итоги будут собираться постепенно все тяжелее и тяжелее за промежуточные периоды внутри месяцев (и по проводкам, в общем тогда когда 1SENTRY читается). Кстати в 8-ке реализовано рациональнее насколько я понял.

Это то что я написал на вскидку. Вообще если интересна такая реализация стучись в аську, там я есть, а сюда только по вечерам счас получается . (205 971 125 - вот)