Описание грубых ошибок и рекомендации #414915

Хотелось бы разъяснить некоторые пункты, это касается экзамена на специалиста (я надеюсь это не только мне поможет): 1. Недопустимым является дублирование механизмов, уже существующих в конфигурации. - я как понимаю это означает, что не запрещено использование механизмов, но повторное их написание считается ошибочным, если не прав поправьте. 2. Ошибочным является конфигурирование с использованием внешних файлов для хранения данных задачи, когда можно хранить их в базе данных. - я так понимаю имеется ввиду использование обработок, отчетов с помощью "открыть", а правильно было бы сохранение внешних отчетов, обработок, печатных форм и т.д. в самой базе (Сервис->Внешние печатные формы и обработки, если не прав поправьте. 3. Принимаемые к учету данные должны храниться в регистрах. Использование других объектов для хранения информации принятой к учету считается недопустимым. - не совсем понимаю данное требование, а вернее не понимаю, что такое "учетные данные", объясните пожалуйста. 4. Недопустимым считается получение данных из первичных объектов, нормативной системы, в случае если они отражены в регистрах. - т.е. правильным считается формирование запросов к регистрам, а не к документам или справочника, я правильно понимаю? 5. Нельзя на регистрах накопления остатков вести учет ресурсов, принципиально не выводимых в ноль! Плохо, когда ресурсы регистра остатков (один или все) изменяются документами только "в одну сторону" (только в "+" или только в "-"), т.е. не обеспечивается выведения остатков ресурсов в "0". Нарушение этого требования приводит к неоправданному "распуханию" таблиц хранения итогов регистров. - тут все доступно объяснено. 6. Нельзя допускать рассогласование по набору измерений при выполнении положительных и отрицательных движений для регистра остатков. Плохо, когда ресурсы регистра остатков (один или все) изменяются документами и в "+" и в "-"), но движения с противоположным знаком для одного того же объекта учета выполняются с разными наборами значений измерений, что также не обеспечивает выведения остатков ресурсов в "0". Например, при положительном движении прописываются значения в измерения "Товар" и "Партия", а при отрицательном – только "Товар". Поскольку "никакое" значение измерения – то же значение, то получаем еще большее "распухание" таблиц итогов. Хотя сводный итог будет, например нулевым, но таблица итогов в результате будет помнить положительное количество товаров в разрезе конкретных партий и отрицательное количество этого же товара в "никакой" партии. - хороший пример, все объясняет. 7. В случае добавления новых регистров или реализации новых задач на существующих регистрах грубой ошибкой является неверное определение вида регистра накопления (остатки, когда нужны обороты или наоборот). - ну тут надо определиться самому, что использовать и уметь обосновать решение :) 8. Конфигурация должна устойчиво работать и при работе пользователей "задним числом". - это вводит меня в транс, учитывая то что конфигурация УТ при работе с задним числом совершает огромное множество ошибок ... уход остатков в минус и т.д. и т.п., хотя работает в этом случае устойчиво, устойчиво без проверок остатков и т.д., поправьте, если я не прав. 9. Если при проведении документа используются каким-то образом данные, считываемые из регистров, обязательно требуется предусмотреть получение таких данных на момент проведения документа. Крайне неправильно при проведении документа прошлым месяцем ориентироваться на данные, взятые на текущий момент. Месяц назад ведь картина была совсем другой. - угу, в конфигурации УТ при проведении задним числом, этот механизм просто отсутствует, поправьте если не прав. 10. Конфигурация должна устойчиво работать не только при движении вперед, но и назад. То есть, при отмене действия любого документа состояние показателей, контролируемых системой, должно возвращаться в исходное положение (как было до движений документа). Фактически тогда можно будет размотать всю цепочку документов назад. - Вот если бы еще 1с-ка ругалась на то, что я отменяю проведение документа, когда на основании него что-то было сделано, было бы замечательно, хоть и мешало бы очень часто, зато ошибок было бы меньше у пользователей. (мечты-мечты) 11. Конфигурация должна устойчиво работать при наличии дублей строк (номенклатуры или сотрудников или т.п.) в документах. Необходимо обеспечить корректное проведение документов при этом. Если невозможно – то лучше запретить дубли строк. - как-то задавал вопрос 1с, почему происходят дубли строк, а при перепроведении исчезают ... не добился ничего, пришлось делать отчет где эти дубли искались и потом просто перепроводил документы, а т.к. эти дубли могли возникнуть банально из-за двух одинаковых строк в документе .. запрещать или удалять или еще что-то делать не предоставлялось возможным. 12. При групповом перепроведении документов (восстановлении последовательностей) система должна четко и точно (локализовано) предупреждать пользователя о проблемах (невозможности проведения тех или иных документов), а по возможности даже выдавать рекомендации по их исправлению. - эх ... 13. Ошибочным является стиль программирования, при котором операции, которые правильнее делать в модуле объекта, выполняются в модуле формы. - а вот это я бы хотел уточнить: 1. Почему, 2. И что должно входить в тот или иной модуль? 14. Ошибочным является стиль программирования, при котором получение любых показателей остатков производится складыванием оборотов или по реальным таблицам регистра. - Это по-моему жесть какая-то обороты складывать ... редко наверное, но имеет место быть эта ошибка. А можете привести пример, когда такое все-таки делается? (пример ошибки) 15. Ошибочным является стиль программирования, при котором допускается выполнение запроса, получение остатков внутри цикла, как неоправданно снижающий скорость работы программы. - А ведь иногда требуется такое? Или это можно как-то обойти? Ну к примеру нужно абсолютно всех контрагентов, даже если по ним не было товародвижения, и вывести взаиморасчеты? Как это можно организовать без запроса в цикле? 16. Ошибочным является стиль работы с запросами, при котором вместо использования параметров виртуальных таблиц накладываются условия в разделе "Где", как неоправданно снижающий скорость работы программы. - Это в принципе понятно, но если не сложно объясните принцип работы сего? 17. Ошибочным является стиль работы с запросами, при котором без необходимости производится соединение виртуальных таблиц с реальными, как неоправданно снижающий скорость работы программы. - Это тоже понятно, хотя следует из предыдущего требования. 18. Обход результата запроса через промежуточную выгрузку в таблицу значений и последующим поиском, как неоправданно снижающий скорость работы программы. - Как это делается? (приведите пожалуйста пример) 19. Нехорошо с точки зрения использования отсутствие возможности выбора даты или периода при построении отчетов. 20. По возможности желательно избегать ситуации, когда при проведении документа учитывается нечто, кроме как данные самого документа или данные, взятые из регистров на момент проведения документов. Обязательно нужно учитывать возможность изменения "чужих" данных. В случае, если при проведении документа Вы учитываете состояние какого-нибудь реквизита некого справочника – есть опасность, что пользователь позже может поменять значение реквизита на совсем другое. Значит, для корректной работы конфигурации надо или запретить изменения таких данных, или как-то отработать этот факт – перепроведением документов или хотя бы предупреждением о возможных коллизиях. - Хорошо объяснено. Вот собственно пока и все :)

