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

Ага. В реквизиты регистра пиши корсчет.

РАУЗ так и делает....

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

технически - можно.
Тока не понятно что делать с субконто, если их произвольное количество.
Чтобы считались итоги - оно должно быть изхмерением.
Можно взять аналог РАУЗ, ключи аналитики юзать

(3) Можно, только не уверен, что это будет лучше регистра бухгалтерии.
(0) Регистры накопления со 100500 измерений - тоже не лучший вариант с точки зрения производительности.

(0) Ответ на твой вопрос - можно.
Со временем придешь к тому, что стоит использовать оба вида регистров (РН и РБ).

(0) > Можно ли обойтись плана счетов и регистра бухгалтерии и при этом не потерять все преимущества регистра бухгалтерии?
обойтись - можно
Не потерять - невозможно.

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

> регистр бухгалтерии ограничен по количеству аналитики (давайте только не будем спорить, просто примем как аксиому), а регистр накопления нет.
Бред. Как аксиому принять вообще не готов. До 4-5 субконто на счете РБ вполне работоспособен. В Бухне для бюджета, по-моему 4 субконто + несколько измерений.

> а регистр накопления нет
Ага. Пока ты не попытаешься решать на нём бухгалтерские задачи с их безумным количеством видов субконто (типов аналитических разрезов).
После увеличения количества измерений больше 8 производительность начнет резко падать.

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

(7) такой?
http://prikol.pikmik.ru/i/prikol.pikmik.ru/imgs/023fb125b35f7c6bc7c2e52265c74c8b.jpg

можно и на плоской таблице все сделать.
Ведь в скуле именно они

(9) Регистр как бы и есть несколько плоских таблиц.

Или даже одна.

(1)(2) ну ок. А как потом эти реквизиты (коррсчета) использовать?
(3) Кстати интересно, а что если сделать регистр бухгалтерии у которого нет субконто и вся аналитика в измерениях? Ктонить видел такое чудо?

(12) а)так же как рауз :)
б) да вы извращенец, батенька

+в любом случае будет интересно послушать человека который сделает это))

Можно.

(4) Я сейчас подсчитал у себя количество аналитик вообще по всему управленческому плану счетов, что-то около 10 получает. Ок, 15 измерений на сколько критично?

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

З.Ы. Рано тебе свою подсистему бюджетирования делать, ох рано.

Нашёл в erp регистр с 12 измерениями СведенияОДоходахСтраховыеВзносы и данных там я думаю будет до дури.

(17) Чем раньше тем больше руки чешутся.

(17) Увольняться чтоли?

(0) простейшая задача: Учет денег в банке.
Вести учет денежных средств в разрезе расчетных (банковских) счетов. Необходимо знать приход, расход и остатки денег. (Типичный показатель остатка - скорее всего реализуется при помощи регистра остатков).
Однако необходимо вести учет движения денег в разрезе статей движения денежных средств (ДДС). Закрытия в ноль по статьям ДДС не предполагается (типичный показатель оборотов - реализуется скорее всего при помощи регистра оборотов).

Бухгалтер (падла такая) захочет видеть данные по деньгам в одном отчете (и расчетные счета и статьи ДДС вместе).

Вариант решения - пихнуть статьи ДДС в реквизит регистра остатков (чтобы не лепить отдельный регистр оборотов). Но тут теряется вся хвалёная производительность регистра накопления, т.к. использовать виртуальные таблицы станет нельзя (в них нет реквизитов регистра - только измерения).
Либо оставить два отдельных регистра.

А потом бухгалтер попросит аналог стандартного отчета "Анализ счета" или "Анализ субконто", которые должны показать обороты между счетами и/или между субконто.

Реализуешь - молодец. Только учти, что это простейшая задача, где я пренебрег такими мелочами, как валютный учёт, количественный учет, возможность настраивать вариантами видов учета по каждому субконто (Только обороты/Суммовой/Количественный/Валютный), вариантами видов учета на счете (Количественный/Валютный) и прочими "мелочами".

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

