Оптимизация проведения документа «Оказание услуги»

Оптимизация документа ОказаниеУслуги, в частности – полное изменение обработчика события ОбработкаПроведения, нужно по трем причинам:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

− табличная часть документа;

− регистр Стоимость материалов;

− регистр Остатки материалов;

− номенклатура Кол-во в документе Сумма в документе;

− вид номенклатуры;

− стоимость;

− количество на всех складах.

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

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

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

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

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

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

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

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

 

План видов характеристик

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

Объект конфигурации план видов характеристик предназначен для описания структуры хранения информации о характеристиках, создаваемых пользователем. Он напоминает справочник, но с более узкой специализацией – хранит только виды характеристик объекта БД.

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

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

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

Итак, были созданы новые объекты конфигурации:

− Справочник ВариантыНоменклатуры, чтобы описывать партии материалов.

− Справочник ДополнительныеСвойстваНоменклатуры, чтобы задавать значения видов характеристик, для которых нет подходящих типов в конфигурации.

− План видов характеристик СвойстваНоменклатуры, чтобы создавать виды характеристик.

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

Далее эти объекты конфигурации были доработаны внесением корректировок в формы и созданием новых элементов для каждого из объектов. Была добавлена возможность указывать произвольные характеристики для номенклатуры и созданы несколько таких характеристик – вариантов номенклатуры. Для того, чтобы иметь возможность еще и учитывать номенклатуру в разрезе этих характеристик, а именно:

− приходовать товар, указывая характеристики,

− расходовать товар, указывая характеристики;

− получать отчеты не просто по номенклатуре, а по номенклатуре с определенными характеристиками

были доработаны регистры и создан новый отчет (рисунок 14.1).

Рисунок 14.1 – Отчет Материалы

На данном этапе:

− Изменена структура регистра накопления ОстаткиМатериалов;

− Доработан документ ПриходнаяНакладная;

− Доработан документ ОказаниеУслуги.

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

Набором данных для системы компоновки данных был простой запрос к регистру ОстаткиМатериалов, к нему было описано как выглядит механизм характеристик. На основе этих описаний система компоновки сама сформировала достаточный интерфейс.

Рисунок 14.2 – Отчет ОстаткиМатериалов

Бухгалтерский учёт

Для организации бухучета использован план видов характеристик и два новых объекта – План счетов и Регистр бухгалтерии. Регистр бухгалтерии используется для накопления данных о совершенных хозяйственных операциях. С помощью плана счетов описываются счета, в разрезе которых ведется учет, а план видов характеристик служит для описания объектов аналитического учета, в разрезе которых должен вестись учет на счетах.

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

Бухучет подразумевает ведение аналитического учета на большинстве счетов. Для обозначения разрезов аналитического учета используется термин виды субконто. Т.е. на каждом счете учет может вестись в разрезе нескольких видов субконто. А для обозначения конкретных объектов аналитического учета используется термин субконто. Для ведения аналитического учета в системе 1С: Предприятие применяется механизм субконто.

Субконто называется любой объект аналитического учета: основные средства, нематериальные активы, малоценные и быстроизнашивающиеся предметы, материалы, организации, подотчетные лица, договоры, бюджеты Видом субконто, в свою очередь, называется множество однотипных объектов аналитического учета. Для организации видов субконто в системе 1С: Предприятие используются объекты метаданных «Виды субконто». Конфигуратор позволяет организовывать любое необходимое число видов субконто.

Субконто — термин, обозначающий аналитический признак («разрез») счета бухгалтерского учета. Низший иерархический элемент в структуре бухгалтерских счетов. Используется в бухгалтерских программах. Субконто - аналитический показатель, позволяющий расшифровать счет по заранее неизвестному или постоянно меняющемуся набору строк - справочнику.

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

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

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

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

Рисунок 15.1 – Основной план счетов

 

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

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

В заключение работы был создан отчет для бухгалтерии предприятия с именем ОборотноСальдоваяВедомость (рисунок 15.2).

Рисунок 15.2 – Оборотно-сальдовая ведомость

Бухгалтерский отчет Оборотно-сальдовая ведомость представляет собой таблицу, в строках которой перечислены все имеющиеся в плане счетов счета, а в колонках – начальное сальдо, оборот и конечное сальдо по дебету и кредиту каждого счета. Сальдо в бухгалтерском учете – остаток по бухгалтерскому счету, разность между суммой записей по дебету и кредиту счетов. Дебетовое сальдо (дебет больше кредита) отражает состояние данного вида хозяйственных средств на определенную дату и показывается в активе баланса. Кредитовое сальдо (кредит больше дебета) отражает состояние источников хозяйственных средств и показывается в пассиве. Если счет не имеет остатка (сальдо равно нулю), то такой счет называется закрытым. В бухгалтерском учете некоторые счета могут одновременно иметь и дебетовое, и кредитовое сальдо.

План видов расчета, регистр расчета

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

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

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

− Зависимость от базы – определяет, будут ли в этом плане находиться зависимые по базовому периоду виды расчета.

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

− Базовые – их результаты должны быть использованы при перерасчете этого вида расчета.

− Вытесняющие – вытесняют этот вид расчета по периоду действия.

− Ведущие – изменение их результатов должно приводить к необходимости перерасчета этого вида расчета

Объект конфигурации Регистр расчета предназначен для описания структуры накопления данных, являющихся результатами расчетов. На основе регистра расчета платформа создает в базе данных таблицы, в которых будут накапливаться данные, формируемые различными объектами базы данных.

Отличительные особенности регистра расчета:

· Он не предназначен для интерактивного редактирования пользователем. Разработчик может при необходимости предоставить пользователю возможность редактирования, но изначально регистр расчета для этого не предназначен.

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

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

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

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

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

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

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

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

Регистр расчета может быть связан с графиком времени. Такой график времени должен представлять собой регистр сведений (непериодический, с обязательным измерением типа Дата и ресурсом типа Число), в котором содержится временная схема исходных данных, участвующих в расчетах. Измерениями этого графика могут быть, например, график работы (ссылка на справочник) и дата, а ресурсом – количество рабочих часов в этой дате. В этом случае можно будет связать запись регистра расчета с каким-либо конкретным графиком работы (указав в качестве реквизита записи ссылку на справочник ВидыГрафиковРаботы) и в дальнейшем средствами встроенного языка получать информацию о количестве рабочих часов в периоде действия, фактическом периоде действия или периоде регистрации этой записи.

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

Рисунок 16.1 – Графики работы сотрудников