Галактика в вопросах и ответах

RavageR писал(а):И еще такой вопрос непонятный для меня пока.
Как мне допустим посчитать значение статьи "Остаток на начало"
Т.е. по сути тут должна быть сумма всех денежных средств организации. Можно как то просуммировать данные остатков на различных счетах и записать в значение этой статьи?

Да можно конечно. По формуле. При этом желательно, чтобы ДС по счетам велись на статьях, а не аналитике. В противном случае возможно придется использовать функционал "Алгоритмы расчета", он более гибок, но требует дополнительных телодвижений.
Есть еще вариант расчета с применением аналитик вроде ТПС (типовые платежные средства), но он тоже трудоемок.
Ну, а формульная технология ведения остатков примерно такая (грубо):
1. Имеются базовые статьи типа "Поступления" и "Выплаты"
2. Вводятся дополнительные статьи типа "Остаток на начало" и "Остаток на конец".
3. Вводится вспомогательная статья типа "Начальный остаток"
4. В начале работы на статью "Начальный остаток" вводятся данные.
5. "Остаток на конец" считается как Остаток на начало плюс Поступления минус Выплаты.
6. Остаток на начало считается как Начальный остаток (если он введен), в противном случае Остаток на начало равен Остатку на конец предыдущего листового периода.
7. На стыке бюджетов разных периодов необходимо сделать так, как посоветовал Den
8. Вообще Начальный остаток вводится один раз, но при необходимости он служит для корректировки начального остатка внутри периода (в листовых подпериодах).
P.S. И в заключение совет: поставить дистрибутивную тест-базу по бюджетам, там все эти формульные конструкции-шаблоны представлены, в рабочем варианте так сказать.
Кстати, относительно недавно появилась возможность закачивать (экспорт-импорт) бюджетные сущности из других баз. Спасибо разработчикам.

По итоговым статьям тоже теперь вроде понятно.
Спасибо за ответы.

Теперь еще такой непонятный момент остался.
Допустим есть БДДС за месяц по дням и внего все данные попадают.
Т.е. в фактические операции разнесены с учетом этого типа периода - (месяц-день)
Допустим я хочу посмотреть БДДС в другом виде: Год по месяцам.
Создаю новое представление бюджета ДДС на базе нового периода Год-Месяц. Но данные в него не попали вообще, хотя в фнварьском бюджете по дням данные есть.
Как быть? Это ограничение Галактики, или я не знаю чего то?

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

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

Давно уж написал сам просто подневный и помесячный ДДС-ы.
Внесите предложение свое разработчикам - может когда и сделают )

Для ден:
"Давно уж написал сам просто подневный и помесячный ДДС-ы."

Каким образом?

в основе финансовые обязательства...от них и пляшется за определенный период. Ну и все это выстраивается по ТФ оперделенной. Вкратце..

RavageR писал(а):Для сим:
"Откуда им взяться?"
Да хотябы от туда что фактически операции разнесены на периоды с большей детализацией чем я хочу. Т.е. если есть разноска факта по дням в рамках месяца, почему нельзя агрегировать такую разноску в более широкие периоды планирования.
Это очень неудобное и серьезное ограничение, которе меня серьезно разочаровало.

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

RavageR писал(а): Одни менеджеры должны следить и планировать в рамках месяца движения денежных средсвт. Другие оперируют более глобальными данными.

Вот и задали бы сразу тип периода Год-Месяц. Вы же сами сказали, что горизонт планирования у вас - месяц ("в рамках месяца" - это ваши слова). Зачем было делать тип периода Месяц-День? И с "глобальным" периодом тоже пролетели, не учли в типе периода "Год".

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

"Откуда им взяться" - имелось в виду, что вы разносили операции в тип периода "Месяц-День". А сформировав новый тип периода "Год-Месяц", вы фактически создали новое хранилище данных, и естественно оно пустое.
Вы же вот сами это подтверждаете:

RavageR писал(а): Допустим есть БДДС за месяц по дням и внего все данные попадают.
Т.е. в фактические операции разнесены с учетом этого типа периода - (месяц-день)

То есть данные ушли в измерение Месяц-День
И далее:

RavageR писал(а): Создаю новое представление бюджета ДДС на базе нового периода

Т.е. создали новое хранилище. Вот я и говорю - откуда там взяться данным?

Медленно и верно движемся к цели. Галактика удивляет количеством настроек и предусмотрительностью любых капризов.
Спасибо всем кто принимает участие в обсуждение.
Небольшое неудобство есть вот думая как его красивее обыграть.
В большенстве своем статья бюджета почти везде соответсвует определенной ТХО.
Но вот в одном сучае в зависимости от контрагента должна быть указана разная статья бюджета и все это в рамках одной ТХО.
Т.е. если контрагент такой то, то одна статья, если другие то другая статья.
Как это сделать ума не приложу. Видел какие то пользовательские режимы, но что там писать не пойму.
Помогите плиз

Если без апи, то можно попробовать

&1. &SoprDoc
&2. coTXOGetField('KATSOPR','CORG',&1)
&3. if(&2<>'nrec организации исключения', TxoSetKau(20,160,<Nrec статья 1>,TxoSetKau(20,160,<Nrec статья 2>))

ну и у статьи бюдежта в шаблоне ТХО выставить <режим0>

RavageR писал(а):Медленно и верно движемся к цели. Галактика удивляет количеством настроек и предусмотрительностью любых капризов.

Вот это другой разговор
Приятно читать.

RavageR писал(а):Небольшое неудобство есть вот думая как его красивее обыграть.
В большенстве своем статья бюджета почти везде соответсвует определенной ТХО.
Но вот в одном сучае в зависимости от контрагента должна быть указана разная статья бюджета и все это в рамках одной ТХО.
Т.е. если контрагент такой то, то одна статья, если другие то другая статья.
Как это сделать ума не приложу. Видел какие то пользовательские режимы, но что там писать не пойму.
Помогите плиз

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

Для Sim
третий вариант это все равно что в ТФО для статьи поставить запрашивать из каталога.

второлй вариант с таблицами соотвествия. Это насколько я понимаю нужно ВСЕМ!!! контрагентам поставить в соответствие какую-либо статью. Т.е. одному двум контрагентам поставить одну статью, а остальным тысячам контрагентов поставить другую. Замучуюсь набивать эту таблицу. И поддерживать конечно тяжело новые покупатели и все такое.

для DEn а можно написать легкий коментарий чтобы я понял что каждая строка делает?

по F3 из шаблона ТХО (на закладках 'системные идентификаторы' и 'общеиспользуемые функции') есть же все перечисленные функции/методы с описанием шо они делают...что именно непонятно ?