Родителей

.....

4. Стоит почитать

4 - это значит аналитические отчеты не должны строится на основании справочников/документов... а только регистров... Самое просто объяснение почему - потому что одни и теже движения могут делать разные документы.. в Одном документе реквизит называется "Клиент", в другом "Контрагент", и вообще это реквизит не документа, а ТЧ, которая называется еще как-то, и вообще несет другую семантическую нагрузку.. Так вот чтобы не вспоминать каждый раз названия всех ТЧ всех документов, и какую семантическую нагрузку имеют те или иные реквизиты, докумерты и делают "движения" в однородные регистры...

Когда сдавал ... сделал регистр который не выводится в 0 А вот почитать стоит.. =)

8. Должен быть механизм, который позволит выправить ситуацию - например восстановление последовательности документов

9. Про УТ не скажу, в БП - например разного рода закрытия месяца.. Они ж не определяют сальдо по счетам на сейчас, определяют на себя, в том месяце, в каком записаны

10. Достаточно что в отчете при отмене прихода расход вылезет красным или жирным минусом... И если отменить проведения и расхода - то типа все должно вернуться в состояние когда не было ни прихода ни расхода

11. Да ну, фантастика какая-то... Возможно просто константа какая-то не была выставлена,  апотом была

13. Потому что документы можно перепроводить из обработки методом Док.Записать - то есть кодом, в котором модуль формы не участвует вовсе.. Если же у нас например получение остатков вынесен в модуль формы, то такой документ проведется с ошибкой...

