Поиск в базе данных. Редактирование движений в форме документ. Список пользователей и их роли. Обмен данными. Функциональные опции

Практическая работа № 10

Тема: Поиск в базе данных. Редактирование движений в форме документ. Список пользователей и их роли. Обмен данными. Функциональные опции

Цель: Формирование практических навыков поиска в базе данных

Время выполнения: 12 часов

Теоретический материал

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

Зачем это нужно? Этому есть три причины.

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

Во-вторых, руководство нашей фирмы решило прекратить ручной ввод стоимости расходуемых материалов и перейти на автоматический расчет «по среднему».

В-третьих, при проведении документа необходимо контролировать остатки расходуемых товаров на складе. Если товаров не хватает - выдавать предупреждение и не проводить документ.

Поэтому в нашей работе три цели:

1.      Повышение скорости выполнения процедуры;

2.      Автоматическое определение стоимости расходуемых материалов при проведении документа;

3.      Разделение алгоритма проведения документа на оперативный и неоперативный режимы и контроль остатков в оперативном проведении документа.

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

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

вать запросы для более быстрой выборки.

Механизм запросов лучше «читает» информационную базу и может за один раз выбрать только нужные данные. Поэтому в типовых решениях вы не увидите использование объекта встроенного языка СправочникВыборка. <имя>. Вместо этого используются запросы к БД.

Задания:

Повышение скорости проведения

Первое, чем мы займемся в этой работе - избавимся от «вредной» конструкции

ТекСтрокаПереченьНоменклатуры. Номенклатура. ВидНоменклатуры.

В режиме Конфигуратор

Откройте модуль документаОказаниеУслуги. Из процедуры обработки проведения видно, что все данные, необходимые для проведения документа, мы получаем из самого документа и только для определения типа номенклатуры (товар или услуга) - читая данные всего объекта Номенклатура.

Обращение к объекту Номенклатура:

Это не единственные данные, которые содержатся не в самом документе и которые будут нужны для его правильного проведения.

Для оптимизации поступим следующим образом: все данные, связанные с номенклатурой, которая содержится в табличной части документа, мы будем получать с помощью запроса к БД. А данные, связанные с самим документом (дата, склад..) будем по-прежнему получать из документа. Такой подход позволит читать только нужные данные и максимально ускорить проведение документа.

Запросом мы будем получать:

•          Номенклатуру

•          Количество

•          Сумму

•          Стоимость

Из документа возьмем:

•          Дата

•          Клиент

•          Мастер

•          Склад

Установите курсор перед циклом Если... и из контекстного меню выберите Конструктор запроса с обработкой результата.

Подтвердите создание нового запроса.

В окне конструктора перейдите на вкладку Таблицы и поля и выберите таблицу

ОказаниеУслугиПереченьНоменклатуры - это табличная часть документа ОказаниеУслуги.
Из этой таблицы нам нужны Номенклатура. ВидНоменклатуры, Количество, Сумма и Стоимость.

Рисунок 189– Конструктор запроса

Но нам нужны не все записи этой таблицы, а только те, которые относятся к нашему документу. Поэтому перейдите на вкладку Условия и задайте условие отбора из таблицы только строк проводимого документа. Для этого перетащите поле Ссылка в список условий запроса:

В обработчике появится условие:

Рисунок 190– Конструктор запроса с обработкой

Следует учесть, что в табличной части документа одна и та же номенклатура может встречаться несколько раз. Поэтому на закладке Группировка сгруппируйте записи по полю Номенклатура и НоменклатураВидНоменклатуры, а рассчитывать будем сумму значений для полей Количество и Сумма. Также в состав суммируемых полей включим поле Стоимость. По нему будем рассчитывать, например, функцию Максимум.

Рисунок 191– Конструктор запроса с обработкой

На закладке Объединение/Псевдонимы задайте псевдонимы для полей Количество и Сумма КоличествоВДокументеиСуммаВДокументе, а для поляНоменклатураВидНоменклатуры – ВидНоменклатуры.

Рисунок 192– Конструктор запроса с обработкой результата