(21) Хреновый вариант решения. Кстати не задумывались почему эти даные в разных регистрах?

(0) План счетов и несколько регистров накопления, все что тебе нужно.
Один счет - один регистр накопления.
Главное.
1. Продумать план счетов, т.к. добавление субконто или счета равносильно изменению конфигурации.
2. Корректно продумать структуру регистров накопления (она должна быть одинаковой, за исключением набора измерений).
3. Написать свои наборы функций для контроля движений по балансовым счетам. Работать только через них.
4. Сделать свой документ - "корректировка записей регистров".

ИМХО. Сделать можно. Даже работать будет быстрее чем на регистрах БУ. Только писанины много.

(23) Варинат в (21) чисто гипотетический. Может у автора ветки родится свой гениальный вариант.

> почему эти даные в разных регистрах?
Какие именно данные? почему нельзя в регистре остатков хранить показатели оборота?
Не понял вопроса.

(24) > Один счет - один регистр накопления.

Круто. А корреспонденцию по оборотам между счетами и субконто как получать?

(24) У меня в упр. плане счетов 50 счетов. Даже если оптимизирую, например все взаиморасчетные счета в один регистр, то все равно много регистров.

(25) Почему обороты по статям хранятся отдельно от остатков.

Короче. Убеждать никого не хочу.
Автор. Хочешь попробавть - начинай делать.
Но лично я убежден на 146%, что еще в процессе реализации, придёт понимание, что получить функциональность медленного и тупого РБ при помощт быстрых и крутых РН просто невозможно.
Утверждение в (24) "работать будет быстрее чем на регистрах БУ" - весьма сомнительно. С ним можно было бы согласиться, если полностью отказаться от большей части функциональности регистра бухгалтерии.

(0) Можно, но не нужно. Надо будет потратить кучу времени на то, чтобы баланс был балансом. В результате придешь к чему-то похожему на 1С-овский бух. регистр. И смысл?

(28) А как ты закроешь в ноль ресурс регистра, если по одному измерению (банковские счета) у тебя предполагается закрытие в ноль, а по другому (статьи ДДС) - нет?

(26) Запросами. (29) На 8.0 участвовал в проекте, как раз перевода с регистра бухгалтерии на регистры накопления. Скорость получения отчетов увеличивалась примерно раз в 10-20.
(27) 50 регистров - не много. Вон в УПП сколько их.

ИМХО, хотела бы 1С - сделала бы регистр БУ со скоростью регистров накопления.
И тогда можно было бы весь учет построить на плане счетов

(33) Столько "бы", а вроде не грибной сезон.

(32) > Запросами

Можно простейший пример отчета Анализ счета 50 по субконто с детализацией по корсчетам и корсубконто?

То что это можно сделать запросом, я ниразу не сомневаюсь. Только работать это быстрее, чем на регистре бухглтерии не будет. А про в 10-20 раз - это чисто воды ваш вымысел. Простейшая ОСВ по счету (по одному регистру накопления) может и будет работать быстрее, но всё остальное...

Простейший свод проводок получить по 50-ти регистрам накопления - это будет феерически "скоростной" отчет.

(35)Я правильно понимаю мысль что запрос одной большой таблице будет быстрее чем к нескольким но мелким?
//
Я бы еще учитывал и частоту пользования разными отчетами -
"Анализ счета 50 по субконто с детализацией по корсчетам и корсубконто" - я вот не видел бухов которые этим бы пользовались

Думаю, что все что здесь обсуждается, это путь который в свое время прошли разработчики РБ: это и есть набор взаимосвязанных таблиц с алгоритмами зашитые на уровень платформы. Действительно, нет смысла изобретать велосипед.
А пример системы бюджетирования со многими измерениями можно посмотреть в БИТ.ФИНАНС: там для подсистемы бюджетирования используется свой РБ (для учета остатков до 4-х субконто) плюс РН там где необходимо вести обороты больше чем 4.

(36) Я не видел бухов, которые бы пользовались шахматкой, и чего? :)
Запрошенный отчёт, на самом деле, вполне нормальный. Буквально "откуда пришли, и куда ушли наличные деньги".