15. Запросом по всем контрагентам вне цикла.. Потом организуется цикл по контрагентам, и мы позиционируемся на результате запроса  на записи, соответсвуюшей текущему контрагенту цикла..

16. На ИТСе есть

18. Как делается что - РезультатЗапроса.Выгрузить?

И потом.. Айвенго пишется как Иванхое...

8. Конфигурация должна устойчиво работать и при работе пользователей "задним числом". - это вводит меня в транс, учитывая то что конфигурация УТ при работе с задним числом совершает огромное множество ошибок ... уход остатков в минус и т.д. и т.п., хотя работает в этом случае устойчиво, устойчиво без проверок остатков и т.д., поправьте, если я не прав. О-да. Особенности российского учета. Navision Attain даже не предусматривает отмену принятого к учету документа. При чем 1С использует среднескользящую дневную при списании (что нужно только оптовым компаниям, работающим с минимальной наценкой и совершенно не необходимо для бухии). А в УПП вообще отказались от проверки остатков при неоперативном учете. Почему нельзя было ввести средневзвешенную за период для бухии и оперативный контроль остатков (только количественный на конец дня) для оперучета, а для опта использовать заранее рассчитанные плановые цены? Снимается море проблем. Не говоря про блокировки.

А у меня вопрос такой назрел вчера. В рекомендациях прочитал, что при неоперативном проведении документа не нужно контролировать остатки и осуществлять проверки, а при оперативном нужно. Но при восстановлении границы последовательности все документы перепроводятся неоперативно, и все проблемы проскакивают так зачем вообще тогда мутить с этой границей последовательности если ничего толком не востановит и не укажет на проблемы

Я их читал уже :)

17. не тривиально. Пришлось прочесть

+19 нетривиально сформулированно, естественно. Смысл то там простой как мычание

ни когда не помешает

Не все виртуальные таблицы представляют собой подзапросы. "Тяжелые" виртуальные таблицы остатков и оборотов с разверткой по периодам, строятся с использованием временных таблиц. В этом случае, условие заданное в параметрах виртуальной таблицы, может в разы уменьшать размер используемых временных таблиц. Ну а так как виртуальная таблица представляет собой черный ящик и начинка его может меняться от релиза к релизу, то данное требование на всякий случай распространено на все виртуальные таблицы.

было не к а по 16-му пункту.

Это не фантастика к сожалению, а баг какой-то :( приходится искать и исправлять постоянно ... ммм, интересный вариант:) надо попробовать в дальнейшей работе :) т.е. 18 пункт, имеется ввиду выгрузка всей таблицы и уже работа с ней? всякими условиями? но 13 пункт все еще не понятен :)

Эт уже оффтопик )) Разошелся гляжу)))

В пункте 18 имеется ввиду видимо Запрос.Выполнить.Выгрузить и потом поисск через НайтиСтроки, потому что сама выгрузка в ТЗ и перебор строк не замедляет ничего сильно.

13й пункт и я не до конца понял, хорошо б они подробней разъясняяли