Нажмите ОК и посмотрите какой текст запроса сформирован.

Рисунок 192– Текст запроса

Проанализируем текст. Для работы с запросами используется объект встроенного языка Запрос. Вначале создается новый объект Запрос и помещается в переменную Запрос. Затем в свойство Текст объекта Запрос помещается сам текст запроса (Запрос.Текст=...). После этого устанавливается значение параметра запроса&Ссылка как ссылка на тот документ, в модуле которого мы сейчас находимся.

Затем запросы выполняется (Запрос.Выполнить()), получается объект РезультатЗапроса, и выполняется его методВыбрать(), который формирует выборку записей из результата запроса.

Получается объектВыборкаИзРезультатаЗапроса, который помещается в переменнуюВыборкаДетальныеЗаписи.

Далее, используя метод этого объектаСледующий() (ВыборкаДетальныеЗАписи.Следующий()), мы будем в цикле обходить выборку записей запроса. Выполняя метод выборки запроса ВыборкаДетальныеЗаписи.Следующий(), мы на каждом шаге цикла позиционируем указатель на следующую запись выборки, пока не будет достигнут конец выборки.

Чтобы в цикле получить значение какого-либо поля выборки из результата запроса, мы будем обращаться к полям запроса через точку от переменнойВыборкаДетальныеЗаписи, которая содержит текущую строку выборки запроса. Например, так: ВыборкаДетальныеЗаписи. Номенклатура.

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

Новый текст в листинге будет выделен жирным текстом для удобствавосприятия.

Сначала вместо комментария «// Вставить обработку выборки ВыборкаДетальныеЗаписи»перенесите условие проверки и весь код, формирующий движения по регистрамОстаткиМатериалов и СтоимостьМатериалов.

В условии заменитеТекСтрокаПереченьНоменклатуры.Номенклатура на ВыборкаДетальныеЗаписи, т

Рисунок 193– Изменение кода запроса

В движениях также заменимТекСтрокаПереченьНоменклатуры на ВыборкаДетальныеЗаписи. Для поля Количество мы задали псевдоним в запросе, поэтому заменим его наКоличествоВДокументе.

Рисунок 194– Добавление изменений в код запроса

Теперь перенесем формирование движений по регистру Продажи:

Рисунок 195– Код формирования движения по регистру Продажи

Рисунок 196– Код формирования движения по регистру Продажи

Здесь произведем аналогичные замены.ТекСтрокаПереченьНоменклатурызаменим наВыборкаДетальныеЗаписи. А также поля Сумма и Количество заменим на их псевдонимыСуммаВДокументе иКоличествоВДокументе

Рисунок 197– Изменение кода формирования движения по регистру Продажи

Оставшийся цикл обхода табличной части можно удалить:

Рисунок 198–Удаление части кода

Процедура проведения примет следующий вид:

Рисунок 195– Результат процедуры

Рисунок 199–Вид процедуры

Теперь запустите 1С: Предприятие в режиме отладки и перепроведите документыОказаниеУслуги, проверьте, что ничего не изменилось.

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

Автоматический расчет стоимости

Приступим ко второму этапу плана. До сих пор стоимость расходуемых материалов мы вписывали в документ Оказание услуги вручную, при его создании.

Теперь же будем определять стоимость номенклатуры «по среднему»: для каждой номенклатуры делить ее общую, суммарную стоимость на имеющееся у нас количество номенклатуры, т.о. получая среднюю стоимость единицы номенклатуры.

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

•              Ее стоимость, хранящаяся в регистреСтоимостьМатериалов;

•              Общее ее количество на всех складах, хранящееся в регистре ОстаткиМатериалов.

Поэтому нам нужно будет доработать запрос, чтобы он получал из БД и эти данные тоже. Т.е. нам хотелось бы, чтобы запрос возвращал следующие поля для каждой номенклатуры, которая есть в документе:

Рисунок 200–Данные получаемые из БД

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

