К знатокам 8.3
 

Нужен методологический совет. Позвонила знакомая, возможно понадобится ей помощь. Жила-была база БП 3.0, горя не знала, обхем наживала. Но в один прекрасный солнечный день взяли ее домой 2 бухгалтера, и стали базы у каждго буха свое добро наживать. А теперь встретились бухи в горькой печали и не знают как им обратно 2 базы в одну засунуть ) Как проще всего провернуть такое мероприятие, желательно максимально штатными средствами. У меня мысли есть, но хочется услышать умные ) Просто может кто уже что-то подобное делал. Базы жили раздельно около квартала, за главную можно взять например первую. Конфигурации будем считать типовыми, если что обновить до одного одинакового релиза не проблема

ууу... оне ж не только добро наживали, но и пропивали ранее нажитое
В смысле могли модифицировать существовавшие на момент развода данные. И если эти данные касаются остатков в регистрах можно получить нежданчика...
Если принять несколько допущений, то задача разрешима
1) считаем, что объект создан в базе 2 если его ссылка отсутствует в базе 1 (а не удалён в базе 1)
2) все коллизии разрешаем в пользу базы 1

Тогда задача сводится к следующим
1) определить созданные в базе 2 объекты (решаемо)
2) определить, нужно ли их синхронизировать с объектами базы 1 (возможно, они родились параллельно)
3) перенести новые не требующие синхронизации объекты (решаемо)


Возможен вариант:
1) определить созданные в базе 2 объекты (решаемо)
2) перенести новые не требующие синхронизации объекты (решаемо)
3) бороться с дублями

Без творчества не обойтись: в первом случае с 2), во втором - с 3)
:)

... и пофиг что это 8.2, 8.5 или 7.7 ...

(1,2)Ну не пофиг, так как в 8.x есть 36-значный UID объекта
Общая схема то мне понятна, определить новые элементы в базе 2 я смогу, а как проще перенести, какими средствами?

ВыгрузкаЗагрузкаДанныхXML82.epf чуть подпилить в части отбора объектов
И аккуратнее с выгрузками "по ссылке", иначе [b]часть [/b]коллизий может быть разрешена в пользу базы 2

+ мне частные случаи бывает легче обработать в консоли из состава инструментов разработчика.
ЗначениеВФайл("бла-бла-бла",мРезультатЗапроса.Выгрузить()) в источнике и мОбъектЗапроса.УмтановитьПараметр("ТЗ",ЗначениеИзФайла) в другой прекрасно отрабатывает в базах идентичных по метаданным ;)

Вот только БП3 после ввода начальных остатков этот период закрывает наглухо. Я поступил так: посмотрел в кишки конфигурации, плюнул, и ввел исправленя ручными операциями. Благо, там и регистры иожно заводить. Датой от 1 января, с 0 часов, 0 минут. Ну да, обороты за январь погибнут ;)

а если базу 2 вычистить от всего, что есть в базе 1, то можно как-то их слить средствами УРИБ ?

Я не знаток 8. И тем более 8.3

Но методологически кое-что понимаю...
(Опыт разработки в различных СУБД с 1993 года).
ИМХО, задача нерешаема.

В базе 1: Введен документ Поступление материалов.
Номер документа - такой-то.
Заведен новый элемент в справочнике материалы. Код в справочнике - такой-то.
Дата документа - такая-то.

В базе 2: Введен этот же документ.
Номер и/или дата документа - другие.
Заведены материалы.
Наименования и коды в справочнике - другие.

По какому признаку сопоставлять?

Если даже удалось сопоставить (что вряд ли) - какие изменения считать приоритетными?
- Документ считать актуальным из базы 2.
- А вот правильность заполнения Справочника Материалы - считать наиболее правильным в базе 1?

ЗЫ: Помимо справочника Материалы в базах еще существуют справочники Контрагенты, Договоры...

КРОМЕ ТОГО, существует первичка.
Счета-Фактуры, Акты сверки, накладные...
На один и тот же документ - разная первичка?

Кроме того, сдавалась отчетность в различные госорганы.

Как вариант - находясь в базе 1 - парсить журнал регистрации в базе 2 (которую принято решение убить), все изменения всех объектов - выдавать на рассмотрение Гендиру и Главбуху. Если совпадение полное - естественно, не учитывать.
Пусть расставляют галочки (оставляем/убиваем).


Насколько мне известно, такой обработки для 1С8 нет.
Для 1С7 есть, даже несколько.

Переходите на 1С77.
И вообще, какой балбес перевел эту фирму на 1С8?
Уволить его.

(0) зачем взяли домой два буха и били разное ?
текущий период били или старый ? данных много?
может ручками :) ?

10-Фдуч > Во ты наивный...

Допустим, били только текущий период.

Неужели ты думаешь, что данные прошлых периодов они при этом не затронули?