по 9-му пункту, закрыть период не значит контролировать число остатков на складе на дату документа ... 1с-ки требуют, но у себя такого не делаю ... --- Допустим если мы будем контролировать остатки товара на складе на дату документа, к чему это может привести? Опять же к минусам на складе, допустим к нам пришло 8.01.09 100ед товара, 10.01.09 отгружено 10ед, 11.01.09 отгружено 90ед, а потом мы создаем документ 09.01.09 и отгружаем 100ед, что у нас получается? Выходит что на складе будет -100 шт ... скорее всего этот метод контроля и отсутствует, так зачем же его требовать? --- ну чем больше у нас ТЗ тем дольше и будет проверка идти ... а если мы заранее уменьшим количество строк в ТЗ тем быстрее и будет:) Т.е. выгружать в таблицу надо уже готовый вариант, а не тот который мы будем еще обрабатывать. Конечно если мы не в такой ситуации, что нельзя создать запрос, который не надо будет обрабатывать.

Ну они просто не сильно любят лишние объекты.. Вернее как.. Еще с 77 пошло - например на экзамене по Торговле использование ТЗ было обязательным (этим типа 77 отличалась от 75), чтобы продемонстрировать что ты владеешь.. Так сказать... А когда я на экзамене по Бух тоже сначала БухИтоги загнал в таблицу (одним циклом, в в77 они не выгружались в ТЗ сами) а потом уже ее перебирал чтобы вывести отчет - сказали что - а зачем, можно ведь сразу... Может типа такое какое-то объяснение...

Пункт 2: нет, имеется ввиду не хранить данные в каких-либо внешних файлах.

вы имеете ввиду всякие печатные формы договоров, картинки и тд?

"3. Принимаемые к учету данные должны храниться в регистрах. Использование других объектов для хранения информации принятой к учету считается недопустимым. - не совсем понимаю данное требование, а вернее не понимаю, что такое "учетные данные", объясните пожалуйста." Полагаю имеется ввиду что если например работник принимается на работу это должно быть отражено не в реквизите справочника и не в каком-то документе, не делающем движений, а в регистрах.

"закрыть период не значит контролировать число остатков на складе на дату документа ... 1с-ки требуют, но у себя такого не делаю ..." э... вообще не понял реплики... Забудьте о закрытии периода.. Представьте ПлатежноеПоручениеИсходящее.. При его перепроведени задним числом онио будет определять количество денег на РС на себя, а не на текущий момент...

Нет, под "для хранения данных задачи" имеются ввиду именно данные, то есть когда ты хранишь что-то во внешнем дбф-е или текстовом файле.

Проведение задним числом - уже ошибочная операция. Требование к учету - отражение операций реальным временем. Как можно выдать деньги задним числом? Это советская школа фокусников и приписчиков. Поэтому считается что все операции были проведены в реальном времени и корректно.

"9. Если при проведении документа используются каким-то образом данные, считываемые из регистров, обязательно требуется предусмотреть получение таких данных на момент проведения документа. Крайне неправильно при проведении документа прошлым месяцем ориентироваться на данные, взятые на текущий момент. Месяц назад ведь картина была совсем другой. - угу, в конфигурации УТ при проведении задним числом, этот механизм просто отсутствует, поправьте если не прав." Это экзамен, ты должен показать что умеешь пользоваться правильными путями, никто потом не неволит поступать как хочешь и типовые здесь не эталон по той же причине.

Ерунда, не всегда есть возможность у пользователей сразу всё вводить в программу.

Это вопрос дисциплины, а никак не проблемы учета. У нас же это возведено в культ. В любой конфе есть такие механизмы. А это наипервейший залог возрастания стоимости обслуживания системы. После проведение операции задним числом необходимо проверять все измерения от даты проведения до отчетной/текущей. Все эти восстановления последовательностей, ночные перепроведения, минусовые остакти - вот результат неверного отражения операций.