Это значит, что наш запрос должен содержать два левых соединения таблицы документа с другими таблицами: одно - с таблицей РегистрНакопления.СтоимостьМатериалов.Остатки; другое - с таблицейРегистрНакопления.ОстаткиМатериалов.Остатки.

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

Для маленькой базы это не важно, но для реальной БД, где 15 ООО наименований и только 5 используются в документе - это непозволительная расточительность вычислительных ресурсов.

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

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

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

Таким образом, схема нашего запроса приобретает следующий вид:

Рисунок 201–Схема запроса

В режиме Конфигуратор

Первое - мы удалим реквизит табличной части Стоимость документа ОказаниеУслуги, который нам больше не понадобится. Для этого откройте окно редактирования объекта ДокументаОказаниеУслуги, перейдите на закладку Данные, раскройте список реквизитов табличной части документа, выделите реквизит Стоимость и нажмите кнопкуУдалить в командной панели. Хотя проще это сделать из окна конфигурации.

Также удалите поле Стоимость из таблицыПереченьНоменклатуры, расположенной в форме.

Рисунок 202–Выбор поля Стоимость

Временную таблицу мы сформируем с помощью того запроса, который у нас уже написан. Откройте модуль документаОказаниеУслуги.

В процедуреОбработкаПроведения() перед созданием запроса создайте менеджер временных таблиц и укажите, что этот запрос будет использовать созданный менеджер:

Рисунок 203–Код процедуры для запроса

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

Чтобы конструктор запроса смог открыть наш запрос, удалите из него строку (поля Стоимость у нас больше нет) и запятую в строке выше этой:

Получим следующее:

Рисунок 204–Результат запроса

Установите курсор внутрь текста запроса (например, на слове ВЫБРАТЬ) и выполните команду контекстного меню Конструктор запроса.

Чтобы результат запроса поместить во временную таблицу, перейдите на закладкуДополнительно и отметьте пункт Создание временной таблицы. Задайте ей имя - Номенклатура Документа. Нажмите ОК.

Рисунок 205–Создание временной таблицы

Конструктор сформировал текст запроса с одной новой строкой:

Рисунок 206–Сформированный текст запроса

Это означает, что результат запроса будет сохранен во временной таблице Номенклатура Документа. Это был Запрос 1 на нашей схеме.

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

Займемся вторым запросом.

Установите курсор на следующую строку после оператора Результат = Запрос. Выполнить(); (именно здесь выполняется создание временной таблицы) и напишите заготовку будущего запроса:

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

Установите курсор внутрь кавычек и выполните контекстную команду Конструктор запроса.Согласитесь на создание нового запроса.

Создадим описание временной таблицы в этом запросе. Для этого над списком Таблицы нажмите Создать описание временной таблицы .

Введите имя нашей временной таблицыНоменклатураДокумента и добавьте поля:

•             Номенклатура, тип СправочникСсылка.Номенклатура;

•             ВидНоменклатуры, тип ПеречислениеСсылка.ВидыНоменклатуры;

•             КоличествоВДокументе, тип Число, 15, 3;

СуммаВДокументе, тип Число, 15, 2. Нажмите ОК.

Рисунок 207–Добавление полей во временную таблицу

Выберите изНоменклатураДокумента все поля и нажмите кнопку Запрос.

Рисунок 208–Сформировать запрос

Рисунок 209–Полученный запрос

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

Добавим в список таблиц запроса виртуальную таблицу РегистрНакопления.СтоимостьМатериалов.Остатки. Из нее выберем полеСтоимостьОстаток. Перейдем на закладку Связи и зададим связь между таблицами.

Из временной таблицы будем выбирать все записи, и поле Номенклатура временной таблицы должно быть равно полю Материал таблицы остатков.

Рисунок 210–Установка связей

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

СтоимостьМатериаловОстатки и нажмите кнопку виртуальной таблицы.

Рисунок 211–Параметры виртуальной таблицы

Задайте условие:

Т.е. материал должен быть среди номенклатуры, выбранной из временной таблицы. Нажмите ОК. Теперь нажмите кнопку Запрос и посмотрите на текст, сформированный конструктором.

Рисунок 212–Сформированный текст запроса

