Здравствуйте. У меня в режиме актуализация, программа пересчитывает таксационные показатели только на 2017 год, вне зависимости от того какой год я указал в графе год актуализации. Проявляется на деморегионе, посмотрите пожалуйста?
Действительно, сейчас заложен алгоритм пересчета на текущую дату без возможности пересчета задним числом или на будущее. Передано программисту в работу.
Добрый день! скажите, при актуализации что должно стоять в самой карточке таксации? Год л/у - у меня 1997, или следующий, 1998? И год актуализации - 01.01.2017 или прямо текущая дата?
год актуализации - 01.01.2017 или прямо текущая дата?
Не могу говорить за всех, так как сталкивался с разными мнениями по этому вопросу. Но правильнее, на мой взгляд, ставить дату начала года, следующего за изменениями, как это было принято раньше. Главное тут - чтобы разница между датами была корректной.
скажите, при актуализации что должно стоять в самой карточке таксации? Год л/у - у меня 1997, или следующий, 1998?
В разных предприятиях по разному: у кого то именно год ЛУ-работ, у кого то следующий. Мне объясняли так: работы по ЛУ ведутся в 1997 г, так как отчётный период идёт на 01.01.1998г, то в этом поле должно стоять 1998.
Спасибо. А так ли обязательно проводить все расчеты и назначать мероприятия до актуализации? Потом же все равно придется все эти операции делать заново, после внесения изменений и других манипуляций.
А так ли обязательно проводить все расчеты и назначать мероприятия до актуализации? Потом же все равно придется все эти операции делать заново, после внесения изменений и других манипуляций.
Я понятия не имею, что Вы вообще делаете, на каких данных, в каких целях и для кого! Как же я могу Вам ответить на этот чисто содержательный вопрос!? ))) Смотрите ТЗ... договор... задание работодателя...
Ну как же, в инструкции четко написано - "Таксационная БД должна быть проконтролирована и заполнена расчетными показателями. " А я не понимаю, зачем заполнять расчетными показателями, если после внесения изменений всю процедуру делать заново. Можно же просто проконтролировать, актуализировать, внести изменения, а заполнить расчетными показателями уже в новой получившейся базе? Расчетные показатели же не влияют на процесс актуализации? Путает меня эта фраза, вот и вопрос.
смотря на сколько лет актуализировать попробуйте сами на 13 лет и на 15 возраст в любом случае поменяется скажем с 55 до 70, а вот запас посмотрите сами, не всегда будут совпадения потому что актуализация "держит в уме" точный возраст, а расчетные показатели считаются по округленному
Ну как же, в инструкции четко написано - "Таксационная БД должна быть проконтролирована и заполнена расчетными показателями
Теперь хотя бы понятно, что речь идет не о содержательной части. )
Людмила написал(а):
А я не понимаю, зачем заполнять расчетными показателями, если после внесения изменений всю процедуру делать заново.
Отчасти ответ есть в следующем тексте инструкции:
Операцию отменить невозможно, поэтому перед ее выполнением следует сделать копию данных! При необходимости переделать актуализированную БД в случае получения некорректных результатов, нужно использовать исходную БД из архива.
То есть, исходную БД мы рекомендуем сохранять в любом случае. Удобнее это делать через "Разделы" - создаете раздел 1998 и там формируете БД исходную. Затем делаете раздел 2017, копируете туда объект и применяете к нему актуализацию. Таким образом, у Вас будет два хронологических состояния одной БД. И если в силу каких то причин, актуализированная Вам не понравится - сможете легко восстановить ее, используя, например, другие справочники запасов. Что касается состояния расчетных в исходной БД то, во-первых, это вопрос культуры и профессионализма. У профи любые базы находятся в рабочем состоянии на актуальную для них дату. У дилетантов - черт голову сломит. Во-вторых, чисто практический резон. От расчетных показателей зависит актуализация хозраспоряжений. Назначив их только в актуализированной БД Вы не сможете корректно перенести их в исходную на случай повторной актуализации. Это ответ на Ваш второй вопрос:
Расчетные показатели же не влияют на процесс актуализации?
Так что - Вам решать. В свою бытность начальником ВЦ я требовал полного порядка в базах на каждый год актуализации и это много раз нас выручало. ))
И к вопросу о годах - там тоже не очень поняла инструкцию, оттуда и возникло. "В поле программы "Год лесоустройства" следует указать год прошлой актуализации - (ранее это был следующий год после лесоустройства), а в поле "Год актуализации" - год текущей актуализации." Я решила, что фраза относится к карточке таксации и при создании исходной базы год актуализации надо поставить текущий, 2017, а год л/у - 1998 вместо моего 1997. Теперь ясно, что в карточке таксации год л/у 1997, год актуализации 1998, а сказанное относится к окну непосредственно актуализации. Понятно, или очень путано написала? Это я к чему - может, немного перефразировать в инструкции? Для новичков топола...
Действительно, сейчас заложен алгоритм пересчета на текущую дату без возможности пересчета задним числом или на будущее. Передано программисту в работу.
Подскажите, алгоритм поправили, пытался сегодня актуализировать лесничество с лесоустройством 1993 года, актуализирует с 2017 по 2017г.г., ставлю 1993, сбрасывает и опять ставит 2017. В чем причина может быть? В карточках прошлое лесоустройство стоит 1993год, год актуализации 20.11.2017г. Все расчеты провел.
В карточках прошлое лесоустройство стоит 1993год, год актуализации 20.11.2017г.
Функция актуализации берет указанный Вами год лесоустройства (или последней актуализации) только для выделов, в которых не заполнен или заполнен годом прошлого ЛУ "Год актуализации". Это необходимо для учета при актуализации текущих изменений или ранее проведенных актуализаций в рамках ежегодного учета текущих изменений и ведения ГЛР. То есть, такие действия как внесение текущих изменений в базе 93 года в 2016 году приводят к заполнению поля Год актуализации датой 2016г. И при запуске актуализации если Вы там поставили, например н/культуры, то она всю базу актуализирует на 2017-1993г=24 года, а выдел с ГА=2016 она добавит культурам один год и только на один год роста прибавит высоты. Поэтому она считывает в БД 2017г и актуализирует до 2017г, то есть добавляет ноль. Этот же механизм предотвращает возможные ошибки "повторных актуализаций". Кстати, убедитесь, что поле не заполнилось в результате уже отработавшей ранее актуализации! Если же Вы уверены, что в БД текущие изменения не вносились и реальная актуализация точно не делалась - просто поменяйте дату в одном выделе на нужную и сделайте массовую замену по правой кнопке. Все это описано в доке: http://www.lesis.ru/infot/les_aktual.html Если там что то не понятно - пишите какие формулировки непонятны и нужно расписать понятнее или подробнее - добавим, распишем. У нас глаз уже замыленный...
