Доброго дня,
помогите решить задачу, код не нужен)) нужно просто продумать структуру и услышать мнение людей которые занимались чем-то подобным...
Дано: 10 удаленных географически филиалов с переработанной конфигурацией КА (конфигурации между собой идентичны, но не РИБ).
Требуется: создать новую конфигурацию с целью получения консолидированной отчетности по всем 10 филиалам организации с возможностью построения отчетов по продажам как по отдельному филиалу так и "консолидированно". Естественно что вся НСИ во всех базах заносилась в разное время с разными кодами и в зачастую с разными наименованиями, хотя продажи ведутся по сути одного и того-же. Т.е. например, все 10 баз продают карандаши, шариковые ручки и фломастеры. Если в каком-то филиале начинают продавать циркули то справедливо утверждение, что рано или поздно циркули продавать будут все. Значит справочник номенклатуры "де факто" идентичен, "де юро", в базе данных представлен в разных наименованиях и кодах в разных филиалах.
Пока мои мысли: посредством веб сервисов (они необходимы для дальнейшего использования "моей_консолидации" на мобильных приложениях) филиалы по запросу конфигурации "моя_консолидация" предоставляют данные по необходимым справочникам и обороты по продажам (детализация на данный момент не важна, будем для упрощения задачи считать, что нам важно знать лишь сколько карандашей\ручек продали филиалы и по чем).
В конфигурации "моя_консолидация" заведен некий справочник "эталонная_номенклатура" и "номенклатура_организаций". В разрезе эталонной номенклатуры и будут формироваться все наши консолидированные отчеты. Справочник номенклатуры организаций нужен для сопоставления. Само сопоставление номенклатур происходит в неком регистре сведений, где одно измерение это "эталон" и десять реквизитов сообщающих нам какая номенклатура какого филиала соответствует этому эталону.
Далее 2 варианта:
1)При загрузке оборотов по продажам в некий РН "Продажи" загружаются предоставленные обороты но сразу в разрезе эталонной номенклатуры Т.е. перед загрузкой строчки движения по регистру выполняется поиск соответствия эталону и вставляется то, что найдено, если не найдено вставляется предопределенный элемент "не_сопоставленный_эталону_товар".
2) Грузится "как есть" и лишь на этапе формирования отчетов мы "подставляем" эталонные значения номенклатур и группируем значения по нужному эталону.


Вопрос: первое, это выбрать вариант как загружать обороты по продажам (если в целом такая методика имеет право на жизнь); второе: такая методика консолидации имеет право на жизнь? Какие подводные камни могут быть? И самое главное, предложите альтернативу лучше)))
Пока не знаю чем, но мой способ мне самому не очень нравится)

ЗЫ. Сразу исключим из обсуждения: вариант при котором вносятся изменения в справочники номенклатуры филиалов. Т.е. никаких реквизитов "Идентификатор_Для_Консолидации" мы не вносим и вообще справочники на стороне филиалов не меняем. Также просьба не предлагать готовых решений от известной нам фирмы, используем только конфигуратор и мозги)) Ну и естественно зачем это надо если можно почтой прислать ексель лист и склеить - тоже не выход. Задача такая какая есть, и ее надо решить.

Специалисты по консолидации отзовитесь!)

Фига се. Ну вообще-то это неплохой такой проект навскидку.

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

И вариант второй ессно, никаких подстановок в продажи чего-то другого. Все на этапе формирования отчетов.

http://v8.1c.ru/consolid/ не предлагать?

(3) - Спасибо, скажите чем плох вариант с подстановкой во время загрузки? Я понимаю, что на момент загрузки может оказаться что не вся номенклатура этого филиала сопоставлена эталону. Но с другой стороны загрузка выполнятся будет на сервере, и незаметна для пользователя, а отчеты формироваться будут явно быстрее. (Сервер также может проходится и по "старым" записям и изменять номенклатуру в регистре если "наконец-то сопоставили" ))
Просто интересны +\- всех вариантов...
(4) - Спасибо, но не предлагать, в разделе ЗЫ топика пояснял)

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

вопрос, а  что мы можем вообще делать на стороне филиалов. можем например добавлять планы обмена?

А совершенно альтернативные способы есть? Ну т.е. предположим, что я свое видение решения не излагал. Как бы Вы решили задачу?

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

(7), да в части создания новых объектов метаданных мы не ограничены, т.е. web сервисы, планы обмена и т.д. создаваться будут, а значит можем создать и что либо еще. Не меняем только то, что там уже имеем.

(8) Да так бы и решил, коли такая постановка задачи.
Другое дело, что кучу вещей в такой базе не решишь.
Но описанное в (0) вполне.

(9) а подробности решений хотя бы на уровне "на пальцах" можно, но т.е. не подробней чем объяснял свое решение.

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

(0) архитектура решения неудачна, она не позволяет на месте и в цене получать один и тот же отчет, а значит автоматизация =0


вместо эталонной номенклатуры надо использовать реальную номенклатурную группу циркули и оболтусы

и прописывать НГ надо на стороне периферии и НГ передавать из центра, запретив менять их на местах

(12) Да все просто. Формирование отчета на лету по данным первичных экземпляров отчетов, а не по данным консолидированного экземпляра отчета.
То есть, если у нас есть данные по Фирма 1 и по Фирма 2 с признаком элиминированности данных, нахрена мне формировать новый экземпляр отчета по Холдинг, если я могу сложить данные по Фирма 1 и Фирма 2 и вычесть из них элиминированные данные?

(15) Сеньк.

(14) Можно подробней про автоматизацию = 0.
Т.е. есть некий управленец всей этой структуры и сейчас чтобы ему посмотреть некий отчет сводно по 10 филиалам нужно чтобы секретарь запросила электронные версии отчетов во всех региональных структурах, затем "склеила" их в одну таблицу руками перешерстив наименования номенклатур и сгруппировав показатели предоставила ему. Взамен предлагается: запустить в браузере нашу конфигурацию, где прямо на рабочем столе написано:
Актуальность:
Филиал1 - 08.02.15 14:00 (обновить)
Филиал2 - 06.02.15 13:20 (обновить)
...
...
(обновить все)

Сформировать отчет.

Ну может конечно это не автоматизация с большой буквы, но думаю и не 0))

И по поводу НГ - детализация нужна до номенклатуры, и скорее всего до регистратора (как следствие контрагента, договора и т.д.) Поэтому вопрос сопоставления актуален)

(16) если руководитель филиала не может сформировать по своему филиалу тот же отчет, что по нему формирую в центре, то это УГ, а не автоматизация

(0) Если конфигурации везде однотипные, то рисуются в КД единые платы обмена. Если конфигурации разные, то рисуются платы обмена для конкретного филиала (менее удобно).
В планах обмена настроить префиксацию справочников и документов.
Поиск контрагентов по ИНН. Поиск номенклатуры - по каталожному номеру. Если не нашлось - создается новый элемнт справочника с соответствующим префиксом (префикс филиала).

Далее - выгружать данные из всех филиалов в консолидированную базу.

(17) - может я не правильно понимаю.. но почему не может?
Например мы выгружаем движения по РН "ТоварыНаСкладах" (именно например). У руководителя есть одноименный отчет в его локальной базе отражающий соответствующую картинку. У управленца структуры есть такой же отчет по этому же филиалу, вопрос только в актуальности данных может быть... Но честно не понимаю почему мой руководитель подразделения не сможет увидеть то, что по его организации формируется в консолидации если источник для отчета РН движения по которому мы полностью перенесли ...

(18)[ Поиск номенклатуры - по каталожному номеру]
фантаст
у ТС нет артикулов и ТМЦ на местах вводят из Торг-12