Тем самым мы добавили к выбранным ранее полям стоимость номенклатуры.

Теперь добавим виртуальную таблицу остатков регистра ОстаткиМатериалов.Остатки, из которой выберем поле Количество.Остаток.

Рисунок 213–Добавление регистров во временную таблицу

Перейдите на закладку Связи и задайте связь между таблицами.

Из временной таблицы будем выбирать все записи, поле Номенклатура временной таблицы должно быть равно полю Материал таблицы остатков.

Рисунок 214–Связи

Также зададим параметры виртуальной таблицыОстаткиМатериаловОстатки. В параметр Условие введите:Тем самым мы добавили к выбранным ранее полям остатки номенклатуры на всех складах.

В заключение перейдем на закладку Объединения/Псевдонимы и зададим следующие псевдонимы полей:

• Стоим ость Остаток - Стоимость;

• КоличествоОстаток – Количество.

Рисунок 215–Объединение/Псевдоним

В результате получим следующий текст запроса:

Рисунок 216–Полученный текст запроса

Нужно предусмотреть тот случай, когда номенклатура в справочнике есть, но у нее нет ни остатков, ни стоимости. Это может быть, например, когда номенклатуру создали в справочнике, но она еще не поступала в нашу фирму.

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

Избавимся в самом запросе от этих значений. Для этого мы применим функциюECTbNULL()к полям Стоимость и Количество. Если значение этого поля будетNULL,функция вернет О. В остальных случаях функция вернет само значение этого поля. Перейдите на закладку Таблицы и поля, выделите СтоимостьМатериаловОстатки.СтоимостьОстаток и нажмите кнопку  Изменить текущий элемент

Рисунок 217–Изменение СтоимостьМатериаловОстаток

Отредактируйте значение поля:

Рисунок 218–Редактирование СтоимостьМатериаловОстаток

Аналогично с другим полемОстаткиМатериаловОстатки. Кол ичествоОстаток.

Нажмите ОК - текст запроса будет вставлен в модуль. Останется всего лишь дописать после него оператор выполнения запроса:

Рисунок 219–Вывод результата Запроса2

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

Единственное, что потребуется изменить - способ получения стоимости. Раньше мы просто брали ее из документа, теперь же нам нужно ее рассчитать на основании данных запроса. Стоимость материала равна частному от деления всей стоимости, полученной запросом (Стоимость) на общее количество материала на всех складах (Количество).

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

Рисунок 220–Внесение изменений в текст зарпоса

Теперь заменим расчет стоимости в движениях регистров СтоимостьМатериалов и Продажи.

Рисунок 221–Внесение изменений в текст зарпоса

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

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

Чтобы в обработчике проведения документа прочитать данные без учета предыдущих движений, которые мог выполнять документ, нужно перед чтением записать пустые наборы записей в те регистры, из которых мы собираемся читать. В нашем случае этоСтоимостьМатериалов и ОстаткиМатериалов.

Перед выполнением второго запроса добавим строки:

Рисунок 222–Добавление строк в Запрос1

Запустите режим отладки и перепроведите все документы Оказание услуги, проверьте правильность занесения данных в регистры.

Оперативное и неоперативное проведение документов

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

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

Оперативность или неоперативность проведения документа определяется по его дате. Если дата проводимого документа совпадает с текущей, то система будет проводить такой документ в оперативном режиме, не задавая вопросов, и в обработке проведения об этом можно узнать, чтобы выстроить определенный алгоритм проведения.

Если дата документа меньше текущей, то такой документ система будет проводить в неоперативном режиме. При этом перед проведением она напомнит, что оперативно она его провести не может (вдруг пользователь ошибся). И если пользователь подтвердит, что хочет провести его неоперативно, то система проведет документ неоперативно.

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

При неоперативном проведении не имеет смысла производить целый ряд проверок, в частности - контроль остатков. Подразумевается, что если в процессе неоперативного проведения были допущены ошибки, то анализ полученного состояния БД является отдельной задачей, не относящейся к неоперативному проведению и выполняющейся не в момент проведения документа.

