Проблема производительности. Как может заблокировать работу в ERP один-единственный документ от 01.01.2099 года?

0. ivanov660 3880 20.01.23 20:22 Сейчас в теме
Разберем ситуацию, когда создание одного ошибочного документа будущей датой может существенно ухудшить работу пользователей в базе 1С.

Перейти к публикации

Отзывы
18. m_aster 104 24.01.23 22:32 Сейчас в теме
(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, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
fatman78; asu63samaraoil; dmitryada; olexi2012; polskay; vakham; kuzyara; kamisov; elena_veza; user1194361; xantif_2000; EliasShy; shu_vol; ivanov660; +14 Ответить
38. Gilev.Vyacheslav 1903 25.01.23 11:43 Сейчас в теме
всего бы этого не было если решения автоматом хотя бы раз в сутки проверяли документы старше ну пусть будет 20 лет и будущими годами, большинство таких ошибок носит характер 0023 год вместо 2023 года
d_sdr; quazare; sapervodichka; ivanov660; +4 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Nefilimus 75 24.01.23 11:32 Сейчас в теме
Кто-нибудь скиньте уже в 1С ссылку на значение слова "Оптимизация". С каждым релизом всё хуже и хуже...
корум; vakham; kamisov; +3 Ответить
2. tormozit 6870 24.01.23 12:27 Сейчас в теме
ВыполнитьКонтрольРезультатовПровдеения
Опечатка ?
3. ivanov660 3880 24.01.23 12:40 Сейчас в теме
4. tormozit 6870 24.01.23 13:21 Сейчас в теме
Было бы полезно иметь не только картинки, отображающие текст, но и их тексты натурально. Это позволит
- искать по ним
- копировать
- разглядеть в хорошо читаемом размере шрифта без необходимости открывать картинку в новом окне, о чем кстати многие не знают
karpik666; artbear; kser87; +3 Ответить
6. ivanov660 3880 24.01.23 14:15 Сейчас в теме
(4)Приложить файл запроса 10 000 и плана с 60 000 строк?
Или речь про контекст? Или про все вместе
8. starik-2005 2831 24.01.23 14:25 Сейчас в теме
(6) 70к знаков - на 7 статей хватит, т.е. на 70 $m)))
ogroup; Shmell; awk; BurlakovIvan; CherTolik_26rus; +5 Ответить
27. tormozit 6870 25.01.23 07:07 Сейчас в теме
(6) На картинках НЕ показаны 10к или 60к строк, а показаны некоторые фрагменты примерно по 50 строк. Вот их и хотелось бы в текстовом виде. Главное неудобство - на ужатых картинках трудно читать текст.
33. ivanov660 3880 25.01.23 10:05 Сейчас в теме
(27) В следующих статьях учту предложение.
5. Tonik_ 24.01.23 13:23 Сейчас в теме
Почитать расследование было интересно. Спасибо
SergeyTerentyev; ivanov660; +2 Ответить
7. starik-2005 2831 24.01.23 14:23 Сейчас в теме
У нас в базе есть документ фактически из следующего тысячелетия.
Прям вот так?
Вообще, в 1С таких костылей овер дофига. Как-то смотрел, как строится запрос по ДЗ/КЗ, так там тоже такой вот "бесконечный" цикл. И то, что там был мелкомягкий скуль, горю мало помогало.
40. siamagic 25.01.23 12:25 Сейчас в теме
57. starik-2005 2831 15.02.23 13:57 Сейчас в теме
(40) Автор, смотрю, поправил. Это как "вы из другой галактики? А мы из Чертаново!" (вот серьезно, прям с Магелланова облака летели, да?), хотя в 90-х авторы были грамотнее и писали, что из другого созвездия (хотя в одном созвездии расстояние между звездами в сотни парсек может быть, а в современной астрономии созвездие - это просто участок неба), хотя самое правильное было бы просто "из другой звездной системы" (и то правда, ибо в солнечной-то системе жизнь пока найдена лишь на Земле-родимой). Так что работа с большими цифрами и расстояниями - это больная проблема миллениалов и людей, который под них косят )))
9. tigrandis 312 24.01.23 14:30 Сейчас в теме
Сталкивался с этой проблемой в 2017 году в КА2 и думал давно исправили ...
10. kser87 2358 24.01.23 14:35 Сейчас в теме
Генерируемые программно запросы опасная штука. И выборки с неограниченным фактически периодом. Думаю, что в бюджетировании таких полно. Но там вряд-ли на общую производительность так влияет.
11. quazare 3144 24.01.23 16:44 Сейчас в теме
(10) УТ 11.5 почти вся сделана на подобных запросах
12. Shmell 502 24.01.23 17:23 Сейчас в теме
Сколько совокупно ушло времени на расследование проблемы? Это всегда забавно - когда незначительный косяк в пользовательских данных, который делается за 1 секунду - отнимает потом +-день на расследование ) Но зато, такие кейсы делают нас сильнее.
14. ivanov660 3880 24.01.23 17:47 Сейчас в теме
(12) Ориентировочно - в районе 1 часа. Если бы не отвлекали, то скорее всего быстрее.
sapervodichka; +1 Ответить
19. CheBurator 3114 24.01.23 22:41 Сейчас в теме
(12) прежде чем лазить в код - надо смотреть на явные косяки в базе на пользовательском уровне.
со времен клюшек два явных косяка с документами/регистрами - документы в начале времен и документы далеко в будущем. Это почти всегда "логическая" ошибка. Даже в код не надо лазить... В код уже лезть когда другое не помогает...
25. Shmell 502 25.01.23 05:47 Сейчас в теме
(19) А здесь вопрос - что быстрее найти: ошибку в данных в базе где работает овер 1000 пользователей (можно представить интенсивность ввода документов и справочников и вообще количество данных) или использовать инструментарий поиска проблем? Мое мнение - работа с инструментарием куда интереснее чем копание в данных. У такого подхода есть существенный плюс - между делом можно найти и другие потенциальные проблемы, которые можно зафиксировать в бэклог и потихонечку заняться их устранением.
28. CheBurator 3114 25.01.23 07:27 Сейчас в теме
(25) это да. но устранение технологических проблем редко ведет к устранению бардака в учете как такового. а документ от2099 года - ну явно в консерватории что-то не так...
d.snissarenko; Shmell; +2 Ответить
29. Shmell 502 25.01.23 07:28 Сейчас в теме
(28) все верно, нужен комплексный подход )
31. ivanov660 3880 25.01.23 09:30 Сейчас в теме
(19)
Без инструментария найти что-то практически не возможно. А тыкать пальцем в данные, на мой взгляд, все равно что играть в спортлото.
Проблемы часто встречаются в тех местах где их не ждешь. К тому же, для каждого случая должно быть объяснение причин и рекомендации по их устранению.
У нас есть методика по поиску и устранению проблем, в рамках нее мы и работаем.
13. tazhitkov 24.01.23 17:35 Сейчас в теме
А есчо с такими движениями, тормоза будут и не только от алгоритмов такого плана. Если более менее насыщеный регистр, там еще итогов стока наплодится. А если он еще не накопления а бухгалтерии, и без алгоритмов все колом встанет.
15. ivanov660 3880 24.01.23 17:58 Сейчас в теме
(13)Чем больше записей в регистре тем больше думает. Поэтому на демонстрационной базе замедление даже не почувствуется.
16. ildary 20 24.01.23 21:05 Сейчас в теме
Спасибо за автору за интересные подробности. Мне пришлось столкнуться с похожей проблемой, но там неверная дата была в прошлом - 215 год вместо 2015. Обнаружилось это из-за тормозов проведения складских документов, а причину нашли посмотрев размеры файлов регистров - и нашли раздувшийся (уже не помню его название), после чего запросом нашли проблемную дату и создавший эту дату документ.
ivanov660; +1 Ответить
17. kauksi 211 24.01.23 21:08 Сейчас в теме
А всего то, написать одну функцию, проверяющую параметры запроса (даже пусть собранный программно) на необычную дату...
18. m_aster 104 24.01.23 22:32 Сейчас в теме
(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, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
fatman78; asu63samaraoil; dmitryada; olexi2012; polskay; vakham; kuzyara; kamisov; elena_veza; user1194361; xantif_2000; EliasShy; shu_vol; ivanov660; +14 Ответить
20. CheBurator 3114 24.01.23 22:46 Сейчас в теме
(18)
хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.

- смотри здесь на портале ответы Нуралиева на вопросы сообщества. Аналогичный мой вопрос - то ли второй то ли третий. Чтобы сделать такую блочную структуру - это надо очень нехило над архитектурой думать. по сути каждый блок работает независимо от кода другого блока. стык только на выходе предыдущего блока и вход текущего блока. Даже получение свободных остатков с блоком резервирования и без блока резервирования - я уже слабо себе представляю - почти никак - насколько изолированы блоки должны быть...
21. m_aster 104 24.01.23 23:39 Сейчас в теме
(20)Сергей, так, наверное, народ не зря спрашивает. Что будет дальше? SAP модульная система, к слову, чем не пример? Ключевые слова "надо очень нехило над архитектурой думать". Непременно надо думать, в любом случае, особенно, на перспективу, и не только о развитии продукта, а и о людях прежде всего, ты же им его продаешь, должен представлять как они будут работать, как удобно, как эффективно, как апгрейд, интеграция, развитие и т.д. Про резервирование не совсем ясно, зачем эти блоки разделять на отдельные блоки? Я о более крупном делении. Живой пример, фирма торгует товаром из Китая, есть УТ, БП, ну и ЗуП. Решили открыть свое производство, чтобы из Китая не возить. Смотрят на ЕРП, а там те же УТ и БП, и ЗуП в составе. Почему не сделать отдельно производственное решение, сама только поставка ЕРП стоит около полумиллиона плюс лицензии почти столько же. И получается люди приобретают избыточный функционал, еще раз такие же подсистемы, которые у них уже есть. А ранее приобретенные решения куда девать, если в ЕРП тоже самое также есть? Для производства важно обеспечение материалами, какими-то комплектующими и т.д., пусть УТ этим и дальше занимается. Нужные движения для БП пусть выгружаются в БП же регламентно. БСП, например, появилась, чтобы унифицировать и однообразить служебные вещи, так почему не унифицировать складской блок, производственный, бухгалтерский, бюджетирование, CRM, финансовый, зарплатный и т.д.?
dmitryada; espero; +2 Ответить
22. CheBurator 3114 25.01.23 00:47 Сейчас в теме
(21) ну вот и унифицировали... В ЕРП
30. noprogrammer 234 25.01.23 09:29 Сейчас в теме
42. m_aster 104 25.01.23 12:53 Сейчас в теме
(30)Спасибо, посмотрел. Люди не просто недовольны, а предлагают свое решение, интересно. Расширения это первое, что приходит на ум. Это небольшие модули все же, и в основе ЕРП, где получаешь все и сразу. Я о более крупных блоках. Почему у нас нет отдельной производственной конфигурации? Чтобы была возможность расширяться более гибко, чтобы не дублировать функционал, а использовать существующий, соответственно, и экономить при этом.
43. noprogrammer 234 25.01.23 13:04 Сейчас в теме
(42)
Это небольшие модули все же, и в основе ЕРП, где получаешь все и сразу.

Это не "небольшие модули" и не в основе типового ЕРП.
Есть ядро конфигурации и есть модули (расширения) которые порой могут быть не меньше самого ядра (как бы странна это не показалась на первый взгляд). Например есть модуль (расширение), который расширяет возможности производственного учета (в частности производство БПЛА) при котором основной модуль производственного учета кажется просто детским.

Если конфигурация написана по принципу "монолита" то расширять ее с помощью модулей(расширений) практически никакого смысла нет.
44. m_aster 104 25.01.23 14:24 Сейчас в теме
(43)Не люблю спорить и не буду, Вы сами себе противоречите, по Вашей ссылке показано ядро конфигурации, которая носит в названии "ERP", посмотрите на базовый функционал "ядра" приведенный в описании, что это, как не "монолит". По сравнению с ним расширения это небольшие модули и так и должно быть, крупные блоки и наработки лучше встраивать в конфигурацию. И что значит "монолит"? Можно расширить и дополнить и ERP в том числе. Речь же не об этом, а об избытке функционала.
24. kauksi 211 25.01.23 05:00 Сейчас в теме
(18) Даже на партнерке, люди пишут, что 1с годами не исправляет критичных недоработок функционала ЕРП, зато в бета-релизах появляются свистоперделки, которые нужны единичным пользователям. LTS-версии живут год... а должны ну хотя бы 3... Вот на этот должна выйти 2.5.12, а ее только к марту выпустят... к сентябрю уберут критичные глюки... с каждым обновлением думаешь... что опять поломали... а исправлять да... часами сидеть в отладчике или (кто не готов) молится и ждать патч... Т
dmitryada; espero; sapervodichka; zakiap; +4 Ответить
23. dmitryada 25.01.23 03:43 Сейчас в теме
Только я в ШОКЕ, что в стандартном решении, для выполнения стандартной для учётной системы операции не придумали ничего лучше, чем сделать запрос на 60 000 строк? Руки опускаются после такого...
34. ivanov660 3880 25.01.23 10:09 Сейчас в теме
(23)Таким он стал из-за ошибки при вводе данных. Но вот про ограничения на "дурака" разработчики судя по всему не думают, т.е. считают что пользователь всегда все делает правильно, всегда вводит корректные данные, и в среднестатистической компании заводят 5-10 документов в год)
36. muskul 25.01.23 10:12 Сейчас в теме
(34)и на этих 5 документах все работает быстро, поэтому оптимизация не нужна
espero; ivanov660; +2 Ответить
53. shard 273 28.01.23 14:16 Сейчас в теме
(23) Относительно недавно в КА2 (2.5 кажется, но точно не помню, как и вид документа) смотрел механизм формирования проводок БУ. Запрос тоже формировался программно, содержал порядка 4000+ строк. На выходе - единственная проводка... И вроде все правильно, но зачем...
dmitryada; d_sdr; +2 Ответить
26. tormozit 6870 25.01.23 07:01 Сейчас в теме
Если запрос выполняется 60 секунд, то даже если он не блокирует других пользователей явно, я бы все равно его сразу проверил. Поэтому кажется надо мониторить все настолько долгие запросы, т.е. читалка логов должна их сразу помечать и ответственный их должен проверять, если это новый тип (шаблон) долгого запроса. А в статье показалось очень издалека шли поиска такого "слона".
32. ivanov660 3880 25.01.23 10:02 Сейчас в теме
(26) Идея конечно правильная мониторить каждый новый запрос и разбирать его причину. Но ситуация сталкивается с суровой действительностью - их очень много. И для их анализа и классификации сейчас нужно сажать отдельного человека.
Во-первых, очень много запросов, которые нельзя оптимизировать из-за RLS. Иными словами тут мы уперлись в ограничения, использовать новый производительный RLS в текущей версии нельзя, пока не выполним переход на 2.5. А перепиливать архитектуру под редко используемые действия - это слишком долго и дорого, не эффективно.
Во-вторых, куча долгих запросов по отчетам. У пользователей есть возможность отчеты крутить туда, сюда, снимать отборы и т.п.
В-третьих, вручную смотреть так себе удовольствие. Просто так сравнивать запросы по тексту на равно, плохо. Будет очень много задач. Их надо классифицировать. Алгоритм классификации, который мы ранее создали Автоматическая классификация ошибок технологического журнала слишком широк. Он сейчас у нас позволяет отнести тип запроса к какому-то ограниченному классу. Требуется более детальное сравнение. Это в дальнейшем можно будет сделать после того как создадим вот этот плагин Создать плагин статистики по аналогии с pg_stat_statements
Иными словами - это выглядит не так что сегодня появилось два новых запроса и мы их тут же препарировали. Их несколько тысяч каждый день. Работа идет, но не всегда, как я писал выше, можно взять и устранить проблему.
35. muskul 25.01.23 10:12 Сейчас в теме
Зря в заголовке написали ответ. Потому что читая всю статью и поиски в голове витало кто то сделал что то подобное.
37. Светлый ум 281 25.01.23 11:25 Сейчас в теме
В упп такие же проблемы были при документе 3***х годов
38. Gilev.Vyacheslav 1903 25.01.23 11:43 Сейчас в теме
всего бы этого не было если решения автоматом хотя бы раз в сутки проверяли документы старше ну пусть будет 20 лет и будущими годами, большинство таких ошибок носит характер 0023 год вместо 2023 года
d_sdr; quazare; sapervodichka; ivanov660; +4 Ответить
39. ivanov660 3880 25.01.23 12:03 Сейчас в теме
(38)
1. Для данной ситуации такое решение подойдет, но часто встречаются проблемы не такого банального характера.
Но вот есть беда, заказчик и владелец данных со скрипом исправляет ошибки в данных. Те что мешают работать оперативно - мгновенно, а все остальные идут очень тяжело. Видимо по принципу - не мешает работать и ладно, сейчас некогда, как-нибудь потом. А обещанного как известно ждут и ждут. И это не один такой заказчик.
2. Конечно идея интересная написать скрипт, который будет проверять на заведомо не верные данные и делать рассылку. Но если данные не будут исправляться, то эти письма в скором времени будут игнорироваться. Попробую обыграть идею.
41. Gilev.Vyacheslav 1903 25.01.23 12:36 Сейчас в теме
(39) да я больше не вам, а фирме 1С
имхо это надо централизовано делать, а не на откуп франчам и программистам, да и не факт что почта, лучше какое то монопольное раздражающее окно - "пока ты гад не исправишь я тебе постоянно буду напоминать, тебе будет легче исправить чем каждый раз ок жать" :)

ну и почему пользователи не любят исправлять - потому что обычно им свешивают задачу без конкретики "исправь там" (почему все программисты думают что пользватели знают что такое запрос с сортировкой по дате или начальник не вникая в детали теряет важное в постановке), а надо списочек этих документов дать и конкретику, написать исправляй дату этого документа (правильный номер должен быть не старше тольких то лет). А так с Вами согласен, с Заказчиками сложно :)
45. sapervodichka 6453 25.01.23 14:38 Сейчас в теме
(38) Сама ошибка с годами в будущем, у меня тоже несколько раз встречалась.
Если смотреть не в скрипты, а со стороны обычного 1С-ка типа меня, то:

Дата 0023 г. успешно отсекается датами запрета редактирования (механизм в каждом продукте 1С есть)
Дата 3023 г. не отсекается датами запрета редактирования (механизма нет)

По идее 1С можно было бы малой кровью механизм дат запрета редактирования допилить, добавив к полю "Запрет до даты" поле "Запрет после даты". Т.к. все подписки проверочные уже есть в конфах и даты проверяются постоянно у документов и регистров, думаю не повлияло бы на производительность проверять не только условие Документ.Дата >= ЗапретДоДаты, но и условие Документ.Дата <= ЗапретПослеДаты.
d_sdr; espero; +2 Ответить
46. kembrik 6 25.01.23 15:33 Сейчас в теме
(45) Встречное предложение, сделать редактирование даты пользователем максимально затрудненным, по типу редактирования номера. По умолчанию ставить текущую дату сеанса

Ловили неоднократно подобные ошибки, так как вовсю использовалось штрихкодирование документов, как и поиск по штрихкоду, если активна ячейка с датой, а пользователь этого не замечал, то в поле подставлялось со сканера такое... В итоге закрыли редактирование даты глобально, включив только просмотр.
espero; sapervodichka; +2 Ответить
47. ivanov660 3880 25.01.23 16:20 Сейчас в теме
(45) Запрет даты редактирования не на всех документах висит, в основном на регламентных. Поэтому не универсально.
56. user851077 04.02.23 19:44 Сейчас в теме
(47)А сравнивать даты в документах с текущей датой перед записью программистам западло?
48. Gilev.Vyacheslav 1903 25.01.23 16:30 Сейчас в теме
(45) реалтайм-проверки дороже по ресурсам сумарно, но тоже можно
но тогда надо еще проверять всякие обработки программистов, которые обычно под полными правами что то делают в обход многих проверок, всякие загрузки не из 1С и 1с-ные обмены, так как оттуда тоже может приехать

ну и кроме быстродействия, это еще ошибки в учете
в фирму 1С писать бесполезно, они всё только голованием теперь определяют )))
55. user851077 04.02.23 19:42 Сейчас в теме
(48)Знаете, Вячеслав, однажды мне удалось очень даже быстро убедить 1С в необходимости исправлений.
Дело было в августе 2012 года. Пользователи пожаловались на неправильных расчёт НДФЛ, и я полез разбираться. Оказалось, что в запросе ошибка (все конфигурации «Зарплата и Управление Персоналом», на мой взгляд, славятся каким-то невероятным числом ошибок в запросах, но, в данном случае, речь не об этом).
Нашёл ошибку и решил (вдруг!) написать в 1С.
Вы не поверите, но уже на следующий день вышли новые конфигурации ЗУП, КА и УПП. Под совершенно надуманными предлогами. Об исправленной ошибке в расчёте НДФЛ в сведениях о релизе не было ни слова.
В самом деле: узнай налоговики, что их любимая и доверенная программа неверно считала НДФЛ, их отношения с !С здорово бы осложнились. А фирме 1С оно надо?
49. user738268 26.01.23 09:58 Сейчас в теме
Проведена интересная работа. Не хотите посотрудничать по данной теме? Есть ряд проблем данного характера, требующие анализа и решения.
50. ivanov660 3880 26.01.23 12:00 Сейчас в теме
51. user738268 26.01.23 16:35 Сейчас в теме
52. пользователь 26.01.23 16:47
Сообщение было скрыто модератором.
...
54. triviumfan 79 30.01.23 20:39 Сейчас в теме
Интересная статья. И да, таких циклов по месяцам в современных конфигурациях предостаточно. Есть над чем подумать.
58. leongl 494 24.03.23 16:29 Сейчас в теме
Подскажите, а вы сбор планов не отключаете на PG? Каким инструментом пользуетесь для сбора планов? Оценивали влияние постоянного сбора планов на нагрузку сервера?
Оставьте свое сообщение
Вакансии
Специалист по технической поддержке пользователей 1С
Москва
зарплата от 70 000 руб.
Полный день

Системный архитектор 1С
Москва
зарплата от 250 000 руб.
Полный день

Системный аналитик (бизнес-аналитика)
Москва
зарплата от 100 000 руб.
Полный день

Руководитель группы 1С
Екатеринбург
зарплата от 200 000 руб.
Полный день

Функциональный архитектор
Москва
зарплата от 200 000 руб. до 300 000 руб.
Полный день