Когда проводил различные «опыты» , эксперименты по написанию «своих блокировок» был необходим механизм обнаружения сложных ошибок в регистрах. В результате появилась эта обработка.
Особенности
Сейчас обработка поддерживает только sql версию. Для работы обработки необходим 1с++
Установка
Скопировать и запустить обработку.
Как пользоваться — интуитивно понятно.
Принимаются ошибки, замечания, критика и.т.д.
Описание кнопок и что они обнаруживают
- Документ не проведен и установлен флаг движения (rf по любому из регистров )
- Документ проведен и установлен флаг движения (rf) конкретного регистра и нет ни одного движения документа по этому регистру
- Ищем случай когда флаг движения (rf) сброшен у конкретного регистра и у документа есть движения по этому регистру
- Ищем случай когда документ не проведен , флаг движения (rf) у конкретного движения сброшен и у документа есть движения по этому регистру.
- Ищем случай когда документ проведен , флаг движения у конкретного движения (rf) сброшен и у документа есть движения по этому регистру.
- В таблице движений конкретного регистра (ra) есть ссылка на несуществующий документ.
- Проверяет что элемент-справочник или документ с максимальным ID существует в соответствующей таблице справочника или в журнале документов.
- Для регистров у которых установлен признак быстрое движение дата, время ( date_time_iddoc ) по регистру должно совпадать с этим полем по журналу документов.
- Ищем ошибки когда при проведении документа было что либо нарушено. Основная идея пункта 7 что при правильном проведении документа все его actno составляют ряд ( арифметическая прогрессия ) 1 2 3 4 5 … n .Причем n должно равняться actcnt из строки журнала документов. Этот ряд составлен из всех движений документа по всем регистрам. В этот ряд также включается движение переодич. реквизита справочника этого документа
Пример из модуля проведения:
Вызвали проведение другого документа при этом второй документ откатил транзакцию а мы дальше стали проводить документ.
Искусственным тестом воссоздал такую ситуацию и обработка это обнаружила
Версия 1.9.08
- Добавлен поиск ошибок связанных с периодич. значениями справочников полученных при проведении документов
- Документ непроведен и у него есть переодич. движения справочников
- Документ непроведен и у него по APPCODE (APPCODE & 0x08 = 8 ) есть движение
- Документ проведен и у него по APPCODE (APPCODE & 0x08 = 8 ), а движения нет
- Документ проведен и у него по APPCODE (APPCODE & 0x08 = 0 ) и движения есть
- В константах есть периодич движение документа в самом журнале документов нет документа iddoc
- В константах есть периодич ID (id плохой) который ссылается на неправильный реквизит справочник
- В константах есть периодич ID справочника спр и непустой, а в самом справочнике нет значения (ссылка в никуда или на удаленный элемент спр)
На 09.04.2012 сделаны изменения версии с 2.0.0.1 по 2.0.0.4
Версия 2.0.01
сделано
1 при открытии делается проверка и если надо то загружается внешняя компонента 1cpp.dll
2 проверка что раньше определенной даты нет движений по rg
3 проверка что позже определенной даты нет движений по rg
4 Для периодичности итогов = месяц проверка что в rg в поле PERIOD не может быть даты отличной от числа 01
Версия 2.0.02 и 2.0.03
1. добавлен 6.1 поиск в rg значений PERIOD по дате меньше заданной доп флаг можно дату наименьшую взять из _ssystem
2. добавлен 6.2 поиск в rg значений PERIOD по дате больше заданной доп флаг можно дату наименьшую взять из _ssystem. Это надо делать если уверены что не двигали ТА в прошлое и в прошлом и остались
3. добавлен 6.3 проверка дат PERIOD d rg переделана для любой периодичности базы 1с
4. добавлен 6.4 где флаг быстрые движения включен то в ra не может быть даты самой ранней чем в _1ssystem
5. добавлен 8.8 по _1sjourn (журнал документов) сделан поиск документов меньше заданной даты. (Т.е если Вы ведете базу с 2005 года то логично предположить что нет документов с датой < 01.01.2005)
6. добавлен 8.9 по _1sjourn (журнал документов) сделан поиск документов с пустой датой ( точнее с датой 01.01.1753)
7. добавлен 8.10 по _1sentry (проводки ) сделан поиск проводок с пустой датой
8. добавлен 8.11 по _1soper (операции ) сделан поиск операций с пустой датой
Версия 2.0.04
1.сделан поиск документов где для документа время документа отличается от времени проводок
2 сделан поиск документов где для документа время документа отличается от времени операции
3 сделан поиск документов где для документа время документа отличается от времени отбора счетов
4 сделан поиск документов где для документа время документа отличается от времени отбора проводок
5. сделано сравнение времени в операции и ее проводок.
Дальнейшее развитие
Есть идеи что из этого можно сделать еще.
Как говорил по этому поводу один заезжий иностранец: «Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно.» 😉
IMHO, описание тестов должно быть в понятных большинству терминах ЖКК, а не в терминах физической структуры.
Хотя, конечно, зависит от позиционирования разработки..
Согласен с (1).
Напишите в описании, КАКИЕ ошибки. Скачивать только для того, чтобы это узнать, наклално. Потом сутки лапу сосать.
У меня не получилось отредактировать публикацию
вот более приближенное к 1с описание
Описание кнопок и что они обнаруживают
1. Документ не проведен и установлен флаг движения (rf по любому из регистров )
2. Документ проведен и установлен флаг движения (rf) конкретного
регистра и нет ни одного движения документа по этому регистру
3.Ищем случай когда флаг движения (rf) сброшен у конкретного регистра
и у документа есть движения по этому регистру
3.1 Ищем случай когда документ не проведен , флаг движения (rf) у
конкретного движения сброшен и у документа есть движения по этому регистру.
3.2 Ищем случай когда документ проведен , флаг движения у
конкретного движения (rf) сброшен и у документа есть движения по этому регистру.
4.В таблице движений конкретного регистра (ra) есть ссылка на несуществующий документ.
5.Проверяет что элемент-справочник или документ с максимальным ID существует
в соответствуюшей таблице справочника или в журнале документов.
6. Для регистров у которых установлен признак быстрое движение
дата,время ( date_time_iddoc ) по регистру должно совпадать с этим полем по журналу документов.
7.Ищем ошибки когда при проведении документа было что либо нарушено.
Пример из модуля проведения вызвали проведение другого документа при этом второй документ
откатил транзакцию а мы дальше стали проводить документ.
Искуственным тестом воссаздал такую ситуацию и обработка это обнаружила
Основная идея пункта 7 что при правильном проведении документа все его actno
составляют ряд ( ариф прогрессия )
1 2 3 4 5 … n .Причем n должно равняться actcnt из строки журнала документов.
Этот ряд составлен из всех движений документа по всем регистрам.В этот ряд также включается
движение переодич. реквизита справочника этого документа.
(1) Для того чтобы проверить базу можно вообще не разбираться в особеностях 1с и структуры
данных. Если кнопка ошибок не обнаружила то она пишет Все Ок.
Все кнопки только Читают поэтому этой обработкой данные не могут быть испорченны.
Случай когда все таки обнаружатся ошибки то они(ошибки) будут все таки локализованы ( хотя бы по документу и по проблеме) и даже если квалификации проверяющего не хватит чтобы исправить их самому он может что либо сделать чтобы найти того кто бы смог помочь решить этот вопрос.
С учетом (4) и (5), пожалуй, отплюсуюсь. Похоже, штука полезная.
Пока нет времени качать и свою базу проверять, но вещь нелишняя, имхо…
Плюсую…
Пришлось добавить в начало:
У меня SQL-версия программы, но база — файловая. Будет ли при при таком раскладе работать?
(8)
Сейчас обработка функционирует только для sql базы.
Я считаю что загружать 1сpp из отчета это плохо.
добавлю сообщение о том что не загружена 1сpp
Обнаружение таких ошибок — вещь хорошая, на моей памяти на фирме разразился скандал — документ не сделал движений. Так во всей 30Gb базе такой документ обнаружился только один, но резонансу от начальства он вызвал …. много, вот так всё совпало и попало в «болевую» точку
Плохо, что нет для DBF
(11) Я посмотрел внутрь, в принципе большого труда постепенно перевести его на класс «ПрямойЗапрос» труда не составит. И тогда данная обработка будет универсальна (и для DBF, и для SQL).
(0) Автор, а ты не готов рассмотреть перевод запросов с ODBC на класс «ПрямойЗапрос»?
Вот ссылка на класс —http://www.1cpp.ru/forum/YaBB.pl?num=1246429625
На ИС тоже есть, но не самая актуальная версия.
(12) Я планирую сначала полностью сделать subj для sql.
Только после этого делать dbf версию.
Ну и не совcем простой перевод будет
например в dbf по моему нет exists и.т.д.
(11) Выход ( не айс) сейчас тоже есть.
Сделай копию базы .Конверти ее в sql ( dbf базы не могут быть очень большими ).
Прогони обработку.
(13) КОП прямой запрос использует 1sqlite. Вроде у него exists вполне существует. Тем баче разве нельзя переписать на in (если я правильно помню место где используется exists). Кроме того in будет уместнее если объем вложенной выборки небольшой. Ну и соответственно наоборот если объем большой :).
(15) exists используется как полусоеденение и антисоеденение
в t-sql ( MS SQL) exists реализован гораздо эффективнее чем in
Хотя эта по моему off для этого сайта(ветки)
Посмотрел sqlitehttp://www.sqlite.org/syntaxdiagrams.html#expr
в sqlite есть exists.
(16) Значит может попробуешь? Я готов оказать посильную помощь 🙂
Популяризация лишней не бывает
По поводу добавлений.
вот мне необходимо было сравнить задолженность по регистру с бухгалтерской обороткой. А то бухи любят производить ручную операцию, а регистр поправить забывают. Ничего в нете не нашел тогда.
(18) Отчет универсальный т.е. должен выполнять в первую очередь проверки которые нужны в любой базе данных 1с.
(viacht)сформулируйте точно и подробно Вашу задачу тогда можно будет об этом что либо сказать.
(19) Бухи во взаиморасчетах, учете материалов, очень любят использовать ручные операции. Взаиморасчеты с нерезами в части расчета курсовых разниц в ОСВ отображаются правильно, а в регистрах полная чушь.
Необходим отчет, который бы сравнивал сальдо в ОСВ и показатели в регистрах по учету взаиморасчетов и учету ТМЦ.
(19) Бухи во взаиморасчетах, учете материалов, очень любят использовать ручные операции. Взаиморасчеты с нерезами в части расчета курсовых разниц в ОСВ отображаются правильно, а в регистрах полная чушь.
Необходим отчет, который бы сравнивал сальдо в ОСВ и показатели в регистрах по учету взаиморасчетов и учету ТМЦ.
Полностью согласен, такой бы отчет очень помог!
При тесте кнопки 8.6 (8.7) выпадывает ошибка:
Тек_Ид = meta1.ИдРеквизитаСправочника(ТаблСпр_Документов.ВидСпр,ТаблСпр_Документов.РеквСпр);
{D:NEWПОИСКОШИБОК_В_РЕГИСТРАХ.ERT(49)}: Не существует справочника с идентификатором: Договоры взаиморасчетов
(22)
А остальные кнопки работают ?
очень похоже что не подгружена компонента 1с++
(22) В 23 похоже я не прав.
Опиши ситуацию как можно подробней.
Привет! Цэ я, с мисты, с побитыми регистрами. )) Попозжа посмотрю код подробней, может там что-то не правильное.
Подскажите пожалуйста, в чём суть проверки 7.3? Что он проверяет?
(26) 7.3 и 7.4 проверяет что нет пропусков в движениях по конкретному документу.
Движения — это или движения регистров или проводки или изменения периодики справочников
из документа.
Пример предположим у документа есть движения с 1 по 10.
Если мы специально удалим движение № 7 из qa (или еще как любым внешним способом)
то одна из проверок или 7.3 или 7.4 обнаружит эту ситуацию.
Дело в том что я не так хорошо разбираюсь в физическоих таблицах 1С.
«есть движения с 1 по 10.» — Это что за цифры? Что они обозначают?
» удалим движение № 7 из qa» — Что такое qa?
» нет пропусков в движениях» — не совсем понятен термин, но думаю пойму, если ответите на предыдущие два.
Какие таблицы участвуют при проверке по этому пункту?
(28)
для опер учета это таблицs ra…
для бухгалтерии это _1sentry
Если есть движения по расчет то скорее всего обработка работает неправильно.
Если Вы используете в модуле проведения ПривязыватьСтроку
то при отображении будут видны номера движений.
Если в документе прих накладной 10 строк то логично предположить что у Вас может быть по документу
10 движений Приход товара.
Так вот если внешним способом удалим движение по 7 строке без всякого 1с
то кнопки 7.3 или 7.4 распознают эту ситуацию и Вы узнаете с каким документом что-то не так.
ну а дальше Вы проанализировав строки документа приходной накладной
и его движения Приход Товара поймете что приход по строке 7 пропал и предпримите какие-то действия.
Спасибо! Буду переваривать. Выдернул ещё запрос с обработки, буду разбирать.