Если логика учета подразумевает, что какой-то документ должен проводиться будущей датой, для такого документа механизм оперативного проведения должен быть отключен в метаданных (на закладке Движения окна редактирования объекта конфигурации).

Контроль остатков

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

В режиме Конфигуратор

Сделаем заготовку. После цикла обхода результата запроса и перед концом процедуры напишем:

Рисунок 223–Запрос контроля остатков

Сначала мы записываем движения в регистры. Затем определяем режим проведения документа. При выполнении процедуры ОбработкаПроведения() вторым параметром (Режим) в нее передается режим проведения документа и значение этой переменной сравнивается со значением системного перечисления РежимПроведенияДокумента. В случае оперативного проведения мы будем выполнять контроль остатков.

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

Рисунок 224–Менеджер виртуальной таблицы

Установите курсор внутрь кавычек и вызовите конструктор запроса. Подтвердите создание нового запроса.

Выберите таблицуОстаткиМатериалов.Остатки и из нее два поля: Материал иКоличествоОстаток. Задайте параметры этой таблице. В параметре Условие напишем:

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

Затем на вкладке Условия перенесем в список условий поле ОстаткиМатериаловОстатки.КоличествоОстаток, поставим флажок Произвольное и укажем, что нас интересуют только отрицательные остатки:

Рисунок 225–Конструктор запроса

Нажмите ОК.

Теперь осталось только установить параметр запроса, обойти результат запроса и вывести сообщения об отрицательных остатках.

Рисунок 226–Добавление кода в запрос

При выполнении проверки в запрос в параметре Склад передается склад, указанный в документе. Затем выполняется запрос для получения отрицательных остатков номенклатуры, содержащейся во временной таблице и на складе, указанном в параметре Склад.

После этого выборка записей запроса обходится в цикле, и если есть такие записи, они выводятся в сообщениях пользователю.

При этом параметру Отказ присваивается значение Истина, т.е. документ не проводится, начатая транзакция отменяется, состояние данных, измененных в процессе проведения, возвращается в исходное, как до начала проведения документа.

Блокировка данных, которые читаются и изменяются при проведении

Сейчас схема нашей процедуры такова:

1.           Выполняем первый запрос с именем Запрос. В результате мы формируем временную таблицу из перечня номенклатуры документа.

2.           Выполняем второй запрос с именем Запрос2. В результате мы читаем стоимость и остатки для номенклатуры, содержащейся в табличной части документа.

3.           Записываем движения регистров (Движения.Записать())

4.           Выполняем третий запросЗапросЗ. Тем самым мы проверяем наличие отрицательных остатков.

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

Однако может возникнуть следующая ситуация. Выполняя второй запрос, мы прочитали, что есть 2 шт. некоторого материала. И другая транзакция (другой пользователь), которая собирается списывать материалы, тоже прочитала, что есть 2 шт. этого материала. После этого мы записали движения, система заблокировала эти данные. Другая транзакция ждет, когда мы освободим данные. Мы провели документ, списали 2 шт. материала и освободили данные. Другая транзакция пытается тоже списать 2 шт. материала, но его уже нет!

Аналогичная ситуация может возникнуть и между пунктами 3 и 4, в результате чего контроль остатков будет работать неверно.

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

В режиме Конфигуратор

Как это сделать? Давайте посмотрим на свойство нашей конфигурации Режим управления блокировкой данных. Он

установлен в значение Управляемый.

Рисунок 227–Режим управления блокировкой данных

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

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

Рисунок 228–Блокировка для изменений

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

В режиме 1С: Предприятие

Запустите режим отладки и проверьте работу нового обработчика события ОбработкаПроведения, перепроведя все документы Оказание услуги.

Контрольные вопросы:

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

2.             Чем отличается оперативное проведение документов от неоперативного.

3.             Почему при неоперативном проведении документов не нужно контролировать остатки.

4.             Что такое временные таблицы и зачем их использовать.

5.             Что такое менеджер запросов.

6.             Как программной блокировать данные.

Скачано с www.znanio.ru