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


Описание файла обновления:
ФайлF_OS_RES_810940.TXT
ОбновлениеF_OS_RES_810940
НазначениеОбщее
ПродуктГалактика 8.10
Релиз03.11.2006 : Atlantis 5.2.8
КомпонентF_OS
ТипRES
Версия8.10.94.0
Дата2017-02-01 15:09:40
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
180.94038.10.86.0Разработать функционал для ведения учета резерва на ликвидацию ОСУчет ОСПредложения по новой функциональности модуля "Основные средства"
Разработать функционал для ведения учета резерва на ликвидацию ОСДоработана обработка операции "Использование резерва" идентификатором &Vip_[Obj:"RESERV"].
102.1578248.10.90.0Не возможно использовать точку расширения epGetOborotOnAnalitOsУчет НМАВедение картотеки
Не возможно использовать точку расширения epGetOborotOnAnalitOs. Дело в том, что в точке расширения нужно наполнить таблицу в памяти tOborotSel, чтобы потом функционал отразил на основании этой таблицы закладку "Обороты". Непосредственно в точке расширения работать с данными нельзя, поэтому создаю объект, который наполняет таблицу в памяти tOborotSel с выборкой проводок. При выходе из точки расширения мой объект уничтожается, а вместе с ним и временная таблица tOborotSel, наполненная в моем объекте. В результате функционал KatOS видит пустую таблицу tOborotSel Пример вложен.Перенес описание таблицы tOborotSel перед интерфейсом KatOss. Т.е. теперь таблица принадлежит компоненте F_OS а не интерфейсу KatOss. Проверил на присланных исходниках, таблица не удаляется после отработки точки расширения.
102.1555068.10.87.0Потерялся отчет в формате FastReportУчет ОСВедение картотеки
Потерялся отчет в формате FastReport Печать реестра инвентарных карточек из картотекиВозвращен.
180.94518.10.85.2Внешние атрибуты к истории изменения источников финансирования не работают корректноУчет НМАИзменение параметров
В истории изменения источников финансирования для новых значений ИФ можно указать значения внешних атрибутов отличные от текущих значений внешних атрибутов для этих ИФ, однако при проведении операции новые значения внешних атрибутов не переносятся в текущее состояние закладки Финансирование. По логике реализованного функционала, должны переноситься. Не доделано. Аналогично при отмене операции должны восстанавливаться старые значения внешних атрибутов.Новые значения внешних атрибутов при проведении операции переносятся в текущее состояние закладки Финансирование. При отмене операции восстанавливаются старые значения внешних атрибутов.
180.94528.10.85.2Не возможно посмотреть внешние атрибуты к старым значениям источников финансирования в интерфейсе их измененияУчет НМАИзменение параметров
Для старых значений изменяемых источников финансирования(нижняя панель) есть пункт меню "Внешние атрибуты"(Alt+A), но он не работает и посмотреть старые значения внешних атрибутов нельзя посмотреть.Пункт меню "Внешние атрибуты"(Alt+A) - работает.
180.94548.10.85.2Реализовать интерфейс просмотра истории изменений по закладке ФинансированиеУчет НМАВедение картотеки
Есть механизм ввода истории изменений по закладке "Финансирование", однако изменения можно увидеть только в операциях, но собирать эту информацию по операциям, тем более не зная в каких операциях Финансирование менялось а в каких нет - очень неудобно. Нужен интерфейс просмотра истории изменений, где по конкретному ОС можно было бы увидеть всю историю по закладке Финансирование.В локальное меню закладки "Финансирование" картотеки ОС добавлена функция "Просмотр истории изменения ИФ", которазая запускает интерфейс отображающий изменения ИФ произведенных в операциях по текущей ИК. В верхней панели отображается список операций в которых изменялись ИФ (показаны Дата операции, номер операции и тип операции). Отсюда можно перейти к самой операции по кнопке "Редактировать[F4]". В нижней панели слева указываются ИФ ДО проведения операции, в нижней справа - ПОСЛЕ проведения.
180.94558.10.85.2Непродуктивное размножение записей в истории изменений закладки ФинансированиеУчет НМАИзменение параметров
В карточке ОС есть закладка финансирование. В новых операциях по этой карточке ОС сохраняется вид закладки "Финансирование" на момент ввода данной операции (StoimStruct.wType = 1500) не зависимо от того, входил ли пользователь в окно "Состав стоимости по источникам финансирования" в создаваемой операции или нет. Эти записи засоряют базу и возможно могут приветси ко всяким некорректным ситуациям функционала, который обрабатывает историю изменений по закладке финансирование, т.к. в операции фиксируется то состояние закладки, которое никто там фиксировать не хочет!В новых операциях по этой карточке ОС вид закладки "Финансирование" на момент ввода данной операции (StoimStruct.wType = 1500) сохраняется только если пользователь входил в окно "Состав стоимости по источникам финансирования" в создаваемой операции.
180.92738.10.85.0Отчет не видит сальдо по карточке ОС при установке сверки по аналитике "Подразделение"Учет ОСНовый диалог настройки
Отчетный период модуля Учет ОС - "январь 2016". Отчетный период бухгалтерского контура "октябрь 2015". Карточка ОС в периоде "январь 2016" По карточке ОС есть проводка Д 01 - Кт "сальдо" от 31.12.2015. Проводок по данному ОС ранее 31.12.2015 нет. Запускаю отчет сверка ОС и КБУ. Период с 01.01.2016 по 31.01.2016 Выбраны счета и метод учета, выбран фильтр по карточкам - выбрана одна карточка. Ставлю птицу "сравнивать аналитику", выбираю несколько аналитик, среди которых НЕ выбираю "Подразделение", затем снимаю птицу "сравнивать аналитику". Формирую. В отчете нет расхождений. Ставлю птицу "сравнивать аналитику", выбираю несколько аналитик, среди которых ВЫБИРАЮ "Подразделение", затем снимаю птицу "сравнивать аналитику". Формирую. В отчете расхождения по первоначальной стоимости и накопленному износу. ОШИБКА. Опция не активирована, а влияет на логику формирования отчета! Не понятно, даже если учитывать что опция сверки работает, то почему нет сальдо по БУ, т.к. подразделение в проводках по созданию остатка на 01 счете и в карточке совпадают!Исправлено. Сравнение ведется согласно выбранного параметра "Сравнивать аналитику".
180.94208.10.84.0Открыть поле Ликвидационная стоимость для НМАУчет НМАВедение картотеки
Нужно открыть поле @Ликвидационная стоимость" для НМА, это поле нам нужно для ведения "оценочной стоимости НМА. Эта величина доступна например в ТХО по НМА, в изменяемых параметрах в Учет НМА, т.е. нужно просто его открыть в карточке, больше ничего делать не нужно.Открылось поле "Ликвидационная cтоимость" для НМА.
102.1454178.10.83.0Доработка функционала для корректировки амортизацииКонтуры: финансовый, бухгалтерского учетаПредложение по новой фукциональности финансового контура
Доработка функциона.ла для корректировки амортизации. Разрешить формирование нескольких операций корректировки амортизации по одной ИК в одном отчетном периоде. Обеспечить обработку идентификатором OsNMA нескольких операций корректировки.В идентификаторе &Vip_[Obj:"OSNMA"] доработан параметра [Рез:КоррАморт] (РезультатАмортизация OC/НМАВеличина корректировки амортизации). Теперь он суммирует все корректировки по одной ИК в одном отчетном периоде.
102.1438038.10.82.0"Параметры бухгалтерских данных" отчета "Сверка с КБУ" вступают в конфликт с параметрами бухгалтерских отчетовУчет ОССтарый диалог настройки
"Параметры бухгалтерских данных" отчета "Сверка с КБУ" вступают в конфликт с параметрами бухгалтерских отчетов.Исправлено. Запуск двух отчетов одновременно не приводит к изменению субсчета в отчете по сверке.
101.468108.10.81.0срабатывает ограничение подразделения, установленное в модуле "Заработная плата"СпецодеждаЛичная карточка спецодежды
Ответственным за табельный учет по подразделению установлена настройка "Заработная плата - Настройка - Администратор - Настройка пользователей - Доступ к подразделениям". Доступ ограничили, чтобы сотрудник видел только табели по своему подразделению. Есть сотрудники, которые в табельном учете отвечают только за свое небольшое подразделение, а в СФО - за все предприятие. Но после установки описанного ограничения пользователь перестает видеть личные карточки учета спецодежды по другим подразделениям.Для ограничения доступа к Личным карточкам учета спецоснастки/СФО по подразделениям добавлена пользовательская настройка "Настройки Галактики Бухгалтерский контур Спецоснастка Доступные подразделения". Список доступных подразделений можно скопировать от одного пользователя другому с помощью стандартного функционала копирования настроек. При изменении настроек происходит перенос ограничений из модуля "Заработная плата" в добавленную настройку.
102.1420498.10.80.0При возврате на дату ввода карточки НМА удаляется источник финансирования.Учет НМАВедение картотеки
При возврате на дату ввода карточки НМА удаляется источник финансирования.Исправлено. Не удаляется. Т.к. архив есть только у операции, то выполняем откат по ИФ карточки только, если период в котором находилась карточка совпадает или больше с периодом в котором проведена операция. Если период карточки меньше периода операции, то откат не выполняется.
102.1443108.10.80.0Вернуть точку расширения epCalcRaznPeriodУчет ОСАмортизация
Была точка расширения epCalcRaznPeriod. Мы ее задествовали в своих доработках. Точка исчезла - функциональность не компилируется и не работает. НЕОБХОДИМО Вернуть точку расширения epCalcRaznPeriodВернул точку расширения epCalcRaznPeriod.
102.1443118.10.80.0Реализовать опцию "Учитывать ам.премию" для типа операции КорректировкаУчет ОСИзменение стоимости
По ПИР 102.134849 был реализован дополнительный тип операции "Корректировка" При этом в формулировке ПИР содержалось следующее требование: << 1) ввести системный тип основания для операций изменения стоимости и износа "корректировка". У такого типа основания должны быть следующие опции - "Учитывать изменения стоимости и износа" = в текущем периоде/в следующем периоде - опция по ам.премии такая же как у "модернизации" >> Причем в описании проблемы содержались пояснения, что с помощью корректировки, корректируют амортизацию, в том числе и премию. Сейчас для типа "Корректировка" не доступна функциональность работы с амортизационной премией. Проблема ПИР 102.134849 реализована не полностью. НЕОБХОДИМО Реализовать опцию "Учитывать ам.премию" для типа операции Корректировка. P.S. Проблема много обсуждалась по почте и на встрече. По сути в ходе обсуждения мы пришли к выводу, что не столько важно само по себе добавление системного типа корректировка, сколь важно добавление параметра: - "Учитывать изменения стоимости и износа" = в текущем периоде/в следующем периоде По сути "основание модернизация + указанный дополнительный параметр" уже решают проблему. Сейчас есть два пути: 1) то что предлагаю: добавить опцию "Амортизационная льгота" в тип операции "Корректировка" (как сформулирована основная часть текущей проблемы) 2) убрать системный тип основания "корректировка" и решать проблему "основание модернизация + указанный дополнительный параметр" (возможно этот вариант лучше для быстродействия?) Можно пойти и по пути 2, если это лучше для быстродействия. Если одинаково, то лучше по пути 1.Добавлена опция "Амортизационная льгота" в тип операции "Корректировка" (как сформулирована основная часть текущей проблемы).
102.1450758.10.80.0Архивировать и восстанавливать значение SumRes2 в операциях по изменению закладки ФинансированиеУчет ОСИзменение стоимости
НЕОБХОДИМО ДОРАБОТАТЬ Архивировать и восстанавливать значение SumRes2 в операциях по изменению закладки Финансирование. У заказчика(всех организаций системы "Транснефть") в этом поле сохранена крайне важная информация.Доработано. Архивируется и восстанавливается значение SumRes2 в операциях по изменению закладки Финансирование.
180.88378.10.80.0Периодически не полностью удаляются документы "Корректировка разниц"Учет ОСКорректировка разниц
Периодически не полностью удаляются документы "Корректировка разниц" В частности сама операция удалилась, а OsRazn с типом 101 нет.Целесообразно облечь удаление всей операции в транзакцию.Удаление операции теперь идет в через транзакцию. Не удаление OsRazn с типом 101 могло быть из-за того, что на момент удаления операция была не проведена, а карточка ос находилась в другом отчетном периоде. Убрал данную проверку.
102.1426828.10.79.0разделить настройку для ОС и НМАУчет ОСПредложения по новой функциональности модуля "Основные средства"
Клиент просит разделить настройку "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Настройка ИК Для источника финансирования в ИК при проведении операций сохранять неизменным" отдельно для ОС и отдельно для НМА. В их случае: по ОС необходимо оставлять неизменным - "процент распределения"; по НМА необходимо оставлять неизменным - "сумму распределения".Настройка разделена на две: "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Настройка ИК ОС Для источника финансирования в ИК при проведении операций сохранять неизменным" и "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Настройка ИК НМА Для источника финансирования в ИК при проведении операций сохранять неизменным".
180.84218.10.79.0Не реализован п.2 по ПИР 102.124702: реализовать доступ в OSNMA доступ к переценке стоимости и переценке износаУчет ОСИзменение стоимости
Необходима возможность обрабатывать в ТХО изменения "переоценки стоимости" и "переоценки износа". Cтарые и новые значения параметров нужно брать с закладки "Изменяемые параметры". Если среди изменяемых параметров отсутствует данный параметр, то новое и старое значение изменяемого параметра должно браться из соответствующих полей "переоценка стоимости" и "переоценка износа" расширенной информации карточки ОС.В параметр "Результат" идентификатора OsNma добавлен пункт "Изменяемые параметры". И доработана возможность получать старые и новые значения накопленной переоценки стоимости и износа с закладки "Изменяемые параметры". Если среди изменяемых параметров отсутствует данный значения, то новое и старое значение берется из соответствующих полей "переоценка стоимости" и "переоценка износа" расширенной информации карточки ОС. Форма записи параметров в идентификаторе: [Рез:НакПерСт] - Накопленная переоценка стоимости (старое значение) [Рез:НакПерСтНов] - Накопленная переоценка стоимости (новое значение) [Рез:НакПерИзн] - Накопленная переоценка суммы износа (старое значение) [Рез:НакПерИзнНов] - Накопленная переоценка суммы износа (новое значение)
102.1348498.10.78.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 ); В операции должно быть выбрано основание операции. Введен системный тип основания для операций изменения стоимости и износа "корректировка". Для всех типов оснований добавлен параметр: - "Учитывать изменения стоимости и износа" = в текущем периоде/в следующем периоде В таблицу попадают только операции текущего периода. Таблица доступна в алгоритмах расчета амортизации.
102.1420178.10.78.0Ошибка, после конфигурирования окна, значения выбираются не из того каталога.Учет ОСВедение картотеки
Ошибка, после конфигурирования окна, значения выбираются не из того каталога.Исправлено. После конфигурирования окна, значения выбираются из нужного каталога.
180.86368.10.78.0Округление стоимости при реализации СпецодеждыУчет ОСВыбытие
При оформлении Реализации необходимо учитывать настройки округления ROUND.SELL "Настройки Галактики Логистика Документы Управление сбытом Округление в документах сбыта" . На данный момент работает так: function SpDocBuf_SetAnotherPrice: boolean; var wasError: boolean; { ... _loop SpMoveOsCur // карточка спецификации операции Выбытие if (GetFirst SpDocBuf where ((SpMoveOsCur.nRec == SpDocBuf.NRecSpStep)) = tsOk) { SpDocBuf.Price := SpDocBuf_GetPrice(TSpMoveOs(SpMoveOsCur.buffer), NastrOsCur.field4 = 1, false); ... А хотело бы так, как это сделано при ручном создании "Накладной на отпуск" - с использованием Паскалевских функций округления, например fRoundRub2: (файл _srcCompSrcLL_SoprDocvipChkSum.vpp) //округление цены при включенной настройке Procedure FSRoundPrice; { if (SpSopr.KolOpl <> 0) if FSRoundRub(SpSopr.Price * SpSopr.KolOpl) <> (SpSopr.Price * SpSopr.KolOpl) OR FSRoundVal(SpSopr.VPrice * SpSopr.KolOpl) <> (SpSopr.VPrice * SpSopr.KolOpl) { SpSopr.Price := FSRoundRub(SpSopr.Price * SpSopr.KolOpl) / SpSopr.KolOpl; !!!НЕЛЬЗЯ ЭТОГО ДЕЛАТЬ SpSopr.rPrice := SpSopr.Price; SpSopr.VPrice := FSRoundVal(SpSopr.VPrice * SpSopr.KolOpl) / SpSopr.KolOpl; !!!НЕЛЬЗЯ ЭТОГО ДЕЛАТЬ SpSopr.rVPrice := SpSopr.VPrice; } }Округление производится согласно настройки "Настройки Галактики Логистика Документы Управление сбытом Округление в документах сбыта".
180.86608.10.78.0Реализовать точку расширения на отбор проводок в закладку "Обороты"Учет ОСВедение картотеки
Необходимо реализовать точку расширения на отбор проводок для отображения в закладке "Обороты" (аналогично 180.8406) Сейчас для добавления в эту закладку информации по своим алгоритмам мы используем Alter интерфейс, но в условиях распределенной системы заказчика с различным уровнем пропатченности очень сложно сопровождать.Добавлена точка расширения для выборки проводок с заданной аналитикой. Данные сохраняются в таблице tOborotSel Точка расширения вызывается из интерфейса "Картотека" из закладки "Проводки" при выполнении пункта локального меню "Отбор проводок по инвентарной карточке". Обработчик точки расширения должен вернуть FALSE если обработка проводилась. TRUE - если не проводилась. Если возвращаемый результат TRUE, то вызывается обработка стандартная обработка, иначе обработка прерывается. ExtensionPoint epGetOborotOnAnalitOs( _wTiDk : word; _cPlansSchNRec : comp; _wTabKau : word; _cKau : comp; _dStDate : date; _dEndDate : date ); _wTiDk - тип документа для которого делается выборка (15, 16) _cPlansSchNRec - план счетов по которым делается отбор _wTabKau - тип аналитики по которой делается отбор счетов _cKau - значение искомой аналитики _dStDate, _dEndDate - диапазон дат для отбора проводок
180.84488.10.77.0Обнулять поле Сумма амортизации (SpKatOS.SumFld) при смене признака использования на признак с режимом амортизации "Суммой"Учет ОСВедение картотеки
Необходимо обнулять поле Сумма амортизации (SpKatOS.SumFld) 1) при смене признака использования на признак с режимом амортизации "Суммой", т.к. поле "Сумма амортизации" (SpKatOS.SumFld) при других значениях режима насчисления амортизации не играет никакой роли, а при режиме расчета амортизации "Суммой" играет роль фиксированной суммы амортизации которая должна начисляться ежемесячно. И если в этом поле как-то случайно оказалась какая-то сумма, а признак использования был изменен на режим амортизации "Суммой", то это может привести к нежелательному начислению амортизации в указанном размере. 2) при смене режима расчета амортизации в признаке использования, система должна задавать вопрос, обнулить ли поле "Сумма амортизации" (SpKatOS.SumFld) во всех ОС с данным признаком использования. 3) при тиражировании карточки ОС с признаком использования предполагающим расчет амортизации "Суммой" стоит также обнулять поле "Сумма амортизации" (SpKatOS.SumFld), т.к. тиражируют карточки обычно чтобы снизить трудозатраты на заведение новой похожей, но не идентичной карточки, и велика вероятность что фиксированная сумма амортизации из карточки родителя подойдет и для карточки потомка.При смене признака использования на признак с режимом амортизации "Суммой" выдается запрос "Обнулить поле "Сумма амортизации" во всех ОС с данным признаком использования?". При утвердительном ответе во всех ОС с данным признаком использования поле "Сумма амортизации" обнуляется.
180.86258.10.77.0Множественное создание StoimStruct с кодом 1500 в ходе перепровения операцийУчет ОСИзменение параметров
Введена операция изменения параметров, в которых StoimStruct никоим образом не менялся (StoimStruct с кодом 1500 в операцию не вставлялся) Пользователь откатил одну карточку из этой операции на месяц назад, а потом на месяц вперед. Осуществилось перепроведение операции и в ходе перепроведения произошло массовое создание StoimStruct с кодом 1500 для всех карточек в операции. Зачем вставились с StoimStruct с кодом 1500 в случае перекатов карточки по периодам, не понятно. Вновь созданная запись оказывает вредное влияние: 1) забивает базу лишней информацией, 2) может вызвать ошибки в работе системы: a. В операции отобъется текущее распределение по StoimStruct b. Пользователь поменяет StoimStruct руками. c. Откати назад. d. Вернет вперед. e. Его ручные правки пропадут в ходе перепроведения ранее добавленного StoimStruct = 1500 Ошибочное создание записей StoimStruct с кодом 1500 нужно утранить.Исправлено. Лишние записи не создаются. Также должно быть установлено решение 180.8609
180.86618.10.77.0Утрата результата операции корректировка разниц в ходе отмены амортизацииУчет ОСКорректировка разниц
Была реализована настройка, которая меняет подход к фиксации результатов операции корректировки разниц ("Настройки Галактики Бухгалтерский контур Учет ОС и НМА Налоговый учет Сразу проводить операцию корректировки разниц"). При значении "да" в этой настройке, операция корректировки применяется сразу, при этом в расчете амортизации эти операции уже не анализируются. Однако при определенном стечении обстоятельств система дает сбой, когда результат применения операции корректировка разниц теряется. Последовательность описана ниже. 1) Пришли в январь 2015. 2) Создали операцию корректировки разниц по ОС № 000001 3) Применили операцию корректировки разниц, получили в разницах скорректированное входящее сальдо. 4) Рассчитали амортизацию и разницы, при расчете оттлокнулись от измененного входящего сальдо. Всё хорошо! 5) Запустили отмену амортизации с галочкой "корректировать разницы" 6) Удалилась строчка в разницах со скорректированным входящим сальдо. 7) Запустили расчет амортизации и разниц заново. 8) Создалась срочка в разницах со нескорректированным входящим сальдо. 9) Операция применения корректировки разниц не запускалась, т.к. по новому функционалу, она не должна запускаться, т.к. считается что сальдо уже скорректировано. 10) Всё плохо: имеем нескорректированное входящее сальдо по разницам. Нужно как-то изменить программу, чтобы в случае создания новой OsRazn она все таки применяла автоматически проведенную корректировку разниц, либо не удаляла OsRazn при отмене, либо несмотря на то что корректировка проведена, и всё теоретически должно быть хорошо, однако система при расчете разниц всё же перепроверяла, действительно ли всё хорошо, либо еще что-то.Исправлено. Если запись разниц по какой-либо причине была удалена, то при расчете амортизации она будет восстановлена вместе с операцией корректировки.
180.86678.10.77.0Размножение записей OsRazn в результате повторного применения операции корректировки разницУчет ОСКорректировка разниц
Создал операцию корректировки разниц. Провел. Отменил проведение. Провел заново. Захожу в карточку - вижу на закладке "Разницы" две записи от текущего месяца. Если повторить отмену и проведение, добавится еще одна запись. ОШИБКА!Исправлено. Записи не размножаются.
102.1390968.10.76.0Некорректно отображается информация в окне визуализацииУчет ОСАмортизация
При расчете амортизации не верно показывает сведения в окне визуализацииВизуализация исправлена.
102.1196168.10.75.0Реализовать возможность привязывать ТХО к операции корректировки разницУчет ОСКорректировка разниц
В Галактике имеется операция корректировки разниц. Корректировка разниц отражается впоследствии во входящем сальдо по разницам при работе с текущим месяцем. Как известно в бухгалтерском учете, временным разницам соответствуют 09 и 77 счета, а постоянным разницам 99 счет. Очевидно, что изменение оперативных данных по разницам должно корреспондировать с соответствующими изменениями по вышеуказанным счетам. Поскольку, сейчас привязывать ТХО к операции корректировка разниц возможности нет, приходится проводить корректировки по бух.учету ручными проводками в бухгалтерских справках, что неудобно и, на мой взгляд, не соответствует концепции Галактики. ПРЕДЛАГАЮ: Реализовать возможность привязывать ТХО к операции корректировки разниц, а также обучить OSNMA работать с этим типом операций.Добавлена возможность привязывать ТХО к операциям корректировки амортизации и корректировки разниц ОС/НМА. В окна редактирования этих операций внедрены стандартные вкладки "ХозОперации" и "Проводки". Для операции корректировки амортизации создаются хозоперации по одной на каждый метод учета на сумму изменения износа по методу учета. Для операции корректировки разниц создается одна хозоперация на сумму первоначальной стоимости предметов по налоговому методу учета (см. настройки "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Налоговый учет ОС Налоговый метод учета" и "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Налоговый учет НМА Налоговый метод учета"). В операции корректировки разниц данные отображаются всегда по налоговому методу учета, переключиться на другой метод учета нельзя. Если налоговый метод учета не указан для пользователя, то интерфейс не открывается. Добавлена настройка "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Налоговый учет Сразу проводить операцию корректировки разниц" Если настройка включена, то : - при проведении операции сразу корректируется сальдо по разницам на начало месяца. - в интерфейсе расчета амортизации Параметр позволяющий включить корректировку дисаблится. - сообщение о несоответствии сальдо прошлого периода и сальдо начало текущего, выдается с учетом проведенной операции.
102.1380178.10.75.0Сообщение об ошибке при удалении операцииУчет ОСИзменение стоимости
Сообщение об ошибке при удалении операции Неверный адрес записи, или возможен конфликт доступа к записи. Код ошибки: 43. таблица N3108 Создаем операцию Изменение стоимости. Задаем значения в Интерфейсе "Состав стоимости по источникам финансирования". Удаляем операцию - выдается сообщение об ошибке.Исправлено.
180.83798.10.75.0Создавать текущий OsRazn, если его нет, в операции корректировки разницУчет ОСКорректировка разниц
Если по карточке, которая включена в операцию "Корректировка разниц", по какой-то причине отсутствует запись OsRazn за текущий период, то в окне "Корректировка разниц (Налоговые)", в котором мы вводим суммы корректировки разниц значения "На начало периода", "В текущем периоде" светится от той карточки, у которой OsRazn за текущий период есть. Чтобы избежать этой проблемы, необходимо при добавлении карточки ОС в операцию корректировки разниц, проверять есть ли у нее текущий OsRazn и создавать его. Доп.инфо. Причина, по которой может отсутствовать OsRazn следующая. Заказчик использует следующий подход: разницы прошлого налогового периода отражает операцией корректировки разниц, чтобы эти суммы как то выделялись и особо попадали в отчет по разницам, а доначисление разниц текущего периода уже отражает обычным начислением разниц. Таким образом, при оформлении документов поступивших с запозданием либо при оформлении задним числом ОС, которые по итогам проверки гос.органами были признаны ОС и должны были амортизироваться, иногда приходится доначислять амортизацию и разницы за прошлые и за текущий налоговые периоды. Таким образом, вводят карточку ОС, которой не было раньше, по которой также раньше не считались разницы. И в месяце ввода сразу же делают операцию корректировки разниц на сумму пропущенных периодов. В этих условиях у ОС отсутствует OsRazn за текущий период.Доработано. Создаются нужные записи в разницах.
180.83808.10.75.0Нелогичный дизайн окна "Корректировка разниц"Учет ОСКорректировка разниц
Сейчас окно редактирования операции корректировка разниц выглядит нелогично: колонка "Корректировка" расположена в середине окна и складывается впечатление, что должно работать так: "На начало периода" + "В периоде" + "Корректировка" = "На конец периода", но это не соответствует действительности. Но на самом деле колонка "Корректировка" при расчете разниц с установленной опцией "[V] учитывать корректировку разниц" учитывается в колонке "На начало периода". Т.е. по сути выполняется следующие формулы: "Сальдо на конец прошлого периода" + "Корректировка" = "На начало периода" и "На начало периода" + "В периоде" = "На конец периода" (корректировка не участвует!). Предлагаю изменить дизайн окна следующим образом. Колонки: "Сальдо на конец прошлого периода" (не редактируемое) (из записи прошлого периода или 0 если нет) "Корректировка" (редактируемое) "На начало периода (до корректировки)" (не редактируемое) (брать сальдо на конец прошлого периода, т.к. иначе будут непонятки в зависимости от того проведена ли корректировка или нет) "На начало периода (после корректировки)" (не редактируемое) (брать сальдо на конец прошлого периода, т.к. иначе будут непонятки в зависимости от того проведена ли корректировка или нет + корректировка) "В периоде" (не редактируемое) (из текущей записи) "На конец периода (до корректировки)" (не редактируемое) (на начало периода без корректировки + в периоде) "На конец периода (после корректировки)" (не редактируемое) (на начало периода с корректировкой + в периоде) Было бы еще логичнее, если бы учет корректировки в текущем сальдо происходил при проведении операции например в НУ (а не при расчете амортизации как сейчас). Считаю, что стоит этот подход реализовать реализации включении системную настройку "всегда учитывать операции корректировки разниц"Колонки будут следующие: "Сальдо на конец прошлого периода" (не редактируемое) (из записи прошлого периода или 0 если нет) "Корректировка" (редактируемое) "На начало периода (не редактируемое) (из текущей записи) "В периоде" (не редактируемое) (из текущей записи) "На конец периода" (не редактируемое) = "На начало периода" + "На конец периода" Если сальдо на конец не совпадает с сальдо на начало, то это будет значить что операция корректировки проведена (возможно.) Поле "Корректировка" становится не доступным после проведения операции. Теперь проводится корректировка разниц и потом проверка на сальдо конца прошлого периода и начало текущего. Причем проверка происходит с учетом проведенной операции корректировки.
180.84288.10.75.0Ускорение расчета разницУчет ОСАмортизация
Методика расчета разниц такова что, чтобы посчитать одну из 5 видов разниц по сути нужно посчитать все 5 видов разниц. Получается, что при расчёте всегда (5раз) считается одно и то же, но для каждого вида разниц берётся одно из 5 рассчитанных значений. Таким образом, можно молучить хорошее ускорение (до 5 раз), если бы алгоритм разниц выполнял вычисления один раз, при этом вычисляя сразу все разницы, возвращал в качестве результата не одно значение, а сразу 5. ПРЕДЛАГАЮ рассмотреть следующие варианты ускорения расчета: 1) реализовать движок расчета разниц, который бы позволил получать из алгоиритма сразу 5 значений и который бы запускался однократно на карточку. 2) реализовать точку расширения, позволяющую заменить стандартный движок расчета разниц своим (вроде премудростей с генерацией новых OsRazn нет, этот вариант при использовании прикладным разработчиком функций DSQL может дать еще больший прирос в производительности!)Добавлена Точка расширения. Вызывается для расчета разниц по карточке в указанный период. ExtensionPoint epCalcRaznPeriod (_cKatOs : comp; _dDate: date); Вызывается из интерфейса OsRazn. Вызывается один раз для каждой ИК. Перед вызовом создается запись таблицы OsRazn для указанного периода. Операция корректировки разниц уже выполнена (если есть). Амортизационная льгота не рассчитывается. Если обработчик точки расширения вернет FALSE, то алгоритмы расчета разниц не вызываются. _cKatOs - ссылка на KatOs. _dDate - дата расчета.
102.1375228.10.74.0Рантайм при выполнении операции "Сверка с КБУ"Учет ОСНовый диалог настройки
Рантайм при выполнении операции "Сверка с КБУ". После настройки параметров сверки и нажатии "Продолжить" выдается: "Cancel:#004 (1111:1151) RunPasRep_Record. Некорректный параметр. Свяжитесь с разработчиками" и рантайм. Привнесено G_BUH dll 8.10.47.0. (на g_buh 8.10.46.0 ошибки нет)исправлено
102.1354038.10.73.0Округление амортизационной премии в операцияхУчет ОСПоступление
Если первоначальную стоимость ОС из операции поступления либо стоимость модернизации из операции изменения стоимости умножить на 10 или 30% зачастую ам.премия получается с третьим знаком после запятой. Нужна настройка, которая позволит в автоматическом режиме следить за тем, чтобы амортизационная премия в операциях была округленной до нужного количества знаков. Это может быть либо настройка реестра настроек, либо настройка основания операции - нужно решить исходя из концепции модуля.В операции округление льготы производится согласно параметрам округления амортизации в настройке метода учета. На закладке "ОперацииАморт." премия округление производится аналогично.
102.1271098.10.72.0Необходима привязка ЭХД и Галактики через штрих кодУчет ОСВедение картотеки
В конце месяца по объектами основных средств находящихся в долевой собственности сдаются акты приема передачи. И таблица Excel где указаны даты приема и передачи. Согласно которых рассчитывается коэффициент по источникам финансирования. До внедрения КИС ЭХД на основании такого комплекта документов (пачка актов и табличка Exclel с датами передачи и коэффициентами) в отчетном месяце бухгалтер в картотеке ОС вводил соответствующие коэффициенты на вкладку "Источники финансирования" (тем самым коэффициенты прошлого месяца нигде не сохранялись). Эти коэффициенты влияют на расчет амортизации и проводки по амортизации. Теперь после внедрения КИС ЭХД возникло желание комплект документов (пачка актов и табличка Excel с датами передачи и коэффициентами) снабдить штрих-кодом. Сохранять ее в КИС ЭХД и иметь связь с этим штрих-кодом в Галактике. Т.е. этот штрих код где-то в Галактике нужно хранить. Каждый месяц, для группы ОС находящихся в долевой собственности иметь и штрих код советующей пачке актов и таблицы дата передачи. И помесячно хранить значения вкладки источники финансирования. При обсуждении наиболее оптимальным вариантом показалось доработать "Операцию ОС - Изменение параметров" - реализовать в ней возможность. Кроме прочих изменяемых параметров также задать изменения списка источников финансирования. А так же внешних атрибутов источников финансирования. Соответственно также потребуется реализовать хранение штрих кодов для этого вида операций. Как вариант можно было бы рассмотреть вариант реализации нового вида операции "Операцию ОС - Изменение источников финансирования". Во вложении часть материала из переписки. На бумаге могу предоставить пометки сделанные от руки по этому вопросу.Добавлена возможность создания архива по источникам финансирования для операций Изм.Стоимости, Изм. параметров и Поступления. При проведении операции ИФ в карточке заменяются на ИФ указанные в операции. При откате операции ИФ в карточке восстанавливаются. Интерфейс задания ИФ в операции сделан двухпанельным. Слева панель с ИФ из карточки(предыдущее состояние), справа с ИФ в операции. Есть возможность переносить все или один ИФ из карточки в операцию. Сделан конвертор для перевода старой структуры ИФ в новую. Запускается автоматически. Добавлена возможности задавать штрих-код в операции Изменения параметров.
102.1345318.10.72.0Неверно происходит актуализация изменяемых параметров "Накопленная переоценка стоимости" и "... износа"Учет ОСИзменение параметров
Если в операции имеются изменяемые параметры "Накопленная переоценка стоимости" и "Накопленная переоценка износа" и пользователь запускает пункт локального меню "Актуализация данных в операции" актуализация этих изменяемых параметров происходит неверно. Устанавливаются равными нулю. Должны устанавливаться равными текущим значениям в картотеке. ОШИБКУ необходимо устранить.Исправлено. "Накопленная переоценка стоимости" и "Накопленная переоценка износа" обновляются в операции правильно.
102.1349558.10.72.0Неверно восстанавливается при откате ИК распределение по ИФ в следующем случае:Учет ОСВедение картотеки
Неверно восстанавливается при откате ИК распределение по ИФ в следующем случае: По карточке не было распределения по ИФ. Через операцию Изменение стоимости распределяем по ИФ1 только величину изменение стоимости. При откате по карточке на предыдущий период, стоимость распределения по ИФ1 должна стать равной нулю, а не становится.Восстанавливается правильно.
102.1350148.10.72.0Изменяется сумма распределения по ИФ при установленной настройке "сумму распределения - сохранять".Учет ОСВедение картотеки
Изменяется сумма распределения по ИФ при установленной настройке "сумму распределения - сохранять". Вся сумма ИК распределена по ИФ. Если в операции "Изменение стоимости" ("Поступление") для суммы изменения не указать источник, то при проведении операции автоматически в интерфейс "Состав стоимости по источникам финансирования" "Источник финансирования (новое значение)" подставляются существующие ИФ с прежним процентом, а должны подставляться ИФ с прежней суммой.Исправлено. Сумма не изменяется.
102.1353358.10.72.0Амортизационная льгота попадает в проводки для тех ОС, в которых ее нетУчет ОСАмортизация
Амортизационная льгота попадает в проводки для тех ОС, в которых ее нет В налоговом методе учета при формировании проводок по рассчитанной амортизации идентификатор &Vip_[Obj:"OSNMA"][Рез:ВАЛ][Аморт:ДС] имеет валидное значение для не имеющего льготы ОС. Причем сумма льготы равно льготе от предыдущего имеющего льготу ОС.Исправлено. Льгота в ТХО считается правильно.
102.1339778.10.71.0Доработать 102.130965 для учета изменения признака использования ручкамиУчет ОСАмортизация
Доработать отражение сумм амортизации в случае трехмесячного простоя ОС для случая, когда признак использования изменялся вручную. Т.е. когда нет операции, то тащить из архива дату изменения признака использования.Когда нет операции, то берется из архива дата изменения признака использования. Возвращается первый день месяца в котором был изменен признак использования.
102.1344388.10.71.0не работает фильтр [ТХО нач. амортизации] в картотеке ОСУчет ОСВедомости наличия
Не работает фильтр [ТХО нач. амортизации] в картотеке ОС. Подробное описание во вложении. Проблему удалось проявить на тестовой БД. При необходимости могу предоставить. Проверял на: F_OS 8.10.70.1 и F_OSOPER 8.10.76.1Исправлено. Фильтр и повторно устанавлиется верно.
180.80558.10.70.0необходима возможность расширенной формы Ведомости аморт льгот в разрезе операцийУчет ОСВедение картотеки
В очередной раз наш крупнейший клиент Азот обратился с просьбой предложить им отчет по ОС в следующем виде: 1.Амортизационная группа; 2.СПИ старый 3.СПИ новый. 4. Дата модернизации; 5. Сумма модернизации; 6.Первоначальная стоимость на дату модернизации; 7.Сумма накопленного износа на дату модернизации. 8.Остаточная стоимость на дату модернизации; Если объект модернизируется несколько раз, то и информация должна быть представлена отдельно по каждой модернизации, по все описанным выше пунктам. Мне удалось подобрать только отчет Ведомость амортизационных льгот (Ведение картотеки - Печать в модуле Учет ОС) с параметром "Величины аморт.льготы отображаемые в отчете " = " суммы в разрезе операций". Однако ранее вы нам добавили в другое значение данного параметра "итоговые суммы" колонки из п.1 и п.2. Колонка из п.4. - это уже есть поле Дата операции. Колонка из п. 5 - это уже есть поле Изменение стоимости. Возможно ли требующиеся клиенту колонки добавить в это значение параметра, а именно колонки из п. 1 и 2 (как у "итоговых сумм"), новые колонки из п. 3,6,7,8 ? Другого похожего отчета я не смогла сообразить. Как обычно клиент от нас требует какого-то срочного решения. Помогите, пожалуйста.В локальное меню картотеки добавлен пункт - "ПечатьПечать реестра операций по карточкам". Также в окно редактирования карточки добавлен пункт - "ПечатьПечать реестра операций по карточке". Печать отчета производится по помечанным карточкам, или по текущей. Возможна фильтрация по: - периоду операций - по типу операций - по проведенности операций. Печать возможна в форме Бизнес-текст или FastReport. В FastReport реализован требуемый отчет. Называется "Реестр операций с СПИ." Отчет "Реестр операций по картотеке" удален из отчета "Печать реестра инвентарных карточек".
102.1305618.10.69.0Сделать корректный выход из безвыходной ситуации в случае когда "не установлена основная настройка НМА"Учет НМАДругие вопросы по НМА
Сделать корректный выход из безвыходной ситуации в случае когда "не установлена основная настройка НМА" Конкретный пример такой ситуации - выбор в настройке "Основной метод учёта по умолчанию" для НМА из перечня методов, в которых не установлен признак "основная настройка" - в результате выбора получаем сообщение "не установлена основная настройка", а доступ к модификации методов ограничен другой настройкой - т.е. и установить признак основной настройки, и выйти из окна выбора пользователь не может. Пользователю и остаётся только снимать AtlExec.exe через Диспетчер задач. Предложение: Необходимо доработать прикладные алгоритмы таким образом чтобы пользователь не мог попасть в такое окно или мог из него корректно выйти. Например один из возможных вариантов решения: если "доступ к модификации методов ограничен другой настройкой" и "не установлен признак "основная настройка"" то при входе в документ вообще не открывать ни каких интерфейсов а выдать MessageBox типа "Запрещен доступ к методам учета обратитесь к администратору"Если "доступ к модификации методов ограничен другой настройкой" и "не установлен признак "основная настройка"" то при входе в документ устанавливается в качестве основной первый Метод учета.
102.1308818.10.69.0ChgPar.vip GetKaureffNewValues научить брать сразу индивидуальные параметры а потом уже общиеУчет ОСИзменение параметров
ChgPar.vip GetKaureffNewValues научить брать сразу индивидуальные параметры а потом уже общие в частности поменять функцию GetKauReffNewValues(pwKau : word) : comp; примерно следующим образом. Function GetKauReffNewValues(pwKau : word) : comp; { GetKauReffNewValues := 0; if ( loOsChgPar.GetFirst FastFirstRow OsChgPar where (( cMoveOsNRec == OsChgPar.cMoveOs and cgOsChg_NewVal == OsChgPar.wType and cKatOsNRec == OsChgPar.cKatOs and cgOsChg_KauReff == OsChgPar.ParCode and pwKau == OsChgPar.dValue (NoIndex) )) = tsOk ) { GetKauReffNewValues := loOsChgPar.OsChgPar.cValue; Exit; } if ( loOsChgPar.GetFirst FastFirstRow OsChgPar where (( cMoveOsNRec == OsChgPar.cMoveOs and cgOsChg_NewVal == OsChgPar.wType and 0 == OsChgPar.cKatOs and cgOsChg_KauReff == OsChgPar.ParCode and pwKau == OsChgPar.dValue (NoIndex) )) = tsOk ) { GetKauReffNewValues := OsChgPar.cValue; Exit; } }ChgPar.vip GetKaureffNewValues научилась брать сразу индивидуальные параметры а потом уже общие.
102.1309658.10.69.0Отражение сумм амортизации в случае трехмесячного простоя ОСУчет ОСАмортизация
3-й абзац п.45 Главы 4 Постановления от 27.02.2009 №37/18/6 гласит: "45. Амортизационные отчисления по объектам основных средств, используемым в предпринимательской деятельности (за исключением находящихся в бюджетных организациях), производятся на протяжении всего срока полезного использования объектов и отражаются с учетом особенностей, указанных в частях второй и третьей настоящего пункта, путем ежемесячного включения амортизационных отчислений: в затраты на производство или расходы на реализацию - при нахождении объектов основных средств в эксплуатации; в простое продолжительностью до(!) трех месяцев, в том числе в связи с проведением ремонта; в состав прочих расходов по текущей деятельности - при нахождении объектов основных средств в простое продолжительностью свыше(!) трех месяцев, в том числе в связи с проведением ремонта, в простое, вызванном полной остановкой производства продукции (работ, услуг) в структурном подразделении организации или организации в целом, а также при нахождении в запасе". Все это означает, что в случае в случае более чем трехмесячного простоя ОС отражение суммы амортизации производится на другой счет бухучета. Необходима доработка, которая позволит проанализировать картотеку и архив на предмет соответствующего изменения состояния ОС и позволит настроить ТХО для автоматического определения бухсчета. Возможно, окажется достаточным добавить в алгоритм ТХО OSNMA какую-либо функцию.Добавлены настройки: "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Настройка ИК ОС Признак использования "Ремонт"" "Настройки Галактики Бухгалтерский контур Учет ОС и НМА Настройка ИК НМА Признак использования "Ремонт"" В идентификатор OsNMA добавлен параметр "Фильтр по ремонту" со значениями "Больше" и "Меньше" для формирования проводок по ОС находящихся в ремонте больше или меньше месяцев указанных в параметре "мес". Количество месяцев рассчитывается как разница месяцев между последней датой установки признака использования "Ремонт" в операции изменения параметров и датой текущей операции проводимой по ОС. Например: дата установки признака использования "Ремонт" 01/01/2014, дата проведения амортизации по ОС 27/02/2014 получаем количество месяцев 1. Если в операции изменения параметров не установлена дата признака использования "Ремонт", то проводки не формируются. Для корректной работы функционала рекомендовано изменять признак использования, указанный в новой настройке, только через операцию Изменение параметров.
102.1319558.10.69.0Пометка из внешнего источника - не помечает гр. карточкиУчет ОСДругие интерфейсы по ОС
Картотека - Пометка из внешнего источника - не помечает групповые карточки. Ошибка импорта. В настройке импорта нет поля - Инвентарный номер вышестоящего ОС.Помечает групповые карточки (подчиненные не помечаются).
102.1323898.10.69.0Реализовать возможность изменения Внешних КАУ в операции изменения группы/вида ОСУчет ОСИзменение группы/вида
Необходимо реализовать возможность изменения Внешних КАУ в операции изменения группы/вида ОС. Данный вид изменений почему-то не доступен в данном виде операций в то время как ряд других изменяемых параметров доступен. Также нужно чтобы OSNMA умели формировать режимы 6 и 7 для изменяемых внешних КАУ.Реализована возможность изменения Внешних КАУ в операции изменения группы/вида ОС.
102.1326638.10.69.0Реализовать возможность изменения Внешних КАУ в операции поступленияУчет ОСПоступление
Необходимо реализовать возможность изменения Внешних КАУ в операции поступления на закладке "Изменяемые параметры".Реализована возможность изменения Внешних КАУ в операции поступления на закладке "Изменяемые параметры".
102.1327898.10.69.0"Плывет" отчет при следующих условиях:Учет ОСВедение картотеки
"Плывет" отчет при следующих условиях: Если печатать отчет по локальному меню "Печать - Печать ведомостей наличия и износа" из картотеки, в которой предварительно установить сортировку, например, по Виду, то в данные в отчет выводятся некорректно.Отчет исправлен.