СКД Посчитать количество заполненных ячеек #518258

Господа, а есть ли возможность посчитать количество непустых ячеек по строке? У меня строка с колонками по дням месяца. Колонок 31 штука. Мне нужно посчитать в скольких колонках по данной строке имеются данные. Как это осуществить? Заранее спасибо

Пытался сделать конструкции в вычисляемых полях, но не получается Т.е. я даже не знаю как подступиться

31-Число01-Число02?

А есть еще 30, 28 и даже 29.

Да тут не суть в том, сколько дней в месяце :) Это я для примера написал, колонки у меня динамически формируются. Мне именно посчитать нужно сколько дней заполнено.

Так не выйдет, скорее всего, т.к. Мне нужно считать именно по 1, а не по тому, что в ячейке. В ячейке допустим 360, но посчитать мне надо как 1 Т.е. в ячейках время работ (час, 2 часа, полчаса). И мне надо посчитать в скольких днях работа происходила

Никто не знает? :(

Немножко апну. А то ускакивает :(

ну типа 31- ВЫБОР КОГДА Число01 > 0 ТОГДА Число01 ИНАЧЕ 0 КОНЕЦ -ВЫБОР КОГДА Число02 > 0 ТОГДА Число02 ИНАЧЕ 0 КОНЕЦ

вариант. страшненько правда :) я думал есть более простые методы. В любом случае, спасибо

У тебя 31 поле в наборе данных СКД? О_о

Угу. ТЧ документа. Никуда не деться, такие запросы руководства. Им хочется вести все а-ля в экселе, как было раньше

"Никуда не деться, такие запросы руководства" - ну вот нам-то заливать не надо. Руководство прямо сказало, что в таб. части документа была 31 колонка? Или это ты сам себе такой способ реализации изобрел и теперь героически преодолеваешь?

Да, именно так и есть. В таб части должна быть 31 колонка. Чтобы все было "как в экселе" и заносилось абсолютно также

Тебе по слогам повторить?

+ И не 31 а динмически от количества дней в месяце. Если можете предложить другую реализацию заполнения каждогодневного графика, то скажу спасибо. В любом случае либо ТЧ, что для меня предпочительнее, так как данные надо хранить. Либо ТЗ, которую надо хранить в ХЗ и потом еще вытаскивать. А ввод данных, о ужас, вообще идет через ПТД

Пипец. Позовите программиста, пусть он расскажет, как можно такие данные хранить. Для этой задачи достаточно ТЧ из 2-х колонок.

сделай группировку месяц и считай, какие проблемы?

Ну расскажите мне, как это можно хранить в ТЧ из 2-х колонок. Я с такими задачами вообще никогда не сталкивался. да и пользователь эту ТЧ должен мочь исправить. да я уже посчитал, это скорее флуд :)

+ если вы предлагаете транспонирование, то это не вариант

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

Номер дня и значение. ВНЕЗАПНО, да?

И в чем разница? Вместо 31 колонки будет 31 строка. Не понимаю смысла. Да и + к тому там еще есть другие колонки с другой информации. И по каждому пункту информации будет по 31 строке? Т.е. 200*31 = 6200 строк в одном документе. И сколько времени обходить такую ТЧ для вывода в отчет? А когда таких документов нужно обойти 200+ штук строк? Не вижу смысла, честное слово

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

а хранится инфа только в доке? или все ж в регистре сведений?

Ты уже придумал, как в 31 колонке посчитать количество незаполненных? "И по каждому пункту информации будет по 31 строке? Т.е. 200*31 = 6200 строк в одном документе" - это делается ТРЕМЯ колонкам. "И сколько времени обходить такую ТЧ для вывода в отчет? А когда таких документов нужно обойти 200+ штук строк?" - ты вручную, что ли отчеты выводишь, с карандашом и ластиком?

Только в доке

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

Я имел ввиду сколько эти строки будут обрабатываться 1С? Запустил отчет на выполнение и пошел курить, так чтоли? А данные да, заносятся вручную.

Ну можт быть, можт быть. ЧСВ тут не причем. Просто я говорю, что делать в документе 7к строк - не вариант для меня

Быстрее обработается 200 строк с 36 колонками

Столько же, сколько и 31 колонка.

И да, я уже посчитал количество незаполненных еще вчера, правда другим методом немного. И написал об этом в

Ну, тогда считай свои колонки и не полоскай тут мозги.

