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


Описание файла обновления:
ФайлC_CHECKOPER_RES_810400.txt
ОбновлениеC_CHECKOPER_RES_810400
НазначениеОбщее
ПродуктГалактика 8.10
Релиз03.11.2006 : Atlantis 5.2.8
КомпонентC_CHECKOPER
ТипRES
Версия8.10.40.0
Дата2013-11-25 12:21:28
Проблема ПИРПервое решениеОписаниеПроектДетализация
Что изменено:Как изменено:
101.53172NEWПосле удаления старой информации возникли проблемы в отчете наличие по складамСкладской учетНаличиепо складам
После удаления старой информации возникли проблемы в отчете наличие по складам После выполнения функции удаления старой информации (удаление сальдовых остатков и ордеров до 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Необходимо удалять ордера и остатки ТОРО и УКС, помимо произвводства и складаНастройкаУдаление старой информации
Необходимо удалять ордера и остатки ТОРО и УКС, помимо произвводства и склада, т.е. добавить такие параметры. А также исправить в сообщении вывод удаленных записей сальдо, надо только те, что до даты удаления включительно, а не все из таблицы.Доработано.
102.840978.10.20.0Доработать функцию удаления старой информации в части карточки МТРНастройкаУдаление старой информации
Доработать функцию удаления старой информации в части карточки МТР: удалять невалидные записи в карточке МТР, т.к. полный перечет сальдо МТР - долгий....доработано
102.996698.10.20.0Проблема при формировании СФ в многопользовательском режимеРасчеты с поставщиками и получателямиНаши счета-фактуры
При многопользовательском режиме появляются длительные блокировки при формировании СФ. При единичном формировании СФ по сопроводительным документам или платежам выдаются сообщения "Некорректный параметр Покупки/Продажи.", "Процесс заблокирован другим пользователем, ждите...".1. При формировании номера СФ вызываются семафоры с указанием дескриптора пользователя, который данный семафор установил. Это будет очень полезно при блокировании - можно узнать кто именно блокирует систему и перегрузить только его сеанс, а не всю базу данных. 2. Пакетное формирование СФ в ФРО, настройка Формировать авансовые СФ, начиная с номера. Доработана проверка номера, если в нем нет ни одной цифры, то пакетное формирование не запускается, т.к. не понятно, как формировать номера СФ и система может зависнуть. Примечание. Если, например, в номере только одна цифра, а создается более 10-ти записей, то для 11-го СФ и далее номер не может быть сформирован и СФ будут формироваться с пустыми номерами. 3. Доработан интерфейс проверки КОУ, накладных. Если у них есть ссылка на несуществующий СФ или на СФ с неправильным направлением, то ссылка обнуляется. Это, в частности, позволяет избежать сообщения при попытке формирования СФ о некорректном параметре и создание СФ проходит корректно.
102.996818.10.20.0В фильтр по группе попадают МЦ из другой группыНастройкаКаталог МЦ
В фильтр по группе попадают МЦ из другой группы При выборе Фильтра по группе матценностей для выбранной и вложенным группам МЦ в список попадают МЦ из другой группы.Настройка Администратор Проверка целостности таблиц проверка каталогов при проверке каталога матценностей с установленной опцией "При проверке исправлять некорректные записи" происходит корректное добавление недостающих записей в каталог единиц измерений. При этом проверка каталога не прерывается и отрабатывает до конца, исправляя несоответствие кода группы МЦ в каталоге МЦ и кода группы МЦ в каталоге групп МЦ. В каталоге МЦ при перемещении по записям происходит проверка на несоответствие кодов группы МЦ между каталогом МЦ и каталогом групп МЦ .
102.973598.10.19.0Добавить новый документ - распоряжение на отпуск МТРУправление договорамиРаспоряжение на прием-отпуск МТР
Добавить новый документ - распоряжение на отпуск МТРВ модуль "Управление сбытом" добавлен новый документ: Распоряжение на отпуск МТР. Данный документ доступен из одноименного пункта главного меню модуля. В накладной на отпуск распоряжение выбирается из расширеннной информации окна редактирования накладной на отпуск. Расбота распоряжения аналогична распоряжениям в складском учете.
102.954288.10.18.0Утилита проверки спецификации сопрдоков на ссылки на спецификацию СФРасчеты с поставщиками и получателямиНаши счета-фактуры
Написать утилиту проверки спецификации сопрдоков на ссылки на спецификацию СФ. Проблема возникла у клиента Лепсе. По какой-то причине не проставились ссылки. В накладной есть ссылка на СФ, но у некоторых позиций спецификации нет ссылки cSpSchF на позицию спецификации СФ. Код по проверке вставить также в функционал проверки КОУ.Доработка проверяет и исправляет ситуацию, когда у сопроводительного документа есть ссылка на счет-фактуру, но у некоторых ее позиций спецификации ссылка на спецификацию СФ не задана. В этом случае в спецификации СФ идет поиск соответствующей позиции, которая совпадает со спецификацией сопрдока по МЦ/услуге, количеству, цене и на которую не ссылается ни одна другая позиция сопрдока. Если такая позиция найдена и она единственная (обязательное условие!), по ссылка на нее устанавливается в спецификации сопроводительного документа. Проверку можно сделать 2-мя способами: 1. Через интерфейс Проверка КОУ, как одну из частей проверки накладных. 2. Через отдельную утилиту, которую можно загрузить как внешний интерфейс L_SF::UTILSPSOPR_SPSCHF (L_SF.res), запускать без параметров. В интерфейсе есть 2 режима - режим проверки, при котором отображается протокол с найденными некорректностями, и режим исправления, при котором идет попытка исправить найденные некорректности. Проверяются все сопроводительные документы в системе.
102.961018.10.18.0Тип документа в претензии, если ДО на консигнациюУправление договорамиПретензии к дебиторам
По договору сформировано ДО "Отпуск на консигнацию". В качестве сопроводительного документа сейчас берется "Накладная на отпуск товара консигнатору". А оплата распределяется по актам на реализацию, по этому и задолженность по оплате возникает по этим актам. Так что в качестве сопроводительного документа в претензии должны фигурировать акты на реализацию.При создании акта на реализацию не заполнялся договор. Из-за этого акт не поподал в иски в иски поподают только акты на реализацию Для корректной работы нужно провести проверку КОУ по накладным
101.434838.10.17.0Медленная работа сервисной функции "Чистка каталога МЦ"НастройкаЧистка каталога МЦ
У клиента в каталоге 56 тысяч записей. На данный момент размер базы данных порядка 100 Гб. При запуске функции, при обработке таблицы Sporder 3% за 1 час 20 минут. Общее время подсчитать невозможно, но явно оно будет более суток. Получается, что предприятие не может воспользоваться данной функцией, на такой срок невозможно остановить работу системы. (Платформа MS SQL).оптмизирован алгоритм: a) изменен алгоритм обработки таблицы SpOrder b) изменен алоритм проверки таблиц производственного контура, которые имеют ссылки на МЦ