Жила -была фирма, работала в "Торговля и склад редакции 8.7". Год назад решилась фирма перейти на редакцию 9.2 (опустим историю о том, почему не УТ 10.3). Перешла, конфигурацию чуть переписали под их спецификацию. Все бы ничего, НО: всплыла проблема. Получают они товар, ручками меняют цены в справочнике, и тут, такая история - при нажатии на кнопку "ОК" в окне "запись периодических реквизитов", все цены в форме справочника цен меняются совершенно как угодно! Никакой логики и закономерности! Но и это еще не все. Случилось это у них - испугались, закрыли справочник, открыли опять - ВСЁ нормально! Все именно так, как и надо, все цены на месте. Еще одна странность - происходит это не постоянно. Работают, работают, все хорошо, а потом бац и плохо! На короткое время помогает перезагрузка компьютера (именно перезаргузка и именно компьютера), а потом опять все по новой. Мною были предприняты меры: тестирование и исправление (ничего не показало), переустановка оболочки (полная, с чисткой реестра), перенос данных между идентичными конфигурациями, полная проверка на вирусы (на всякий случай), полная переустановка Винды -результат нулевой. Заметила странность при переносе данных между идентичными конфигурациями: переносила обработкой Export77/Import77 - в чистую базу переносятся цены только из первой строчки справочника (из закупочной, оптовой и розничной только закупочная, та, что сверху). Думается мне, что все это из-за перехода из редакции 8.7 в 9.2, возможно некорректно перенеслось. Но что делать-то теперь? Может кто-нибудь подскажет? Ужас, как много написала!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Описанное в (1) может быть когда в программе открыты две разные формы списка справочника "Номенклатура" с разными текущими элементами.
В какой то момент подчиненный справочник "переключается" с одной формы на другую, это расценивается как изменение цен на что угодно, хотя это цены другой номенклатуры.
В какой то момент подчиненный справочник "переключается" с одной формы на другую, это расценивается как изменение цен на что угодно, хотя это цены другой номенклатуры.
В штатной типовой ТиС ред.9.2 - таких глюков не замечено.
так что копать в сторону
- "конфигурацию чуть переписали под их спецификацию. " - кривые ручки?
- корректность переноса из старой конфигурации.
.
работы примерно на день усидчиво и упорно. Так как тонкие моменты лично мне известны (ну, я так думаю ;-) и быстренько пробежаться по ним - проблем особых нет.
так что копать в сторону
- "конфигурацию чуть переписали под их спецификацию. " - кривые ручки?
- корректность переноса из старой конфигурации.
.
работы примерно на день усидчиво и упорно. Так как тонкие моменты лично мне известны (ну, я так думаю ;-) и быстренько пробежаться по ним - проблем особых нет.
(2) То, что она переписана была, это я так, к слову сказала, дабы дать полную информацию :) Переделка никоим образом цен не касалась. Сложность еще в том, что у меня не получается воссоздать глюк на их базе у себя (я говорила, что может появиться спустя некоторое время после нормальной работы, возможно одним днем тут не обойтись ;) Скорей всего, дело в переносе из старой редакции. А как можно это побороть??? Глюк не систематический. Может хоть какие-то предположения? Можете поделиться некоторыми "тонкими моментами"? (только в этом вопросе - мне чужого не надо :)
да нет там никаких особых трюков - просто все аккуратно должно быть...
посмотри в сторону: корректного завершения сеансов и ОБЯЗАТЕЛЬНОЙ РЕИНДЕКСАЦИИ ПРИ БАЗЫ ПРИ МОНОПОЛЬНОМ ЗАХОДЕ И ОТВЕТЕ НА ВОПРОС О РЕИНДЕКСАЦИИ - вполне можт быть что просто жмут "нет".
сделать просто:
- при входе каждого юзера - создавай в папке сигнальный файл если его нет.
- если при входе юзера сигнальный файл есть - блокировка входа (с выдачей какого-нибудь предупреждения) и завершение сеанса зашедшего юзера - соответственно юзера начнут орать - это и будет признаком "некорректной" работы... - есоли ора много - тогда сделай так, чтобы нельзя было сказать "нет" на вопрос "переиндексировать базу?"
.
ну и напиши пару мелких тривиальных обработок на проверку корректности подчиненности цен номенклатуре...
посмотри в сторону: корректного завершения сеансов и ОБЯЗАТЕЛЬНОЙ РЕИНДЕКСАЦИИ ПРИ БАЗЫ ПРИ МОНОПОЛЬНОМ ЗАХОДЕ И ОТВЕТЕ НА ВОПРОС О РЕИНДЕКСАЦИИ - вполне можт быть что просто жмут "нет".
сделать просто:
- при входе каждого юзера - создавай в папке сигнальный файл если его нет.
- если при входе юзера сигнальный файл есть - блокировка входа (с выдачей какого-нибудь предупреждения) и завершение сеанса зашедшего юзера - соответственно юзера начнут орать - это и будет признаком "некорректной" работы... - есоли ора много - тогда сделай так, чтобы нельзя было сказать "нет" на вопрос "переиндексировать базу?"
.
ну и напиши пару мелких тривиальных обработок на проверку корректности подчиненности цен номенклатуре...
Спасибо за внимание - Вы единственный, кто откликнулся (я оценила :), но вариант с некорректной работой с базой отпадает, потому как тестирование исправило бы ситуацию (хотя бы временно), да и с ценами тоже все в порядке, имею ввиду, все подчинены, все узнаются документами, обработки ничего не показывают и т.д. Да, видимо, не судьба мне решить этот вопрос, первый раз такое вижу! Но, все равно, спасибо :)
этот тонкий момент давно известен ;-)
на тебе еще тонкий момент: открой номенклатуру, рядом открой подчиненный справочник цен и попробуй в номенклатуре воспользоваться быстрым поиском по первым набираемым символам...
;-)
на тебе еще тонкий момент: открой номенклатуру, рядом открой подчиненный справочник цен и попробуй в номенклатуре воспользоваться быстрым поиском по первым набираемым символам...
;-)
(13) все очень просто! не надо одновременно делать несколько работ! не надо держать открытыми форм больше чем необходимо. Ябу ябуди наоди муди - как говорят японцы - Шаг за шагом к поставленной цели! Работа должна делаться НЕ ВСЯ СРАЗУ ВСЯ ВОТ ЗДЕСЬ, а маленькими декопозиционными шажками... а то ломанулись одно делать - не завершили - полезли другое делать...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот