Дело вот в чем: надо отследить, сколько осталось у сотрудника ТМЦ, выданного с определенного склада. Добавил реквизит регистра "СоСклада", но ни на одном из уровней группировок не могу получить значение этого реквизита. Установка фильтра не помогает, установка значения фильтра не помогает (не работает). Получить аттрибут тоже ничего не дает...
Вот функция, которая выдает остатки по МестуХранения, но когда условие равенства реквизита заданному значению - возвращается пустая таблица запроса... Подскажите, плз, что я делаю не так. Или может есть другой способ... Пожалуйста! т.к. не в первый раз уже не могу получить значения реквизитов. В прошлый раз пришлось добавлять вместо реквизита измерение, но это же не метод... Пришлось все доки и отчеты переписывать...
Если реквизит - число, то получается получить его сумму. (как в регистре партий, например)
LiS Написал:
-------------------------------------------------------
> Вот функция, которая выдает остатки по
> МестуХранения, но когда условие равенства
> реквизита заданному значению - возвращается пустая
> таблица запроса... Подскажите, плз, что я делаю не
> так. Или может есть другой способ... Пожалуйста!
> т.к. не в первый раз уже не могу получить значения
> реквизитов. В прошлый раз пришлось добавлять
> вместо реквизита измерение, но это же не метод...
В том, то и дело - что метод.
Реквизит регистра - есть оборотная сущность. Это значит, что остатков в разрезе реквизитом НЕ СУЩЕСТВЕТ.
Накладывая фильтр на реквизит, ты формируешь определенные значения фукнций Приход и Расход, но не НачОст и КонОст.
Если ты хочешь видеть значения функций НачОст или КонОст в разрезе (в фильтре) какого-то перечисляемого типа данных, то этот тип данных должен быть среди измерений. А это значит, что нужно переписывать все документы и отчеты в части касающейся. Иначе никак.
Да. Спасибо. Это понятно. Я добавил период в запросе (чтобы этой сущности увидеть свои приходы-расходы) и в принципе получаю КонОст, но: не начнет ли база дико тормозить, когда обороты по этому регистру станут накапливаться. Ведь, чтобы получить правильный остаток, по сути, надо перебрать все документы в базе...
LiS Написал:
-------------------------------------------------------
> Да. Спасибо. Это понятно. Я добавил период в
> запросе (чтобы этой сущности увидеть свои
> приходы-расходы) и в принципе получаю КонОст, но:
> не начнет ли база дико тормозить, когда обороты по
> этому регистру станут накапливаться. Ведь, чтобы
> получить правильный остаток, по сути, надо
> перебрать все документы в базе...
Тормозить будет не база, но твой отчет.
В любом случае, этот реквизит будет заполняться документами. Если с результате описанного алгоритма ты получишь правильный результат, то может проще реквизит перенести в измерения?
Уже. :-)
Только еще пару регистров пришлось добавить и описать их движения в модулях проведения. Да. Это не отчет. Это надо было контролировать при проведении документа (типа откуда ТМЦ и если не с того склада, тогда ругаться). Я просто сделал еще один регистр, где и буду хранить информацию сколько и откуда и у кого есть. Думается будет гораздо быстрее. Все равно база на этапе проектирования, так что документов в ней пока нету. Этап внедрения будет болезненный и мучительный... :-( А еще придется из старой базы справочники переносить... Тяжело писать базу с нуля, когда ты один...
Имхо, где-то ты накосячил в самом начале, при постановке задачи.
Изложи чуть подробнее что контролируешь и ограничиваеь и ПОЧЕМУ (ПО КАКОЙ ПРИЧИНЕ).
есть подозрение, что это поможет разрулить ситуацию гораздо проще... проходили уже...
LiS Написал:
-------------------------------------------------------
> справочники переносить... Тяжело писать базу с
> нуля, когда ты один...
Конечно тяжело, если не умеешь работать в команде... Хотя в команде ты один из многих, а сам посебе - величина. Выбирать - тебе. В любом варианте есть плюсы и минусы.
Чебур в чем-о прав. Хотя сам допускаю несколько регистров в рамках одного учета. Например, в ТиС регистры ОстаткиТМЦ и ПартииНаличие. Вроде учитывем одно и тоже, но в разных разрезах. Такой подход должен быть обоснован и агрументирован.
З.Ы. Прикалываюсь над тем, что типовые конфигурации не смогут пройти сертификацию 1С:Совментимо
> Вроде учитывем одно и тоже, но в разных разрезах.
неа... в типовой ТиС ОстаткиТМЦ - это в первую очередь количественный учет (кладовщики), а ПартииТМЦ - это учет себестоимостей (управленц и бухи) - совершенно разные вещи...
про 41.1 - это да...
>Позволю себе не согласиться. Допускаю, что ты, Сhe Burashka, мало внедрил Бухгалтерий и ТиС отдельно, и Бух+ТиС совместно.
не вштырил.. ты в основном с чем не согласен?
бух+тис совместно юзаю, в нескольких местах.
есть и где отдельно только бух,
но не встречал где только ТИС, и нету бух...
..
поясни..
..
счет не на десятки, но схема более-менее наработанная...
причем я склонен на бух не реализовывать (ДОПИСЫВАТЬ!) те вещи, которые можно сделать штатно на ТИС
Сhe Burashka Написал:
-------------------------------------------------------
> Имхо, где-то ты накосячил в самом начале, при
> постановке задачи.
> Изложи чуть подробнее что контролируешь и
> ограничиваеь и ПОЧЕМУ (ПО КАКОЙ ПРИЧИНЕ).
> есть подозрение, что это поможет разрулить
> ситуацию гораздо проще... проходили уже...
Конечно. Может и накосячил. Я уже поднимал эту тему.
http://infostart.ru/forum/read.php?22,3084,ref=427 Теперь вот сражаюсь. В качестве шпаргалки посматриваю в ТиС9.2. Относительно следующего поста: один, т.к. в принципе програмер начинающий, друзей-знакомых, пишущих более-менее именно на 1С практически нет. Все в основном на дельфях да на С++. А тут приходится и в бухию въезжать, и сайт иногда пописывать, и другие нетривиальные задачи, например, как эта решать... Да и как потом объединяться без косяков? Поле, выполняющее одну и ту же функцию у разных людей по-разному названо и т.п.
Косяк в том, что конечный пользователь сам четко не знает, что ему надо. Партионный учет - надо. Взаиморасчеты - !!!не надо???!!! А для чего вообще база тогда? Учет техники, находящейся в ремонте - надо. Учет серийных номеров - !!!не надо???!!!... Непонятные мутные движения запчастей, разные статусы поставок и т.д. А потом отчеты перед производителями техники. Одним - так, другим - эдак. Проще для каждого производителя свою базу написать... Короче, как понял специфику работы конкретного СЦ, так и выстроил структуру МД. Постарался как можно универсальней структуру сделать... Посмотрим, что получится...