Имя: Пароль:
1C
 
Количество субконто на счете
0 Snovy
 
10.11.10
23:05
Тема написания ТЗ для дочек нефтянной компании. В кулуарах была высказана просьба - а можно без всяких там ваших регистров, все на плане счетов?
Результат - только для ОС в целях консолидированной, факта управленческой, а также РСБУ и НУ без всяких МОЛ и местонахождений ОС необходим 24 аналитических разреза. 2/3 закину в справочники и аналитку движений (проводок). Остается 8 штук. По просьбе заказчика это должно быть вынесено на субконто. Ну еще что-нибудь спрячу, но в итоге как минимум 6 субконто необходимо.
Мои консультации с сертифицированными экспертами от 1С и самой один 1С получили ответ: 4 и не больше. Но если только через кэш индексов, то реально можно поднять до 8 без потери производительности регистра бухгалтерии - пользователю то это не понять (про кэш и как это ему нарисовать в бух.справке!). С другой стороны типовой функционал поддерживает только 3 субконто (я имею в виду типовые бух. отчеты).

Вопрос: стоит ли городить огород с больше трех субконто? (переделка отчетов меньшее зло, интересует потеря производительности). Это вопрос для того случая, если мы поведемся на призыв - все на плане счетов. Хотя это нереально, но тем не менее...
1 Господин ПЖ
 
10.11.10
23:09
>С другой стороны типовой функционал поддерживает только 3 субконто (я имею в виду типовые бух. отчеты)

кроме отчетов надо колбасить табличные поля типа движений ОперацияБух + документы которые перестраивают форму в зависимости от выбранной аналитики/операции (например ППВ/ППИ) - если это не учесть будут дырки в аналитике при проведении
2 Snovy
 
10.11.10
23:13
(1) ОперацияБух изначально выдирается из продукта как класс. Вместо нее делается документ "Бух.справка", которая интеллектуально поддерживает все счета и регистры, с ними связанные. Так что это не вопрос...
3 Snovy
 
10.11.10
23:14
(2)+ Это у нас. В том ПО, которое будет дорабатываться или зааново периписваться по нашему ТЗ = хз...
4 Snovy
 
10.11.10
23:15
(3)+ я это ПО еще не видел. Увижу где-то через пару недель, когда будут готовы план счетов, требования к аналитике и модель учета :) Я только знаю, что это доработка БП 1.6
5 ilkoder
 
11.11.10
00:06
Есть у меня подозрения, что 1с считает ВСЕ соотношения и остатки промежь всех разрезов аналитики - в вашем случае их будет столько, что пипец просто. А им нужна просто таблица проводок с кучей аналитики, а что с ней потом делать - типа отдельная песня. Выноси просто все лишние разрезы в отдельную таблицу и привязывай как-нибудь к операции. Или САП-ахапта, или чего там еще под оракелом крутится...
6 Snovy
 
11.11.10
00:20
(5) Таблица проводок с кучей аналитики - в терминологии 1С называется оборотной аналитикой. Это не проблема, можно провести анализ и на реквизиты регистра бухгалтерии выкинуть совокупность однородной аналитики - максимум 3-5 составных элементов. Это все фигня. Нужно поставщика протянуть от к60-д10 через все производство до 90 счета. Во где проблема. При этом поставщик должен побывать и на 01 счете, и через амортизацию проклюнуться на счета затрат, и многопередельно распределиться по 20, 23, 25 счетам, и через готовую продукцию 43 добежать до себестоимости на 90.2 счете. При этом по отдельным позициям не только в сумме, но и по количеству........
7 RayCon
 
11.11.10
03:24
(6) Не далее, как сегодня обсуждали с Кумариком подобный вопрос. :)

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

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

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

Например, аналитика "проект" сквозная => она может быть маркером хозоперации. А, скажем, "регион" может быть более узкой аналитикой, т.к. проект может осуществляться в нескольких регионах => разные регионы могут прикрепляться к разным проводкам хозоперации, которая относится к одному проекту.