(20) Тогда не будет консолидации, она не возможна.

(0) Я бы начал с создания единого информационного пространства, т.е. единая база данных с единой товарной номенклатурой для целей продаж (единым каталогом продаж). Тогда можно легко уйти от сопоставления товарных позиций при продажах. Вообще-то, такая задача сопоставления - стандартная для покупателей, когда надо из нескольких каталогов поставщиков сверстать свой собственный каталог продаж, но никак не для продавцов. Будучи продавцом, в принципе неразумно делать такие сопоставления.

Пришел человек и сразу - сделайте мне все.
А то, что другие на этом уже геморой поимели, причем, за бесплатно.
У тебя опыт, хоть какой-то, имеется?
Для начала, вопросы, типа, " Можно подробней про автоматизацию = 0", потом ТЗ попросит всем сообща тут набросать.

(0)
> Специалисты по консолидации отзовитесь!)
Это ты так тендер объявил?)

(23) - Ты внимательно прочитал топик? Разве я просил сделать мне все или вообще хоть что-то? Я озвучил свою идею реализации задачи и попросил либо осудить ее, либо, возможно, если есть есть опыт, предложить свое видение вопроса. Опыта мне хватает не клянчить код и подходить к задачам так чтобы не переделывать потом, для этого иногда использовать форум, также его достаточно для того чтобы разобраться с типовыми механизмами УТ11))

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

(22) - Да, это была бы идеальная ситуация) но к сожалению для этого сейчас в сбытовых структурах пришлось начать бы с чистого листа, но заниматься вводом начальных остатков в 10 компаниях ради получения консолидации никто не будет, потому вопрос сопоставления никуда не девается. Более того, как уже сообщал я в описании упростил задачу, в перспективе расшифровка данных должна будет проходить до контрагента и договора, а значит часть из них тоже придется "склеивать". К тому же остальные пункты задачи предусматривают работу со статьями затрат и ДДС. Т.е. от склейки никак не уйти, вопрос лишь как грамотно это делать с технической точки зрения.

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

(25)
>Ты внимательно прочитал топик?

А ты мой?

>Разве я просил сделать мне все или вообще хоть что-то?

Кто и что тебе сделал? Тебе дают подсказку, в каком направлении двигаться.

>Я озвучил свою идею реализации задачи и попросил либо осудить ее, либо, возможно, если есть есть опыт, предложить свое видение вопроса.

>Разве я написал что-то иное, кроме своего видения на основе своего опыта?

P.S. Неспровоцированная агрессия до добра не доводит.

(27) вы не верно поняли, я вроде в адрес 23 поста высказался, а вам я только благодарен и мои слова в ваш адрес начинаются с "Да, это была бы идеальная ситуация) но к сожален.."))

(25) После твоего вопроса еще раз перечитал. Даже задом наперед, чтобы поверил. Ничего не поменялось. Та же просьба.
И насчет "Опыта мне хватает не клянчить код" - вот это еще больше убедило в том, что "кодировщик" хочет постановку клянчить. Процентов 80 решения всегда в ТЗ. Правильно тут написали "Фига се. Ну вообще-то это неплохой такой проект навскидку."

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

Зачем по твоему форум? Какой должен быть вопрос чтобы не сказали "читай справку", "читай книжку", "учи матчасть", "отстатыщ" и главное "Пришел человек и сразу - сделайте мне все". Ну мне просто интересно уже такая психология). В моем понимании данный ресурс существует для поиска помощи и совета, а в твоем?

(30) Начни с того, что написано в (18).

(30)[ В моем понимании данный ресурс существует для поиска помощи и совета]
доктора в топик, срочно

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

(28) Извини. Бывает и на старуху проруха. :(

(33) ТС-су даже не нужна такая детализация.Достаточно указать идентификатор НГ центра
(0) сопоставлять  вес мусор из 10 баз кто будет в центре? Нафик не надо