И как вообще определить период у реквизита "Фамилия" у сотрудницы, вышедшей замуж?

Или тот же самый, например, (смотри страдания Бухты) реквизит ИНН?

Валютная Выписка проведена в базе 1 с одним курсом евро, в базе 2 - с другим. Какая валютная сумма правильная?
(Рублевая сумма - одинаковая. Все в этих базах сходится, и в клиент-банке тоже).

В базе 1 у Контрагента заведен Договор (аццки важный, стотыщ триллиардов убытки будут по нему, если чо. В базе 2 - абсолютно такой же заведен. И в базе 2 - сумма более правильная. А дата прекращения Договора - КРИТИЧЕСКИ неправильная.).

В другие системы выгрузки были?
(Даже в виде текстовой почты Гендиру, чтобы он лапками себе вбил в свой ЧОРНЫЙ Эксель некие данные, кому из Контрагентов он откаты должен чисто по понятиям, или ему должны, кого пора прессовать...).

Если ДА, то из каких баз и когда?

Прикольно будет, если Ваш Владелец Бизнеса обратится к бандитам (т.е. в ФСБ или МВД), с просьбой, чтобы они закатали в асфальт Контрагента.

Они приедут со всем реквизитом...
Пригонят 5 машин асфальта...

А Контрагент предъявит первичку из базы 2 Акт Сверки, что он не должен...

Ваша Служба Безопасности каждую из этих бухш проверила (на предмет логов их мобильников, звонки любовникам, одновременно являющимися сотрудниками конкурентов), прежде, чем давать им базы?

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

Ибо если возникает такая задача - раздать базу 2м курицам, - то у любого нормального психически программиста 1С мгновенно есть ответ: УРБД.
Если такого рефлекса нет, - то это не настоящий сварщик.
Увольнять немедленно.

Ну и нафлудили. Все замечания справедливы, зачем давали - не знаю. Я их и в глаза не видел. Задача сегодня уже вроде как умерла. Я бв может и не взялся, потом буду виновать во всех грехах.
А сопоставлять предполагалась по UID, который уникальный внутри каждого вида объектов. База вычищается, перенумеровываются справочники и документы и затем уже объединяются. Если оба буха завели одни и те же объекты (например, материал), то это уже их проблемы. Причем программист у них вроде как есть, но вроде как заболел ))

[quote=DeiMos;41192351]ИМХО, задача нерешаема.[/quote]

Соглашусь… Попытка программиста ублажить сразу двух барышень, чревата тем, что при малейшем подозрении на некорректную работу программы, в два голоса будет раздаваться, что до слияния баз окаянным программистом все работало просто очаровательно.
Посему, надо было брать за основу чью-то базу (можно, например, монетку кинуть), а “коллектив” рационализаторов делил бы работу менее везучего бухгалтера, и лапками бы доколошмачивал недостающие документы.
Тем самым, на будущее, подобная самодеятельность была бы пресечена просто и элегантно.

15-USSR > Чегоооо?
Ты трезв сейчас?
Увольняйте программиста (Гоните в шею франча).

UID абсолютно разный в каждой базе для новых объектов.

UID одинаковый для старых объектов.
А какой из этих старых объектов приоритетен?

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

Если он настолько непрофи, что допустил ситуацию из сабжа.

(16+) Чтобы 2 бухгалтера в один день взяли домой базу, сомневаюсь... Не верится мне в подобные совпадения. Какая-то одна, да, могла. И когда она заявилась на работу с результатами своей работы дома, оказалось, что с базой на работе трудится другая бухгалтер.
В это я еще готов поверить... Так что, видится мне, лукавит знакомая. Скорей всего, это ее косяк.

(17)Что не так про UID ? UID в 8-ке формируется совсем не так как в 7-ке.
(18)я подробностей не знаю. Про "руками" я сразу посоветовал

19-USSR > Я ХЗ. Что там не так.
Я тебе написал, что у старых объектов - UID будет одинаковым.

У новых - разным.

Если напишешь, в чем я был не прав, - буду весьма признателен.

(20)а кто спорит, что у новых разные ? а в чем я неправ ?))

21-USSR > Ты не прав в своем мессидже (19).
Чего ты там хотел, чего писал, не понимаю.

Я тебе в (17) написал, что ты профнепригоден, потому что планируешь отталкиваться от UID в (15).

Ты мне в ответ написал в (19) - а что не так?
Да ВСЕ не так.

(22)смотри (15) UID (36 значный) уникален внутри каждого вида объектов. То что я профнепригоден, раз говоришь, значит так и есть. Тут трудно спорить )

(22)примерно вот так проверяется:
UID = Новый УникальныйИдентификатор(UID);

НоваяСсылка = Справочники[ИмяСправочника].ПолучитьСсылку(UID);
НашЭлемент = НоваяСсылка.ПолучитьОбъект();
Если НашЭлемент <> Неопределено Тогда
Возврат Истина;
Иначе
Возврат Ложь;
КонецЕсли;

23-USSR > Жееесть....
Ты точно сейчас трезв?

Объект - справочник Контрагенты.

В базе 1 завели нового контрагента.
Его UID ты прав, уникален внутри вида.
Т.е. - однозначно будет отличаться от UID документа "Акт сверки" (другого вида объектов).

В базе 2 завели этого же Контрагента.
Тоже весь из себя уникальный UID.

Далее продолжать?

Объект - вида Справочник Контрагенты.
УИД уникальный.

Ну и чо?

Он разный в 2х базах для одного и того же Контрагента.
Как от него отталкиваться?

Ты не в том направлении мыслишь, я не собираюсь сливать контрагентов, задача стояла лишь распознать объекты, которые созданы в базе 2, то есть новые, введенные после унесения домой. Более ничего )) дубли возможно бы возникли. Хотя не исключаю, что один мог заниматься отгрузкой, второй приходом. А по поводу UID. Могу быть неправ, но по моему как раз UID контрагента может совпадать с UID номенклатуры

27-USSR > Так в (9) жеж единственно правильное решение указано.
Не?

И не только новых, но измененных список можно выцепить...

Ну распознал ты их в базе 2...
Дальше что?

(28)Распознал и перебросил в Базу 1 )) Фигня все, не грузись )) Может скоро и 1С не надо будет )

29-USSR > Ну, задвоил ты их в базе 1.
Дальше чо?

Дальше пусть раздваивают ) если им нужно Или ты думаешь такая контора заплатит и оценит идеальное решение ? Это скорее всего шарашка

Вопрос благополучно скончался ) Но вот есть другая проблема. Совсем недавно в БП 3.0 1С вынесла вперед ногами "ОсновнойДоговор" из карточки контрагента, в регистр сведений "ОсновныеДоговорыКонтрагента". Тем самым, для каждой организации у контрагента может быть свой "ОсновнойДоговор". И все бы хорошо и замечательно, но вот возникает проблема обмена с программами, в которых основной договор по прежнему один. Импортирую документы из ТИС 7.7, там у контрагента есть документы по разным организациям, поэтому при обмене по ссылкам тяну его "ОсновнойДоговор". Но так как он всего один, то БП 3.0 пытается переписать у договора организацию и ругается, что по договору есть проведенные документы (по другой организации). А 1С не дает возможности в регистре сведений оставить организацию пустой, чтобы основной договор действовал для всех организаций. Вот такая коллизия, как ее лучше разрешить? Может просто я что-то не понимаю. Да еше и самого договора есть реквизит "Организация". И получается этот "ОсновнойДоговор" каким то неприкаянным ))

Придумал, малой кровью, вопрос закоыт ))

32-USSR > Вообще-то, вопрос с РС "Основные договоры Контрагентов" интересный: если взять сиюминутную ситуацию, то вообще не понятен смысл - в чем польза для нахождения ссылки на договор из отдельного РС по регистратору (докумена), заместо взять туже самую ссылку из реквизита документа? Окромя переписи туевой хучи запросов?

Но смысл появляется, если "основных договоров" будет не один: на каждый вид операции свой собственный. Т.е., "на покупку" - один "основной договор", "на продажу" - другой, "лизинг" - третий, и т.д.

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

(34)О том и речь, что 1С вроде что-то придумало, а толку непонятно есть или нет. Тем более, что сделано это в программе бухгалтерского учета. Самое смешное и печальной, что с покупкой и реализацией своя засада, так как в договоре надо указывать его тип, то есть правильно ты говоришь, что если Контрагент может быть и поставшиков и покупателем, то в существующей парадигме 1С для него вообще теряется смысл основного договорв. Я выгружаю своей обработкой и поддерживаю специальный регистратор в торговле (36 значный UID Объект ТИС) и сейчас этот регистратор просто "разрезал" по фирме для договоров. В принципе можно разрезать и по другим параметрам.

35-USSR > Ну, толк есть: ЗУ/ЗиК не надо будет формировать проводки, например. И наверное, УТ/ТиС/ets. И в обратную сторону тоже.

(28)не очень понял. Я увы не понял и зачем надо было вставлять в договор "ВидВзаиморасчетов" (Покупатель, Поставщик, Прочее). Договор - аналитика взаиморасчетов. Куда упадет движение зависит от учетного документа. Зачем еще вид договора, организация договора. Может я просто не вник. Но по мне так это лишнее )

а вариант что у старого контрагента/договора с одним и тем же UIDом поменяли что-то вообще не рассматривается?
как с вами жить тогда?

наприер один бух взял старый "Основной джоговор" и обозвал его "Договор №1 от 01.01.2014 года комиссионный". а второй бух изменил тот же договор на "Договор с покупателем №2 от 02.02.2012 на поставку офигенной кучи всего проводимый через счёт 76.5"
и?