Статья со сравнением подходов к автоматизации консолидации - первичные данные только обороты или остатки и обороты

Коллеги.
Подскажите, встречали ли вы статью с доступным описанием, почему (при возможности выбора) надо всегда выбирать вариант, где в качестве исходных данных только обороты, а не остатки (сальдо) и обороты? 
Желательно, чтобы объяснялось на пальцах для людей, слабо разбирающихся в ИТ (у которых опыт работы в основном с вордом и екселем).
Часа полтора искал - ничего похожего не нашел.

Почему вы думаете, что такая статья должна непременно быть?  
Система может иметь принципиальное ограничение, когда производится только расчет, а не загрузка конечного сальдо, либо иметь оба варианта. 

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

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

Системы, в которых баланс может порвать - лучше, так как больше мотивация к поиску ошибок...
Автомобили ВАЗ - лучше, так как больше мотивация к изучению устройства и способов ремонта автомобиля...

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

Если по теме -  40 лет назад была разработана теория реляционных баз данных. По значимости это примерно то же самое, как изобретение двойной записи для бухучета. И одним из основных положений этой теории является исключение избыточности как метод поддержания целостности (непротиворечивости) данных.

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

Все верно. Только в отличие от средне-абстрактной базы данных, данные для консолидации как правило 1) преобразуются из другой базы (учетной); 2) уже имеют встроенную "функцию коррекции данных за счет избыточности", т.е. двойную запись. К данным во второй базе (консолидации) предъявляется требование корректно отражать первую базу (учет), что технически выражается в наборе контрольных проверок, балансировка как простейшая из них

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

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

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

s_ustinov
Коллеги.
Подскажите, встречали ли вы статью с доступным описанием, почему (при возможности выбора) надо всегда выбирать вариант, где в качестве исходных данных только обороты, а не остатки (сальдо) и обороты? 
Желательно, чтобы объяснялось на пальцах для людей, слабо разбирающихся в ИТ (у которых опыт работы в основном с вордом и екселем).
Часа полтора искал - ничего похожего не нашел.

Если речь о трансформации отчетности, то здесь такое объяснение. Трансформация, когда она  делается в последующих годах, отталкивается от цифр МСФО на конец предыдущего года. Т.е.:
Остаток по МСФО на конец периода = Остаток по МСФО на начало периода + Оборот по РСБУ за период +/- Корректировка оборота

Как видно, из РСБУ мы берем только обороты, не трогая остатки. Это чисто технический момент, необходим чтобы трансформировать из года в год.

Григорий Чуланов
Все верно. Только в отличие от средне-абстрактной базы данных, данные для консолидации как правило 1) преобразуются из другой базы (учетной); 2) уже имеют встроенную "функцию коррекции данных за счет избыточности", т.е. двойную запись. К данным во второй базе (консолидации) предъявляется требование корректно отражать первую базу (учет), что технически выражается в наборе контрольных проверок, балансировка как простейшая из них

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

Григорий, скажите, как вы оцениваете свои знания в области ИТ - базы данных, ерп системы, механизмы интеграции и тп?
Вы разбираетесь, как устроены "внутри" механизмы учета? Это я к вопросу о вырезании

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

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

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

Я не эксперт в ИТ. Хотя пришлось познакомиться гораздо больше, чем хотелось будучи заказчиком при внедрении системы консолидации.

Что касается второго вашего комментария. Давайте вернемся в реальный мир. В ТЗ всегда есть ошибки, и всегда оно доделывается в процессе внедрения. И всегда после внедрения появляются новые операции, которые не были учтены.

Григорий Чуланов
Вырезание "лишней" информации (сальдо)

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

Так что термин "вырезание" не совсем правильно применять по отношению к остаткам. Изначально их нет, и они специально создаются при выгрузках.

Эскапист
Что касается второго вашего комментария. Давайте вернемся в реальный мир. В ТЗ всегда есть ошибки, и всегда оно доделывается в процессе внедрения. И всегда после внедрения появляются новые операции, которые не были учтены.

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

Но есть еще один момент, который часто не учитывают - если создавать систему консолидации только на основе оборотов, объем ТЗ на механизмы интеграции можно сократить в 10 раз.
и тут начинает работать статистика - ошибок в документе на 50 страниц обычно намного больше, чем ошибок в документе на 5 страниц.

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

Не совсем понятно как удастся сократить ТЗ в 10 раз отказавшись от мэппинга сальдо?

я бы руки поотрывала "вырезателям" сальдо в САПе, например

т.е. когда можно загрузить ЛИБО сальдо на дату, ЛИБО обороты

а потом сидишь и тупо "скрещиваешь" эти два отчета в экселе, чтобы наконеч получить нормальную оборотно-сальдовую ведомость
 Данные на начало, дебетовый оборот, кредитовый оборот, Данные на конец периода

Григорий Чуланов
На точность терминах не претендовал  спасибо за поправку. Но основной поинт был, что пользователь ожидает, что сальдо будет таким же как в учете и баланс пойдет. Как технически считается сальдо ему не интересно

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

Григорий Чуланов
Не совсем понятно как удастся сократить ТЗ в 10 раз отказавшись от мэппинга сальдо?

 ну в самом примитивном случае структура данных может быть такой:
период, счет, сумма по дебиту, сумма по кредиту, необходимые аналитики

ограничение целостности - суммы по дебиту счетов должны равняться суммам по кредиту

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

для сравнения можно посмотреть на пакет, в котором есть баланс (остатки), P/L (обороты) и много-много листиков с информацией для раскрытий - я думаю у вас такой есть
сколько там контролов и насколько сложным будет ТЗ на выгрузку данных из учетной системы в такое "чудо" и загрузку в систему консолидации?

Сельхозозабоченная
а потом сидишь и тупо "скрещиваешь" эти два отчета в экселе, чтобы наконеч получить нормальную оборотно-сальдовую ведомость
 Данные на начало, дебетовый оборот, кредитовый оборот, Данные на конец периода

а самой написать нужный отчет - религия не позволяет?

Кто сказал что в оборотах нужен только дебет и кредит. Мы же тут не excel обсуждаем, а полноценную систему консолидации с хранилищем данных и автоматизированным ETL инструментом. Требуется аналитика по видам движения, которые берутся из корреспонденций счетов в лучшем случае, но чаще из аналитик первичных документов. Ошибка в аналитиках будут неизбежно: в мэппинге при внедрении и в будущем при сбое в процессе change management, а в учете вообще всегда. 
Вероятно, если такая аналитичность движения не нужна, то можно без проблем сделать сальдо расчетным, с простым контролем дебитов и кредитов как вы предлагаете. Но тогда гораздо дешевле обойтись excel и зачем автоматизация непонятно.

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

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

Григорий Чуланов
Кто сказал что в оборотах нужен только дебет и кредит.

Действительно, кто это сказал?

Сергей
ну в самом примитивном случае структура данных может быть такой:
период, счет, сумма по дебиту, сумма по кредиту, необходимые аналитики

Григорий Чуланов
Мы же тут не excel обсуждаем, а полноценную систему консолидации с хранилищем данных и автоматизированным ETL инструментом.

вообще-то я в предыдущем посте объяснял, каким образом отказ от сиспользования остатков в качестве исходных данных для консолидации, позволяет в 10 раз сократить ТЗ на интерфейс между учетной системой и консолидационной системой.
обычно в качестве интерфейса выступает файл с пакетом данных, и в качестве ТЗ в таких случаях выступает подробное описание структуры данных в файле.

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

А можно конкретную цитату, где я такое предлагаю?

