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


Описание файла обновления:
ФайлC_CHECKOPER_RES_810470.TXT
ОбновлениеC_CHECKOPER_RES_810470
НазначениеОбщее
ПродуктГалактика 8.10
Релиз03.11.2006 : Atlantis 5.2.8
КомпонентC_CHECKOPER
ТипRES
Версия8.10.47.0
Дата2014-10-16 15:59:58
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
102.135611NEWУчет банковских гарантийУправление договорамиРабота с банковской гарантией
Реализовать функциональные требования согласно ФТРеализованы функциональные требования согласно ФТ (BG_New.doc)
102.135927NEWНекорректно создается банковская гарантияУправление договорамиРабота с банковской гарантией
Некорректно создается банковская гарантия - при проверке КОУ получаем: Проверка накладных Банковская гарантия № MIV@333/44 от 16/10/2013: неправильный год (0 вместо 2013) в шапке. (Table KatSopr NRec=281474976712910) Банковская гарантия № MIV@55/789 от 01/02/2014: неправильный год (0 вместо 2014) в шапке. (Table KatSopr NRec=281474976712911) Банковская гарантия № MIV@55555 от 03/09/2014: неправильный год (0 вместо 2014) в шапке. (Table KatSopr NRec=281474976712912) Нужно подкорректировать накладные (неправильный год): 3 Проверка накладных законченаИсправлено - банковская гарантия не проверяется
101.548788.10.44.0Добавить фильтры для удаления ордеров и сальдовых остатков.НастройкаУдаление старой информации
Добавить фильтры для удаления ордеров и сальдовых остатков. Добавить фильтры по группам МЦ и МЦ1. Добавлены фильтры по МЦ и группам МЦ при удалении ордеров и остатков. Одновременно нельзя выбрать оба фильтра, только один из них. 2. Доработано создание приходного ордера с нулевым количеством без учета ЦУ. Если завис остаток по ЦУ с нулевым количеством, но ненулевой ценой, то по таким позициям будет создан один приходный ордер с нулевым количеством без ЦУ. Следует отметить, что после удаления информации необходимо запустить пересчет сальдовых остатков по МТР. Фильтры добавлены только для возможности разделения остатков для удаления, пользователи сами отвечают за полноту удаления данных и выборку всех МЦ в конечном итоге.
101.480068.10.43.0Объединение серийных номеров при объединении МЦНастройкаОбъединение МЦ
Учет матценностей Настройка Администратор Объединение данных Объединение МЦ Выбираю два МЦ и нажимаю Объединить. По окончанию открыл карточки МЦ в них расходы, приходы переместились. Захожу в карточки серийных номеров. Карточки СН у МЦ, которая должны была удалится после окончания объединения - остались привязаны к этой МЦ, а должный были перенестись на МЦ, в которую происходило объединение, и история движения по карточке СН (приходы, расходы) тоже должны были переместится.Осуществляется учет серийных номеров. При чистке каталога МЦ проверяется таблица серийных номеров по которым было движение.
101.544428.10.43.0Удаление контрагента, на которого есть ссылка в документахНастройкаЧистка каталога организаций
Удаление контрагента, на которого есть ссылка в документах При выполнении функции "Чистка каталога организаций" произошло удаление контрагента, на которого была ссылка в накладной на отпуск МЦ в поле Заказчик(плательщик).Добавлена проверка организаций в следующих полях: 1.Заказчик(плательщик) 2.Пункт погрузки - организация 3.Пункт разгрузки - организация
101.546908.10.42.0Некоторые проблемы при удалении старой информацииКонтур логистикиНе знаю, какая именно часть контура логистики, научите
Некоторые проблемы при удалении старой информации Установили обновления C_CHECKOPER_RES_8_10_41_0 L_OSTATKI_RES_8_10_60_0 Во вложении результаты выполнения функции удаления старой информации. Сильно расходятся данные до и после удаления. Сегодня у нас очень остро стоит вопрос удаления, потому что в ближайшее время наша база намного увеличится (объединение),Исправлено удаление старой информации при наличии остатков по ЦУ
102.1299298.10.41.0Удаление старых ордеров без пересчета сальдо и текущих остатковНастройкаУдаление старой информации
Удаление старых ордеров без пересчета сальдо и текущих остатков На данный момент при удалении старых ордеров происходит пересчет сальдовых остатков с даты удаления по текущую дату плюс модификация текущих остатков. Необходимо реализовать возможность удаления старых ордеров без пересчета сальдовых и текущих остатков, а только с созданием сальдового остатка на дату удаления информации по новому приходному ордеру.При удалении старых ордеров и остатков создается сальдовый остатков на дату удаления информации по ордеру, но не происходит пересчет текущих остатков, а также остатков с даты удаления информации по текущую дату. Это ускорит процедуру удаления старой информации и не изменит текущие и сальдовые остатки на текущую дату. & УНАСЛЕДОВАННЫЕ ИЗМЕНЕНИЯ БАЗОВЫХ ФОРМ: НЕТ & УНАСЛЕДОВАННЫЕ ИЗМЕНЕНИЯ ШАБЛОНОВ: НЕТ
101.531728.10.40.0После удаления старой информации возникли проблемы в отчете наличие по складамСкладской учетНаличиепо складам
После удаления старой информации возникли проблемы в отчете наличие по складам После выполнения функции удаления старой информации (удаление сальдовых остатков и ордеров до 31.12.2008г.) отчеты наличия по предприятию не совпадают до и после удаления.Остатки после удаления старой информации корректны.
104.199938.10.39.0Производительность системы при удалении старой информацииНастройкаУдаление старой информации
Производительность системы при удалении старой информации При выполнении операции удаления старой информации (параметры запуска на скрине во вложении) на атлантисе 504401 (версии компонент в файле Patches504401 во вложении) заметно упала производительность по сравнению с Атлантисом 504385 (версии компонент в файле Patches504385 во вложении), на тестовой базе на "старом" Атлантисе удаление заняло около 4 минут, на текущей версии - около 11 минут.Оптимизирован процесс удаления складских остатков.
101.454068.10.38.0Проверка целостности изменяет наименование банкаПроверка каталоговПроверка контрагентов
Проверка целостности изменяет наименование банка на "Иркутск". Однако, такого города нет в таблице katcity. Подробно во вложении.Исправлена ошибка следующим образом: Убрана по умолчанию опция Проверять соответствие расчетные счета -> банки Алгоритм по данной опции работает следующим образом: a) восстанавливается связь между р./с. и банком, если ее не было. подставляется существующий банк, найденный в бд по ограничениям согласно настройке "Настройки Галактики Общие настройки системы Каталог организаций и банков Привязка банков к справочнику расчетных счетов", или же создается новый банк в противном случае. b) после восстановления связи делается проверка на основных полей р.с и банка: a.1 Наименование банка a.2 Описание банка a.3 Адрес банка a.4 БИК a.5 РКЦ a.6 Кор. счет и если одно из них из р./с. не равно значению из аналогичных полей в банке, то значения поля берется из р./с. с) если связь существовала, то делается проверка согласно п. b Замечание: при запуске проверки с данной опцией следует помнить, что если р./с. для одного банка делались в разное время и за это время у банка менялись вышеуказанные поля, то в разных р./с. может отличная информация и соответственно при проверке можем получить эффект возврата старой информации по банку.
102.1195068.10.38.0Выводить в протокол название документа, а не вид.Проверка КОУПроверка накладных
Выводить в протокол название документа, а не вид(503/251/229/210), см. может есть и другие документы с видом..: Документ с видом <503> № MIV@000004 от 31/05/2007: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=2169) Документ с видом <251> № MIV@000000 от 02/08/2007: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=3070) Документ с видом <229> № MIV@000007 от 01/04/2008: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=6205) Документ с видом <210> № MIV@000012(-КН) от 23/12/2009: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=4611700078852032232) Акт на пересортицу № MIV@000030 от 29/06/2006: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=4611811196237388371) Акт на списание из производства /подразделение-.../ № MIV@000001 от 16/10/2006: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=4611811214379717154) Накладная на возврат МЦ покупателями по рекламации (СБЫТ) № MIV@654556 от 18/05/2010: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=4611814965244393387) Накладная на ОТПУСК МЦ № MIV@000087 от 24/05/1999: нет ссылки на спецификацию СФ. Не найдено ни одной подходящей ссылки. (Table SpSopr NRec=4611818387120563020) Накладная на возврат товара консигнатору № MIV@000003 от 28/04/2011: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=4611889359391931736) Накладная на возврат МЦ покупателями по рекламации (СБЫТ) № MIV@654590 от 01/08/2012: была неправильная ссылка на валюту (0 вместо 2) в одной из спецификаций. (Table SpSopr NRec=4611978676093029980) Проверка накладных законченаДля документов с типом 503/251/229/210 выводиться их текстовое описание.
102.1214228.10.38.0После проверки КОУ (остатков МЦ) - некорректная ссылка на каталог МЦСкладской учетпросмотр текущих остатков
После проверки КОУ (остатков МЦ) - некорректная ссылка на каталог МЦ: Проверка корректности ссылок в справочниках сальдо МЦ I ЭТАП : по таблице ордеров II ЭТАП : по таблице сальдовых остатков Неправильная ссылка на каталог МЦ в сальдо по МЦ "" от 15/01/2013. (Table SaldoMC NRec=65595) III ЭТАП: по таблице разрезов движения Нужно добавить записей в каталоги: МЦ: 1 cкладов: 0 МОЛ: 0 партий: 0 валют: 0 Проверка целостности в справочниках сальдо МЦ законченаДоработана обработка ситуации при проверке КОУ, если в таблице SaldoMC есть записи со ссылкой на МЦ, которой нет в каталоге МЦ и по данной МЦ нет ни одного ордера: 1. Если МЦ нет в каталоге МЦ и нет ни одного ордера, то записи из таблицы SaldoMC по этой МЦ удаляются; 2. Если МЦ уже ранее добавлена в каталог МЦ, например проверкой КОУ, то запись в каталоге МЦ остается, ее пользователь затем может удалить вручную, а из таблицы SaldoMC записи удаляются.
102.1245138.10.38.0Предлагается проверять некорректные ссылки договора, ссылающегося на самого себяПроверка КОУПроверка КОУ - другие вопросы
Предлагается проверять некорректные ссылки договора, ссылающегося на самого себя и обнулять их при запуске функции "Проверка целостности таблиц Проверка КОУ", так как, если такие записи существуют, система зависает при проверке и невозможно ее выполнить до конца. Платформа SQL. Запускают проверку целостности КОУ на иерархии договоров и ПКП (см. рис1) Установлена 1 галочка, период не имеет значения. На 10% проценты замирают, SQL чем-то занят, а занят он постоянным запуском хранимки с одним и тем-же параметром: exec FT0000000000000000000000000DLL 0x806E000000001282 (см.рис2). В процессе обсуждения ситуации было выяснено, что такое происходит, если договор ссылается на самого себя. См. скриншоты.В проверку КОУ для договоров контролируется наличие ссылок на самого себя. Если они есть - ссылка на вышестоящий обнуляется
102.977218.10.38.0Вставить букву "В"Проверка КОУПроверка ордеров
нужно исправить текст сообщенияисправлено. текст будет выглядеть таким образом: ... приходный ордер №732 от 01/03/2010 г. Тип ордера - склад: не соответствует код группы подразделений (Table SklOrder NRec=4611843928274676269) для сообщений, связанных исключительно с ордером ... Спецификация приходного ордера №732 от 01/03/2010 г. Тип ордера - склад: не соответствует код группы подразделений (Table SklOrder NRec=4611843928274676269) для сообщений, связанных со спецификацией
102.983128.10.38.0время проверки КОУПроверка КОУПроверка накладных
Клиент просит уменьшить время проверки КОУ по накладным (см. файл).Время проверки уменьшилось. Вместо 3 этапов теперь 2. Этам проверки корректонсти ТТН в накладных проходит во время проверки ссылки в накладных.
102.994848.10.38.0Некорректно указан тип документа!Проверка КОУПроверка ДО
Некорректно указан тип документа! Пишет 111 - это акт на прием услуг, а на самом деле это ДО на предоплату закупок! Надо писать в протоколе название документа, согласно кодов документов системы. Проверка документов-оснований Документ с типом "111" № MIV@1222 от 28/02/2007: в одном из этапов ДО есть несоответствие дат (вместо даты 28/02/2007 была дата ДД/ММ/ГГГГ). (Table StepDoc NRec = 4611734324924281720) В данном этапе ДО изменяется поле - Дата начала этапа Счет на закупку № MIV@6445546 от 03/05/2010: в одном из этапов ДО есть несоответствие дат (вместо даты 03/05/2010 была дата ДД/ММ/ГГГГ). (Table StepDoc NRec = 4611826112167525606) В данном этапе ДО изменяется поле - Дата начала этапа Документ с типом "111" № MIV@1222 от 28/02/2007: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты ДД/ММ/ГГГГ дата 28/02/2007. (Table SpStep NRec = 4611841826656317605) Документ с типом "111" № MIV@1222 от 28/02/2007: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты ДД/ММ/ГГГГ дата 28/02/2007. (Table SpStep NRec = 4611855244304762886) Счет на закупку № MIV@6445546 от 03/05/2010: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты ДД/ММ/ГГГГ дата 03/05/2010. (Table SpStep NRec = 4611857437769163132) Обнаружено: не связанных с документом этапов ДО: 0 некорректных спецификаций ДО: 0, в том числе без МЦ/услуги: 0 не связанных со спецификацией резервов по ДО: 1 Для их удаления запустите процесс снова... Необходимы исправления в таблицах: дата в спецификациях этапов ДО..3 валюта в спецификациях этапов ДО..0 дата в этапах ДО................2 сумма в этапах ДО...............0 год в документах-основаниях.....0 дата окончания действия ДО......0 Выявлено не связанных с журналом хозопераций ДО: 1 Проверка документов-оснований законченаисправлено.
103.59878.10.38.0Пропущен пробел между сообщением и названием организацииФинансово-расчетные операцииПроверка контрагентов (~Н)
После проверки получаем лог файл. ............................................ Проверка контрагентов Дублирование значения ключа дляООО "МЕГА АЛЬЯНС" (Table KatOrg NRec=281474976710844) Дублирование значения ключа дляООО Даймэкс Новосибирск (Table KatOrg NRec=281474976710850) Дублирование значения ключа дляЗАО Инэко Москва (Table KatOrg NRec=562949953421514) Дублирование значения ключа дляЕгоров Егор Николаевич (Table KatOrg NRec=562949953421516) Дублирование значения ключа дляМинистерство экономики Удмуртской Республики (Table KatOrg NRec=4612055073387967389) Дублирование значения ключа дляАО Акзо Нобел Инкс ОЮ (Финляндия) Москва (Table KatOrg NRec=4612234282245182433) Выявлено 39 несоответствий в наименованиях организаций Добавлено 114 записей в каталог для интерфейса выбора банков Проверка каталога контрагентов закончен ............................................ Между "для" и названием контра надо бы поставить пробел.Добавлен пробел.
106.95848.10.38.0Ошибки при проверке КОУ "Ордера с удалением"Проверка КОУПроверка ордеров
Ошибки при проверке КОУ "Ордера с удалением" При Проверке КОУ "Ордера с удалением" выявилось 2 проблемы/ошибки (думаю они связанные) Кратко опишу тут: При проверках и наличие в БД пустых ордеров (когда заведены только шапки): 1. В отчете после проверки Пишет Удалено 2 пустых ордера (на практике и больше было с множителем 2), хотя удаляется всего одна шапка. 2. При создании ордера, идут вставки в др. таблицы (по словам заказчика в SoprHoz, у меня при проверке на тестовой в AttrVal), а УДАЛЯЕТСЯ при проверке только шапка, что приводит к увеличению мусора в БД и введения путаницы. Подробное описание 2. пункта во вложении.При удалении ордера удаляются и записи в таблице SoprHoz и AttrVal. Подсчет удаленных ордеров ведется верно.
102.1175988.10.37.0Не верно формируются суммы в USD в отчетеУправление сбытомв разрезе контрагентов
В отчете не правильно формируются суммы в валюте, из за этого не верная информация по колонке USD. См вложение.Отчет формируется корректно. Некорректные ссылки на валюту в самой накладной. Требуется провести проверку КОУ, которая доработана.
102.1132358.10.36.0Некорректно создается акт по распоряжениюСкладской учетАкты на перемещение между объектами
Некорректно создается акт на перемещение между объектами по распоряжению на прием-отпуск МТР. Проверка КОУ выявляет следующее: Проверка накладных Документ с видом <632> № MIV@000037 от 11/01/2012: неправильная дата проведения (11/01/2012 вместо ДД/ММ/ГГГГ) в одной из спецификаций. (Table SpSopr NRec=4612022337729461222) Документ с видом <632> № MIV@000037 от 11/01/2012: неправильная дата проведения (11/01/2012 вместо ДД/ММ/ГГГГ) в одной из спецификаций. (Table SpSopr NRec=4612037813940904330) Документ с видом <632> № MIV@000037 от 11/01/2012: неправильная дата проведения (11/01/2012 вместо ДД/ММ/ГГГГ) в одной из спецификаций. (Table SpSopr NRec=4612045307966736393) Документ с видом <632> № MIV@000037 от 11/01/2012: неправильная дата проведения (11/01/2012 вместо ДД/ММ/ГГГГ) в одной из спецификаций. (Table SpSopr NRec=4612114727971935437) Нужно подкорректировать спецификации накладных с неправильной датой операции: 4 Проверка накладных закончена Вообще-то писать в протоколе надо акт..., а не 632...Исправлено ошибочное заполнение даты оприходования спецификации акта при создании по распоряжению. При проверке КОУ добавлено наименование Акта на перемещение вместо <632> кода.
101.473518.10.34.0анализировать МЦ в маршрутных картах и производственных спецификацияхНастройкаЧистка каталога МЦ
При вызове сервисной функции чистки каталога МЦ не анализируется использование МЦ в Маршрутных картах и Производственных спецификациях(Модуль Спецификация продуктов). В результате могут быть удалены записи, по которым не было движения, но которые используются в МК и ПС. Заказчик просит рассмотреть возможность реализации проверки ссылок на МЦ в МК и ПС при вызове функции чистки каталога.добавил анализ для табдиц - KatMarsh, Marsh_Sp, MnfOper, Hdr_PS, PS_Lines, Normas, DistDoc, PS_Exec - XChange, HistZam, NBSIzm, NBSZam, NBSProd,XChangeMC4Izd Ф-ия вызывается в модуле Настройка: Администратор - Сервисные функции - Чистка каталога МЦ Администратор - Сервисные функции - Чистка каталога услуг Ищется первое вхождение МЦ/услуги в одну из таблиц группы (выше описаны 2 группы таблиц) (дальнейший поиск не производится)
102.1022448.10.33.0Реализовать Saldo_K2.vpp на отдельном интерфейсеУправление сбытомНакладные на отпуск
Реализовать Saldo_K2.vpp на отдельном интерфейсе.Реализованы функции создания, модификации, удаления записей SpOrder и установки семафоров в объектном интерфейсе. Подключение в Sklad.vih и Sklad.var.
102.1093648.10.33.0Перевести nNewOrd.vpp на объектный интерфейсСкладской учетПриходные ордера
Перевести nNewOrd.vpp на объектный интерфейс Ф-ии добавить в modifOrd.vih.Добавлены функции из nNewOrd.vpp в объектный интерфейс ModOrd.vip. Подключение через Sklad.vih и Sklad.var.
101.473328.10.32.0При проверке КОУ выдается сообщениеПроверка КОУПроверка ДО
При проверке КОУ выдается сообщение. См. вложение. Фрагмент БД выкладываю в лотус на ваше имя.При проверке КОУ корректно обрабатываются статусы у документов типа "Заявка на ремонт". Сообщение не выдается.
102.1066528.10.32.0Проверка выдает ошибку, а где такой документ 566?Проверка КОУПроверка накладных
Проверка выдает ошибку, а где такой документ 566? Проверка накладных с видом <566> № MIV@000001 от 05/04/2011: нет ссылки на пояснение по статусу. (Table KatSopr NRec=4611716717222434924) Нужно чтобы написало навзание документа и в интерфейсе документов отобюражало названиеИсправлено. Т.к. документ 566 - "Акт на замену ОР" не имеет статуса, то убрана соответствующая проверка для данного типа документа.
102.1069858.10.32.0Проверка КОУ дает несоответствие по вновь созданным заявкамТехническое обслуживание и ремонт оборудованияФормирование заявки на ремонт по типовому ремонту
Проверка КОУ дает несоответствие по вновь созданным заявкам: Проверка документов-оснований Заявка на ремонт № MIV@000058 от 14/04/2011: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты 14/04/2011 дата 12/04/2011. (Table SpStep NRec = 4611688639037091976) Заявка на ремонт № MIV@000058 от 14/04/2011: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты 14/04/2011 дата 12/04/2011. (Table SpStep NRec = 4611793975789988703) Заявка на ремонт № MIV@000057 от 14/04/2011: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты 14/04/2011 дата 12/04/2011. (Table SpStep NRec = 4611838354899064125) Заявка на ремонт № MIV@000058 от 14/04/2011: в одной из спецификаций этапов ДО в поле Дата начала этапа вместо даты 14/04/2011 дата 12/04/2011. (Table SpStep NRec = 4611953452843878600) Необходимы исправления в таблицах: дата в спецификациях этапов ДО..4 валюта в спецификациях этапов ДО..0 дата в этапах ДО................0 сумма в этапах ДО...............0 год в документах-основаниях.....0 дата окончания действия ДО......0 Проверка документов-оснований законченаНастройка / Администратор / Проверка целостности таблиц / Проверка КОУ При выполнении проверки КОУ для заявок, учитывается что дата начала этапа может быть равно дате документа или дате начала ремонта (ранее дата начала ремонта не проверялась). В противном случае выводится сообщение в отчет. При исправлении, неверные даты меняются на дату создания документа.
102.1105028.10.31.0Исключить проверку поля PRIKAZ.CORGISНастройкаЧистка каталога организаций
Исключить проверку поля PRIKAZ.CORGIS для TIPDOC==2 из работы функции, поскольку проставляемая в нем ссылка не является NREC организации!Исключил проверку поля PRIKAZ.CORGIS для TIPDOC=2 из работы функции.
102.1084828.10.30.0Как-то неправильно формируем ДО из рекламационных накладных в КонсигнацииУправление консигнационным товаромНакладные на возврат
Как-то неправильно формируем ДО из рекламационных накладных (отпуск/прием) в Консигнации: есть кнопка Формирование ДО - создали. Теперь если выполнить проурку КОУ(ДО), то получим: Проверка документов-оснований Отпуск на консигнацию № MIV@000044 от 17/06/2011: в ДО указано неправильное направление. (Table BaseDoc NRec = 4611761425754808892) Прием на консигнацию № MIV@123456790 от 03/06/2011: в ДО указано неправильное направление. (Table BaseDoc NRec = 4611881807882871289) Выявлено ссылок на несуществующие неправильных направлений: 2 Проверка документов-оснований закончена Может, как в Сбыте/Снаюжении для рекламаций убрать(задисайблить) данную кнопку, а то получаем некорректности.Исправили ошибку при проверку КОУ в ДО на консигнаци по типу документа.
102.1080538.10.29.0Дебет и кредит по Договорам уступки долга ( покупка)(продажа)Расчеты с поставщиками и получателямиАкт сверки взаиморасчетов с контрагентом по ДО
Дебет и кредит по Договорам уступки долга ( покупка)(продажа) Суммы по документам "Договор уступки долга ( покупка)(продажа)" в отчет "Акт сверки взаиморасчетов с контрагентами по ДО" не верно выводятся. Суммы по покупке должны выводится по кредиту,а они встают в дебет, по продажам - наоборот. Подробности в прикрепленном файле.Договора уступки долга (продажа и покупка) отображаются в Акте сверки взаиморасчетов про до и в Оперативном сальдо контрагентов с верным направлением
102.1084808.10.29.0Непонятки в протоколе с документом МБППроверка КОУПроверка накладных
При проверке КОУ для накладных Спецоснастка -> Склад в протокол выводится следующее: Накладная на передачу МБП на склад № MIV@000009 от 09/06/2011: нет ссылки на пояснение по статусу. (Table KatSopr NRec=4611700466447278714)Из проверки КОУ для накладной Спецоснастка->Склад убрана проверка наличия ссылки на пояснение по статусу, т.к. данная накладная не использует статусы.
102.1072348.10.28.0Проверка накладных в КОУПроверка КОУПроверка накладных
При проверке накладных в КОУ с исправлением некорректных записей клиент получил следующий отчет "неправильная дата проведения (01/04/2011 вместо 01/04/2011)" см. вложениеДаты отображаются корректно.
102.1083018.10.28.0Неправильные суммы в валютеУправление сбытомИерархический реестр накладных/актов
Неправильные суммы в валюте в реестре накладных/актов.Реестр формировался неверно из-за некорректных ссылок на валюту по позициям спецификации накладных. Доработана проверка КОУ накладных на соответствие валюты документа и позиций спецификации.
106.93708.10.27.0Договор уступки собств.долга не верно отображается в расчетах с контрагентамиРасчеты с поставщиками и получателямиДоговоры уступки собственного долга
Договор уступки собств.долга не верно отображается в расчетах с контрагентами Договор уступки собственного долга неверно отображается в расчетах с контрагентами (подробности во вложении). Установлены актуальные обновления на 07/04/2011 (отчет о системе прилагается). Проверку КОУ запускали - не помогло.Договора уступки собственного долга для BaseFin.TiDkGal = 92 - Direct = 1 Для исправление ранее введенных документов необходимо запустить проверку КОУ для ДО В расчетах с контрагентами отображается верно
102.1006278.10.26.0Добавить проверку существования записиПроверка КОУПроверка остатков МЦ
Добавить проверку существования записи в таблице TekMC в проверку остатков МЦ. Иначе при запуске данной проверке и наличие такой записи будет выдаваться ошибочное сообщение, о том что запись создать нельзя. В таблице TekMC уникальный ключ по полю cMC. и Такой ситуации не должно быть (запись в таблице KatMC нет, а ссылка в TekMC есть) но получается надо обработать.Добавлена проверка на существование записи.Сообщение не выдается.
102.1032608.10.26.0При проверке КОУ - некорректность с документом 251Управление консигнационным товаромОснование
При проверке КОУ - некорректность с документом 251 - Акт реализации отпущенных на консигнацию МЦ Проверка накладных Документ с видом <251> № MIV@000000 от 16/11/2010: в ТТИ в поле "Доверенность" указан несуществующий номер доверенности. (Table KatSopr NRec=4611720192028869466) Документ с видом <251> № MIV@000000 от 16/11/2010: в ТТИ в поле "Доверенность" указан несуществующий номер доверенности. (Table KatSopr NRec=4611805253088320782) Накладная на отпуск товара на консигнацию № MIV@000046 от 16/11/2010: разноска ТХО некорректна. (Table SoprHoz NRec=4611852093492836103) Документ с видом <251> № MIV@000000 от 23/11/2010: в ТТИ в поле "Доверенность" указан несуществующий номер доверенности. (Table KatSopr NRec=4611962353603324348) Проверка накладных законченаПри проверке КОУ исправили некорректное сообщение для документа 251 - Акт реализации отпущенных на консигнацию МЦ.
102.1066118.10.26.0Кому верить: есть спецификации с нулевым количеством или нет?Проверка КОУПроверка накладных
Тип 421 в проверке КОУ - заменен на "Распоряжение на отпуск МТР". Проверка КОУ больше не находит в них нулевые позиции.Тип 421 в проверке КОУ - заменен на "Распоряжение на отпуск МТР". Проверка КОУ больше не находит в них нулевые позиции.
102.980218.10.26.0Протокол проверки статусовПроверка целостности таблицПроверка статусов
Протокол проверки статусов После совместного совещания между "Топ Софт" и "Керамин", клиент прислал протоколы проверки БД и саму обезличенную базу. Клиент утверждает: после запуска проверки целостности таблиц (Проверка целостности таблиц Проверка статусов) выдается очень большой отчет с информацией (см. вложение) Что должен предпринять клиент на основании отчета: Проблема в выводе отчетов? Нарушение целостности БД? Насколько существенны ошибки? \OTP-SERVERotp_dkeramin20100105dbcheck eports_obezlich -ссылка на протоколы Host Name: oit-server702.oit.local -БД Keramin (Oracle) Port Number: 1521По данной проблеме исправлено: Подсчет обработанных документов. Количество проверенных документов каждого типа будет равно количеству всех документов данного типа. P.S. Для ошибок, описанных ниже проверка работае корректно. Информация по остальным ошибкам из протокола: a) ошибка вида "... Некорректная ссылка на статус (=0)" Данная ошибка проявляется для старых документов до 2008 года. В данных документах: - Основание на закупку - ЛЗК на отпуск в производство - Накладная на отпуск МЦ - Накладная на отпуск в производство - Накладная на приход готовой продукции - Накладная на возврат сырья из производства - Акт на списание МЦ из производства - Накладная на внутреннее перемещение /склад-склад - Акт инвентаризации об излишке МЦ - Акт инвентаризации о недостаче МЦ - Договор отстутствует обязательная ссылка на статус документа. На новых документах данная ссылка заполняется правильно. После запуски проверки в режиме исправления для данных документов подставится статус по умолчанию и ошибка в протокол не будет появляется. b) ошибка вида "... Несоответствие вида документа (=100)" проявляется для документов - Акт на списание МЦ со склада - Накладная на внутреннее перемещение /склад-склад - Акт инвентаризации об излишке МЦ - Акт инвентаризации о недостаче МЦ - Акт на комплектование (пакетирование) - Акт на разукомплектование (распакетирование) из-за того, что была изменена статусная ситема. данная ошибка проявлятся для старых документов. После запуска проверки в режиме исправления ошибка исчезнет.
103.46508.10.26.0Криво считается остаток по спецификации договораУправление договорамиСпецификация
Выбираю мц/услугу из каталога, вношу количество вроде все ок.. После вставки спец. перебиваю количество - получаю 0 в остатке. см. мульт во вложении и отчет о системе+патчи PS: 102.97750 - смотрел 102.98225 - читал и выполнял. И на самом деле не корректное решение. У меня на базе этого клиента нашлось 80000 записей с 2002 года тогда производства не былоПри проверке КОУ ссылка на спецификацию договора/соглашения/ПКП SpSopr.cSpDocs, которая не соответствует ссылке на договор/соглашение/ПКП в шапке документа обнуляется.
102.1028878.10.25.0Проверка КОУ не исправляет некорректные спецификации распоряжений МТРКонтур логистикиНе знаю, какая именно часть контура логистики, научите
Проверка КОУ не исправляет некорректные спецификации распоряжений МТР.Доработана проверка КОУ для накладных в части проверки спецификации распоряжений МТР.
102.1024908.10.24.0Не то направление договоров цессии(лично для Ждановича Ю.Г.)Расчеты с поставщиками и получателямиДоговоры уступки долга (покупка)
Не верно формируются BASEDOC.DIRECT и BASEDOCMIRROR.DIRECT в следующих типах документов : тип 92 BASEDOC.DIRECT должен быть 2-закупка, а формируется 1 . Тип 94 BASEDOCMIRROR.DIRECT должен быть 1, а формируется 2 Тип 91 BASEDOC.DIRECT должен быть 2-закупка, а формируется 1 Тип 93 BASEDOCMIRROR.DIRECT должен быть 1, а формируется 2Доработано формирование BasaeDoc.Direct в договорах цессии: Тип 90 BASEDOC.DIRECT должен быть 1 Тип 91 BASEDOC.DIRECT должен быть 2-закупка тип 92 BASEDOC.DIRECT должен быть 2-закупка Тип 95 BASEDOC.DIRECT должен быть 2-закупка Тип 93 BASEDOC.DIRECT должен быть 1 Тип 94 BASEDOC.DIRECT должен быть 1 90 Договор уступки долга (продажа) 91 Договор уступки долга (покупка) 92 Договор уступки собственного долга 95 Договор уступки собственного долга (спецификация) 93 Договор уступки долга (оплата должником) 94 Договор уступки долга (продажа, спецификация) Доработана проверка КОУ
102.758118.10.24.0Работа не должна завершаться молча.НастройкаПересчет налогов в договорах, соглашениях, ПКП
Работа не должна завершаться молча. Нет информации о завершении работы функции - а надо.По окончании выдается сообщение о завершении пересчета
102.758128.10.24.0Аналогично и для функции Пересчет налогов по услугам актов реализацииНастройкаПересчет налогов в договорах, соглашениях, ПКП
Аналогично и для функции Пересчет налогов по услугам актов реализации (пункта нет в ПИРе) Работа не должна завершаться молча. Нет информации о завершении работы функции - а надо.По окончании пересчета выдается сообщение.
102.970158.10.24.0Добавить в CheckOper проверку документов 420,446,447,448,449Складской учетРаспоряжение на возврат-отпуск МТР
Добавить в CheckOper проверку документов 420,446,447,448,449. При проверке КОУ на данные документы выдается сообщение о некорректности, хотя количество не нулевое.Добавлена проверка документов 420,442,446,447,448,449.
102.975468.10.24.0Вернуть обработку актов на оказание услуг в проверку КОУПроверка КОУПроверка накладных
Вернуть обработку актов на оказание услуг в проверку КОУ! В рамках решения проблемы 102.38833 был закомментирован!!! вывод ошибочных ситуаций при проверке актов на оказание услуг(Сбыт). И теперь все, что касается документа 211, в протокол проверки не выводится ни одна ошибочная ситуация, типа некорректной даты проведения, ссылки на СФ... Вышеказанную проблему закрыл в 2004 году, т.к. в протокол ошибок не выводилось.Возвращена обработка актов на оказание услуг в проверку КОУ.
180.24948.10.24.0Подставляет любую отпускную единицу при создании МЦ под MS SQLНастройкаКаталог МЦ
Проявляется только на платформе MS SQL Вхожу в каталог МЦ, нажимаю F7 - создается пустая карточка МЦ, но под кнопкой Отпускные единицы - запись - Есть отпускные единицы. Затем ввожу наименование МЦ, выбираю учетную единицу, а отпускная при этом остается неизменной. В итоге, если не зайти под кнопку и не исправить, может получиться так, что учетная - КГ, а отпускная - ШТУКА.При проверке катлагов проверяет отп.ед.изм на правильность ссылки (мц, услуг, гр мц и услуг, и шаблонов).
102.1008508.10.22.1Объединить ф-ции по определению соответствия вида статуса виду документаУправление сбытомПредложение по новой функциональности модуля Управление сбытом
Объединить ф-ции по определению соответствия вида статуса виду документаРазработана общая функция для получения вида статуса по виду документа. Проверять настройку прав общего доступа, создание новых документов с настройкой, возможность зайти в старые документы.
102.1002088.10.22.0В проверки КОУ добавить проверку по статусамПроверка КОУПроверка накладных
В процедуру проверки КОУ для накладных добавить следующую проверку по статусам. Данная проверка должна отрабатывать, в случае перехода с общих статусов документов на собственные. Недавно, например, возникла проблема с типами 204 и 115: ранее у них использовались статусы с типом 100, сейчас у каждого документа свои статусы (тип 204 и 115)Для проверки статусов нужно использовать утилиту, вызываемую по пункту меню "Администратор - Проверка целостности таблиц - Проверка статусов".
102.1006838.10.21.0В проверке КОУ убрать контроль поля cDover для распоряженийСкладской учетРаспоряжение на возврат-отпуск МТР
Проверку убрать для всех распоряжений.Убрана проверка ссылки на доверенность для всех распоряжений в проверке КОУ.
102.1005238.10.20.0Дисайблить параметр , если:НастройкаУдаление старой информации
Дисайблить параметр Хозоперации и обороты по ордерам , если активны Накладные или сальдовые остатки. Т.к. флаг не ставится и не имеет смысла.Параметр недоступен, когда не имеет смысла.
102.1005428.10.20.0Необходимо удалять ордера и остатки ТОРО и УКС, помимо произвводства и складаНастройкаУдаление старой информации
Необходимо удалять ордера и остатки ТОРО и УКС, помимо произвводства и склада, т.е. добавить такие параметры. А также исправить в сообщении вывод удаленных записей сальдо, надо только те, что до даты удаления включительно, а не все из таблицы.Доработано.