Если рассматривать проблему "поставщика протянуть от к60-д10 через все производство до 90 счета", то, очевидно, что её не решить на уровне субконто. В данном случае поставщик играет роль сквозной аналитики, в некотором роде аналогичной проекту.

В принципе, конечно, можно всё и на плане счетов сделать, но тогда план счетов утратит иерархию на уровне субсчетов. На Западе часто встречаются такие планы счетов, но 1С такое вряд ли переварит. Тем не менее, структура счетов может быть, например, следующей:
ХХХХ.ХХХХ.ХХХХ.ХХХХ.ХХХХ.ХХХХ.ХХХХ.ХХХХ
где каждый сегмент - ничто иное, как сквозная аналитика. Иными словами, один сегмент - одна размерность, а весь план счетов - многомерная (неиерархическая!) структура. Замечу, что, в самом общем случае, это может быть суперпозиция иерархических и неиерархических аналитик. Например, иерархическими могут быть лишь некоторые сегменты, или иерархия может быть только внутри них.

Как это всё работает? Да очень просто: крутится OLAP-куб. А при выборке данных при формировании отчетов может осуществляться маскирование по определённым сегментам.

На 1С можно реализовать нечто подобное, но не на плане счетов, а на, скажем, специальном составном регистре, который будет хранить информацию о каждом сегменте. А сегмент - это ничто иное, как код элемента в соответствующем справочнике. Например:
0001 - код бизнес-единицы
8240 - код проекта
1234 - код поставщика
4744 - код отв. лица
1212 - код региона
5555 - код подразделения

В форме документа делаются поля для выбора элементов из соответствующих справочников. По мере их заполнения пользователем в отдельном поле собирается стринг (в терминах 1С - представление) из кодов выбранных элементов:
0001.8240.1234.4744.1212.5555
Формируя отчет и делая срез по тем или иным аналитикам, можно всегда вытащить нужные суммы.

В заключение хочу обратить внимание, что в зависимости от бизнес-логики некоторые сегменты в отдельных проводках могут вырождаться. Если вернуться к твоему сквозному поставщику, то в том случае, если в момент реализации ОС нам не нужно знать, у кого оно куплено, то в операции продажи ОС сегмент поставщика можно заблокировать для заполнения пользователем.
8 DrShad
 
11.11.10
05:24
(6) я так подозреваю что на одной конфе решили запустить всех, причем начинаете с самого первого это бухи, потом экономисты налепили своих бантиков, продажники своих, отдел снабжения своих и т.д? но так не взлетит никогда
Сколько уже внедряю предприятий, ну ни на одном бухам не интересно на 90 счетах видеть контрагентов
А почему не сделать несколько конфиг с разным функционалом и настроить между ними обмен? а бухию оставить в покое
9 DrShad
 
11.11.10
05:28
(7) интересная идея (записал в блокнот)
10 zak555
 
11.11.10
12:12
закладка на (7)
11 Snovy
 
11.11.10
13:19
(7) Я это принцип давно использую. Еще в семерочных проектах, где не хотелось увеличивать колтчество субконто больше трех, применялась составная аналитика - например на 60 и 62 счетах в качестве аналитики висел упакованный справочник, который хранил в себе Контрагента, Договор и Вид расчетов. Таким образом оставалось еще субконто для документа расчетов и иеще одно для разных там целей. Соответственно отчеты были немножко доточены.

Кстати, теперь это гордо называется РАУЗ. Не совсем кончено так, но суть та же...

(8) Нет. Чисто бухгалтерский и налоговый учет с поставкой наверх для системы консолидации и сбора управленческого факта.
12 RayCon
 
11.11.10
14:27
(11)
>например на 60 и 62 счетах в качестве аналитики висел
>упакованный справочник, который хранил в себе Контрагента,
>Договор и Вид расчетов.

А вот это, как раз, чревато... Дело в иерархии. Если подчинённость справочников сверху-вниз при этом сохраняется, то всё ОК. Но вообще-то описанный в (7) подход применяется для НЕиерархических справочников. Это получило широкое распространение для центров ответственности (в частности - для центров затрат), когда измерения не зависят друг от друга.
Закон Брукера: Даже маленькая практика стоит большой теории.