Добрый день! Имеется организация с примерно 20-ю филиалами по стране. В каждом филиале ведется своя база БГУ. Собственно вопрос как из этих 20 баз склеить (сконсолидировать) одни общий журнал "Журнал операций № 7 по выбытию и перемещению нефинансовых активов".
Очевидный вариант объединить все 20 баз в 1, например, с помощью ВыгрузкаЗагрузкаДанныхXML82 или подобного инструмента, НО здесь возникает проблема:
при создании баз за основу бралась одна и затем справочники и некоторые документы переправлялись под себя (т.е было учреждении "111" наименование переправили на свое например "222") к чему это ведет? а к тому что у некоторых объектов (например организация "111" и "222") используются одинаковые GUID, а следовательно при объединении обработка посчитает, что это один и тот же объект и заменит "111" на "222", в итоге получается каша.
Как выйти из данной ситуации?
Заменить GUID я так понимаю нельзя, т.к он создается только при создании объекта.
Очевидный вариант объединить все 20 баз в 1, например, с помощью ВыгрузкаЗагрузкаДанныхXML82 или подобного инструмента, НО здесь возникает проблема:
при создании баз за основу бралась одна и затем справочники и некоторые документы переправлялись под себя (т.е было учреждении "111" наименование переправили на свое например "222") к чему это ведет? а к тому что у некоторых объектов (например организация "111" и "222") используются одинаковые GUID, а следовательно при объединении обработка посчитает, что это один и тот же объект и заменит "111" на "222", в итоге получается каша.
Как выйти из данной ситуации?
Заменить GUID я так понимаю нельзя, т.к он создается только при создании объекта.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Про GUID . Если кратко, то у каждого объекта, будь то элемент справочника или конкретный документ есть уникальный индентификатор, и он не меняется на протяжении всей жизни этого объекта чтобы мы не делали с этим объектом (переименовывали, изменяли дату создания, код и т.д.). Теперь представьте ситуацию в организации создается филиал заводить полностью новую ИБ лень, поэтому берут уже имеющуюся и перебивают некоторые справочники и документы под себя (не создают новые, а именно изменяют уже существующие). Что получаем в итоге? А то, что в первой базе например по GUID "6a09f20a-8de6-11e1-b3e1-001617ec3f2a" найдется элемент справочника ЦМО "Гадя Петрович Хренова", а в другой базе ЦМО "Убиваков Патрашил Насильевич". А при объединении баз например стандартной обработкой получаем, что "Гадя Петрович Хренова" заменяется на Убивакова П.Н. т.к. ссылки то одни и теже (GUid). Вот как то так!
Причем самая большая беда это, когда у документов из разных баз один индентификатор, тогда начинают рваться обороты.
Причем самая большая беда это, когда у документов из разных баз один индентификатор, тогда начинают рваться обороты.
(3) 2PRV, слушайте, несколько раз объединяли БГУ, никаких конфликтов не возникало! Никто никого не подменял, ни в одном справочнике! Если что-то не получилось при объединении, кидайте скрины.
Что значит: "создается филиал заводить полностью новую ИБ лень, поэтому берут уже имеющуюся и перебивают некоторые справочники и документы под себя (не создают новые, а именно изменяют уже существующие)"???
С какого они перебивают существующие? Зачем? На основании чего?
Что значит: "создается филиал заводить полностью новую ИБ лень, поэтому берут уже имеющуюся и перебивают некоторые справочники и документы под себя (не создают новые, а именно изменяют уже существующие)"???
С какого они перебивают существующие? Зачем? На основании чего?
(5) MBM89, Ну например есть 2 базы Иб1 и Иб2 и их нужно объединить. В Иб1 есть ИФО "Ифо1" в Иб2 есть "ИФО2". Для контроля формируем оборотки до объединения. И с помощью обработки ВыгрузкаЗагрузкаДанныхXML82 из Иб2 выгружаем все документы с движениями и загружаем в Иб1. После загрузки формируем оборотку с отбором ифо="Ифо1" и видим что обороты перестали идти с теми что были до загрузки в Иб1 (например по счету 101.34). А оборотка с отбором ифо="ифо2" совпадает с той что была сформирована в Иб2, т.е поломались только обороты из Иб1. ОК. Начинаем разбираться. Формируем карточку счета 101.34 и видим, что после объединения документ "Ввод остатков ОС и НМА Я5000032 от 31.12.2011 0:00:00" исчез, а до загрузки он был в Иб1.
(5) MBM89,
Точно не знаю, не участвовал в этомбеспределе создании. Но могу предположить, что была была Иб1 в центральном офисе. Затем создается филиал, который решает а зачем нам брать пустую бгу и заносить в нее кучу данных (основные, номенклатуру, ифо), когда можно взять Иб1 и удалить из нее все лишнее, ну а того чего будет не хватать дозанесем руками. Ну вот они берут Иб1 обзывают ее как Иб2 и начинают править. Например в Иб1 был ОС "Стол письменный", а в филиале нет стола письменного, но зато есть "стол компьютерный" и тоже 5 штук, а значит мы сейчас зайдем в ОС "Стол письменный" переправим название на "стол компьютерный" и все будет Ок и даже не надо будет создавать новый ввод остатков, а можно будет взять и перепровести существующий, тот что остался от Иб1. И т.д. и т.п.
Логика ужасная, но по другому я не могу объяснить то, что вижу и с чем я столкнулся.
Что значит: "создается филиал заводить полностью новую ИБ лень, поэтому берут уже имеющуюся и перебивают некоторые справочники и документы под себя (не создают новые, а именно изменяют уже существующие)"???
С какого они перебивают существующие? Зачем? На основании чего?
С какого они перебивают существующие? Зачем? На основании чего?
Точно не знаю, не участвовал в этом
Логика ужасная, но по другому я не могу объяснить то, что вижу и с чем я столкнулся.
(9) 2PRV, а почему 2011 год???? перед объединением БД должны быть проведены все регламентные операции: закрытие года, счетов санкционирования, забалансовых, если бюджетники. После этого производится свёртка каждой БД на дату 31.12.2013. 23:59:59. Поскольку с Корректировкой записей регистров удобнее возиться. После этого уже объединять!
PS. А вообще то, что вы рассказываете, как они перебивают имеющиеся объекты - это жэсть! Трэш! Дайте автомат я устрою 37-й год этим бухгалтерам!!!! Ааааааа мамамамамааааа! Что они творят! Бейте их по рукам, а если не понимают, то по голове! Не удивительно, что такие проблемы.
PS. А вообще то, что вы рассказываете, как они перебивают имеющиеся объекты - это жэсть! Трэш! Дайте автомат я устрою 37-й год этим бухгалтерам!!!! Ааааааа мамамамамааааа! Что они творят! Бейте их по рукам, а если не понимают, то по голове! Не удивительно, что такие проблемы.
(10) MBM89,
А вообще да, страашноо!
После этого производится свёртка каждой БД на дату 31.12.2013. 23:59:59
А свертку рекомендуете производить каждый год? Мне кажется для бухгалтеров будет не очень удобно иметь 3-4 базы и среди них искать какую то определенную операцию за позапрошлый год.
А вообще да, страашноо!
(13) 2PRV, свёртка в принципе обязательна, когда такие объёмы! А уже удобно или нет - не бухам решать, можно просто начальнику сказать, что либо так, либо вообще никак)))) Кстати я так и не понял, почему БД не свернули 31.12.2013 г., и только после этого не начали объединение?
Дальше, берем обработку ПолучитьСсылкуПоУникальномуИдендификатору и в оригинальной Иб1 запускаем ее и смотрим какой GUId соответствует Ввод остатков ОС и НМА Я5000032 от 31.12.2011. Копируем Guid. Дальше Заходим в Иб2 и пробуем найти объект который соответствует этому Guid и, о чудо, (точнее беда-беда) находим "Ввод остатков ОС и НМА Я1000002 от 31.12.2011 0:00:00". Теперь заходим в ту, что получилась после объединения и запускаем там поиск объекта по Guid и находим "Ввод остатков ОС и НМА Я1000002 от 31.12.2011 0:00:00"!!! Т.е. документ с номером я1000002 заменил документ с номером Я5000032, т.к. их индентификаторы одинаковые.
ммм, чую запах минобороны)))
разделение и соединение частей происходит. и тяжело сотрудникам забивать в базу 20 тыщ наименований. поэтому базы копируют. и начинают их править. или была одна часть, а ее разделили на 4. делали 4 копии и удаляли лишнее.
журнал 7 общий заносим в общую базу руками. потому как проверку дополнительную проводят бухгалтера. с большой вероятностью к этому вы придете в процессе работы. у нас собирается порядка 40 баз в одну. и делать перенос все ос и мз просто не реально. можно как вариант сделать загрузку оборотом. типа создать цмо - подразделение 1 (ну или номер части) и ос (мз) с названием части. идея понятна?
разделение и соединение частей происходит. и тяжело сотрудникам забивать в базу 20 тыщ наименований. поэтому базы копируют. и начинают их править. или была одна часть, а ее разделили на 4. делали 4 копии и удаляли лишнее.
журнал 7 общий заносим в общую базу руками. потому как проверку дополнительную проводят бухгалтера. с большой вероятностью к этому вы придете в процессе работы. у нас собирается порядка 40 баз в одну. и делать перенос все ос и мз просто не реально. можно как вариант сделать загрузку оборотом. типа создать цмо - подразделение 1 (ну или номер части) и ос (мз) с названием части. идея понятна?
(11) comaa, Спасибо за понимание!)))
А вот это
можно как вариант сделать загрузку оборотом
- это понятно тоже была такая идея и даже делали так какое то время, но потом отказались, сейчас не помню по каким причинам.
А вот это
журнал 7 общий заносим в общую базу руками. потому как проверку дополнительную проводят бухгалтера
не очень понятно. Руководство настаивает на том, что бы журнал общей базы отражал все те же операции и расшифровки, что и в филиалах (внутриведомственное перемещение, списание, перемещение и т.п.). А как этого добиться вручную? Хотя руководство на то и руководство чтобы требовать. По мне так это все лишнее-вот например формирую журнал за один из филиалов за 1 месяц и выходит порядка 200 страниц, а таких филиалов больше 20 получаем 4000 страниц и так каждый месяц. Хмм((. Думаю это не очень рационально.
у нас собирается порядка 40 баз в одну
а Вы каким образом это делаете и для каких целей? А "Свод отчетов" в данном случае не сможет облегчить жизнь?
(12) 2PRV, мы собираем для тех же целей, что и вы желаете. есть 40 баз где ведут ОС и МЗ. есть одна головная, где ведут еще и расчеты. надо общий журнал. и еще отчеты сдавать.
в общую головную бухи заносят руками обороты из 40 баз. получаем отдельные журналы (в каждой базе) и сводный (в головной).
ничего не грузим с 40 баз, так как есть ошибки. и сложнее потом ошибки искать. при внесении в головную оборотов допконтроль получается. левые проводки тут же вычисляются. а бухи на местах, такие изобретательные))
в свод отчетов грузятся только 125 и 168
в общую головную бухи заносят руками обороты из 40 баз. получаем отдельные журналы (в каждой базе) и сводный (в головной).
ничего не грузим с 40 баз, так как есть ошибки. и сложнее потом ошибки искать. при внесении в головную оборотов допконтроль получается. левые проводки тут же вычисляются. а бухи на местах, такие изобретательные))
в свод отчетов грузятся только 125 и 168
Я б свернул базы потом с помощью КД написал бы правила для переноса и на всякий случай потом бы прошелся обработкой Поиск и замена дублей что бы привести в норму такие справочники как номенклатура контрагенты и т.д. Ну это дело каждого можно и универсальной обработкой которая идет в поставке с КД перебросить только все равно я бы потом ещё от дублей отделался !!!!
(22) Consultant_1C, Спасибо, но в моем случае сводная база нужна для отражения оборотов за всю организацию и задвоенная номенклатура и контрагенты никак не помешают. К тому же при работе с теми объемами, что у нас в базах сделать поиск и замену дублей нереально (в первой же попавшейся базе в справочнике номенклатура 150тыс объектов, а баз порядка 20).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот