Информация о файле обновления Галактика F_ALG_RES_810280.TXT


Описание файла обновления:
ФайлF_ALG_RES_810280.TXT
ОбновлениеF_ALG_RES_810280
НазначениеОбщее
ПродуктГалактика 8.10
Релиз03.11.2006 : Atlantis 5.2.8
КомпонентF_ALG
ТипRES
Версия8.10.28.0
Дата2016-01-22 16:50:43
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
102.133100NEWНеобходимо прогнозирование в итоговой ведомости НМА за период с учётом алгоритма расчёта амортизацииУчет НМАИтоговые ведомости за период
Исправить работу режима прогнозирования "с пересчетом амортизации" (отчет "Итоговая ведомость за период"): Результаты расчетов прогнозирования не всегда соответствуют износу рассчитанному при переходе на новый отчетный период.Исправлена работа режима прогнозирования "с пересчетом амортизации": Результаты расчетов прогнозирования соответствуют износу рассчитанному при переходе на новый отчетный период.
102.1452448.10.27.0Дополнить таблицу mtIzmStoim полями для срока полезного использованияУчет ОСИзменение стоимости
НЕОБХОДИМО ДОРАБОТАТЬ Дополнить таблицу mtIzmStoim (102.134849) полями для срока полезного использования IzmSPI - изменение срока полезного использования подлежащее учету с текущего месяца IzmSPINo - изменение срока полезного использования подлежащее учету со следующего месяца Использование этих полей такое же, как и остальных связано с дифференциацией корректировок и модернизацийДополнена таблица mtIzmStoim полями для срока полезного использования: IzmSPI - изменение срока полезного использования подлежащее учету с текущего месяца IzmSPINo - изменение срока полезного использования подлежащее учету со следующего месяца Дополнена таблица mtIzmStoim полями для срока полезного использования: IzmSPI - это величина, равная сумме срока полезного использования до поступления и срока полезного использования после поступления (из карточки за текущий месяц), при условии, что в текущем месяце есть изменение стоимости, подлежащее учету с текущего месяца. IzmSPINo - это величина, равная сумме срока полезного использования до поступления и срока полезного использования после поступления (из карточки за текущий месяц), при условии, что в текущем месяце есть изменение стоимости, подлежащее учету со следующего месяца
102.1348498.10.26.0Опция "Учитывать изменения стоимости и износа" = в текущем периоде/в следующем периодеУчет ОСИзменение стоимости
Практика такова, что операция изменения стоимости и износа используется для следующих целей: - отражение модернизации/реконструкции - отражение капитального/текущего ремонта без изменения стоимости и износа - корректировки стоимости - корректировки износа - корректировки ам.премии. - ввод ОС в НУ с начислением ам.премии (* поясню ниже) С другой стороны, согласно законодательству, изменения в стоимости из-за модернизации и реконструкции учитываются месяцем позже. Поэтому в алгоритме амортизации настраиваем либо стоимость из архива, либо текущую стоимость за минусом суммы модернизации(изменения стоимости) с помощью таблицы в памяти OperIzmStoim. Корректировки стоимости и износа могут быть различными: те которые мы решили сделать уже после расчета амортизации и мы там корректируем и стоимость и износ. Либо корректировки которые мы выявили и произвели до расчета амортизации, и которые мы бы хотели учесть прямо в периоде корректировок, например прибавляя к стоимости из архива, либо вычитая из текущей стоимости. Сейчас это сделать невозможно. ПРЕДЛОЖЕНИЕ Таким образом, для дифференцирования данных ситуаций, предлагаю 1) ввести системный тип основания для операций изменения стоимости и износа "корректировка". У такого типа основания должны быть следующие опции - "Учитывать изменения стоимости и износа" = в текущем периоде/в следующем периоде - опция по ам.премии такая же как у "модернизации" 2) доработать логику, формирующую таблицу в памяти, чтобы формировались поля "Изменение стоимости, подлежащее учету в текущем периоде", "Изменение износа, подлежащее учету в текущем периоде", "Изменение стоимости, не подлежащее учету в текущем периоде", "Изменение износа, не подлежащее учету в текущем периоде". * по законодательству в БУ ОС можно начать амортизировать еще до того как оно фактически начало использоваться в деятельности, связанной с получением прибыли, по НУ, использование в деятельности, приносящей прибыль - обязательное условие для начала амортизации. Поэтому в НУ ОС может начать амортизироваться позже. Чтобы не происходило перекоса по периоду возникновения и применения ам.премии, эту ам.премию мы не указываем в операции поступления, а указываем ее в операции изменения стоимости, в которой стоимость не меняется а лишь начисляется ам.премия. Плюсы такого подхода в том, что премия отражается тем периодом когда она должна отражаться в НУ. Минусы - то что происходит искажение показателя "изм.стоимости подлежащее льготе" и "изм.стоимости не подлежащее льготе", но об этом отдельно в другой проблеме. В этой проблеме данный случай не рассматривается.Добавлена настройка "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Настройка операций Амортизация Производить расчет суммы изменения стоимости и износа в операциях изменения стоимости" По ней производится расчет по всем операциям изменения стоимости текущего периода. Рассчитанные суммы записываются в таблицу // таблица изменения стоимости ОС(НМА) для расчета амортизации Table struct mtIzmStoim ( cKatOS : comp //ссылка на KatOS , cNastrOS : comp //ссылка на NastrOS , dOper : date //дата операции , Kol : double //количество объектов карточки , IzmStoim : double // сумма Изменения стоимости, подлежащее учету в текущем периоде , IzmSumIzn : double // сумма изменения износа, подлежащее учету в текущем периоде , IzmStoimNo : double // сумма Изменения стоимости, не подлежащее учету в текущем периоде , IzmSumIznNo : double // сумма изменения износа, не подлежащее учету в текущем периоде ) with index ( Index1 = cKatOs + cNastrOs + dOper ); В операции должно быть выбрано основание операции. Введен системный тип основания для операций изменения стоимости и износа "корректировка". Для всех типов оснований добавлен параметр: - "Учитывать изменения стоимости и износа" = в текущем периоде/в следующем периоде В таблицу попадают только операции текущего периода. Таблица доступна в алгоритмах расчета амортизации.
180.79688.10.25.0необходима возможность формирования Ведомости аморт льгот по периоду признания льготыУправление недвижимостьюВедение картотеки ОС
Перед нами наш крупный клиент Азот поставил опять сложную задачу, в решении которой я хотела бы обратиться к вам за помощью. Необходимо сверить данные за отчетный месяц по бух.проводкам и по оперативным данным по амортизационной льготе по карточкам ОС. Для получения данных по БУ мы используем интерактивный отчет и выбираем проводки по аморт. льготе, например, за декабрь 2013 г. Проблема при формировании отчета по Картотеки ОС - Печать - Ведомость аморт. льгот. На предприятии существуют следующие ситуации: 1. поступили карточки ОС в ноябре, но по законодательству признана аморт. льгота должна быть только в декабре 2013 (в следующем периоде). 2. поступление карточки ОС в декабре но по законодательству признана аморт. льгота должна быть только в январе 2013 (в следующем периоде). 3. модернизация в ноябре 2013. По законодательству необходимо принимать к учету аморт.льготу в месяце операции, т.е. в ноябре 2013 г. 4. модернизация в декабре 2013. По законодательству необходимо принимать к учету аморт.льготу в месяце операции, т.е. в декабре 2013 г. Проводки мы настраиваем только за декабрь 2013г. Таким образом в отчет по аморт. льготам для сверки должны попасть только п. 1 и п. 4. Если же формировать Ведомость аморт.льгот за период "декабрь 2013", то выберутся только операции, проведенные в декабре 2013 (не попадают данные из п.1.) Если указать период ноябрь - декабрь 2013г., то тогда попадают лишние операции модернизации ноября, т.к. в проводки уже были сформированы в ноябре 2013г. Необходима возможность настройки отчета таким образом, чтобы система анализировала дату операции и период признания этой льготы по операции. А именно, если указать декабрь, то чтобы анализировались операции предыдущего месяца (ноября), если в Основании операции стоит " льгота в следующем периоде", а с Основанием "льгота в текущем периоде" - не попадали в отчет за декабрь 2013. На данный момент я не смогла найти возможность такой настройки. Необходимо добавить какой-то переключатель, типа с учетом периода признания и без учета периода признания. Пока приходиться вручную из отчета за ноябрь-декабрь 2013 г. убирать карточки ОС, по которым была модернизация в ноябре 2013 и вручную их вычеркивать. Это очень трудоемко на картотеке ОС, в которой порядка 80 000 карточек, очень частые модернизации с льготами и много постпулений ОС (все с аморт льготами). Прошу оказать помощь для совместного выхода из сложившейся ситуации!В отчет добавлен параметр "С учетом периода признания амортизационной льготы". Если он имеет значение ДА, то : - дату начала поиска операций уменьшаем на период (месяц). - если учет льготы в следующем месяце - к дате проведения операции добавляем месяц. Получаем дату признания льготы и проверяем чтобы она попала в период отчета.
180.76088.10.24.0Проверка алгоритма в момент исполнения - указывает не на ту строкуУчет ОСКаталог алгоритмов начисления амортизации
1) Настроил алгоритм амортизации (во вложении). 2) Запустил пункт локального меню в окне редактирования алгоритма амортизации "Проверка корректности алгоритма". 3) Система выдала - Алгоритм расчета корректен. 4) Закрепляю алгоритм в карточке ОС. 5) Нажимаю Alt+S для тестового просчета амортизации - получаю сообщение (см. вложение): --------------------------- Предупреждение --------------------------- Алгоритм расчета амортизации некорректен №п/п: 1 Ключ: &STOIMM Формула: IF(ISVALIDALL(TNARCIZNOS), ARCIZNOS.STOIM, SPKATOS.STOIM) --------------------------- ОК --------------------------- 6) Попробовал взять содержимое ключа &STOIMM и подставить его в поле "Алгоритм" в шапке алгоритма. Запустил тестовый расчет. Сообщений об ошибке нет. Очевидно что само это выражение правильное. 7) Методом тыка нашел, что проблема не в ключе &STOIMM, а в ключе &CorrIznos = if(isValidAll(tnSpMoveOsCorAmort) and (SpMoveCorAmort.Proved=1), SpMoveOsCorAmort.NewSumIzn, 0) Если его заменить на 0, то сообщение об ошибке пропадает. Отсюда две проблемы: 1. Почему проверка из контекстного меню говорит что алгоритм корректен, если при его выполнении оказывается, что он некорректен. Значит какая-то из проверок работает неверно. Нужно исправлять. 2. Сообщение об ошибке указывает на то что некорректен первый ключ среди всех ключей, в то время как некорректность вовсе не в этом ключе. Значит сообщение системы проверки алгоритма генерится неверно. Нужно исправлять.Теперь проверка алгоритма в момент исполнения - указывает на строку в которой обнаружена ошибка.
180.71208.10.22.1Реализовать возможность ввода справок по начислениям процентов кредитовВекселя и кредитыПолученные кредиты
Необходимо, что бы аналогично векселям была возможность ввести справку по начислениям процентов по кредитам, так как независимо от погашения процентов по кредитам начисление их мы должны производить ежемесячно за период 01 числа по последнее число месяца, тогда как многие банки требуют погашение с 26 по 25 число. Поэтому по таким кредитам всегда возникает задолженность на начало следующего месяца по % за 26-31 числа, есть даже договор, по которому проценты гасятся один раз. Под "ввести справку" имеется ввиду необходимость функционала по аналогии с векселями: Модуль "Векселя и кредиты" - Векселя - Бухгалтерские справки по начисления процентов. Нужна возможность формирования проводок.В модуле "Векселя и кредиты" в раздел меню "Кредиты" добавлены новые документы "Справка по начислению процентов по выданным кредитам" (тип 1089) и "Справка по начислению процентов по полученным кредитам" (тип 1090). Также в раздел меню "Настройка" для этих документов добавлена настройка каталогов статусов и каталогов алгоритмов начисления процентов. В модуле "Хозоперации" в меню в раздел "Векселя и кредиты" добавлены справки по начислению процентов по выданным/полученным кредитам. На справки распространяют свое действие следующие настройки: - "Настройки Галактики Общие настройки системы Доступ к документам"; - "Настройки Галактики Бухгалтерский контур Обработка документов Разрешить модификацию справок по векселям при наличии проводок"; - "Настройки Галактики Бухгалтерский контур Типовые проводки Доступ к формированию проводок"; - "Настройки Галактики Бухгалтерский контур Векселя и кредиты Налоговые справки Сохранять историю статусов"; - "Настройки Галактики Бухгалтерский контур Векселя и кредиты Налоговые справки Способ нумерации справок"; - "Настройки Галактики Бухгалтерский контур Векселя и кредиты Налоговые справки Автонумерация справок". Так же как и для других справок, в алгоритмах начисления процентов по выданным/полученным кредитам можно использовать поля следующих таблиц: AppVeks - справка, SpApp - спецификация справки, Veksl - карточка кредита, KatKlass - условия погашения кредита, ReFinPol - ставка рефинансирования на дату выдачи кредита (Veksl.DatVip), ReFinV - ставка рефинансирования на дату погашения кредита (Veksl.DatOb). Если алгоритм начисления процентов не задан, то сумма процентов рассчитывается как сумма этапов план-графика погашения кредита, попадающих в период формирования справки, с типом "проценты по кредиту".
102.1168848.10.22.0Необходима Величина корректировки амортизацииУчет ОСАмортизация
Необходимо в алгоритмы расчета вытягивать Величину корректировки амортизации. Рассмотрим пример: У клиента используется алгоритм расчета амортизации "от остаточной стоимости". Сейчас май 2012 года. В этом же месяце клиент проводит операцию корректировки амортизации (на какую величину надо увеличить/уменьшить начисленную до 01/05/2012 амортизацию). Например, величина корректировки амортизации составляет 100 руб, т.е. на 01/05/2012 остаточная стоимость должна была быть на 100 руб меньше, чем сейчас в архиве. Поэтому, чтобы верно посчитать амортизацию за текущий месяц (май), клиенту надо в алгоритме начисления амортизации от остаточной стоимости учесть величину корректировки амортизации.ДОРАБОТАНО. Величина корректировки амортизации хранится в поле SpMoveOsCorAmort.NewSumIzn. SpMoveOsCorAmort это синоним SpMoveOs. SpMoveCorAmort синоним SpMove. Подцеплена таблица так and cgOs_51_Amort == SpMoveOSCorAmort.SysOper and KatOs.nRec == SpMoveOSCorAmort.cKatOS and NastrOs.nRec == SpMoveOSCorAmort.cNastrOS and KatOS.OtchPer == SpMoveOSCorAmort.DatOb and SpMoveOSCorAmort.cSpMove == SpMoveCorAmort.NRec В алгоритме расчета амортизации вытащить величину корректировки можно так if (not isValidAll(tnSpMoveOsCorAmort), 0, if (SpMoveCorAmort.Proved=0, 0, SpMoveOsCorAmort.NewSumIzn)) (SpMoveCorAmort.Proved=1) - проверка, что операция корректировки амортизации проведена.
180.70768.10.22.0Не переводить в верхний регистр наименования ключей алгоритмаУчет ОСКаталог алгоритмов начисления амортизации
Наименования ключей в алгоритмах расчета амортизации стали переводиться в верхний регистр. При сложной структуре наименований это сильно снижает читаемость, например SumIznMetChng - сумма износа на момент смены метода начисления амортизации. SUMIZNMETCHNG - нечитаемо по сравнению с вышеприведенным примером. Считаю что следует оставлять наименования ключей как есть, а преобразовывать их к верхнему регистру, если это нужно движку расчета непосредственно в ходе расчета амортизации. хранить при этом оригинальный вариант наименования ключа.Не переводятся в верхний регистр наименования ключей алгоритма.
102.714128.10.19.0ToolBar для импорта-экспортаКонтуры: финансовый, бухгалтерского учетаF_Common [Общая функциональность финансового контура]
ToolBar для импорта-экспорта каталога алгоритмов начисления амортизации (переоценки)На ToolBar интерфейса алгоритма расчета добавлены кнопки: 1. Экспор Данных (Alt+O) 2. Импорт Данных (Alt+I) 3. Протоколы Экспорта-импорта данных (Alt+H) Соответствующие пункты добавлены в локальное меню. по умолчанию импорт экспорт проходит в файл C:TEMPCalcAlgam.xml В модуле Обмен Бизнес-документами для импорта-экспорта доступны: Алгоритмы амортизации ОС Алгоритмы амортизации НМА Алгоритмы расчёта разности данных по ОС Алгоритмы расчёта разности данных по НМА Алгоритмы переоценки ОС Алгоритмы коэф. пересчета срока исчерпания эксплуатац. ресурсов Алгоритмы расчета суммы начисляемого износа по МБП Алгоритмы амортизации налоговых групп
102.1012638.10.18.0Нужна возможность заполнения поля Вклад в уставный капитал закладке Аморт льготаУчет ОСВедение картотеки
Нужна возможность отдельного заполнения поля Вклад в уставный капитал в закладке Аморт льгота карточки ОС и описания его в алгоритме начисления.Реализовано для России. (Для остальных регионов - добавлен атрибут) Реализована возможность отдельного заполнения поля Вклад в уставный капитал в операции "изменение стоимости", значение которого в последствии отображается на закладке Аморт.льгота карточки ОС и доступно в алгоритме начисления амортизации. Реализованный механизм: Для позиции спецификации операций добавлен внешний атрибут "Вклад в уставный капитал", которому присваивается необходимое значение Для данного атрибута учитываются только те значения, которые заданы в операциях "Поступление", "Изменение стоимости", "Выбытие". - В операции "изменение стоимости" для позиции спецификации выбирается внешний атрибут "Вклад в уставный капитал", которому присваивается необходимое значение. - Во временной таблице, используемой для описания алгоритмов (OperIzmStoim) добавлено поле SumInCapital - вклад в уставный капитал. - в окне редактирования ИК на вкладке "Амортизационная льгота" добавлена колонка "Вклад в уставный капитал".
180.28278.10.18.0Нужен архив по изменению ликвидационной стоимостиУчет ОСВедение картотеки
В инвентарную карточку основного средства заносится сумма ликвидационной стоимости, значение которой используется в алгоритме начисления амортизации ((SPKATOS.STOIM - SPKATOS.STOIML)*VIDNORMA.NORMA) /100*12. По карточке проводим операцию по переоценке соответственно изменяем ликвидационную стоимость вручную. Если возвращаемся на предыдущий месяц и рассчитываем износ, то износ рассчитывается от новой суммы ликвидационной стоимости, тем самым нарушается корректность информации. Что бы избежать этой проблемы необходим архив изменений по ликвидационной стоимости.Для операций "Изменение стоимости", "Переоценка", "Изменение параметров": - добавлен параметр "Ликвидационная стоимость" на вкладке "Изменяемые парамеры" - добавлен параметр "Ликвидационная стоимость" в окне редактирования "Именяемых парамеров по шаблону", При этом: - если значение данного параметра задано суммой (ненулевое), то данное значение будет перенесено в операцию. - в расширенном окне можно задать алгоритм расчета значения данного параметра, при переносе в операцию. (таблицы которые могут быть реально задействованные при расчете: KatOS, SpKatOS, MoveOS, SpMove, SpMoveOS) Для стоимостных характеристик реализована возможность редактирования новых значений для всех ИК из операции. Пункт локального меню "Значения параметра для всех ИК операции" (Ведение архива не реализовывалось, т.к. требует изменение словаря)
180.51078.10.18.0При копировании алгоритма амортизац делать приписку в наимен.Учет ОСИзменение параметров
При копировании алгоритма амортизации необходимо делать приписку в его наименовании в скопированном экземпляре, иначе визуально исходный алгоритм и его копию сложно различить, и можно сильно наредактировать не в том алгоритме.При копировании алгоритма в наименовании вновь созданной копии экземпляре (в начале) добавляется префикс "[Копия #<N>]". Если алгоритм является копией основного алгоритма, т.е. наименование начинается с "[Копия #<N>]", то при копировании данного алгоритма наименование будет иметь вид: "[Копия #<N+1>]"<наименование первоисточника>
102.1008468.10.17.0Реструктуризация состава обновленийКонтуры: финансовый, бухгалтерского учетаF_Alg [Настраиваемые расчетные алгоритмы]
В связи с дублированием файлов каталога DOC в составе компонент F_OS и F_Alg, и уже выпущенной обновлённой версией данных файлов в обновлении F_OS_RES_810360, предлагается удалить из состава обновления F_Alg_810170 каталог DOC и в требованиях компонент для этой проблемы указать F_OS_RES_810360.Из состава обновления удалены файлы "Dopolnitelnaya_documentacia.doc", "TestMem.vih", "TestMem.VIP", и добавлено требование компонента F_OS_RES_810360. Т.к. указанные файлы присутствуют, в том же виде, в обновлениях компонента F_OS.
102.988928.10.17.0Необходим алгоритм в методике списания СФО. (Туликова Ирина)СпецодеждаЛичная карточка спецодежды
Необходимо добавить возможность использовать в алгоритмах начисления износа срок из нормы, по которой выдана спецодежда.В алгоритмах начисления износа на спецодежду можно использовать поля: 1) IznMetodVar.isByNorm - признак того, что предмет выдан по норме; 2) IznMetodVar.NormSrok - срок службы из нормы, по которой выдан предмет.
101.405918.10.16.0Начисление амортизации по остаточной стоимостиСпецодеждаНе знаю, какая именно часть модуля "Спецодежда", научите
Существует данная проблема. Начальник должен костюм носить реже, чем обычный работник, поэтому и срок эксплуатации у одного и того же костюма различный. По поводу сдачи спецодежды и получения заново. Сдали спецодежду (за несколько месяцев была начислена амортизация). В карточке отображается сколько составил износ. Затем этот же костюм выдали вновь этому же сотруднику, но на новый срок эксплуатации. Когда начинаем считать амортизацию по этому костюму (вновь выданному), она должна считаться от остаточной стоимости (так как часть суммы этого костюма уже была списана на затраты), но считается от первоначальной стоимости.Предполагается, что для начисления амортизации от остаточной стоимости пользователи будут пользоваться алгоритмами. Для этого добавлена возможность использовать в алгоритмах поля таблицы MBPInExpl (синоним таблицы MBPIn). Таблица MBPInExpl спозиционирована на приходную операцию, которой был введен в эксплуатацию текущий предмет (текущая запись таблицы MBPIn). Таблицы MBPInExpl и MBPIn могут быть спозиционированы как на одну и ту же запись, так и на разные (в случае проведения операций внутреннего перемещения, переоценки и т.д. после ввода в эксплуатацию). Перед тем, как воспользоваться в алгоритме полями таблицы MBPInExpl, необходимо проверить с помощью функции ISVALIDNEW(tnMBPInExpl), найден ли приход, которым предмет был введен в эксплуатацию. Таблица MBPInExpl может быть спозиционирована на приходные операции четырех типов: - Просто поступление (MBPInExpl.InState = 1); - Поступление со склада МЦ (MBPInExpl.InState = 3); - Ввод в эксплуатацию (MBPInExpl.InState = 4); - Оприходование излишка (MBPInExpl.InState = 9). Для получения % износа предмета на момент ввода его в эксплуатацию можно использовать поле MBPInExpl.PercDoc для прихода с типом 4 ("Ввод в эксплуатацию") или поле MBPInExpl.PercNach для остальных приходов.
102.900838.10.15.0KatMBP в алгоритмы начисления износа по спецоснасткеУчет спецоборудования и спецоснасткиВедомость начисления износа
Добавить возможность использовать поля таблицы KatMBP в алгоритмах начисления износа по спецоснастке/СФО.Доработано.
102.952048.10.15.0Необходимо доработать ал-тм нач-ия из-са и интерфейс Вед-сть начисления износаСпецодеждаРегламентное начисление износа
Необходимо доработать алгоритм начисления износа, добавив возможность использования кода нормы выдачи предмета, а также сделать отображение кода нормы, по которой выдавался предмет в интерфейсе "Ведомость начисления износа" в нижней панели.Если предмет спецодежды выдан по норме, то код этой нормы: - отображается в нижней панели окна редактирования Ведомости начисления износа; - хранится в поле IznMetodVar.NormKod при расчете износа по алгоритму.
180.41418.10.15.0двойная выдача спецодеждыСпецодеждаЛичная карточка спецодежды
Если работнику по норме положен один комплект одежды, но он не может его носить, не меняя, то ему выдается второй комплект сверх нормы, но срок носки обоих комплектов удваивается. Поэтому должна быть реализована возможность автоматического перерасчета срока службы предмета СФО при двойной выдаче. Выдача обоих комплектов СФО в общем случае не происходит одновременно. Сначала выдается один комплект по норме, в течении нескольких месяцев считается износ исходя из срока носки по норме. Затем выдается второй комплект СФО и вводится в эксплуатацию с этого же месяца. С месяца, следующего за выдачей второго комплекта, срок носки обоих комплектов удваивается. Общий срок службы первого комплекта равен: ОСС1=(ССдоВ2+1)+(ССН1-(ССдоВ2+1))*2, где ОСС1 - общий срок службы; ССдоВ2 - срок службы до выдачи второго комплекта; ССН - срок службы по норме. Общий срок службы второго комплекта, если не был выдан по истечении срока службы первого новый комплект, такой же. Дата окончания срока службы должна отражаться в отдельном поле спецификации интерфейса Личной карточки учета СФО (в носке). Необходимо обеспечить в Системе автоматический расчет износа предметов двойной выдачи. Если в носке у работника находится один предмет, износ его считается исходя из нормы. Если в носке оба предмета, то исходя из НОРМЫ*2. Далее приведен пример расчета амортизации при двойной выдаче. 1-ый костюм выдан в ноябре 2008 года стоимостью 2000 руб на 24 месяца 2-ой костюм выдан в феврале 2009 года стоимостью 3000 руб на 24 месяца До момента выдачи 2-го комплекта (в течении 3-х месяцев) амортизация 1-го считается от 24 месяцев и срок носки 24 месяца. При выдаче 2-го костюма срок носки 1-го костюма увеличивается до 24*2-3=45 месяцев (3 месяца 1-ый костюм был в эксплуатации до выдачи 2-го костюма), срок окончания носки становится август 2012, амортизация 1-го костюма считается от удвоенного срока 24*2=48 месяцев. Или увеличенный срок носки можно рассчитать по-другому: (24-3)*2+3=45, т.е 42 месяца костюмы будут носиться одновременно. Срок носки 2-го костюма тоже увеличивается до 45 месяцев (24+21=45) и заканчивается в ноябре 2012, амортизация 2-го костюма считается от удвоенного срока 24*2=48 месяцев. Срок носки (кол-во месяцев от даты выдачи до даты окончания носки) и кол-во месяцев, от которых рассчитается амортизация, для двойной спецодежды разные. В данном примере амортизация рассчитывается от 48 месяцев, а срок носки 45 месяцев.Добавлена системная настройка "Настройки Галактики - Бухгалтерский контур - Спецодежда - Ведется учет двойных выдач спецодежды", которая может принимать следующие значения: "нет" (по умолчанию) и "да". Если она установлена в значение "нет", то все работает как сейчас. Если она установлена в значение "да", то в в справочнике норм для спецификаций ненакопительных норм, по которым количество больше 1, а срок не равен значениям "Разовая" или "До износа", можно установить параметр "Двойная выдача". Для предметов, выданных по спецификациям нормы с параметром "Двойная выдача", особым образом рассчитываются срок носки и дата окончания сроков носки. В алгоритмах начисления износа на спецоснастку/спецодежду доступны для использования следующие переменные: IznMetodVar.onDate - дата, на которую осуществляется расчет суммы износа; IznMetodVar.isPersSFO = true, если в ЛК учета СФО есть запись о выдаче предметов работнику (таблица PersSFO), связанная с текущим приходом; IznMetodVar.Srok = PersSFO.Srok (если IznMetodVar.isPersSFO = false, то 0); IznMetodVar.isDblGive = true, если предметы выданы по спецификации нормы, для которой установлен параметр "Двойная выдача"; IznMetodVar.DblKoef - количество предметов в носке на дату расчета суммы износа, включая предметы из текущего прихода (если IznMetodVar.isDblGive = false, то 0). В ЛК учета СФО в поле "Срок" отображается срок носки предметов, полученный как кол-во_предметов * срок_службы_одного_предмета. При выдаче очередного предмета одежды срок не изменяется, но увеличивается дата окончания срока носки предметов. Примечания: 1. Чтобы функционал работал, необходимо чтобы настройка "Настройки Галактики - Бухгалтерский контур - Спецодежда - Срок использования в справочнике норм указывается" была установлена в значение "на все количество". 2. При работе с двойными выдачами нельзя пользоваться функционалом приостановок сроков носки. 3. В модуле "Вещевое имущество" не рекомендуется указывать фурнитуру для спецификаций с установленным параметром "Двойная выдача".
102.933708.10.14.0Восстановление амортизационной льготыУчет ОСВыбытие
Восстановление амортизационной льготы. По налоговому кодексу с 1 января 2008 года , если ОС в налоговом учете выбывает в течении 5 лет после ввода в эксплуатацию, и по нему была начислена амортизационная премия, то эту премию необходимо восстановить для расчета налога на прибыль. В карточках ОС на вкладке "Амортизационная льгота" эти данные отсутствуют.Для страны РФ в операции выбытия добавлено поле "Восстановление амортизационной премии". При нажатии F3 осуществляется расчет амортизационной льготы подлежащей восстановлению. Значение данного поля доступно в алгоритмах ТХО операции выбытия: параметр "Восстановленная льгота" Данное поле так же отображается на закладке "Амортизационная льгота" из картотеки ИК
102.849928.10.13.0Необходимо учитывать скорректированную разницу в этой же операцииУчет ОСПредложения по новой функциональности модуля "Основные средства"
При выполнении операции КОРРЕКТИРОВКИ РАЗНИЦ необходимо учитывать скорректированную разницу в этой же операции. Пример. Алгоритм расчета постоянной разницы (ПР) следующий: Стоимость по БУ - Стоимость по НУ - сумма рассчитанной ПР на начало отч. периода и все поделить на остат. срок полезн. использования. Когда идет корректировка за один месяц (любой) расчет верный. Но стоит выбрать период - два и более месяцев для корректировки разниц, то расчет неверный. Проверяя, откуда программа получает неверную сумму, получаю, что если в формуле сумму рассчитанной ПР на начало отч. периода (функция OSRAZNCURR.PR) за второй месяц перерасчета брать так, как она храниться в карточке, то я получу то же, что и программа. Но ведь первый месяц перерасчета изменил общую сумму ПР, т.е. функция OSRAZNCURR.PR должна это учитывать. Получается, что параметр "Учитывать операции корректировки разниц", если он должен менять в том числе и сумму OSRAZNCURR.PR не работает.Для операции корректировка разниц за период при перерасчете разниц "текущего периода" учитываются перерассчитанные разницы "предыдущего" периода.
102.875958.10.13.0Сложность при вычислении разниц при определенном условииУчет ОСАмортизация
При расчете разниц получаем в алгоритме результат деления меньше 0,02 например (замечено по локализации проблемы от клиента, об однозначности именно этой цифры утверждать не могу), то результат вычислений в алгоритме принимается как равный нулю, далее расчет не идет. Вручную суммы, сколь угодно малые в разницах поставить можно и они сохраняются в соответствующих полях. Дело либо в результате деления или в большой стоимости, которая и есть делитель. У клиента стоимости десятизначные. Сейчас вышли из ситуации, используя вариант следующий: стоимость делим на 100, результат деления на стоиомсть умножаем на 100, но предусмотреть возникновение таких проблем во всех случаях невозможно, просьба рассмотреть вложенный пример на цифрах и исключить анализ малых сумм при делении. Настройка округления алгоритма для расчета разниц - не использовать.При вычислении значений по формулам алгоритма убрано отсечение нулевой дробной части до целого цисла для значений больше 2147483647 или меньше -2147483648. Внимание(!) В алгоритмах расчета амортизации/разниц настоятельно не рекомендуется явным образом прописывать большие ЦЕЛЫЕ величины больше 2147483647 (или меньше -2147483648), т.к. результаты вычислений могут оказаться неверными.
102.895688.10.13.0Учет ОС Каталог алгоритмов начисления амортизацииУчет ОСКаталог алгоритмов начисления амортизации
Учет ОС Каталог алгоритмов начисления амортизации Для написания Алгоритма начисления постоянной разницы добавить таблицу VIDNORMA в интерфейс "Выбор переменной алгоритма".Добавлена таблица VIDNORMA в интерфейс "Выбор переменной алгоритма" Для написания Алгоритмов по разницам описаны синонимы таблицы VIDNORMA для бухгалтеского метода учета VIDNORMABUH для налогового метода - VIDNORMANAL.
102.885108.10.11.1Утечка памяти при расчете скриптов в алгоритмах ОСУчет ОСАмортизация
Утечка памяти при расчете скриптов в алгоритмах ОС при большом количестве вызовов расчета скриптовУстранена утечка памяти при расчете скриптов в алгоритмах ОС при большом количестве вызовов расчета скриптов Исключена повторная компиляция скриптов
102.887328.10.11.1Доработать функцию "Проверка" для скриптов на платформе Oracle.Учет ОСКаталог алгоритмов начисления амортизации
Доработать функцию "Проверка" для скриптов на платформе Oracle. На текущий момент данная функция всегда выдает: --------------------------- Предупреждение --------------------------- Ожидалось: "Begin" или сразу "End" --------------------------- ОКУстранены проблемы с компиляцией скриптов на платформе Oracle.
102.832828.10.11.0Скрипты в алгоритмах расчетаУчет ОСДругие интерфейсы по ОС
Необходимо добавить возможность использования скриптов vip4app в алгоритмах расчета.В каталоге алгоритмов добавлена возможность использования скриптов vip4app. СКРИПТЫ доступны для алгоритмов: 1. амортизация ОС 2. амортизация НМА 3. расчёт разности данных по ОС 4. расчёт разности данных по НМА 5. переоценка ОС 1. В окне редактирования алгоритма добавлено поле "Использовать скрипт" 2. В случае установки "Да" в данном поле строчный формульный редактор заменяется на мемо-редактор скрипта 3.Скрипт имеет синтаксис: [<описание_переменных>] [<описание_вложенных_процедур_и_функций>] ["Begin"] [<Тело_скрипта>] ["End."] 3.1. В теле скрипта доступны блоки begin-end; var; for, while; if..else; case; exit, break, continue и стандартные операторы, доступные в языке VIP. При задании идентификаторов внутри скрипта допустимо использование русских букв. Описание переменных также допустимо и между блоками begin-end 3.2. Результат скрипта возвращает переменная Result:Double 4. Для скриптов остаются доступными поля таблиц, которые подставляются мастером, вызываемым по F3 5. Для проверки корректности алгоритма можно воспользоваться комбинацией Ctrl-F9 или пунктом "Проверка" из выпадающего меню редактора. 6. В печатных формах FastReport выводится информация о скрипте, в случае его использования Пример Расчета алгоритма амортизации для инвентарной карточки: var TmpRes:Double; function StoimToSrok(coef:double):double; { // первоначальная стоимость разделить на срок использования // умножить на Коэффициент coef result:=coef*(SPKATOS.STOIM/SPKATOS.SROKISP); } begin TmpRes:=StoimToSrok(0.1); result:=TmpRes; end. Внимание! 1. При создании алгоритмов на скрипт необходимо избегать совпадения наименования объявленных переменных и наименования таблиц, полей таблиц. Наименования переменных должны быть уникальны! 2. Вместо функции при написании скрипта: function Date (day : byte; month : byte; year : word) : date; необходимо использовать функцию: function To_Date (day : byte; month : byte; year : word) : date; В составе обновления, в каталоге DOC, вложены файлы с описанием и примером использования скриптов: 1.Dopolnitelnaya_documentacia.doc 2.TestMem.vih 3.TestMem.vip
101.412368.10.10.0Сообщение при печати алгоритмаУчет ОСДругие вопросы по ОС
Jшибка при печати параметров алгоритма при установленном параметре "Анализ остаточной стоимости в архиве на ноль" = НЕТИспралена ошибка при печати параметров алгоритма при установленном параметре "Анализ остаточной стоимости в архиве на ноль" = НЕТ
101.410778.10.9.0Изменение ставки амортизационной льготы до 30% с 01/01/2009Учет ОСАмортизация
Законом 224-ФЗ введены изменения в гл. 25 НК РФ. В частности, с 01.01.2009 года предусмотрено увеличение амортизационной премии при приобретении либо создании основных средств, а также в случае достройки, дооборудования, реконструкции, модернизации, технического перевооружения, относящихся к третьей-седьмой амортизационным группам до 30%. По остальным ОС размер амортизационной премии остался прежним. В связи с этим возникла проблема при настройке алгоритмов расчета амортизации.Доработано Во временной таблице OperIznStoim добавлено поле накопленная величина изменения стоимости подлежащая амортизационной льготе с 01.01.2009 Sum2From01012009, которое м.б. использовано в алгоритмах расчета амортизации (разниц) согласно Закона 224-ФЗ введены изменения в гл. 25 НК РФ (в поле SUM2 рассчитывается накопленная величина изменения стоимости подлежащая амортизационной льготе за весь период)
102.803008.10.8.0Позиционирование на нужную записьУчет ОСВедение картотеки
При просмотре алгоритма через инвентарную карточку в открывающемся по F3 интерфейсе " Каталог алгоритмов начисления амортизации" курсор должен устанавливаться именно на том алгоритме, который задан в карточке. Нужно доработать функционал для тех алгоритмов начисления амортизации, которые входят в состав группы (иерархическая структура - алгоритмы являются "листиками дерева"). Это касается как Каталога алгоритмов начисления амортизации, так и Каталога алгоритмов расчета разниц данных по методам учета.При просмотре алгоритма через инвентарную карточку в открывающемся по F3 интерфейсе " Каталог алгоритмов начисления амортизации" курсор устанавливаться именно на том алгоритме, который задан в карточке.
102.806618.10.8.0Некорректно отрабатывает проверка каталога алгоритмов расчетовУчет ОСПроверка целостности таблиц
Некорректно отрабатывает проверка каталога алгоритмов расчетовИсправлены некорректные предупреждения при проверке корректности каталога алгоритмов расчета На корректность проверяются только те алгоритмы, ключи которых используются для вычисления окончательного результата.
101.388848.10.6.0Таблица алгоритмов ОСУчет ОСЗаполнение каталогов
После расчета разниц налогового учета обнаружено, что не работают "ключи" в главном алгоритме. Предположительно, проблема в таблице алгоритмов, возможно, она не корректна из-за репликации.Реализована фунция проверки корректности алгоритмов расчета, которая запускается: - из справочника алгоритмов (в данном случае проверяется корректность алгоритмов для заданного типа документов, т.е., н-р, алгоритмы расчета амортизации ОС при вызове функции локального меню "Проверка корректности алгоритмов расчета" из справочника "Каталог алгоритмов начисления амортизации") - из меню ... Проверка целостности таблиц -> Проверка корректности алгоритмов расчета (в данном случае проверяется корректность всех алгоритмов описанных в системе и хранящихся в таблицах OsAlg, OsSpAlg) Кроме того, внезависимости от места запуска, выполняется проверка наличия отвязанных записей описания алгоритмов расчета при установленном параметре "исправлять" данные записи будут удалены !!!).
102.757548.10.6.0Некорректные предупреждения при редактировании алгоритма расчетаУчет ОСЗаполнение каталогов
При добавлении новой записи в каталог алгоритмов расчета амортизации выдается ошибочное предупреждение о некорректности одной из строк описания алгоритма "Алгоритм &<N> некорректен".При редактировании алгоритма расчета амортизации устранено ошибочное предупреждение о некорректности одной из строк описания алгоритма "Алгоритм &<N> некорректен".
102.780048.10.6.0Необходимо разработать дополнительный универсальный алгоритм расчета амортизацУчет ОСАмортизация
Необходимо разработать дополнительный универсальный алгоритм расчета амортизации Привожу выдержки из письма клиента + прикладываю файл с постановлением: На основании этого письма делаю расчет амортизации в том же месяце, в котором была операция изм. первоначальной стоимости (произведена модернизация изношенного ОС). Для этого настраиваю алгоритм: применение алгоритма - с учетом дополнительных параметров; расчет от даты - не анализировать. Все работает, пока не возникнет ситуация, когда до изм. стоим. остаточная стоимость была равна 0, а потом добавилась стоимость амортизации. В этом случае приходится применять другой алгоритм с настройкой: применение алгоритма - всегда. Более того в следующем месяце этот алгоритм надо перевыбрать, иначе не будут анализироваться дополнительные параметры. Постоянный перевыбор алгоритмов крайне затрудняет работу пользователей с модулем, приводит к ошибкам.В каталоге "Алгоритмы расчета амортизации" в окне редактирования добавлен новый параметр: "Анализ остаточной стоимости в архиве на ноль" = [ДА/нет], который доступен при значении параметра "Применение алгоритма" = [с учетом дополнительных параметров]. Если значение параметра "Анализ остаточной стоимости в архиве на ноль" = [нет], то при расчете амортизации не контролируется полный износ на начало периода расчета.
102.741538.10.5.0Ошибочное предупреждениеУчет ОСЗаполнение каталогов
При редактирование алгоритма в каталоге алгоритмов начисления амортизации, если алгоритм начинается с &, то выдается ошибочное предупреждение: "Не найден ключ &RES."Если основной алгоритм начинается с "&..." и в шапке описания алгоритма что-то изменено, то при переходе в нижнию панель сообщение об ошибке не выдается.
102.744608.10.5.0Нельзя удалить алгоритм из Каталога алгоритмов расчета разниц данных по мет. уУчет ОСНастройка шаблона имущественного номера
Нельзя удалить алгоритм из Каталога алгоритмов расчета разниц данных по методам учета.Исправлено.
102.746488.10.5.0Нужен контроль длины алгоритма при расчете разницы данныхУчет НМАВедение картотеки
Нужен контроль длины строк, в которых содержатся как алгоритмы, так и результаты их вычислений, в алгоритмах для расчета разниц данных по методам учета, как это сделано для алгоритмов расчета амортизации. С выходом пакета GAL_P_02(ПИР 102.73956), в котором отрицательные числа, получаемые как результат вычисления одного из фрагментов алгоритма расчета,берутся в круглые скобки, возрастает вероятность превышения длины строки более 255 символовДоработан контроль длины алгоритма при расчете разницы данных. Так если при расчете разницы по заданному алгоритму произошло превышение длины строки (более 255 символов) при подставновке вычисленных значений в формулу для расчета, то будет выдано соответствующее сообщение.
101.380708.10.4.1Сумма изменений, не подлежащая льготе при расчете разниц данныхУчет ОСДругие вопросы по ОС
Для расчета разниц по методам учета ОС нужна функция, вычисляющая сумму изменения стоимости не подлежащую амортизационной льготе за ТЕКУЩИЙ период.Доработана возможность использования величин подлежащих/не подлежащих амортизационной льготе в описании алгоритмов расчета разниц. Где, OperIzmStoimBuh - синоним таблицы с данными для бухгалтерского метода учета OperIzmStoimNal - синоним таблицы с данными для налогового метода учета Поля актуальные для использования в описании алгоритмов: Sum1 : double //величина подлежащая амортизационной льготе для проведения амортизации текущего отчетного периода Sum1_1 : double //сумма изменения стоимости за предыдущий период для основания с признаком "учитывать в следующем отчетном периоде" Sum2 : double //накопленная величина изменения стоимости подлежащая амортизационной льготе // значения задаваемые в операциях SumL : double //величина амортизационной льготы текущего отчетного периода SumL_Next: double //величина аморт.льготы за предыдущий период для основания с признаком "учитывать в следующем отчетном периоде" AllSumL : double //накопленная величина амортизационной льготы //--------------------------------------------------------------- Sum3 : double //накопленная величина изменения стоимости не подлежащая амортизационной льготе Sum4 : double //величина изменения стоимости не подлежащая амортизационной льготе текущего отчетного периода // значения задаваемые в операции "поступление" SumL_PS : double //величина амортизационной льготы из операции поступления текущего отчетного периода SumL_NextPS : double //величина аморт.льготы за предыдущий период для основания с признаком "учитывать в следующем отчетном периоде" текущего отчетного периода рекоммендуемая простейшая формула: if (IsValidNew(tnOperIzmStoimBuh),OperIzmStoimBuh.Sum1,0)
102.732288.10.3.0Функционал для работы с алгоритмамиУчет ОСЗаполнение каталогов
добавлены функции копирования, группового удаления, отчеты FastReport1. Реализованы функции копирования и вставки алгоритмов ОС. 2. Разработаны функции копирования и вставки алгоритмов из буфера. Соответствующие пункты добавлены в меню. Имя скопированного алгоритма имеет вид : <Имя скопированного алгоритма> = <Имя копируемого алгоритма > (копия <номер>). Комментарии в скопированные алгоритмы не переносятся. Вставка производится на текущей ветке дерева алгоритмов. Для интерфейса создан ToolBar содержащий пиктограммы «Копировать алгоритм в буфер», «Восстановить алгоритм из буфера», «Печать», «Переключение режима панели “список-иерархия”» 3. Разработана функция вставки в окне редактирования алгоритма. Соответствующий пункт добавлен в меню. Поле ключ заполняется в виде <ключ> = &<номер>. 4. Создана функция удаления группы помеченных алгоритмов. 5. Групповая пометка распространена на режим редактирования алгоритмов. 6. Функция удаления в случае попадания в пометку нетерминального узла дерева удаляет всю ветвь для сохранения ссылочной целостности. 7. Реализована группа отчетов для интерфейса выбора/редактирования алгоритмов расчета. 7.1. Разработан алгоритм печати древовидных структур в FastReport 3. Отчет «Дерево алгоритмов», отражает иерархическую структуру каталога алгоритмов. Отчет содержит алгоритмы для расчета и их спецификации. 7.2. Предусмотрена групповая пометка для вывода на печать только части алгоритмов. Отчеты «Каталог алгоритмов», «Параметры алгоритмов» строятся в зависимости от маркера пометки. 7.3. Создан отчет «Каталог алгоритмов (матричный)» для печати на мтричном принтере. 7.4. Создан отчет «Параметры алгоритмов», который формируется в зависимости от маркера пометки и типа алгоритмов. Отчет содержит алгоритмы для расчета, их параметры и спецификации.
102.658928.10.1.0перестали работать длинные алгоритмыУчет ОС?
В определенных случаях (ОИТ знает как проявить) при расете амортизации в окне редактирования ИК по Alt-S выдается сообщение "Алгоритм расчета амортизации некорректен". На самом деле все корректно и амортизация должна рассчитываться. Аналогичная ситуация и при расчете амортизации в операции "Амортизация", в протакол выводится сообщение "Алгоритм расчета амортизации некорректен"исправлено