Замерять мне нечем. Так если работать будет с такой же скоростью, то какая разница? И у меня опльзователь может править ТЧ вручную, если требуется. Где ему тогда искать инфу после транспонирования? Иили делать 2 ТЧ, одну для пользователя и одну конечную?

Лучше делать в цикле.

Повторюсь, я еще в 18 написал, что все уже посчитано :) Дальше пошел просто флуд

"если работать будет с такой же скоростью, то какая разница?" - покажи свой метод расчета, поймешь. "И у меня опльзователь может править ТЧ вручную, если требуется" - а я запрещал, что ли?

Так я и считал собственно. Просто думал, что можно быстрее посчитать в самой СКД

Зачем выкидывать целые предложения? Я писал: "И у меня опльзователь может править ТЧ вручную, если требуется. Где ему тогда искать инфу после транспонирования?" искать эти строки в огромной ТЧ как минимум неудобно. Метод расчета в . У меня практически одно и тоже. Я считаю заполненные таки не в СКД а в документе

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

считывать инфу из дока не есть методически гуд, для этого регистры сделаны. в принципе ничего не мешает сделать док с ТЧ какого угодно вида, а инфу писать в РС и оттуда быстренько читать. писать соответственно записями в две-три колонки.

Ты в этот топик пришел ЧСВ чесать или что? :) Проблема уже решена :) Я уж не знаю где и что получают приличные люди, но кто мешает сделать точно такой же цикл запросом? :) Просто на данном этапе мне этого не нужно. Буду реструктуризацию делать, сделаю запросом. Когда делать нужно быстро, чтобы все было готово вчера - не до красоты. Красоту начинают наводить, когда все уже работает и нужно ускорить/подправить. ИМХО, конечно. А вот насчет на форме это будет выглядить также, отсюда можно действительно по-подробнее, потому что я представляю это только созданием второй ТЧ. Могу быть неправ ессно, тогда расскажи как :) Мериться нчием я не собираюсь

Согласен, что это некрасиво. Согласен, что надо писать в РС, но это пока в планах. Сейчас надо, чтобы инфа из доков просто попадала в отчет

Вот писать в РС таким методом как ты предложил - удобно, согласен

+ Это было для Defender aka LINN

Ресурс = 1. Итог по колонке

Сейчас вопрос о записи в регистр не стоит, да и там я проблем не вижу :) Господа, всем спасибо, тема закрыта :)

"Когда делать нужно быстро, чтобы все было готово вчера - не до красоты" - если бы мне каждый раз давали по рублю, когда я это слышу... Вот что мешает сразу делать нормально и по-человечески? Зачем сразу выпучивать глаза и бежать воротить неподъемные и неподдерживаемые конструкции?

Я честно готов учиться. Я не претендую на то, что моя конструкция самая лучшая и даже на то, что она имеет право на жинь (хоть и работает, и даже быстро работает). Расскажи как можно сделать правильно? По-человечески разхясни или дай ссылку на мануал, похожую проблему. Поясню "как это выглядит": Действие номер раз: Есть общий документ с ПТД. В ПТД пользователь забивает инфу и она должна хранится в документе. Как? Я сделал ТЧ. Можно ли сделать ТЧ не с 31 колонкой а с 2 - не уверен. Если можно, то как сделать такую ТЧ (желательно одну), чтобы пользователь в самой ТЧ видел информацию также как в ПТД? Действие номер два: На основание строк ТЧ формируются документы - собирается информация из первой колонки ТЧ (в моем случае - контрагент) и по этому контрагенту информация из ТЧ общего документа передается другим документа. Действие номер три: В созданных документах формируются уже другие ПТД другого формата на основании ТЧ (тут берется только дата, т.е. если она <> 0, то заносится в ПТД). После формирования ПТД у меня формируется уже окончательная ТЧ (в ней не 31 колонка (: ). Данные из этой ТЧ по каждому документу собираются непосредственно в отчет. Пока прямо из ТЧ, прикрутить к РС я не успел, потому что действительно все надо вчера, и это не метафора. Когда ставят жесткий срок - "чтобы было готово через два часа" - не всегда успеваешь продумать правильную структура и действуешь по наитию, согласись. Собственно вот. Как сделал я тебе уже известно, как можно сделать лучше - всегда гоотв услышать. Нормальную критику я воспринимаю спокойно :) Какие-то советы - подавно.