Часто приходилось слышать, что фирма 1С категорически не рекомендует использовать в плане счетов более трех субконто. Возможно кто-то подскажет, где можно почитать об этом поподробнее?

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

(1) А помимо этого? Где-то встречал объяснение, что это как-то связано с особенностями работы SQL, и может крайне негативно сказаться на производительности.

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

(2) главное чтобы индекс не превысил предел по длине

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

(0) издалека зашел? колись куда решил присобачить 5 субконто?

(0) там кажись, если субконто больше 4-х не индексируется.
а вообще в (6) хороший вопрос :)

(3) Да тут дело в том, что кое-кто из руководства, решил сделать на одном из заб.счетов(материалы) учет не только по номенклатуре, складам, контрагентам, но и по объектам, куда эти материалы покупаются. Учитываю некоторые(непрограммные) ньюансы - подобное решение повлечет за собой огромнейший геморрой. И теперь надобно как-то "по-научному" объяснить, почему этого реализовать нельзя технически.(про регистры накопления человеку неизвестно))))

(8)
>надобно как-то "по-научному" объяснить ->
>про регистры накопления человеку неизвестно

Ну так расскажи, вот и будет научное объяснение...

>почему этого реализовать нельзя технически

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

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

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

+(9) +Можешь дать почитать "кое-кому" из руководства главу из "библии", посвященную производительности регистра бухгалтерии.

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

(12) [все основные счета то останутся на своих таблицах.] вобще-то у них как бы одна таблица

(15) Имеется ввиду оборот по аналитике а не таблица счетов.

(11)Дело в том, что учитывая некоторые особенности производственного процесса(первичка от заказчика, в том числе), подобное "нововведение" сильно снизить производительность труда... Но это его не волнует. Поэтому приходится изворачиваться и выдумывать другие причины...

(16) неужели не в регистре бухии?

(18) с. 304 Проф разработки. рекомендую к прочтению.

(17) Каким образом снизит? Другое дело, что может руководство привыкло юзать план счетов + оборотки... Мне тут в одной организации экономист предложил выкинуть из УПП все регистры и оставить только план счетов ))

+(18) И вообще какбэ.. РБ не в одной таблице хранится. Если это новость, рекоменую к прочтению весь раздел.

Да ничего не снизится. Тупить из-за индексов будет только таблица с оборотами по счетам с 4 субконто, для автора это забалансовый счет, не думаю что он мегаактивный в плане работы с ним. Хотя ХЗ, зависит от задачи.

(19) сам то внимательно прочитал?

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

(23) Давай, покажи где я ошибся.

Как я отмазываюсь: бух-ия для сдачи отчетности, а не для детального анализа. Излишняя аналитика приведет к росту кол-ва бухов, каше в их голове и прочие усложения. В конечном итоге все будет еле шевелиться. Про производительность молчу, т.к. самодурам плевать на это и проблемы только разработчика. Ну не надо знать оборотке про склады, ед.измерения и прочей каши, что бы не захлебнуться. В качестве примера привожу отчеты для укрупненного анализа, бухгалтерского анализа и серию отчетов торгашей, продавцов и производственников. Потом делаем замеры, где быстрее инфа анализируется. Конечно, ОСВ с перенсыщенной аналитикой специально раздуваю и раскрашиваю так, что бы там нельзя было разобраться, за то результат если и не 100%, то заставляет серьезно задуматься

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

(27) "таблица появляется для всех счетов, а вот запись в нее будет только по тем счетам в которых 4 субконто" - взаимоисключающие параграфы.
Если писаться туда будут только определенные счета, что значит "таблица появляется для всех счетов" ?

+(27) и сколько по времени будет выполняться запрос укажи в фильтрах субконто Склады к примеру? медленнее, так как таблиц уже 4

(28) по-твоему выходит что для каждого счета своя таблица?

(30) Да нет же, блин. Сама таблица вообще не привязана "ко всем" или к "некоторым счетам". Да там есть поле с ссылкой на счет. Данные в ней будут только по счетам с определенным количеством субконто.

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

(0) Было 6 свели к 4. При 6 итоги бесконечно пересчитываются, считай не пересчитываются. В принципе можно использовать смотря по каким счетам(если планируется количество записей более 3 миллионов, то использовать не стоит).

(31) так вот если ограничить запрос счетами только с 3-мя субконто то не будет, а если ограничивать только субконто то залезет, если на счете с 4-мя субконто есть данное субконто

Это как к легковушке приделать кузов, что бы возить кирпичи, потом гусеницы, что бы проходимость была и крылья для скорости. Только вот такая груда хлама будет требовать лошадей в упряжке, что бы хоть как-то сдвинуть с места. И виноват во всем будет разработчик. Ёлыпалы, там же откровенное самодурство!
Автор, сначала "куда покупается", потом "ответственный менджер", потом "срок годности" и "условия хранения". Этому менеджеру не нужна может информация в виде 2-х мерной таблицы? Ему же надо просто свой отчетик со всякими сверкалками, свистелками и прочими рюшками. Просто он этого еще не знает. Да он сам будет доволен, если ему такой мега навороченный отчет предоставить. И без разницы, где что будет храниться. Главное и бухи целы и начальник довольный.
Предлагаю, помимо давления в сторону бессмысленности, сразу подготовить макет красивого отчета

(34) В ОСВ он хочет видеть все. И у него есть бабки чтобы подтвердить своё желание. А нет - другого прога найдут.

(35) ну и я бы не пожалел бы никогда о таком начальнике - пусть ищет другого прога

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

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

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

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

+(40) ему надо доп.субконто или более расширенный анализ?

(41)Настаивает на доп.субконто.

(42)В общем, основная причина не делать такова. От заказчика в начале месяца приходят материалы на склад. Затем, эти материалы перемещаются с основного склада по участкам. Затем со складов участков материалы списываются в производство. В сопроводиловке к материалам помимо прочего идет ведомость сколько и каких материалов предположительно(!!!) должны уйти на какие объекты. Затем, в следуюзем месяце заказчик предоставляет акт сверки, где расписано сколько и каких материалов мы списали на объекты, причем, там чаще всего совсем не те объекты на которые планировалось.

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

(0) Ну я это читал в Конфигурировании в системе "1С-Предприятие" Решение бухгалтерских задач (УЦ № 3), еще под 1С 8.0, там было написано, что по четвертому, пятому и т.д. субконто просто не может быть построен индекс и система работает тупым перебором, а посему крайне не рекомендовалось использовать более трех субконто...

(43) а приход то зачем перебивать?

+(44) Написано было так, что максимальная длина индекса в MS SQL - 16, а период, Организация, Валюта, Счет и три субконто уже тянут 13, а все что превышает 16 по длине - перебор...

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

(47) САП для заработка денег, а не ведение учета. Это же сколько придется еще бухов брать? Или на сколько меньше придется существующим пить чай

(48) за то сколько прелестей - контрагенты разбиты на кредиторов и дебиторов, айдоки всякие, синхронизация с 1с-кой))) и нет субконто )))