Mag1str, Было бы намного эффективнее, если бы вы описали свою структуру регистров, и задачу, которую хотите решить. Тогда, если проблема в архитектуре, можно было бы подсказать вам, какая структура регистров больше подойдет для вашей задачи, а если с регистрами всё ок, то можно было бы вам подсказать, как извлечь данные.
Mag1str, блин, не обратил внимание, что у вас таблица остатков.
Никак не доберетесь, не отслеживаются остатки по реквизитам, если вам нужно, то это должны быть не реквизиты а измерения.
Если нужно условие на ресурсы, то его делай во вкладке "Условия"
Смысл в том, что ты должен максимально описать условия в параметрах виртуальной таблицы, чтобы ограничить её размер. А дальше делай что тебе нужно.
В данном конкретном примере можно было обойтись просто null.
Брюс Эккель всеми силами пытается донести мысль, что "просто null" это плохо, и его нужно избегать любыми способами, а вы вот так, одной фразой перечеркнули все его усилия. =)
Mag1str, ровно как я и написал: сразу делать две записи и датой начала и датой окончания.
Например подписка с 01.03.2022 по 31.08.2022
Вы сразу делаете две записи:
1) 01.03.2022 Пользователь, Подписка, 01.03.2022, 31.08.2022, Истина
2) 31.08.2022 Пользователь, Подписка, 01.03.2022, 31.08.2022, Ложь
таким образом срез последних, на любую дату с 01.03.2022 по 30.08.2022 даст вам запись с актуальностью Истина
А если вы сделаете срез последних на 31.08.2022 (и позже) то актуальность будет Ложь
Mag1str, Я бы вынес дату покупки и дату окончания в ресурсы. Добавил бы еще один ресурс "Актуальность" типа "булево". И при оформлении подписки делал бы два движения, одно датой покупки, с актуальностью "Истина", и второе датой окончания, с актуальностью "Ложь"
Это дало бы мне возможность по срезу последних сразу выбрать все подписки пользователя, и при необходимости отобрать нужные по признаку актуальности без лишних вычислений.
Да нет, у него там кругом "НзваниеСклада", он специально на скриншотах показал. Но я в шоке, везде в коде писать с ошибкой, вместо того чтобы один раз исправить!
Похоже на то, что не хватает какого-то шрифта, и система не очень удачно выбрала ему замену. Я бы попробовал поменять настройки шрифтов в программе, если они там есть. Если удастся выяснить в каком шрифте дело, можно попробовать установить его вручную.
Думаю что проблема здесь не виртуалбоксе, а в системе которая в нем установлена.
Tsudzukeru, Tsudzukeru, ну, таки нужно использовать bitmap решение архитектурных задач, это уже отдельный вопрос. Но, без кеширования будет плохо, ваша картинка будет постоянно перекачиваться по любому чиху, и иногда не будет отображаться вовсе.
pierabelar, Я бы сделал справочник "АвтомобилиКонтрагентов" подчиненный справочнику "Контрагенты"
В форме элемента справочника клиентов выводил бы на отдельной закладке динамический список.
k0r0g, Всё-таки конфигурации, это не казуальные игры, поэтому такого хаба нет. Есть Инфостарт - ресурс где специалисты делятся наработками и опытом, но готовых конфигураций там нет.
Для начала вам нужно разобраться, в какой структуре данных вы собираетесь хранить эти добавленные значения.
Это может быть: табличная часть справочника, регистр сведений, другой справочник.
Попробуйте сформулировать вопрос от задачи, какую конкретно бизнес-задачу вам нужно решить. Тогда вам смогут подсказать, какая структура данных для этого больше подойдет.
Если вы укажете, в какой конфигурации вы это собрались реализовать, возможно окажется что там это уже есть.
Xris, Видимо на той что работает, запускаете в файловом варианте. А на той что не работает в клиент-серверном.
А если пропишите так как вы указали, ошибка конечно выскакивать перестанет, но и код выполняться не будет.