"16. Ошибочным является стиль работы с запросами, при котором вместо использования параметров виртуальных таблиц накладываются условия в разделе "Где", как неоправданно снижающий скорость работы программы. - Это в принципе понятно, но если не сложно объясните принцип работы сего?" 1. Выбрать * ИЗ РегистрНакопления.Туфта.Остатки КАК ост ГДЕ и тут куча условий Что происходит? Он рассчитывает все остатки абсолютно, что конечно же долго. Кучу условий перенесли в параметры, таким образом он рассчитывает остатки только для отвечающих условию измерений. Разница в скорости огромна.

В навижн операционист завела поступление товаров. Оказалось манагер ей дал не те цены. Когда это выяснилось - товар уже ушел в магазин и был частично продан. Как решается эта опрерация - отменить учтенный докумнт нельзя. делается возврат от покупателей, возврат поставки на склад, возврат поставщику, поступление с правильными ценами и обратно в магазины и покупателям. Заняло месяц с небольшим. Выставили счет менеджеру. Уволился в минусе. Это конечно перебор - но суть отражает верно - наша система заточена под бардак.

иначе говоря он формирует сперва таблицу какую-то, потом еще фильтрует, а в другом случае сразу фильтрует таблицу, я так понимаю? автоматизированный бардак :D

Суть в запросе, который идет на сервер. в первом случае выбираются все остатки - потом на них накладывается условие, во втором выборка остатков уже идет с условиями. Т.е. данных получается на порядок меньше

воспринимай так: в первом случае вытягивается сервером из базы данных целиком вся таблица, отсылается на клиента, там она фильтруется... Во втором варианте сервер отбирает из таблицы только нужные записи и тсылает на клиента...

и окончательно сформировалось это знание ;) Спасибо :)

это всего лишь значит, что ваш запрос умрет в недрах SQL при достаточно большой выборке из таблиц документов.

для обхода такой ситуации достаточно произвести группировку в запросе и для случая проверки остатков сделать эту группировку в подзапросе до момента соединения с регистром.

особенно порадовала, что из правльного запроса 1 и не правильного запроса 2 правильным запросом является запрос 3 ... а ситуация с повторяющимися строками в тз?

да

практически не замедляет, только не забываем про то, что выгруженная таблица висит в оп. памяти на клиенте и при достаточно больших объемах данных будет не оченьт весело.

Типовые механизмы УПП всегда выгружают ТЧ в ТЗ, сворачивают и дальше отправляют механизмам проведения

злобные юзвери будут кричать, а чего у меня компьютер завис :) на счет это глюк который лечится перепроведением, а проверка здесь не помогает ... потому что всегда может быть одинаковая строка в самом документе, которую надо внести в регистр, а если такая ситуация случается то ... трындец :)

есть один момент, реализуемый платформой, который горе-дятлы пользуют: например в параметрах ВТ указать (...,Номенклатура.Поле1.ПолеХ = &ЗначениеХ)вместо того, чтобы вынести такое условие в ГДЕ или предварительно (тем же подзапросом) выбрать нужную номенклатуру и отдать массив в параметр. Это замедлит выполнение запроса в разы.

я и сам похожим образом делаю, в документах обычно большая редкость 10000 позиций в тч.

+ замедлит - при (...,Номенклатура.Поле1.ПолеХ = &ЗначениеХ)

Хм, не знал, спасибо, а почему так происходит? То есть надо в параметрах Номенклатура В (Выбрать Ссылка Из Справочник.Номенклатура ГДЕ Поле1.ПолеХ = &ЗначениеХ) так?

берется реальная таблица, делается соединение со справочником номенклатуры для выборки значения поля Поле1, затем делается еще одно левое соединение со справочником типа Поле1 для получения реквизита ПолеХ, происходит сравнение и дальше по цепочке. Как следствие - в реальной таблице может быть миллионы записей, а в полученной виртуальной только 10000. Из какой таблицы будет быстрее отобрать записи и в какой последовательности?

+ есть еще план выполнения запроса, он конечно может внести свои коррективы, но кто сказал что они будут в лучшую сторону? :)