Григорий Чуланов
Если аналитика нужна, то придется взвешивать, что лучше. Я бы сказал что иметь правильный баланс и плаговое необъясненное движение по отдельному счету имеет больше преимуществ, чем неправильный баланс и отсутствие плаговых движений. Во-втором случае, сказать быстро где искать ошибку, почему баланс не идет, несопоставимо сложнее.

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

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

Григорий Чуланов
Такое ощущение, что вы по профессии системный интегратор  Знакомые нотки - главное внедрить и отчитаться об успехе,  а как потом пользователю с этим работать не важно.

не угадали.
внедрение и поддержка финансовых модулей ерп систем
и давайте не переходить на личности - я ведь не начинаю намекать про четверку и белые циферки в скрытой ячейке, учитывая, что вы везде плаговать предлагаете
Исправлений: 1; последнее - в 06.06.2013, 01:21.

Если рассуждать абстрактно, то для консолидации нужны остатки по балансовым статьям, обороты по PLным + доп данные собственно для правильной консолидации, примечаний и остальных форм отчетности.

Подход, что в систему консолидации вводятся/грузятся только такие данные я встречал у всех без исключения иностранных компаний, с которыми я работал. Все мэппинги, корректировки и проч. проч. - делается на стороне учетных систем отдельных компаний.

вообще-то я в предыдущем посте объяснял, каким образом отказ от сиспользования остатков в качестве исходных данных для консолидации, позволяет в 10 раз сократить ТЗ на интерфейс между учетной системой и консолидационной системой.
обычно в качестве интерфейса выступает файл с пакетом данных, и в качестве ТЗ в таких случаях выступает подробное описание структуры данных в файле.

При интерфейсе через пакетник в нем всегда есть сальдо. Как вы думаете почему? Надо перестать думать как айтишник, и стать на место бухгалтера.

Цитата
Григорий Чуланов
если такая аналитичность движения не нужна, то можно без проблем сделать сальдо расчетным, с простым контролем дебитов и кредитов как вы предлагаете.
А можно конкретную цитату, где я такое предлагаю?

Пожалуйста

период, счет, сумма по дебиту, сумма по кредиту, необходимые аналитики

ограничение целостности - суммы по дебиту счетов должны равняться суммам по кредиту

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

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

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

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

Цитата
Григорий Чуланов
Такое ощущение, что вы по профессии системный интегратор  Знакомые нотки - главное внедрить и отчитаться об успехе,  а как потом пользователю с этим работать не важно.
не угадали.
внедрение и поддержка финансовых модулей ерп систем

А консолидацию не внедряли?  Везет вам.

Григорий, я кажется догадался, о каком алгоритме выгрузки вы говорите
Сперва выгружаем "платежи за сырье", потом "выплату зарплаты" и тд
а если при проектировании выгрузки никто не вспомнил про "платежи за телефон / интернет" - их не будет в выгрузке и баланс порвется
вы это описываете?

я же говорю о другом алгоритме, в котором таких проблем нет. 

и с аналитиками, наверно,  то же самое...
вы описываете стандартный отчет по проводкам за период, правильно?

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

PS а консолидацию я не внедрял, вы правы. просто система после внедрения строила консолидированную отчетность - это была одна из функций 

Это не _отчет_ по проводкам. А обработка всей базы данных документов из учетной системы за период с целью сделать из них пакет данных для консолидации. Ну вообщем да аналогия примерно такая. Данные извлекаются с разными аналитиками для разных счетов и вдобавок не только из финансового модуля, еще и из модулей учета ОС и материалов. Наверно, не показательный пример для массового решения. 

Так это вы топик-стартер?  Статью интересно было бы почитать. Только не пишите, что в пакетниках для загрузки в конс систему не нужно показывать конечное сальдо. Бухгалтеры вас не поймут

Дописал черновик и пример. Надеюсь, что за выходные допишу базу и селекты под этот пример.

Подскажите, может есть еще типичные проблемы с консолидацией, которые я пропустил в тестовом примере? Про перепродажу ОС внутри группы я помню, но это слишком сложно для тестового примера (фактически, надо делать параллельный учет ОС) - будет не очень наглядно.

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

Кстати, а что будем делать через 5 лет? "Отрезать" пятый год и хранить от него только входящие остатки?

Статья для человека, который решает, как в группе будет консолидация работать.

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

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

стоимость диска на 3 терабайта (корпоративного класса) - долларов 200-300, если даже делать первый рейд - это 2 диска
то есть стоимость хранения всех данных за год - сейчас максимум 600 долларов (сейчас)
за прошлые 5 лет стоимость гигабайта упала в несколько раз
так что вариантов, что делать через пять лет - масса
можно отрезать все что старше 5 лет, можно вообще все хранить - по сравнению со стоимостью нескольких дней работы консультанта или аудитора - сумма несущественная

Т.е. статья для человека, разбирающегося в МСФО и трансформации и принимающего решения по внедрению, но не понимающего в IT? Тогда не пойдет: примеры для него будут слишком примитивными и не раскрывающими ситуацию, почему обороты лучше остатков.

Если хотите его убедить - нужно привести жизненный пример, при котором выгрузка остатков приведет к ошибкам, а выгрузка оборотов позволит ее избежать

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

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

самая близкая аналогия, которую могу придумать:
есть три бухгалтера:

Первый - каждую хозяйственную операцию классифицирует и заносит в учетные регистры с использованием двойной записи. потом строит отчетность на основе данных учетных регистров

Второй - каждую хозяйственную операцию классифицирует и заносит в учетные регистры БЕЗ использования двойной записи. потом строит отчетность на основе данных учетных регистров

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


Для любого варианта исходных данных можно построить ПРАВИЛЬНУЮ отчетность ЛЮБЫМ из этих методов.

Вопрос на засыпку - какой способ действий является правильным?

Несколько вопросов по беглому просмотру:
1) Вы планируете обрабатывать на лету миллиарды проводок? По каждой компании группы за все годы? Заказчик потребует гарантии производительности. Проблема отнюдь не в паре тысяч долларов на дополнительный жесткий диск. Технически я так понимаю одной таблицой не обойдешься, понадобится множество промежуточных таблиц куда будут складываться обработанные данные в том числе и пресловутое сальдо, иначе об оперативной выгрузке отчетов можно забыть. А изменение мэппинга, например, потребует пересчета всех таблиц и прооводок и может занять несколько дней, если не недель

2. Пересчет операций по курсу на дату проводки для перевода в валюту группы вовсе не "лучше соответствует мсфо". Это снизит,  а не повысит аудируемость и качество данных. Заказчику это не нужно, нет смысла предлагать как достоинство. Кстати, вы сами себе противоречите: вначале все равно придется посчитать сальдо в валюте учета и затем перевести в валюту группы по текущему курсу. Таким образом, ваш алгоритм с пересчетом всех проводок сложнее, чем взять готовое сальдо и умножить на текущий курс. Также следует предусмотреть, чтобы внутригрупповые инвестиции не перекурсовывались.

3. Не совсем понятно, зачем приводить примеры стандартных консолидационных алгоритмов. Они есть в любой системе и не зависят от выбора детализации исходных данных подлежащих загрузке в консолидацию - наличие или отсутствие сальдо. Стоит сосредоточиться именно на ETL инструменте и более подробно обосновать тезис про нецелесообразность загрузки сальдо. 

4. Подготовка конс. отчетности посредине месяца - бессмысленно из-за особенностей отражения операций. Услуги, работы, зарплата, начисления, налоги и тд -заводятся обычно последним числом месяца. По той же причине не следует заводить новую компанию в консолидацию путем обрезания проводок до фактической даты перехода контроля. Нужно использовать баланс на предыдущий или следующий месяц.

