nicktcher Нет ограничений по кол-ву субконтов на счетах в 1С 8!!! .1С 8 - это платформа. В ней понятие "субконто" вообще отсутстует, точно так же как и понятие "счет". Ограничения на то, что отсутствует, разумеется, тоже отсутствуют... :)
Кстати, в Делфи тоже отсутствуют ограничения на число субконто, которых там тоже нет... :)

А вот ежели Вы возьмете типовую конфиграцию 1С:УПП, то в ней ограничение есть, и именно для количества субконто, и именно для "счетов". И это ограничение звучит так: максимум 3 субконто.

Чтобы увеличить количество субконто, необходимо переписать конфигурацию, то есть сделать ее "нетиповой". Наверное, если переписать исходный код ИНФИНа, то можно количество аналитик тоже увеличить до 50. Только ни у кого не возникает в этом потребности. :)

Garyanicktcherпропущено...


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

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

bahrovGaryaне пересчитывая от царя гороха все остатки и обороты в разрезе "атрибута"... :)
а в чем проблема пересчета от начала времен?В быстродействии.
Если для того, чтобы увидеть вступительное сальдо на начало текущего месяца, нужно пересчитать все движения за последние 10 лет, и такой пересчет будет запускаться каждый раз, когда кому-нибудь понадобиться увидеть развернутое сальдо, то это совсем не здорово.

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

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

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

Garyabahrovпропущено...

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

СисойGarya1С 8 - это платформа. В ней понятие "субконто" вообще отсутстует, точно так же как и понятие "счет". Ограничения на то, что отсутствует, разумеется, тоже отсутствуют... :)
Кстати, в Делфи тоже отсутствуют ограничения на число субконто, которых там тоже нет... :)


Грубая ошибка. Классы "регистр бухгалтерии" и "план счетов" являются неотъемлемой частью этой платформы. Сравнение с Delphi неуместно.Значит, звиняйте.

Я работал на уровне платформы с версией 7.5 и 7.7. Там никаких "планов счетов" не было. На уровне платфоры были только регистры, измерения, ресурсы, справочники, журналы документов.

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

GaryaТем более не понятно, на кой 1С использует регистры, если есть все возможности использовать счета.Если увеличение количества субконто приводит к проблемам с быстродействием, значит, что-то недомудрили или перемудрили с реализацией.

ПМСМ, 1С тянет файл-серверное прошлое, требующее обеспечить совместимость с хранением данных в DBF-файлах. Сегодня это уже совершенно неактуально. Продвинутое использование оптимизатора запросов MS SQL и грамотное использование индексов, ПМСМ, могло бы решить все проблемы. В конце концов, можно было бы за отдельные деньги поставлять компненту, задействующую MS Analysis Services для продвинутого хранилища данных с наиболее оптимальной совокупностью производительности и объемом хранимых агрегатов, раз не хватает собственных сил, чтобы агрегаты, хранимые на счетах, не снижали существенно быстродействия.

ex-IBS13Помню ИНФИН-бух, в которой добавили четвертую аналитику на какой-то счет.
Расчет вместо 15 минут стал 2 дня.Если Вы про DOS-версию, то да, там такое могло быть. В Win-версии ни один расчет не занимает даже 2-х минут.

ex-IBS13Зачем всё запихивать в субконто, если часть аналитики используется редко?Перечитайте топик пожалуйста. Выше я уже детально ответил на каждую компоненту Вашего вопроса. И про "редко но метко", и про "зачем" - в отдельности. Если Вы считаете нормальным, что в бухгалтерском балансе используется сальдо, которые невозможно увидеть в оборотно-сальдовой ведомости по счету, то я с Вами согласиться не могу.

ex-IBS13А Инфин... А что Инфин?
А читаем.
http://win.infin.ru/forum/index.php?showtopic=595
http://win.infin.ru/forum/index.php?s=b75c840f963292939eb03d5106a77297&showtopic=2046
Ну и..?
Как будто производительность и фунциональность(колво аналитики) в Инфине могли быть не связаны обратно пропорционально.Во-первых, количество аналитик вообще никаким боком не влияет на формирование журнал-ордера по всем счетам (это что-то вроде шахматки). Потому что в него выводится только корреспонденция всех счетов, которой аналитики по барабану.

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

В-третьих, я сейчас уже дома и провести эксперимент на боевой базе не могу. Но специально ради прикола запущу эту самую шахматку за весь 2010-й год по самой крупной БД, засеку время и сообщу, сколько времени она формировалась. У нас шахматкой мало кто пользуется, потому что отчет размером с аэродром в ширину как бы не очень юзабелен - существуют альтернативные и в 1000 раз более удобные варианты получения той же самой информации. Сотрудники бухгалтерии обычно запускают детализированный оборотно-сальдовый баланс. Он имеет удобную вертикальную компоновку и содержит всю ту же самую информацию, что и шахматка, раскрывая обороты каждого счета и субсчета со всеми остальными счетами и субсчетами. Я тоже запускаю его регулярно. Формируется по итогам года он примерно 2-3 секунды.

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

Давайте представим себе две разные таблицы SQL-сервера, в которых сохраняются проводки по некоторому бухгалтерскому счету с высокой и с малой степенью детализации... В Таблице1, допустим, 2 аналитических разреза. В Таблице2 их 7. Это означает, что в Таблице1 имеются поля НомерПроводки, Ан1, Ан2, Сумма. в Таблице2 полей больше: НомерПроводки, Ан1, Ан2, Ан3, Ан4, Ан5, Ан6, Ан7, Сумма. Начинаем делать проводки по этому самому счету... Приход №1 - запись №1 в Таблицу1. И в Таблицу2 - тоже. Приход №2 - пошла вторая проводка и туда, и туда... После того как мы выполним все проводки по этим таблицам, мы увидим, что количество записей в них одинаковое . Только в Таблице1 информация менее детализирована, и сгруппировать обороты в разрезе аналитик 3-7 не получится, потому что эта информация в систему просто не вводилась. Скорость вычисления итоговой суммы оборотов, допустим, за 1 месяц, как оборотов по счету - одинаковая. Если поля Ан1 и Ан2 в этих таблицах проиндексированы одинаково, то получение оборотов в разрезах Ан1 и/или Ан2 по обеим таблицам будет отрабатывать с одной и той же скоростью - в каждом агрегате должны будут сложиться одинаковое количество элементарных сумм с использованием индекса одной и той же структуры и наполнения. Отсюда ясно, что скорость вычисления оборотов за период по счету или в разрезе Ан1 или в разрезе Ан2 практически не зависит от того, есть ли на этом же счете аналитические разрезы Ан3, Ан4, Ан5, Ан6 и Ан7. На самом деле это не совсем так, потому что при расчете агрегирующих оборотов скорость такого расчета зависит от того, сколько значений поля Сумма умещается в одной странице данных. Но в первом приближении можно считать, что это влияние несущественно. В ИНФИНе агрегаты оборотов не хранятся, они всегда вычисляются "на лету". Поскольку расчет этот линейный, он, по сравнению с расчетом хранимых остатоков, выполняется очень быстро, если используются возможности именно SQL-сервера группировать агрегаты по аналитикам с помощью конструкции group by. И это, ПМСМ, правильно, потому что сама проводка с указанием всех аналитических разрезов уже является хранимым оборотным агрегатом.

Неужели же увеличение числа полей вообще никаким образом не скажется на быстродействии? Не будем кривить душой - скажется. Но не на операциях выборки, а на операциях записи. Если поля Ан3, Ан4, Ан5, Ан6 и Ан7 проиндексированы, то при добавлении каждой записи придется вносить изменения и в каждое из пяти B-деревьев всех пяти индексов. Операция добавления, модификации и удаления записей в данном конкретном случае могут замедлиться в 3-5 раз. Однако, если добавление одной записи в Таблицу1 происходит за 10 миллисекунд и это практически не сказывается на ощущениях юзверя, то и увеличение времени добавления записи о проводке до 40 миллисекунд останется для него за пределами внимания. Если же, предположим, у нас совсем непроизводительное оборудование или есть другие причины, по которым запись в таблицы производится медленно, то даже при добавлении записи в Таблицу1 пользователь ощущает задержку, скажем, в 3 секунды. И увеличение такой задержки до 12 секунд его уже может весьма прилично нервировать. Лично меня начали бы нервировать даже 3 секунды... :) Отсюда следует простой вывод - время добавления проводок в систему может отличаться в разы и даже на порядки, но пока оно находится вне восприятия человеком, все эти "разы" и "порядки" не существенны. Существенны они становятся примерно тогда, когда еще ДО увеличения количества аналитических разрезов время добавления записи в таблицу по каким-то причинам становится ощутимым для пользователя. Я бы уже на этой стадии начал усиленно интересоваться, что это за причины и попытался бы их устранить.

Что еще станет медленнее при увеличении количества аналитических разрезов? Медленнее станет производится расчет хранимых агрегатов, потому что количество таких агрегатов возрастет, причем возрастет объем этого рачета очень существенно. Если мы представим, что каждый аналитический разрез (справочник) содержит 10 записей, то для Таблицы1 придется произвести расчет 10*10=100 агрегатов (остатков в разрезе каждой совокупности записей Ан1 и Ан1). Для Таблицы2 придется произвести расчет 10*10*10*10*10*10*10=10000000 агрегатов, что в 100000 (на 5 порядков!) больше. Вот это единственно существенный аргумент со стороны тех, кто считает, что увеличение числа субконто приводит к снижению производительности. И я с ними в этом согласен... :) Но только в этом... :) Потому что дальше логика начинает выворачиваться наизнанку, и те, кто предпринимают попытки ее вывернуть наизнанку, в попытках обмануть законы природы, математику и реальность, обманывают на самом деле только себя. И я это постараюсь продемонстрировать...

Прежде всего, хочу обратить внимание на то, что количество хранимых агрегатов по остаткам не может превысить количество хранимых агрегатов по оборотам (то есть, проводок). Если за 3 месяца по таблице, в которой даже 100 аналитических разрезов, было сделано 50 проводок, то максимальное количество хранимых агрегатов по остаткам равно 50. Это в самом худшем случае! А в лучшем они могут образовать 1 хранимый агрегат (если у всех проводок было указано одно и то же значение на всех аналитических уровнях, и они свернулись в итоге одну комбинацию). Если в месяц по счету выполняется 100'000 проводок, то в самом худшем случае мы получим количество хранимых агрегатов в остатках, которое необходимо 1 раз в месяц рассчитать, примерно такого же порядка. Для SQL-сервера выполнить такой расчет 1 раз в месяц задача совсем не из разряда архисложных, и он способен с ней справиться за вполне приемлемое время. Нет, конечно, если аналитическая информация просто никому и никогда не нужна, то я и не спорю - зачем хранить то, что никому не нужно?

Но в конечном итоге ведь аналитические уровни могут быть НУЖНЫ для ведения учета. Может потребоваться хранить и информацию о виде деятельности, в которых используются учитываемые ТМЦ (для расчета доли НДС, которая может приниматься в зачет при наличии видов деятельности, как облагаемой, так и не облагаемой НДС), может потребоваться учитывать внтуригрупповые обороты (ВГО) для того, чтобы произвести взаимную компенсацию доходов и расходов нескольких предприятий одной группы (холдинга) при формировании консолидированной отчетности. Причем, по требованиям аудиторов раскрывать информацию о том, какая доля расходов у данного предприятия соответствует какому поставщику, являющегося аффилированным лицом. Может потребоваться вести учет в разрезе партий... И всё это в дополнение к тому, что учет ведется еще и в разрезе мест хранения, и в разрезе номенклатуры. Что делать, если существует ОБЪЕКТИВНАЯ НЕОБХОДИМОСТЬ в том, чтобы количество аналитических разрезов было увеличено?

Ок, думают архитекторы 1С и приближенные к ним круги, а давайте мы воспользуемся Таблицей1 с двумя полями Ан1 и Ан2 и сделаем еще одну дополнительную ТаблицуРегистра, и именно в нее станем записывать данные в требуемых дополнительных пяти разрезах, привязывая ее содержимое к Таблице1. Давайте создадим в ней такую структуру полей: НомерПроводки, Ан3, Ан4, Ан5, Ан6, Ан7, Сумма. И далее пишут программу, которая записывает информацию одновременно в две таблицы Таблицу1 и в ТаблицуРегистра. Смотрим на эту затею внимательно и пытаемся понять, какой в итоге получен выигрыш по сравнению с Таблицей2. Смотрим, приглядываемся... Вы видите какой-нибудь выигрыш? Я пока не вижу... Вижу только, что сосвкупность этих двух таблиц образует ту самую Таблицу2... Сейчас, сейчас... Посмотрю еще внимательнее... Ага, вижу, что НомерПроводки и Сумма записывается дважды... По сравнению с одной Таблицей2 количество индексов стало больше (по полям НомерПроводки теперь два разных индекса для двух разных таблиц), следовательно операция добавления записи в систему теперь станут работать дольше. Что еще? Для того, чтобы увидеть всю информацию в совокупности по счету, пользователи должны использовать разные интерфейсы для "лазания" по Таблице1 и по ТаблицеРегистра... Это действительно удобно, когда для просмотра каждой таблицы делается отдельный интерфейс? В варианте с одной Таблицей2 им достаточно одного интерфейса - такого же как для Таблицы1... Извините, но вижу одни только проигрыши, и ни одного выигрыша... Ах, да вот же он, выигрыш! Мы не расчитываем и не храним агрегат по аналитике Ан7 потому что в его хранении нет смысла! Ура! Нашли! :)

Но пардонте, а что, нельзя было указать для Таблицы2, какие агрегаты делать хранимыми а какие нет? Нельзя было указать разную периодичность агрегатов, скажем, по одним аналитикам квартал, по другим месяц, по третьим сутки? К слову, в ИНФИНЕ такого нет, это просто мысли в слух на тему, каким способом вообще-то нужно было решать задачу, если бы ее нужно было решить не "передней левой ногой через правое заднее ухо". :) ИНФИН, разумеется, не идеален, как неидеален любой программный продукт. Но в нем над структурой данных и над архитектурой как-то потщательнее подумали. Схему хранимых агрегатов сделали весьма жесткой, но при этом весьма близкую к оптимальной. Агрегаты хранятся по всем семи аналитическим разрезам, но 1 раз в месяц. Те агрегаты, которые требуется вычислить внутри месяца в отчете с помощью встроенной функции (например, сальдо на конкретную дату в разрезе конкертной совокупности аналитик) отталкиваются в своем расчете от хранящегося в системе сальдо на начало месяца. Поскольку массив данных за один месяц не такой астрономический, то расчет "на лету" работает очень быстро. Один вызов такой функции отрабатывает за сотые доли секунды. При работе в стандартном экранном интерфейсе используются еще более производительные операции, использующие исключительно SQL-запросы (то есть, результат запроса со всеми необходимыми уровнями группировки возвращает SQL-сервер с конструкциями "group by", а на клиенте он просто подается юзверю через удобный интерфейс.

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

Операция по полному пересчету всех остатков на всех счетах занимает примерно 5 минут (выполняется при закрытии месяца). Это при том, что у нас счетов с количеством аналитик более 5 несколько десятков. При выполнении текущих проводок никаких задержек вообще не наблюдается. Всё работает просто "со свистом". Поскольку такая операция выполняется 1 раз в месяц, то задержка на 5 минут нареканий не вызывает.

Самые массовые и объемные операции - это "автоматические операции". Ими выполняется, например, начисление амортизации, курсовых разниц на всех валютных счетах во всех аналитических разрезах, расчет калькуляции себестоимости на 20-м счете, выполняются проводки по закрытию счетов (тоже во всех аналитических разрезах). Как я уже говорил выше, самая долго выполняемая "автоматическая операция" выполняется 2 минуты.

У нас порядка 80 пользователей, из которых примерно половина постоянно сидит в системе. Компания довольно крупная, не какой-нибудь ларек. Имеет несколько заводов в РФ и СНГ, зарубежные представительства, котируется на лондонской бирже IPO. Так что обороты приличные, объем операций тоже, номенклатура товара и продукции - исчисляется десятками тысяч.

Схема хранения агрегатов ИНФИН, кстати, далеко не самая идеальная. Можно было сделать еще лучше. Как именно - намекнул чуточку выше.

Теперь два слова про 1С... То там, то сям вдруг выяснятся, что на самом нужны агрегаты в разрезе аналитик, информация о которых имеется только в "регистре", но при этом их нужно как-то скомбинировать с данными на счете и увидеть рядом с сальдо по счету. И каждый раз, когда нечто подобное потребовалось, в 1С разрабатывается отдельный отчет, который собирает воедино данные Таблицы1 и ТаблицыРегистра. На его разработку требуются некоторые усилия... Спрашивается, зачем нужно было разъединять, чтобы потом опять соединять в отчетах? Какой глубокий смысл в разделении, от которого нет совершенно никакой пользы, за исключением одного только вреда? Ну, точнее, вреда технологического, не более того. Есть, конечно же, и польза, но она немного в другой сфере... Большое количество разработчиков отчетов, в которых данные Таблицы1 и ТаблицыРегистра объединяются то так, то сяк, то разэтак, постоянно заняты работой, востребованы, и имеют возможность получать приличную зарплату. :)

Есть еще один нюанс, который связан с увеличением быстродействия при сокращении количества аналитических уровней. Он может быть связан с необходимостью разбивать одну проводку на несколько при увеличении количества уровней. Допустим, если мы отказываемся вести учет на счете 41 в разрезе номенклатуры, то приход или расход 100 позиций по одной накладной можно провсети одной итоговой суммой, а не по каждой номенклатурной позиции. Если мы не ведем аналитический учет еще и в разрезе складов, то за весь месяц мы можем сделать вообще всего 2 проводки - на итоговую сумму прихода на счет 41 и на итоговую сумму расхода с этого счета. Однако, нам придется где-то за пределами данной программной системы отдельно считать в excel, на калькуляторе или отдельным средством автоматизации вести учет в тех аналитических разрезах, которые обязаны быть в учете в соответствии с требованием законодательства РФ. То есть, вводить данные придется дважды - один раз для детального ведения учета в одно место, второй раз для менее детального - в другое. И потом каждый раз чесать репу на тему, как проверить, что с чем в итоге должно сходиться из разных мест ведения учета, когда речь идет только об одном виде учета - бухгалтерском.

Есть все-таки один нюанс такого разделения. И он связан с забывчивостью, свойственной всем людям.
Когда аналитический разрез добавляется на счет, то в оборотно-сальдовой ведомости, развернутой по аналитикам, и в аналитической карточке по счету сразо видно входящее сальдо по добавленному аналитическому разрезу. И тут бухгалтера как кувалдой по мозгам стукает мысль "ё-моё! да в этом разрезе же должны быть введены вступительные остатки!". А вот когда он или что-либо подобное добавлется "за облака" ("атрибут", "параметр", "свойство" или что там еще), и сальдо в соответствующем разрезе нигде не видно, то и мысль такая может никому не прийти в голову. Разработчик отчетов что-то там сгруппирует и где-то покажет, может быть. Но то, что он покажет, на самом деле не будет иметь никакого отношения к термину "сальдо", даже если он это слово надпишет над соответствующей колонкой таблицы, потому что никто никуда не ввел вступительных остатков на момент появления нового аналитического разреза. Никто не может посмотреть, какие именно были введены вступительные остатки в каком-то унифицированном интерфейсе, в котором просматриваются вступительные остатки в любых разрезах и по любым счетам. Здесь нужно смотреть вот этот документ, здесь вот этот отчет... Куда нужно смотреть, каким способом - всё это нужно держать в голове, каждая такая ситуация является "исключительной". Ответ на вопрос "каково развернутое сальдо по счету?" является исключительным, и для ответа на него требуется разрабатывать специальный отчет! Это нормально?

GaryaВ-третьих, я сейчас уже дома и провести эксперимент на боевой базе не могу. Но специально ради прикола запущу эту самую шахматку за весь 2010-й год по самой крупной БД, засеку время и сообщу, сколько времени она формировалась.Провел эксперимент. Результат меня поразил. Действительно время ее формирования составляет порядка 10 минут.
Что же, ex-IBS13, поздравляю Вас! :) Я теперь знаю хотя бы один расчет в ИНФИНе, который выполняется дольше 2-х минут. :)

И ведь что удивительно. Никто из сотрудников нашей бухгалтерии, и я в том числе, о том, что существует расчет с таким временем выполнения, просто не знали! Хотя мы работаем с ИНФИНом уже много лет. Если считать с DOS-версий, то с 1993-го года.

Что я могу сказать по этому поводу? Этот расчет ни разу в жизни никогда никому не понадобился. Те, кому он может понадобиться, скорее всего, просто не в курсе, что он им просто не нужен. :) Что существует расчет, предоставляющий всю ту же самую информацию за 3 секунды (засек по секундомеру) под названием "Шахматный оборотно-сальдовый баланс".

Запрашивать журнал-ордер сразу по всем счетам - бессмысленно. Мы используем просмотр журнал-ордера когда нужно отобразить некие корреспонденции между некоторыми (а не всеми!) счетами в тех аналитических разрезах, которые имеются на этих счетах, при необходимости выполняя drill-down проваливание в какие-то итоговые данные, чтобы увидеть более детальную информацию на следующем аналитическом уровне. Просматривать сразу все счета сразу во всех комбинациях их аналитических разрезов - это просто глупая затея. Такой просмотр содержит настолько обширный океан информации, что просматривать его целиком никто никогда не станет. А выборочные просмотры по выборочным (а не всем-всем-всем) счетам отрабатывают моментально.

Сейчас провел эксперимент - открыл журнал-ордер за весь 2010-й год по счету 41 в аналитических разрезах этого счета (стандартный просмотр - предусматривает просмотр аналитик в порядке их следования в настроенных счетах). Табличная форма открылась за 1-1.5 секунды. Содержит обороты по дебету счета 41, сгруппированные по аналитикам верхнего уровня этого счета в корреспонденции со всеми счетами/субсчетами. Выводит эти обороты одновременно в сумме и в количестве (итоговая информация по количеству используется для тех крупп товара, у которых одна и та же единица измерения, например, шт). Количество корреспондирующих счетов/субсчетов - 9. Количество записей на первом аналитическом уровне (группы товара) - 9.

Далее выполняю drill-down проваливание в самую многочисленную по номенклатуре группу товара "Запчасти". Проваливание осуществляется за время меньше секунды. На экране вижу 2453 номенклатуры товара из номенклатурной группы "Запчасти". Количество счетов/субсчетов уменьшилось - их стало 7, потому что 2 субсчета из 9 счетов верхнего уровня конкретно с аналитикой "запчасти" не корреспондировались за весь 2010 год (эта корреспонденция прошла по другим группам товара).

Далее выбираю номенклатуру товара "Втулка защитная Д630-90" и проваливаюсь в нее. Время проваливания вообще не ощущается (равно практически нулю). На экране вижу 2 записи в следующем аналитическом разрезе - по местам хранения. То есть, эта самая втулка приходила на два разных склада. Вижу, что за 2010 год 10 втулок на сумму 23700руб пришло на один склад и 12 втулок на сумму 28009.20 на другой. Вижу корреспонденцию только с одним субсчетом 60.16 - следовательно приход был только по взаиморасчетам с поставщиками и только в рублях.

