Проблема производительности. Как может заблокировать работу в ERP один-единственный документ от 01.01.2099 года?
Платформа 1С v8.3
1С:ERP Управление предприятием 2
1С:Комплексная автоматизация 2.х
1С:Управление торговлей 11
Отзывы
(17)Вот-вот. Как будто 1С вчера появилась и подобных ошибок предположить ребята-разработчики не могли проектируя такое сложное решение. Ведь сама 1С разработала стандарты, в том числе написания запросов и т.д. Впечатление, что пишут настолько разные люди, что кто-то соблюдает стандарты, кто-то около того(в статье о комментариях привел в пример два модуля, один "голый", ни единого коммента, второй привычный, как полагается, как пишет сама 1С в своих стандартах).
Вообще, системы 1С усложняются все больше, превращаясь в монстров, на мой взгляд, не всегда оправданно, к примеру, в УХ дали задачу посмотреть почему не формируются счета номенклатуры в документе, я пока прошел по всем модулям в отладчике, потратил около 4-х часов, и в конце концов пришел к месту в коде, где по типу номенклатуры, например, "Товар" присваивается программно 41 счет. Зачем такая сложность, куча проверок, сложного кода, когда проще было сделать как раньше, регистр с одноименным названием - "Счета учета номенклатуры", заполнить его и вести, и гораздо проще, и быстрее, плюс конфа будет меньше "весить". Ну да, человеческий фактор, это ж надо себя заставлять, заполнять, вести, следить)).
Сейчас в семействе УТ, КА, ЕРП наблюдается система жизненных циклов, насколько я вижу, поддержка 2.4 прекратилась с мая 2022 и даже внутри 2.5 тоже самое, 2.5.8 сколько-то живет, поживет-поживет и отомрет, переходи на 2.5.9.
Люди только-только внедрили 2.4, потратив кучу денег и сил, и теперь хочешь, не хочешь переходи на 2.5.8(не важно какая версия, она все равно будет ограничена по времени), к примеру, а она до апреля 2023 и так дальше.
Такие сложные системы, на мой взгляд, эффективнее выпускать в виде блоков, в той же КА сколько раз видел, как БП подсистемой не хочет народ пользоваться(по сути, "висит", ненужный блок), пилят различные обмены, выгрузки и т.д. в БП, из-за регламентного формирования движений, как это мотивирует 1С почему так, судя по учебным роликам, потому что во главе оперативный учет. Так и выпустите основной блок УТ 11, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
Вообще, системы 1С усложняются все больше, превращаясь в монстров, на мой взгляд, не всегда оправданно, к примеру, в УХ дали задачу посмотреть почему не формируются счета номенклатуры в документе, я пока прошел по всем модулям в отладчике, потратил около 4-х часов, и в конце концов пришел к месту в коде, где по типу номенклатуры, например, "Товар" присваивается программно 41 счет. Зачем такая сложность, куча проверок, сложного кода, когда проще было сделать как раньше, регистр с одноименным названием - "Счета учета номенклатуры", заполнить его и вести, и гораздо проще, и быстрее, плюс конфа будет меньше "весить". Ну да, человеческий фактор, это ж надо себя заставлять, заполнять, вести, следить)).
Сейчас в семействе УТ, КА, ЕРП наблюдается система жизненных циклов, насколько я вижу, поддержка 2.4 прекратилась с мая 2022 и даже внутри 2.5 тоже самое, 2.5.8 сколько-то живет, поживет-поживет и отомрет, переходи на 2.5.9.
Люди только-только внедрили 2.4, потратив кучу денег и сил, и теперь хочешь, не хочешь переходи на 2.5.8(не важно какая версия, она все равно будет ограничена по времени), к примеру, а она до апреля 2023 и так дальше.
Такие сложные системы, на мой взгляд, эффективнее выпускать в виде блоков, в той же КА сколько раз видел, как БП подсистемой не хочет народ пользоваться(по сути, "висит", ненужный блок), пилят различные обмены, выгрузки и т.д. в БП, из-за регламентного формирования движений, как это мотивирует 1С почему так, судя по учебным роликам, потому что во главе оперативный учет. Так и выпустите основной блок УТ 11, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
Остальные комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Было бы полезно иметь не только картинки, отображающие текст, но и их тексты натурально. Это позволит
- искать по ним
- копировать
- разглядеть в хорошо читаемом размере шрифта без необходимости открывать картинку в новом окне, о чем кстати многие не знают
- искать по ним
- копировать
- разглядеть в хорошо читаемом размере шрифта без необходимости открывать картинку в новом окне, о чем кстати многие не знают
У нас в базе есть документ фактически из следующего тысячелетия.
Прям вот так?
Вообще, в 1С таких костылей овер дофига. Как-то смотрел, как строится запрос по ДЗ/КЗ, так там тоже такой вот "бесконечный" цикл. И то, что там был мелкомягкий скуль, горю мало помогало.
(40) Автор, смотрю, поправил. Это как "вы из другой галактики? А мы из Чертаново!" (вот серьезно, прям с Магелланова облака летели, да?), хотя в 90-х авторы были грамотнее и писали, что из другого созвездия (хотя в одном созвездии расстояние между звездами в сотни парсек может быть, а в современной астрономии созвездие - это просто участок неба), хотя самое правильное было бы просто "из другой звездной системы" (и то правда, ибо в солнечной-то системе жизнь пока найдена лишь на Земле-родимой). Так что работа с большими цифрами и расстояниями - это больная проблема миллениалов и людей, который под них косят )))
Сколько совокупно ушло времени на расследование проблемы? Это всегда забавно - когда незначительный косяк в пользовательских данных, который делается за 1 секунду - отнимает потом +-день на расследование ) Но зато, такие кейсы делают нас сильнее.
(12) прежде чем лазить в код - надо смотреть на явные косяки в базе на пользовательском уровне.
со времен клюшек два явных косяка с документами/регистрами - документы в начале времен и документы далеко в будущем. Это почти всегда "логическая" ошибка. Даже в код не надо лазить... В код уже лезть когда другое не помогает...
со времен клюшек два явных косяка с документами/регистрами - документы в начале времен и документы далеко в будущем. Это почти всегда "логическая" ошибка. Даже в код не надо лазить... В код уже лезть когда другое не помогает...
(19) А здесь вопрос - что быстрее найти: ошибку в данных в базе где работает овер 1000 пользователей (можно представить интенсивность ввода документов и справочников и вообще количество данных) или использовать инструментарий поиска проблем? Мое мнение - работа с инструментарием куда интереснее чем копание в данных. У такого подхода есть существенный плюс - между делом можно найти и другие потенциальные проблемы, которые можно зафиксировать в бэклог и потихонечку заняться их устранением.
(19)
Без инструментария найти что-то практически не возможно. А тыкать пальцем в данные, на мой взгляд, все равно что играть в спортлото.
Проблемы часто встречаются в тех местах где их не ждешь. К тому же, для каждого случая должно быть объяснение причин и рекомендации по их устранению.
У нас есть методика по поиску и устранению проблем, в рамках нее мы и работаем.
Без инструментария найти что-то практически не возможно. А тыкать пальцем в данные, на мой взгляд, все равно что играть в спортлото.
Проблемы часто встречаются в тех местах где их не ждешь. К тому же, для каждого случая должно быть объяснение причин и рекомендации по их устранению.
У нас есть методика по поиску и устранению проблем, в рамках нее мы и работаем.
А есчо с такими движениями, тормоза будут и не только от алгоритмов такого плана. Если более менее насыщеный регистр, там еще итогов стока наплодится. А если он еще не накопления а бухгалтерии, и без алгоритмов все колом встанет.
Спасибо за автору за интересные подробности. Мне пришлось столкнуться с похожей проблемой, но там неверная дата была в прошлом - 215 год вместо 2015. Обнаружилось это из-за тормозов проведения складских документов, а причину нашли посмотрев размеры файлов регистров - и нашли раздувшийся (уже не помню его название), после чего запросом нашли проблемную дату и создавший эту дату документ.
(17)Вот-вот. Как будто 1С вчера появилась и подобных ошибок предположить ребята-разработчики не могли проектируя такое сложное решение. Ведь сама 1С разработала стандарты, в том числе написания запросов и т.д. Впечатление, что пишут настолько разные люди, что кто-то соблюдает стандарты, кто-то около того(в статье о комментариях привел в пример два модуля, один "голый", ни единого коммента, второй привычный, как полагается, как пишет сама 1С в своих стандартах).
Вообще, системы 1С усложняются все больше, превращаясь в монстров, на мой взгляд, не всегда оправданно, к примеру, в УХ дали задачу посмотреть почему не формируются счета номенклатуры в документе, я пока прошел по всем модулям в отладчике, потратил около 4-х часов, и в конце концов пришел к месту в коде, где по типу номенклатуры, например, "Товар" присваивается программно 41 счет. Зачем такая сложность, куча проверок, сложного кода, когда проще было сделать как раньше, регистр с одноименным названием - "Счета учета номенклатуры", заполнить его и вести, и гораздо проще, и быстрее, плюс конфа будет меньше "весить". Ну да, человеческий фактор, это ж надо себя заставлять, заполнять, вести, следить)).
Сейчас в семействе УТ, КА, ЕРП наблюдается система жизненных циклов, насколько я вижу, поддержка 2.4 прекратилась с мая 2022 и даже внутри 2.5 тоже самое, 2.5.8 сколько-то живет, поживет-поживет и отомрет, переходи на 2.5.9.
Люди только-только внедрили 2.4, потратив кучу денег и сил, и теперь хочешь, не хочешь переходи на 2.5.8(не важно какая версия, она все равно будет ограничена по времени), к примеру, а она до апреля 2023 и так дальше.
Такие сложные системы, на мой взгляд, эффективнее выпускать в виде блоков, в той же КА сколько раз видел, как БП подсистемой не хочет народ пользоваться(по сути, "висит", ненужный блок), пилят различные обмены, выгрузки и т.д. в БП, из-за регламентного формирования движений, как это мотивирует 1С почему так, судя по учебным роликам, потому что во главе оперативный учет. Так и выпустите основной блок УТ 11, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
Вообще, системы 1С усложняются все больше, превращаясь в монстров, на мой взгляд, не всегда оправданно, к примеру, в УХ дали задачу посмотреть почему не формируются счета номенклатуры в документе, я пока прошел по всем модулям в отладчике, потратил около 4-х часов, и в конце концов пришел к месту в коде, где по типу номенклатуры, например, "Товар" присваивается программно 41 счет. Зачем такая сложность, куча проверок, сложного кода, когда проще было сделать как раньше, регистр с одноименным названием - "Счета учета номенклатуры", заполнить его и вести, и гораздо проще, и быстрее, плюс конфа будет меньше "весить". Ну да, человеческий фактор, это ж надо себя заставлять, заполнять, вести, следить)).
Сейчас в семействе УТ, КА, ЕРП наблюдается система жизненных циклов, насколько я вижу, поддержка 2.4 прекратилась с мая 2022 и даже внутри 2.5 тоже самое, 2.5.8 сколько-то живет, поживет-поживет и отомрет, переходи на 2.5.9.
Люди только-только внедрили 2.4, потратив кучу денег и сил, и теперь хочешь, не хочешь переходи на 2.5.8(не важно какая версия, она все равно будет ограничена по времени), к примеру, а она до апреля 2023 и так дальше.
Такие сложные системы, на мой взгляд, эффективнее выпускать в виде блоков, в той же КА сколько раз видел, как БП подсистемой не хочет народ пользоваться(по сути, "висит", ненужный блок), пилят различные обмены, выгрузки и т.д. в БП, из-за регламентного формирования движений, как это мотивирует 1С почему так, судя по учебным роликам, потому что во главе оперативный учет. Так и выпустите основной блок УТ 11, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
(18)
- смотри здесь на портале ответы Нуралиева на вопросы сообщества. Аналогичный мой вопрос - то ли второй то ли третий. Чтобы сделать такую блочную структуру - это надо очень нехило над архитектурой думать. по сути каждый блок работает независимо от кода другого блока. стык только на выходе предыдущего блока и вход текущего блока. Даже получение свободных остатков с блоком резервирования и без блока резервирования - я уже слабо себе представляю - почти никак - насколько изолированы блоки должны быть...
хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
- смотри здесь на портале ответы Нуралиева на вопросы сообщества. Аналогичный мой вопрос - то ли второй то ли третий. Чтобы сделать такую блочную структуру - это надо очень нехило над архитектурой думать. по сути каждый блок работает независимо от кода другого блока. стык только на выходе предыдущего блока и вход текущего блока. Даже получение свободных остатков с блоком резервирования и без блока резервирования - я уже слабо себе представляю - почти никак - насколько изолированы блоки должны быть...
(20)Сергей, так, наверное, народ не зря спрашивает. Что будет дальше? SAP модульная система, к слову, чем не пример? Ключевые слова "надо очень нехило над архитектурой думать". Непременно надо думать, в любом случае, особенно, на перспективу, и не только о развитии продукта, а и о людях прежде всего, ты же им его продаешь, должен представлять как они будут работать, как удобно, как эффективно, как апгрейд, интеграция, развитие и т.д. Про резервирование не совсем ясно, зачем эти блоки разделять на отдельные блоки? Я о более крупном делении. Живой пример, фирма торгует товаром из Китая, есть УТ, БП, ну и ЗуП. Решили открыть свое производство, чтобы из Китая не возить. Смотрят на ЕРП, а там те же УТ и БП, и ЗуП в составе. Почему не сделать отдельно производственное решение, сама только поставка ЕРП стоит около полумиллиона плюс лицензии почти столько же. И получается люди приобретают избыточный функционал, еще раз такие же подсистемы, которые у них уже есть. А ранее приобретенные решения куда девать, если в ЕРП тоже самое также есть? Для производства важно обеспечение материалами, какими-то комплектующими и т.д., пусть УТ этим и дальше занимается. Нужные движения для БП пусть выгружаются в БП же регламентно. БСП, например, появилась, чтобы унифицировать и однообразить служебные вещи, так почему не унифицировать складской блок, производственный, бухгалтерский, бюджетирование, CRM, финансовый, зарплатный и т.д.?
(30)Спасибо, посмотрел. Люди не просто недовольны, а предлагают свое решение, интересно. Расширения это первое, что приходит на ум. Это небольшие модули все же, и в основе ЕРП, где получаешь все и сразу. Я о более крупных блоках. Почему у нас нет отдельной производственной конфигурации? Чтобы была возможность расширяться более гибко, чтобы не дублировать функционал, а использовать существующий, соответственно, и экономить при этом.
(42)
Это не "небольшие модули" и не в основе типового ЕРП.
Есть ядро конфигурации и есть модули (расширения) которые порой могут быть не меньше самого ядра (как бы странна это не показалась на первый взгляд). Например есть модуль (расширение), который расширяет возможности производственного учета (в частности производство БПЛА) при котором основной модуль производственного учета кажется просто детским.
Если конфигурация написана по принципу "монолита" то расширять ее с помощью модулей(расширений) практически никакого смысла нет.
Это небольшие модули все же, и в основе ЕРП, где получаешь все и сразу.
Это не "небольшие модули" и не в основе типового ЕРП.
Есть ядро конфигурации и есть модули (расширения) которые порой могут быть не меньше самого ядра (как бы странна это не показалась на первый взгляд). Например есть модуль (расширение), который расширяет возможности производственного учета (в частности производство БПЛА) при котором основной модуль производственного учета кажется просто детским.
Если конфигурация написана по принципу "монолита" то расширять ее с помощью модулей(расширений) практически никакого смысла нет.
(43)Не люблю спорить и не буду, Вы сами себе противоречите, по Вашей ссылке показано ядро конфигурации, которая носит в названии "ERP", посмотрите на базовый функционал "ядра" приведенный в описании, что это, как не "монолит". По сравнению с ним расширения это небольшие модули и так и должно быть, крупные блоки и наработки лучше встраивать в конфигурацию. И что значит "монолит"? Можно расширить и дополнить и ERP в том числе. Речь же не об этом, а об избытке функционала.
(18) Даже на партнерке, люди пишут, что 1с годами не исправляет критичных недоработок функционала ЕРП, зато в бета-релизах появляются свистоперделки, которые нужны единичным пользователям. LTS-версии живут год... а должны ну хотя бы 3... Вот на этот должна выйти 2.5.12, а ее только к марту выпустят... к сентябрю уберут критичные глюки... с каждым обновлением думаешь... что опять поломали... а исправлять да... часами сидеть в отладчике или (кто не готов) молится и ждать патч... Т
(23)Таким он стал из-за ошибки при вводе данных. Но вот про ограничения на "дурака" разработчики судя по всему не думают, т.е. считают что пользователь всегда все делает правильно, всегда вводит корректные данные, и в среднестатистической компании заводят 5-10 документов в год)
(23) Относительно недавно в КА2 (2.5 кажется, но точно не помню, как и вид документа) смотрел механизм формирования проводок БУ. Запрос тоже формировался программно, содержал порядка 4000+ строк. На выходе - единственная проводка... И вроде все правильно, но зачем...
Если запрос выполняется 60 секунд, то даже если он не блокирует других пользователей явно, я бы все равно его сразу проверил. Поэтому кажется надо мониторить все настолько долгие запросы, т.е. читалка логов должна их сразу помечать и ответственный их должен проверять, если это новый тип (шаблон) долгого запроса. А в статье показалось очень издалека шли поиска такого "слона".
(26) Идея конечно правильная мониторить каждый новый запрос и разбирать его причину. Но ситуация сталкивается с суровой действительностью - их очень много. И для их анализа и классификации сейчас нужно сажать отдельного человека.
Во-первых, очень много запросов, которые нельзя оптимизировать из-за RLS. Иными словами тут мы уперлись в ограничения, использовать новый производительный RLS в текущей версии нельзя, пока не выполним переход на 2.5. А перепиливать архитектуру под редко используемые действия - это слишком долго и дорого, не эффективно.
Во-вторых, куча долгих запросов по отчетам. У пользователей есть возможность отчеты крутить туда, сюда, снимать отборы и т.п.
В-третьих, вручную смотреть так себе удовольствие. Просто так сравнивать запросы по тексту на равно, плохо. Будет очень много задач. Их надо классифицировать. Алгоритм классификации, который мы ранее создали слишком широк. Он сейчас у нас позволяет отнести тип запроса к какому-то ограниченному классу. Требуется более детальное сравнение. Это в дальнейшем можно будет сделать после того как создадим вот этот плагин
Иными словами - это выглядит не так что сегодня появилось два новых запроса и мы их тут же препарировали. Их несколько тысяч каждый день. Работа идет, но не всегда, как я писал выше, можно взять и устранить проблему.
Во-первых, очень много запросов, которые нельзя оптимизировать из-за RLS. Иными словами тут мы уперлись в ограничения, использовать новый производительный RLS в текущей версии нельзя, пока не выполним переход на 2.5. А перепиливать архитектуру под редко используемые действия - это слишком долго и дорого, не эффективно.
Во-вторых, куча долгих запросов по отчетам. У пользователей есть возможность отчеты крутить туда, сюда, снимать отборы и т.п.
В-третьих, вручную смотреть так себе удовольствие. Просто так сравнивать запросы по тексту на равно, плохо. Будет очень много задач. Их надо классифицировать. Алгоритм классификации, который мы ранее создали слишком широк. Он сейчас у нас позволяет отнести тип запроса к какому-то ограниченному классу. Требуется более детальное сравнение. Это в дальнейшем можно будет сделать после того как создадим вот этот плагин
Иными словами - это выглядит не так что сегодня появилось два новых запроса и мы их тут же препарировали. Их несколько тысяч каждый день. Работа идет, но не всегда, как я писал выше, можно взять и устранить проблему.
всего бы этого не было если решения автоматом хотя бы раз в сутки проверяли документы старше ну пусть будет 20 лет и будущими годами, большинство таких ошибок носит характер 0023 год вместо 2023 года
(38)
1. Для данной ситуации такое решение подойдет, но часто встречаются проблемы не такого банального характера.
Но вот есть беда, заказчик и владелец данных со скрипом исправляет ошибки в данных. Те что мешают работать оперативно - мгновенно, а все остальные идут очень тяжело. Видимо по принципу - не мешает работать и ладно, сейчас некогда, как-нибудь потом. А обещанного как известно ждут и ждут. И это не один такой заказчик.
2. Конечно идея интересная написать скрипт, который будет проверять на заведомо не верные данные и делать рассылку. Но если данные не будут исправляться, то эти письма в скором времени будут игнорироваться. Попробую обыграть идею.
1. Для данной ситуации такое решение подойдет, но часто встречаются проблемы не такого банального характера.
Но вот есть беда, заказчик и владелец данных со скрипом исправляет ошибки в данных. Те что мешают работать оперативно - мгновенно, а все остальные идут очень тяжело. Видимо по принципу - не мешает работать и ладно, сейчас некогда, как-нибудь потом. А обещанного как известно ждут и ждут. И это не один такой заказчик.
2. Конечно идея интересная написать скрипт, который будет проверять на заведомо не верные данные и делать рассылку. Но если данные не будут исправляться, то эти письма в скором времени будут игнорироваться. Попробую обыграть идею.
(39) да я больше не вам, а фирме 1С
имхо это надо централизовано делать, а не на откуп франчам и программистам, да и не факт что почта, лучше какое то монопольное раздражающее окно - "пока ты гад не исправишь я тебе постоянно буду напоминать, тебе будет легче исправить чем каждый раз ок жать" :)
ну и почему пользователи не любят исправлять - потому что обычно им свешивают задачу без конкретики "исправь там" (почему все программисты думают что пользватели знают что такое запрос с сортировкой по дате или начальник не вникая в детали теряет важное в постановке), а надо списочек этих документов дать и конкретику, написать исправляй дату этого документа (правильный номер должен быть не старше тольких то лет). А так с Вами согласен, с Заказчиками сложно :)
имхо это надо централизовано делать, а не на откуп франчам и программистам, да и не факт что почта, лучше какое то монопольное раздражающее окно - "пока ты гад не исправишь я тебе постоянно буду напоминать, тебе будет легче исправить чем каждый раз ок жать" :)
ну и почему пользователи не любят исправлять - потому что обычно им свешивают задачу без конкретики "исправь там" (почему все программисты думают что пользватели знают что такое запрос с сортировкой по дате или начальник не вникая в детали теряет важное в постановке), а надо списочек этих документов дать и конкретику, написать исправляй дату этого документа (правильный номер должен быть не старше тольких то лет). А так с Вами согласен, с Заказчиками сложно :)
(38) Сама ошибка с годами в будущем, у меня тоже несколько раз встречалась.
Если смотреть не в скрипты, а со стороны обычного 1С-ка типа меня, то:
Дата 0023 г. успешно отсекается датами запрета редактирования (механизм в каждом продукте 1С есть)
Дата 3023 г. не отсекается датами запрета редактирования (механизма нет)
По идее 1С можно было бы малой кровью механизм дат запрета редактирования допилить, добавив к полю "Запрет до даты" поле "Запрет после даты". Т.к. все подписки проверочные уже есть в конфах и даты проверяются постоянно у документов и регистров, думаю не повлияло бы на производительность проверять не только условие Документ.Дата >= ЗапретДоДаты, но и условие Документ.Дата <= ЗапретПослеДаты.
Если смотреть не в скрипты, а со стороны обычного 1С-ка типа меня, то:
Дата 0023 г. успешно отсекается датами запрета редактирования (механизм в каждом продукте 1С есть)
Дата 3023 г. не отсекается датами запрета редактирования (механизма нет)
По идее 1С можно было бы малой кровью механизм дат запрета редактирования допилить, добавив к полю "Запрет до даты" поле "Запрет после даты". Т.к. все подписки проверочные уже есть в конфах и даты проверяются постоянно у документов и регистров, думаю не повлияло бы на производительность проверять не только условие Документ.Дата >= ЗапретДоДаты, но и условие Документ.Дата <= ЗапретПослеДаты.
(45) Встречное предложение, сделать редактирование даты пользователем максимально затрудненным, по типу редактирования номера. По умолчанию ставить текущую дату сеанса
Ловили неоднократно подобные ошибки, так как вовсю использовалось штрихкодирование документов, как и поиск по штрихкоду, если активна ячейка с датой, а пользователь этого не замечал, то в поле подставлялось со сканера такое... В итоге закрыли редактирование даты глобально, включив только просмотр.
Ловили неоднократно подобные ошибки, так как вовсю использовалось штрихкодирование документов, как и поиск по штрихкоду, если активна ячейка с датой, а пользователь этого не замечал, то в поле подставлялось со сканера такое... В итоге закрыли редактирование даты глобально, включив только просмотр.
(45) реалтайм-проверки дороже по ресурсам сумарно, но тоже можно
но тогда надо еще проверять всякие обработки программистов, которые обычно под полными правами что то делают в обход многих проверок, всякие загрузки не из 1С и 1с-ные обмены, так как оттуда тоже может приехать
ну и кроме быстродействия, это еще ошибки в учете
в фирму 1С писать бесполезно, они всё только голованием теперь определяют )))
но тогда надо еще проверять всякие обработки программистов, которые обычно под полными правами что то делают в обход многих проверок, всякие загрузки не из 1С и 1с-ные обмены, так как оттуда тоже может приехать
ну и кроме быстродействия, это еще ошибки в учете
в фирму 1С писать бесполезно, они всё только голованием теперь определяют )))
(48)Знаете, Вячеслав, однажды мне удалось очень даже быстро убедить 1С в необходимости исправлений.
Дело было в августе 2012 года. Пользователи пожаловались на неправильных расчёт НДФЛ, и я полез разбираться. Оказалось, что в запросе ошибка (все конфигурации «Зарплата и Управление Персоналом», на мой взгляд, славятся каким-то невероятным числом ошибок в запросах, но, в данном случае, речь не об этом).
Нашёл ошибку и решил (вдруг!) написать в 1С.
Вы не поверите, но уже на следующий день вышли новые конфигурации ЗУП, КА и УПП. Под совершенно надуманными предлогами. Об исправленной ошибке в расчёте НДФЛ в сведениях о релизе не было ни слова.
В самом деле: узнай налоговики, что их любимая и доверенная программа неверно считала НДФЛ, их отношения с !С здорово бы осложнились. А фирме 1С оно надо?
Дело было в августе 2012 года. Пользователи пожаловались на неправильных расчёт НДФЛ, и я полез разбираться. Оказалось, что в запросе ошибка (все конфигурации «Зарплата и Управление Персоналом», на мой взгляд, славятся каким-то невероятным числом ошибок в запросах, но, в данном случае, речь не об этом).
Нашёл ошибку и решил (вдруг!) написать в 1С.
Вы не поверите, но уже на следующий день вышли новые конфигурации ЗУП, КА и УПП. Под совершенно надуманными предлогами. Об исправленной ошибке в расчёте НДФЛ в сведениях о релизе не было ни слова.
В самом деле: узнай налоговики, что их любимая и доверенная программа неверно считала НДФЛ, их отношения с !С здорово бы осложнились. А фирме 1С оно надо?