5. Система внутригрупповой сверке уж очень суровая  Стоить подробнее продумать механизм двусторонней сверки и урегулирования расхождений.

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

Григорий Чуланов
Несколько вопросов по беглому просмотру:
1) Вы планируете обрабатывать на лету миллиарды проводок? По каждой компании группы за все годы? Заказчик потребует гарантии производительности. Проблема отнюдь не в паре тысяч долларов на дополнительный жесткий диск. Технически я так понимаю одной таблицой не обойдешься, понадобится множество промежуточных таблиц куда будут складываться обработанные данные в том числе и пресловутое сальдо, иначе об оперативной выгрузке отчетов можно забыть. А изменение мэппинга, например, потребует пересчета всех таблиц и прооводок и может занять несколько дней, если не недель

Это уже чисто технические аспекты.
Речь не идет об обработке в реальном времени (OLTP, OLAP). Время формирования может достигать десятков минут и часов (с учетом обработки пакетов), и ничего особо плохого нет.
Вообще о подобных вещах (миллиарды записей) можно легко почитать, набрав в поисковике Data Warehouse. И миллиарды записей - это системы начального уровня.
По количеству одновременно обрабатываемых данных - десятки (редко сотни) тысяч записей. После первоначальной загрузки в алгоритмах используются агрегированные данные (обороты за период по комбинации измерений).
Таблиц может быть несколько (2-3), но прекрасно будет работать одна таблица и два индекса по таблице. Добавляем измерение "период" и один индекс - обороты за период для каждой комбинации измерений, второй индекс - обороты за период и все предыдущие периоды по каждой комбинации измерений. в таком варианте количество обрабатываемых данных вообще будет константой и не зависеть, за сколько лет накоплено информации в базе. базы данных работают по другим принципам, чем ексель.
все эти технологии достаточно хорошо отработаны, используются далеко не первый год, и давно преодолели "детские болезни". если интересна эта тема, вам лучше пообщаться со специалистами в области баз данных, я не настолько хорошо в этом разбираюсь.

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

Григорий Чуланов
2. Пересчет операций по курсу на дату проводки для перевода в валюту группы вовсе не "лучше соответствует мсфо". Это снизит,  а не повысит аудируемость и качество данных. Заказчику это не нужно, нет смысла предлагать как достоинство. Кстати, вы сами себе противоречите: вначале все равно придется посчитать сальдо в валюте учета и затем перевести в валюту группы по текущему курсу. Таким образом, ваш алгоритм с пересчетом всех проводок сложнее, чем взять готовое сальдо и умножить на текущий курс. Также следует предусмотреть, чтобы внутригрупповые инвестиции не перекурсовывались.

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

Григорий Чуланов
3. Не совсем понятно, зачем приводить примеры стандартных консолидационных алгоритмов. Они есть в любой системе и не зависят от выбора детализации исходных данных подлежащих загрузке в консолидацию - наличие или отсутствие сальдо. Стоит сосредоточиться именно на ETL инструменте и более подробно обосновать тезис про нецелесообразность загрузки сальдо. 

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

Григорий Чуланов
4. Подготовка конс. отчетности посредине месяца - бессмысленно из-за особенностей отражения операций. Услуги, работы, зарплата, начисления, налоги и тд -заводятся обычно последним числом месяца. По той же причине не следует заводить новую компанию в консолидацию путем обрезания проводок до фактической даты перехода контроля. Нужно использовать баланс на предыдущий или следующий месяц.

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

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

Григорий Чуланов
5. Система внутригрупповой сверке уж очень суровая  Стоить подробнее продумать механизм двусторонней сверки и урегулирования расхождений.

??????
это вы о чем?

Григорий Чуланов
PS. Очень правильно про выбор детализации по степени автоматизации выгрузки. Печально наблюдать проекты с моделью данных в несколько десятков измерений и несколькими тысячими счетов, которые не включают автоматизацию интерфейса.

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