Выбираю склад №2 и проваливаюсь дальше. Время проваливания равно нулю. Вижу только одну запись в следующем аналитическом разрезе "поставщики" и вижу, что приход был только от одного поставщика. Всё с того же одного счета 60.16. Нажав F5 могу вызвать инструменты управления табличным просмотром, переназвать поля шапки, включить в нее дополнительные подуровни и поля, добавить итоги в нижнюю часть, добавить вычисляемые поля... Мне все эти навороты не нужны, но я могу в данном режиме включить просмотр дополнительного кастом-поля "категория контрагента" и, если бы поставщиков было бы много, отфильтровать только те обороты по этому полю, которые необходимы для определения ВГО.

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

Проваливаюсь еще и попадаю на уровень отдельных проводок. Время проваливания равно нулю. Вижу 2 проводки, обе выполнены в декабре 2010г. Одна - приход по накладной № 10796 от 01.12.2010 10 шт на сумму 23341руб, вторая по накладной № 10802 от 01.12.2010г 2 шт на сумму 4688.20 руб. Добрались до самого нижнего аналитического уровня... :)

...

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

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

Дальше описывать скучно - примерно так же, как описано раньше. Проходим по очереди все аналитические уровни. Скорость проваливания в них равна нулю.

...

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

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

Проваливаюсь на следующий уровень и вижу на нем сразу проводки по этой номенклатуре (все остальные аналитические уровни "свалены в одну кучу"). Вижу 7 проводок. Вижу, что приход этой номенклатуры был со счета 41 (внутреннее перемещение) и со счета 60.16. Вижу, что приходы были в мае, июле и в декабре. Вижу, на какую именно сумму и в каком количестве и по каким именно документам. Время проваливания равно нулю.

...

Можно загрузить журнал-ордер при просмотре в разрезе аналитик сразу по нескольким счетам сразу. Но имеет смысл это делать только по тем счетам, которые имеют схожую настройку аналитичских разрезов. Например, счет 41 и счет 45.

Выделяю несколько субсчетов счета 41 и 45, нажимаю enter... Никаких отличий в скорости загрузки от загрузки только одного счета 41 не заметил. Одним словом

...

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

Открал ОСВ по счету 41 за весь 2010-й год. Открывалась 7 секунд. Вижу вступительные остатки, обороты по дебету, обороты по кредиту и остатки на конец по этому счету в разрезе каждого вида товара. Всего 9 видов товара.

Проваливаюсь в вид товара "запчасти". Время проваливания - ноль. Вижу 2722 номенклатуры. Втсупительные остатки, дебетовый оборот, кредиторвый оборот, исходящий остаток в разрезе каждой из них.

Проваливаюсь дальше в уже знакомую нам втулку. Вижу 2 склада. Время проваливания - ноль.

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

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

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

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

Кстати, комментарии у нас заполнены почти ко всем проводкам. Когда проводка формируется "стандартной" или "автоматической" операцией, поле комментария заполняется автоматически по настроенной для него формуле - туда помещается в текстовом виде вся информация об аналитических разрезах дебетового и кредитового счета, информация о курсе, о том, на какую дату он был использован и т.д. и т.п. Выглядит при этом комментарий вполне осмысленно, например:
Приход товара №123 "Колесо рабочее Н4567" по договору №32 от 18.01.10 от поставщика 777 "ЗАО "Рога и копыта" с оценкой в USD по курсу 25.77 на дату прихода 03.05.10". Когда проводка выполняется вручную, бухгалтеры обычно сами заполняют комментарий примерно в этом же виде. По корректировочным и сторнирующим проводкам - особенно тщательно, детально и аккуратно. Потому что глядя на комментарий, можно, по сути, понять смысл любой самой нестандартной проводки.

Извините за многословие... :)