(38)Я к тому лучше что бы ОСВ строились быстро, а шахматки медленно. Чем все одинаково медленно

(39) Только ОСВ по счёту будет строиться быстро. Всё остальное - очень вряд ли.

Анализ субконто будет адово тормозным, например.

(36) > запрос одной большой таблице будет быстрее чем к нескольким но мелким?

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

(36) > я вот не видел бухов которые этим бы пользовались

Не поверю. Отчеты "Анализ счета" и "Анализ субконто" - едва ли не самые часто используемые бухгалтерами отчеты.
Карточка счета - постоянно используемый в качестве расшифровке к полям ОСВ.

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

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

Скорость работы отчетов, на регистрах накопления была в 10-20 раз выше. Платформа 8.0. Возможно, сейчас что-то поменялось, но тогда это было так.

Текст конечного запроса выходил примерно, на 10-30 тысяч строк.

(12) Инталев:КМ так и построен

(41)Но почему? какая разница данные будут из нескольких маленьких или из одной большой таблицы собираться?
Какие-нибудь контрагенты наверное не более чем в 5 таблицах окажутся
(42)Вот мне кажется как раз в к 5-ти таблицам и будут такие запросы
(43)Анализ субконто - да, а вот Анализ субконто с корреспонденцией по корсубконто бухи не осиливают
Карточка счета - из журнала проводок тащится будет
//
Вот я работая как бухгалтер больше 10 лет, отчетом по субконто пользовался очень редко, впрочем как и анализом счета с по коррсубконто - тоже редко.
Для ОСВ по всем счетам - можно и отдельную табличку завести + данные по оборотам между счетами

Я думаю самые крупные субконто по количеству - это Контрагенты (договоры) и Номенклатура.
Так задач где нужно было бы выбирать данные по корреспонденции субконто не так и много

(46) Контрагенты окажутся не более, чем в 5 таблицах? Да ладно? Или ты имеешь в виду, что какой-то конкретный контрагент вряд ли окажется во всех таблицах сразу?

(48)03,45,58,59,60,62,63,66,67,75,76 + забалансовые
Причем все данные будут по 60,62 счету, по остальным счетам или данных вообще не будет или будут минимальными

(49) Зависит от вида деятельности, какбе. У Лизинговой компании, напримр, по 03 тоже будет ого-го.

И да, это не пяток счетов, а десяток :)

(50)зато у нее чего-нибудь другого не будет
(51)из десятка 4/5 пустые будут или с минимальными данным.
Все лучше чем общие таблицы перебирать

(52) Не знаю, честно. Я не думаю, что регистр бухгалтерии можно эмулировать на регистрах накопления абсолютно без потери функциональности, но при этом с увеличенной скоростью. Иначе бы это уже, очевидно, сделали.
И (0) нужна куча аналитики на каждом счёте, представь себе отчёт по измерениям 10 регистров, при этом измерение в каком-то регистре является 6-м, а в каком-то 8-м. Это тебе не контрагенты...

Мое имхо - задача решается на 2х регистрах - остатки и обороты

по 6 измерений в каждом
счет, кор.счет,
Субкото1...3, КорСубконто1...3

или по 4 измерения - тогда по две записи делать, и идентификатор проводки в реквизиты

т.е. в такую структуру данных можно записать необходимые данные.

Или еще какую структуру можно придумать (можно подглядеть бух регистры в платформе :) ).

НО - это же надо потом анализировать

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

т.о. - кому надо чего ускорить - RTFM, либо ищите специалиста

(53) > регистр бухгалтерии можно эмулировать на регистрах накопления абсолютно без потери функциональности, но при этом с увеличенной скоростью

+100500 Бинго!

Конечно можно всё сделать. В этом никто не сомневается.
Только есть одно маленькое НО!
Либо мы потеряем где-то в функциональности (пусть даже в редко используемой, но потеряем)
Либо это будет работать где-то быстрее, но и одновременно где-то медленнее.

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