Момент времени и граница, назначение, примеры использования. VIII

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

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

Пару слов о моем опыте работы с 1С

Сейчас, как я уже не раз писал, я работаю бизнес-консультантом в сфере малого и среднего бизнеса. Я постоянно сталкиваюсь с различными задачами по автоматизации работы, и, как следствие, с программными продуктами 1С. Чаще всего я в качестве бизнес-консультанта нанимаю специалистов по 1С для решения определенных задач, у меня есть постоянная команда, привлекаю также и сторонних специалистов, в том числе, на фрилансе. В очень редких случаях пишу что-то на 1С и сам, чаще всего, если нужно в срочном порядке решить небольшую задачу.

С другой стороны, я все дальше и дальше ухожу от постоянной работы с продуктами 1С. Если на заре моей карьеры работа с программами 1С приносила мне 100% дохода, то сегодня внедрение каких-то 1С решений занимает в моей работе не более 20%, все остальное – это сайты, это CRM-системы и т.д.

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

Еще немного об 1С и о том, зачем я это все пишу

1. Я планирую создать целую серию статей об 1С, где расскажу об этом программном продукте с разных точек зрения. Эта статья предназначена, прежде всего, для программистов. А потому я размещаю ее на Хабре. Следующие будут охватывать более широкий спектр понятий, интересных в том числе, бизнесменам и пользователям программных продуктов 1С, а потому они будут размещены на Мегамозге.
2. Я не буду углубляться в нюансы применения кода, в другие технические подробности, которые каждый из вас может самостоятельно прочитать на официальном сайте 1С, на сайтах поддержки, на известных форумах и пр.
3. Я не буду обсуждать нюансы работы той или иной версии платформы. Более того, чаще всего я буду говорить о платформе 8.3 как о последней актуальной на момент написания статьи, а также о типовых конфигурациях, которые наиболее востребованы у моих клиентов (средний и малый бизнес).

Сегодня компания 1С своими силами внесла такое количество путаницы в описания продуктов, в требования к уровню специалистов, которые будут настраивать систему, в выбор платформы, конфигурации, плагинов, надстроек, версий и прочее, прочее, что система 1С лично мне начинает напоминать старый сериал «Спрут». Если кто-то еще помнит, то в этом фильме комиссар боролся с преступной группировкой, часть которой являлась банковская группа. И эта банковская система была настолько запутанной, что понять, откуда берутся деньги, куда они уходят, каким образом работает то или иное подразделение и главное зачем, было очень трудно.

В системе 1С усилия по «запутыванию» пользователя, как мне кажется, направлены на одно: не надо ни в чем разбираться, надо просто платить. И многие бизнесмены приходят к тому, что платят и правда, не разбираясь, надо ли им это обновление, требуется ли им этот продукт. Просто платят и все.

Я же попытаюсь распутать «щупальца Спрута» и структурирую общее понимание того, каким образом работает система 1С.

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

А если вам нужны какие-то конкретные технические нюансы работы 1С, то вы всегда можете воспользоваться следующими ресурсами:

1. Сайт 1С и партнерский форум. http://www.1c.ru
2. Другие ресурсы

1С как экосистема

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

В статье я уже рассказывал, что на самом деле 1С нужно воспринимать как целую экосистему. Именно такой подход поможет понять, что такое 1С и зачем она нужна.

Итак, с точки зрения технической экосистемы 1С состоит из следующих компонентов:

1. Платформа 1С – это та основа, на которой пишутся конфигурации, с которой работают программисты и пр. Она обновляется от версии к версии, а потому может быть: 6.0, 7.7, 8.0, 8.2 или 8.3.
2. Конфигурация. Это следующий уровень конкретизации. Конфигурации пишутся на платформе с использованием кода 1С. Пользователи работают с конфигурациями.
3. 1С Битрикс. Система для работы с сайтами, о ней поговорить стоит отдельно.

1. Сама компания 1С и ее штат специалистов.
2. Партнеры 1С (франчайзинг) и специалисты, занимающиеся обслуживанием системы. Их также стоит вныделить в качестве одной из составляющих эко-системы. Без специалистов, которые дорабатывают и внедряют 1С, система работать не будет. Это могут быть компании-партнеры 1С или одиночки-фрилансеры, не важно, они просто должны быть, иначе система не будет жизнеспособной.

Платформа

Работать можно на разных версиях платформы. Я знаю, что на практике встречается применение версии 8.2 и 8.0, а также достаточно старой, но все еще популярной 7.7, иногда встречается даже использование первого удачного релиза 6.0. Но я буду говорить исключительно о версии 8.3, как о самой последней на момент написания статьи. Многие вещи, которые мы обсудим, одинаково актуальны и для прошлых версий. Но часть была добавлена только в последних релизах. Хотелось бы, чтобы читатели учитывали этот факт.

Программисты при работе с 1С используют специальный язык программирования, который был создан разработчиками 1С для работы с платформой 1С. Сегодня он доступен на русском и английском языках, но изначально был написан на русском, а потому типовые конфигурации также пишутся традиционно на русском языке, хотя всегда есть возможность применить в нужном месте также и английские версии операторов, если программисту так удобнее работать. Язык этот представляет смесь бейсика и C+ с добавлением SQL для написания запросов. Кроме того, в нем предусмотрена возможность использования различных конструкторов и плагинов.

Еще одна ремарка, которая поможет, надеюсь, избежать флейма и споров:

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

Варианты поставки платформы

• Файловое решение
• Клиент-серверный вариант

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

Для решения этой проблемы компания 1С пытается примерять кэширование данных, но этот метод пока что приносит еще больше проблем. Если кому-то интересна эта тема, достаточно набрать в поисковой системе «проблемы кэша 1С», в поиске будет очень много форумов и обсуждений по этому поводу с самыми разными проблемами, которые в итоге сводятся к тому, что кэширование работает не всегда корректно.

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

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

Версии 1С для разных платформ

Итак, существуют версии 1С:

• для Windows,
• для Linux.

Программу 1С, которая работает под Windows, разрабатывали с самого начала, это мощный привычный всем инструмент, который достаточно доработан, чтобы пользоваться им без особых проблем. Версия под Linux на сегодняшний день считается еще новой, а потому достаточно «сырой», в ней пока еще имеется очень много ошибок, как и в любом новом программном продукте.

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

Компонентная база 1С

Что можно сказать о компонентах платформы 1С:

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

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

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

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

По этому признаку можно выбрать:

1. Нативный 1С-клиент. Это традиционный программный интерфейс, когда к 1С идет обращение из 1С.
2. Работу через браузер.
3. Работу через мобильное приложение.

Нативный клиент

В чем разница между этими подклиентами?

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

Web-клиент (работа через браузер)

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

Мобильная версия

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

• Настройка доступа к базе данных извне;
• Решение вопросов безопасности;
• Настройка сервера для работы с мобильными приложениями;
• Настройка программных продуктов 1С;
• Настройка web-приложений (по необходимости).

Платформа 1С: резюме

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

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

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

Все это вместе приводит к проблеме позиционирования:

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

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

На понятийном уровне я думаю, информации достаточно. А технические нюансы вы всегда можете найти на ресурсах 1С, которые я рекомендовал выше.

Конфигурации

Конфигурации бывают:

1. Типовые – написанные компанией 1С. Они все присутствуют на сайте 1С.
2. Нетиповые – написанные компаниями-партнерами.

1. Типовые конфигурации создает и сопровождает компания 1С. В большинстве случаев они большее качественные, в этих конфигурациях лучше организована работа с кодом, используются чаще всего оптимальные решения, оперативно исправляются ошибки. Конечно, все и постоянно слышат о «вечных багах» в типовых конфигурациях 1С, и они там действительно постоянно присутствуют, но все таки, стоит отдать должное специалистам компании. Критичные ошибки они исправляют действительно оперативно.
2. Нетиповые конфигурации пишут компании-партнеры 1С, и здесь достаточно сложно сказать что-то определенное. Такие конфигурации бывают очень разными. Чаще всего их пишут по случаю: отраслевые (для какой-то определенной отрасли) или написанные для определенного случая (конкретной компании). И здесь необходимо понимать, что компании-партнеры 1С в большинстве своем имеют достаточно высокую текучку кадров. А потому и конфигурации в них пишутся довольно не организовано. Начинает писать один программист, продолжает – другой, завершает – третий. При это каждый из них вносит туда что-то свое, свое понимание, решения, идеи. А наработки предшественника применяет так, как удобно, а не как это было задумано.

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

1. Написанные на основе типовых. Эти конфигурации создаются путем добавления функционала к какой-то типовой. Например, существует такой продукт, как 1С: Управление торговлей и CRM. Здесь совместили типовую конфигурацию Управление торговли и систему CRM. Интересно, что создатели конфигурации компания Рарус, называют именно Управление торговли подсистемой, хотя на самом деле – это была та основа, на которой писалась вся конфигурация.
      Плюсы таких конфигураций – они более функциональны в сравнении с типовыми, в них добавлены часто очень нужные возможности.
      Минусы – разработчики этих конфигураций часто не успевают создавать своевременно свои обновления. Таким образом, очень может быть, что компания 1С уже выложила свои варианты обновлений, а пользователю нетипового решения придется ждать какое-то время, пока разработчик создаст аналогичное обновление для конкретного решения. Кроме того, подобные доработки также бывают достаточно «сырыми», в них может быть много ошибок.
      
2. Конфигурации, написанные с нуля. При их создании типовые конфигурации не используются вообще, решения пишутся для определенных задач.
      Плюсы : конфигурация написала точно под нужны заказчика, здесь есть все необходимое и почти ничего лишнего.
      Минусы : обычно при написании подобных решений стандарты кода не соблюдаются, дорабатывать подобные программные продукты очень сложно, чаще всего, это может сделать достаточно быстро только автор.

Резюме

Таким образом, программисту важно знать, с какой платформой потребуется работать. Пользователю интересна конфигурация. При этом без помощи 1С: программиста бизнес в большинстве случаев не сможет настроить работу нужной конфигурации. Потому я называю специалистов 1С – неотъемлемой частью эко-системы 1С.

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

Для внедренцев, которые работают с типовыми или собственными конфигурациями – и тех, кто готовится к Аттестации на 1С:Специалист по платформе.

В статье мы разберем:

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

Время на прочтение – 20 минут.

Итак, две методики контроля остатков в 1С:Предприятии 8.3

Давайте начнем с того, что обозначения “старая методика” и “новая методика” достаточно условны. В самом деле, если “новая методика” используется с 2010 года – она уже не очень новая:)

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

“Старая методика” – это подход к контролю остатков, который использовался со времен «1С:Предприятие 8.0».

C 2010 года, с развитием платформы и добавлением новых возможностей с «1С:Предприятие 8.2» – применяется “новая методика” (однако – не везде ).

В чем разница?

Принципиальная разница – в моменте контроля остатков:

• В “старой” методике остатки контролируются ДО записи движений в регистры.
  Сначала проверяем остатки, если остатков “не хватает” (будут возникать отрицательные остатки) – проводить документ не будем
• В “новой” методике – контроль происходит ПОСЛЕ записи движений, то есть постфактум.
  Если после проведения образовались отрицательные остатки – нужно «откатить» транзакцию, то есть отменить проведение документа.

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

Ok, значит, старая методика ушла в прошлое и это удел УТ 10.3?

Нет, это не совсем так.

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

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

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

Например, вот так:

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

Вот пример одного регистра и для количества, и для себестоимости:

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

Не всегда!

Вот, например, в «1C:Управление торговлей 11.3» есть 2 регистра:

При проведении документов отгрузки регистр «Себестоимость товаров» не заполняется вообще. Данные в этот регистр попадают только при выполнении регламентных операций по закрытию месяца.

В УТ 11 используется новая методика , так как все данные для проведения документов можно получить, не обращаясь к контролируемым регистрам.

Что касается «1C:Бухгалтерии», то там и количество, и себестоимость хранятся в одном регистре бухгалтерии, на соответствующих счетах БУ.

Поэтому в БП 3.0 используется старая методика .

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

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

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

В этом простом вопросе часто встречаются заблуждения.

Иногда считают, что оперативное проведение – это контроль остатков по новой методике. Это не так, от слова «совсем».

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

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

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

Что значит «регистрировать здесь и сейчас»? Платформа для оперативно проводимых документов выполняет ряд действий:

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

Но главное другое – система передает признак оперативности проведения документа в обработку проведения:

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

Актуальные остатки хранятся в системе и получаются максимально быстро (остатки на другие даты в большинстве случаев получаются расчетным путем).

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

Интересный факт.

В УТ 11 документам, списывающим номенклатуру, запрещено проводиться оперативно. Например, это документы «Реализация товаров и услуг», «Сборка товаров», «Перемещение товаров», «Внутреннее потребление товаров» и другие.

Почему так сделано?

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

Контроль остатков по новой методике – без блокировок

Коротко рассмотрим алгоритм контроля остатков при проведении документа «Реализация товаров и услуг» на модельной конфигурации.

Есть два регистра:

• Свободные остатки – для количественного учета
• Себестоимость товаров – для учета себестоимости

Для контроля остатков товаров достаточно работы с регистром «Свободные остатки».

Код обработки проведения будет выглядеть таким образом:

Запрос = Новый Запрос;

#Область Область1
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
#КонецОбласти

#Область Область2
Запрос.Текст =
"ВЫБРАТЬ

|ПОМЕСТИТЬ ТоварыДокумента
|ИЗ
|ГДЕ
|
|СГРУППИРОВАТЬ ПО
|
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура
|;

|ВЫБРАТЬ
| &Дата КАК Период,
| ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход) КАК ВидДвижения,
| ТоварыДокумента.Количество КАК Количество
|ИЗ
";
Запрос.УстановитьПараметр("Дата", Дата);
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
Движения.Записать();
#КонецОбласти

#Область Область5
Запрос.Текст =
"ВЫБРАТЬ
| -СвободныеОстаткиОстатки.КоличествоОстаток КАК Дефицит
|ИЗ
| ТоварыДокумента КАК ТоварыДокумента
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.СвободныеОстатки.Остатки(
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| ТоварыДокумента.Номенклатура КАК Номенклатура
| ИЗ
| ТоварыДокумента КАК ТоварыДокумента)) КАК СвободныеОстаткиОстатки
| ПО ТоварыДокумента.Номенклатура = СвободныеОстаткиОстатки.Номенклатура
|ГДЕ
| СвободныеОстаткиОстатки.КоличествоОстаток < 0";
#КонецОбласти

#Область Область6
МоментКонтроляОстатков =
?(Режим = РежимПроведенияДокумента.Оперативный,
Неопределено,
Новый Граница(МоментВремени(), ВидГраницы.Включая));
Запрос.УстановитьПараметр("МоментВремени", МоментКонтроляОстатков);
РезультатЗапроса = Запрос.Выполнить();
#КонецОбласти

#Область Область7
Если НЕ РезультатЗапроса.Пустой() Тогда
Отказ = Истина;
ВыборкаОшибки = РезультатЗапроса.Выбрать();
Пока ВыборкаОшибки.Следующий() Цикл
Сообщение.Текст = "Недостаточно товара в количестве: "+ВыборкаОшибки.Дефицит;
Сообщение.Поле = "Товары["+(ВыборкаОшибки.НомерСтроки-1)+"].Количество";
Сообщение.Сообщить();
КонецЦикла;
КонецЕсли;
#КонецОбласти

#Область Область8
Если Отказ Тогда
Возврат;
КонецЕсли;
#КонецОбласти

КонецПроцедуры

Рассмотрим ключевые точки алгоритма контроля остатков.

1. Инициализация менеджера временных таблиц

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

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

2. Запрос, группирующий данные табличной части

В запросе выбираются сгруппированные данные табличной части.

Обратите внимание, что выбирается и номер строки документа – он потребуется для контекстной привязки сообщения об ошибке. Для номера строки используется агрегатная функция МИНИМУМ() – то есть сообщение будет привязано к первой строке, где встречается указанная номенклатура.

В первом запросе пакета создается временная таблица. Во втором запросе выбираются данные временной таблицы и добавляются 2 поля, необходимые для каждой записи регистра – Период и ВидДвижения.

Плюсы такого подхода:

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

Кстати, подобный подход используется в типовых конфигурациях, в частности, в УТ 11 и БП 3.0.

4. Запись движений в БД

Запись можно было бы выполнить одной командой (вместо двух) – Движения.СвободныеОстатки.Записать().

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

Но более универсальным является такой подход:

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

После выполнения команды «Движения.Записать()» флаг Записывать у всех наборов сбросится в Ложь.

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

В типовых решениях используется подобная схема для записи движений. Почему?

Метод Записать() коллекции Движения записывает наборы записей в одинаковой последовательности даже для разных документов.

Запись же движений вручную может привести к проблемам.

Приведем пример.

Если в документе «Реализация» выполнить запись так:

Движения.СвободныеОстатки.Записать();
...
Движения.СебестоимостьТоваров.Записать();

А в документе «Перемещение товаров» изменить порядок:

Движения. СебестоимостьТоваров.Записать();
...
Движения. СвободныеОстатки.Записать();

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

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

5. Запрос, получающий отрицательные остатки

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

Отрицательный остаток – это и есть нехватка (дефицит) товара.

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

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

6. Определение момента времени для контроля остатков

Вот здесь нам пригодилось оперативное проведение.

Если документ проводится оперативно, то момент для получения остатков – Неопределено, что означает получение актуальных остатков.

Если это неоперативное проведение, то мы получаем момент времени «после» документа – чтобы учесть только что сделанные движения.

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

Именно в этом и заключается выигрыш оперативно проводимых документов.

7. Если запрос не пустой, значит, образовались отрицательные остатки

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

Вот так будет выглядеть диагностическое сообщение:

8. Если есть ошибки, то возвращаемся из обработчика события

Если была хоть одна ошибка – выходим из процедуры.

Поскольку нет смысла продолжать проведение, транзакция всё равно не будет зафиксирована (а дальше у нас будет разработан код по списанию партий).

Реализация списания себестоимости по партиям

После того, как проверка остатков прошла успешно, можно приступать к списанию партий.

Код для списания по FIFO будет таким:

// I. Анализ смещения даты документа вперед

И НЕ ЭтотОбъект.ЭтоНовый()
И ЭтотОбъект.Проведен Тогда

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Документ.Дата КАК Дата
|ИЗ
|ГДЕ

РезультатЗапроса = Запрос.Выполнить();
ВыборкаДокумент.Следующий();

Иначе
Ложь);
КонецЕсли;

КонецПроцедуры

Процедура ПриЗаписи(Отказ)

ЭтотОбъект.ДополнительныеСвойства.Вставить("ДатаДокументаСдвинутаВперед",
ЭтотОбъект.Дата>

КонецЕсли;

КонецПроцедуры

Процедура ОбработкаПроведения(Отказ, Режим)

Запрос = Новый Запрос;

// 1. Инициализация менеджера временных таблиц
#Область Область1
...
#КонецОбласти

// 2. Запрос, группирующий данные табличной части
#Область Область2
...
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
...
#КонецОбласти

// 5. Запрос, получающий отрицательные остатки
#Область Область5
...
#КонецОбласти

// 6. Определение момента времени для контроля остатков
#Область Область6
...
#КонецОбласти

// 7. Если запрос не пустой, значит образовались отрицательные остатки
#Область Область7
...
#КонецОбласти

// 8. Если есть ошибки, то возвращаемся из обработчика события
#Область Область8
...
#КонецОбласти

// II. Подготовка наборов записей регистра "Себестоимость товаров"
#Область ОбластьII

Движения.Записать();
КонецЕсли;
Движения.СебестоимостьТоваров.Записывать = Истина;
#КонецОбласти

// III. Запрос получающий остатки партий для списания по FIFO
#Область ОбластьIII
Запрос.Текст =
"ВЫБРАТЬ
| ТоварыДокумента.Номенклатура КАК Номенклатура,
| ТоварыДокумента.НомерСтроки КАК НомерСтроки,

| Остатки.Партия КАК Партия
|ИЗ
| ТоварыДокумента КАК ТоварыДокумента
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| ИЗ

|УПОРЯДОЧИТЬ ПО
|ИТОГИ
| МАКСИМУМ(Количество),
| СУММА(КоличествоОстаток)
|ПО
| Номенклатура";
РезультатЗапроса = Запрос.Выполнить();
#КонецОбласти

// IV. Цикл по номенклатуре документа
#Область ОбластьIV

// V. Получим количество для списания
// VI. Цикл по партиям по FIFO
Пока ВыборкаПартии.Следующий() И ОсталосьСписать>0 Цикл
// VII. Проверка на нулевой остаток
Если ВыборкаПартии.КоличествоОстаток=0 Тогда
Продолжить;
КонецЕсли;
Движение.Период = Дата;

// VIII. Расчет количества и суммы для списания

// IX. Уменьшим количество для списания
КонецЦикла;
КонецЦикла;
#КонецОбласти

КонецПроцедуры

Разберем ключевые точки алгоритма списания партий по FIFO.

I. Анализ смещения даты документа вперед

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

Для анализа сдвига даты документа потребуется 2 события:

• Перед записью – для получения старой даты документа и проверки режима проведения документа
• При записи – для получения новой даты документа

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

Похожий прием используется в типовой «1С:Бухгалтерии 8». Но там используется одно событие «Перед записью».

Почему в БП не нужно задействовать «При записи»?

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

II. Подготовка наборов записей регистра «Себестоимость товаров»

Для документа установлен режим удаления движений – “При отмене проведения”:

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

Приведем пример:

• Остаток мониторов LG на момент проведения документов – 10 шт.
• Проводится документ, который списывает 8 шт.
• В этом же документе время увеличивается на 1 минуту, перепроводим

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

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

Но это неправильно: ситуации изменения «неоперативных» документов (вчерашних и более ранних) они не учтут.

То есть проблема «нехватки 6 мониторов» (см. выше) будет в этом случае решена только для документов изменяемых сегодняшним числом.

III. Запрос, получающий остатки партий для списания по FIFO

В запросе обращаемся к остаткам по партиям, при этом накладываем итоги по номенклатуре.

На уровне итогов получается количество из документа – МАКСИМУМ(Количество) и остаток партии – СУММА(КоличествоОстаток).

Как Вы думаете, может ли количество из документа превышать суммарный остаток номенклатуры по всем партиям?

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

IV. Цикл по номенклатуре документа

Благодаря итогам в запросе во внешнем цикле обходим номенклатуру из документа.

V. Получим количество для списания

Запомним, какое количество нужно списать. Далее это количество будет уменьшаться.

VI. Цикл по партиям по FIFO

Вложенный цикл будет содержать партии по текущей номенклатуре.

VII. Проверка на нулевой остаток

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

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

VIII. Расчет количества и суммы для списания

Количество для списания - это минимальное значение между остатком партии и тем, что осталось списать.

Сумма рассчитывается элементарной пропорцией.

Если списывается весь остаток партии, то будет списана и вся сумма этой партии. Это математика 3-го класса церковно-приходской школы: Х*Y/X = Y:)

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

А тем, кто дает вредные советы имеет смысл заглянуть в конфигурацию «1С:Бухгалтерия 8». Там (о, ужас!) нет проверки на то, что списывается партия целиком:)

Вот скрин общего модуля «Учет товаров», метод «СписатьОстаткиТоваров»:

IX. Уменьшим количество для списания

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

Зачем нужны управляемые блокировки?

Вот мы и дошли до управляемых блокировок.

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

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

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

В этом примере два пользователя почти одновременно проводят продажу товаров – документ №2 начал проводиться чуть позже документа 1.

При получении остатка система сообщает, что остаток 10 шт., и оба документа успешно проводятся. Печальный итог – на складе минус 5 мониторов LG.

Но при этом контроль остатков работает! То есть, если документ №2 будет проводиться после окончания проведения документа №1, система не проведет документ №2:

Иногда встречается заблуждение – «У меня в базе одновременно работают только 3-4 пользователя, вероятность параллельного проведения документов равна нулю, поэтому на блокировки можно не отвлекаться».

Это очень опасное рассуждение .

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

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

Как решить проблему при параллельном проведении документов?

Решение простое – заблокировать мониторы LG в момент времени Т1, так чтобы другие транзакции не могли обратиться к остаткам по этому товару.

Тогда в момент времени Т2 система будет ждать, когда монитор LG будет разблокирован. И после этого система получит актуальный остаток товаров и будет выполнено (или не выполнено) списание товаров.

Буквально пару слов о классификации блокировок.

Существует 2 типа блокировок:

• Объектные
• Транзакционные .

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

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

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

Когда нужно накладывать блокировки?

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

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

То есть блокировки нужно накладывать при проведении всех документов?

Ни в коем случае. Устанавливать блокировки «на всякий случай» точно не стоит . Ведь сами по себе блокировки снижают параллельность работы пользователей (масштабируемость системы).

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

В примере выше таким ресурсом является остаток по товару. Система должна была заблокировать остаток с момента получения данных об остатке (Т1) до окончания транзакции (Т3).

Примечание. Транзакция при проведении документа №1 начинается раньше, чем момент получения остатков. Но для простоты считаем, что Т1 – и время начала проведения документа, и момент получения остатков.

Пример, когда не нужно накладывать блокировку – проведение документа «Поступление товаров». В этом случае нет никакой конкуренции за ресурсы (остатки, …), поэтому блокировка будет вредна: она уменьшит масштабируемость системы.

Автоматические и управляемые блокировки

Здесь мы не будем вдаваться в теорию (это тема отдельной статьи), а скажем лишь, что управляемые блокировки являются более оптимальными.

Вместо теории можем привести пруф – все современные типовые конфигурации работают на управляемых блокировках.

Поэтому в нашей модельной конфигурации будет выбран соответствующий режим:

Управляемые блокировки в новой технологии контроля остатков

Блокировку будем накладывать на регистр “Свободные остатки” и только на номенклатурные позиции, встречающиеся в документе.

Причем правильный вариант наложения блокировки – как можно позднее.

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

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

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

Нужно просто установить свойство БлокироватьДляИзменения у набора записей регистра:

// 3.1. Блокировка остатков регистра
#Область Область3_1
Движения.СвободныеОстатки.БлокироватьДляИзменения = Истина;
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
Движения.СвободныеОстатки.Записывать = Истина;
Движения.Записать();
#КонецОбласти
...

В результате 2 транзакции не смогут изменять свободные остатки по одной номенклатуре.

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

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

Кстати, в типовой УТ 11 не так-то просто найти установку свойства БлокироватьДляИзменения для регистра “Свободные остатки”. Дело в том, что это выполняется в модуле набора записей регистра, в событии “Перед записью”.

Вот и всё, одной строкой кода была обеспечена корректная работа системы!

Важно . Мы не накладываем блокировку на регистр “Себестоимость товаров”.

Почему? Такая блокировка являлась бы излишней (а это определенная нагрузка на сервер 1С), поскольку движения в регистры “Свободные остатки” и “Себестоимость товаров” выполняются всегда синхронно, то есть последовательно друг за другом.

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

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

Старая методика контроля остатков

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

Пусть это будет регистр “Себестоимость товаров”:

Тогда алгоритм проведения документа “Реализация товаров” будет выглядеть вот так:

// 1. Обработчик события "Перед записью"
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)

Если РежимЗаписи = РежимЗаписиДокумента.Проведение
И НЕ ЭтотОбъект.ЭтоНовый()
И ЭтотОбъект.Проведен Тогда

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Документ.Дата КАК Дата
|ИЗ
| Документ.РеализацияТоваровУслуг КАК Документ
|ГДЕ
| Документ.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", ЭтотОбъект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДокумент = РезультатЗапроса.Выбрать();
ВыборкаДокумент.Следующий();

ЭтотОбъект.ДополнительныеСвойства.Вставить("СтараяДатаДокумента", ВыборкаДокумент.Дата);

Иначе
КонецЕсли;

КонецПроцедуры

Процедура ПриЗаписи(Отказ)

Если НЕ ЭтотОбъект.ДополнительныеСвойства.Свойство("ДатаДокументаСдвинутаВперед") Тогда

ЭтотОбъект.ДополнительныеСвойства.Вставить("ДатаДокументаСдвинутаВперед",
ЭтотОбъект.Дата>ЭтотОбъект.ДополнительныеСвойства.СтараяДатаДокумента);

Сообщить(ЭтотОбъект.ДополнительныеСвойства.ДатаДокументаСдвинутаВперед);
КонецЕсли;

КонецПроцедуры

Процедура ОбработкаПроведения(Отказ, Режим)

// 2. Удаление "старых" движений документа
Если ДополнительныеСвойства.ДатаДокументаСдвинутаВперед Тогда
Движения.СебестоимостьТоваров.Записывать = Истина;
Движения.СебестоимостьТоваров.Очистить();
Движения.Записать();
КонецЕсли;

// 3. Установка флага для записи движений в конце транзакции
Движения.СебестоимостьТоваров.Записывать = Истина;

// 4. Запрос, получающий остатки по партиям на момент времени документа
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РеализацияТовары.Номенклатура КАК Номенклатура,
| СУММА(РеализацияТовары.Количество) КАК Количество,
| МИНИМУМ(РеализацияТовары.НомерСтроки) КАК НомерСтроки
|ПОМЕСТИТЬ ТоварыДокумента
|ИЗ
| Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТовары
|ГДЕ
| РеализацияТовары.Ссылка = &Ссылка
|СГРУППИРОВАТЬ ПО
| РеализацияТовары.Номенклатура
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура
|;
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ТоварыДокумента.Номенклатура КАК Номенклатура,
| ТоварыДокумента.Количество КАК Количество,
| ТоварыДокумента.НомерСтроки КАК НомерСтроки,
| ЕСТЬNULL(Остатки.КоличествоОстаток, 0) КАК КоличествоОстаток,
| ЕСТЬNULL(Остатки.СуммаОстаток, 0) КАК СуммаОстаток,
| Остатки.Партия КАК Партия
|ИЗ
| ТоварыДокумента КАК ТоварыДокумента
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.СебестоимостьТоваров.Остатки(
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| Т.Номенклатура КАК Номенклатура
| ИЗ
| ТоварыДокумента КАК Т)) КАК Остатки
| ПО ТоварыДокумента.Номенклатура = Остатки.Номенклатура
|УПОРЯДОЧИТЬ ПО
| Остатки.Партия.МоментВремени
|ИТОГИ
| МАКСИМУМ(Количество),
| СУММА(КоличествоОстаток)
|ПО
| НомерСтроки";

Запрос.УстановитьПараметр("МоментВремени", МоментВремени());
Запрос.УстановитьПараметр("Ссылка", Ссылка);

РезультатЗапроса = Запрос.Выполнить();

ВыборкаНоменклатура = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);

// 5. Цикл по номенклатуре - проверяем достаточность количества для списания
Пока ВыборкаНоменклатура.Следующий() Цикл

ДефицитНоменклатуры = ВыборкаНоменклатура.Количество - ВыборкаНоменклатура.КоличествоОстаток;

Если ДефицитНоменклатуры>0 Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Недостаточно товара в количестве: "+ДефицитНоменклатуры;
Сообщение.Поле = "Товары["+(ВыборкаНоменклатура.НомерСтроки-1)+"].Количество";
Сообщение.УстановитьДанные(ЭтотОбъект);
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;

Если Отказ Тогда
Продолжить;
КонецЕсли;

// 6. Получим количество для списания
ОсталосьСписать = ВыборкаНоменклатура.Количество;
ВыборкаПартии = ВыборкаНоменклатура.Выбрать();

// 7. Цикл по партиям
Пока ВыборкаПартии.Следующий() И ОсталосьСписать>0 Цикл

Движение = Движения.СебестоимостьТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Номенклатура = ВыборкаПартии.Номенклатура;
Движение.Партия = ВыборкаПартии.Партия;
// 9. Расчет количества для списания
Движение.Количество = Мин(ОсталосьСписать, ВыборкаПартии.КоличествоОстаток);
// 10. Расчет суммы списания
Движение.Сумма = Движение.Количество*
ВыборкаПартии.СуммаОстаток/ВыборкаПартии.КоличествоОстаток;

// 11. Уменьшим количество для списания
ОсталосьСписать = ОсталосьСписать - Движение.Количество;

КонецЦикла;
КонецЦикла;

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

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

1.2. Дата и время документа

1.3. Порядок расположения документов

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

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

1.4. Изменение документов "задним числом"

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

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

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

1.5. Перепроведение документов

Соблюдение перечисленных правил позволяет программе, например, построить отчет о наличии товаров или любых других средств на любой момент времени. Причем, данные этого отчета будут совпадать с реальным наличием средств на тот момент времени. Кроме того, определенные механизмы учета "1С:Предприятия" основываются на текущих итогах на момент конкретного документа. Например, при проведении расходной накладной может выполняться расчет себестоимости списания "по средней" или по методу LIFO (FIFO). Разумеется, при изменении документа "задним числом" все документы, которые следуют за измененным документом, автоматически не перепроводятся. Их может быть очень много, и такая операция заняла бы продолжительное время. Однако, изменение документов "задним числом" приводит к тому, что списание, выполненное последующими документами, становится неверным. Например, если выяснилось, что в начале месяца неверно указали сумму приходной накладной, то очевидно, что все расходные накладные, по которым отпускались данные товары после этой приходной накладной, неверно рассчитали сумму списания. Для решения этой проблемы в "1С:Предприятии" существует возможность не только исправления документа "задним числом", но и перепроведения документов с целью правильного отражения в учете всех последующих хозяйственных операций. В процессе перепроведения каждый документ заново выполняет анализ итогов на тот момент, в котором он расположен в журнале, и соответственно правильно отражает данные списания в учете. Разумеется, перепроводить имеет смысл только те виды документов, которые в процессе проведения анализируют текущие итоги.

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

2. Проблема проведения последовательности при работе с УРБД

• Было взято 3 метода: ПринадлежитПоследовательности - как метод документа;
• ПринадлежитПоследовательности - как метод последовательнсоти;
• Сравнить - как метод последовательности. Был проведен опыт на базе, с УРБД (ЦБ) в SQL формате.

При попытке востановить последовательность проводятся лишь те доки, для которых поле DS7536 = 1. Т.е. для рещения проблемы восстановления последовательности - надо для всех проведенных доков и которые после ГП установить поле DS7536 = 1. А теперь собственно говоря, почему такое возникает? Т.е. почему при доступных значениях метода последовательности "ПринадлежитПоследовательности" 0 и 1 есть еще значения и 2?

Первое условие:
Все документы вводятся в переферийной ИБ, при этом в свойствах миграции последовательности стоит флаек на "Единая последовательность в центральной ИБ". Соответсвенно в переферийной ИБ (где вводятся все документы) поле DS7536 всегда равно или 0 или 2, и соответсвенно метод ПринадлежитПоследовательности всегда возвращает 0 или 2. И что интересно, при автообмене в ЦБ также передается значение поля DS7536 равным 2

Теперь вспомним что происходит при проведении последовательности стандартным методом. 1С делает не проверку через метаданные принадлежности последовательности (что правильно, так как есть еще движения, влияющие на последовательность и только по движениям/проводкам можно сказать что документ входит в последовательность или нет), а проверяет поле DS7536, которе равно 2. Ну и конечно же 2 <> 1 и восстановленеи последовательности не приводит к проведению доков, входящих в последовательность.

Подытожим.

1. Если база распределенная и документы вводится не в ЦБ, при этом стоит флажок в окне свойств последовательности "Единая последовательность в центральной ИБ", то поле DS7536 всегда равно 0 или 2 (что в принципе правильно).
2. Во время автообмена происходит глюк, который приводит к тому, что поле DS7536 загружается с периферийной ИБ и становится равным 2. 3. 1С во время проведения перепроводит только те документы у которых поле DS7536 = 1.

Как побороть?

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

Нужно ли переходить на «1С:Предприятие 8.2»? Если вы читаете данную статью, значит, себе вы уже наверняка ответили на этот вопрос утвердительно. Поэтому сейчас мы не будем еще раз рассказывать о преимуществах перехода на новую платформу, а сосредоточимся непосредственно на деталях и особенностях данного процесса.

1. Общий алгоритм

Итак, вы решили переходить на «восьмерку» и хотите узнать, как это делается, и чем это вам «грозит». В самом общем виде схема перехода выглядит так (рис. 1).

Рис. 1. Алгоритм перехода с платформы «1С:Предприятие 7.7» на платформу «1С:Предприятие 8.2»

1. Апгрейд. Первое, что вам нужно сделать - написать заявление от вашей организации, сдать регистрационную анкету на платформу 7.7 и приобрести платформу 8.2. При этом Вам будет предоставлена скидка в размере стоимости старой платформы, но не более 50% . Старая платформа за Вами сохраняется, и вы можете пользоваться ей и дальше, однако она будет снята с технической поддержки в фирме 1С.

2. Обновление текущей конфигурации до последнего актуального релиза.

3. Подготовка базы данных к переносу. Подразумевает резервное копирование базы данных, закрытие текущего расчетного периода, очистку базы от элементов, помеченных на удаление, и исправление ошибок в учете (если таковые имеются).

4. Перенос данных. Это основной этап. Алгоритмы и трудоемкость в каждом конкретном случае разные.

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

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

Рассмотрим процесс перехода на новую платформу в контексте конфигурации «1С:Бухгалтерия» .

2. Меняем «1С:Бухгалтерию 7.7» на «1С:Бухгалтерию 8.2»

Стратегия и механизмы переноса данных из «1С:Бухгалтерия 7.7» в «1С:Бухгалтерию 8.2» определяются следующими факторами:

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

Своим клиентам мы советуем начинать работать в новой программе учета с 1-ого января нового года . Это связано с тем, что большинство налогов рассчитывается нарастающим итогом. Следовательно, чтобы не разрабатывать средства корректного переноса накопленных итогов, необходимо привязать начало работы в программе к началу отчетного периода по налогам. Разумеется, можно начинать работу и с начала квартала, и даже с начала следующего месяца, но такой переход повлечет за собой более значительные затраты (ввиду существенных различий в структуре документов в 7.7 и 8.2).

В зависимости от сочетания вышеуказанных факторов ситуации могут быть следующими.

Ситуация 1:

Переход с нового года, ТИПОВАЯ конфигурация, в старой программе сформированы правильные остатки на счетах

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

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

Ситуация 2:

Переход с нового года, ТИПОВАЯ конфигурация, в старой программе ОТСУТСТВУЮТ ПРАВИЛЬНЫЕ ОСТАТКИ НА СЧЕТАХ

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

Рис. 2. Переходный период при смене платформы

Чтобы преодолеть данный период с наименьшими потерями можно пользоваться следующими стратегиями:

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

Ситуация 3:

Переход с середины года, ТИПОВАЯ конфигурация

«1С:Бухгалтерия 8.2» поддерживает ряд важных для ведения учета механизмов, работоспособность которых зависит от данных, вносимых в документы в течение года. Среди таких механизмов уже упомянутый расчет налогов нарастающим итогом, алгоритм распределения косвенных расходов и прочие процедуры, относящиеся к закрытию месяца. Именно из-за этих особенностей в данной ситуации невозможно перейти на новую программу также легко, как в первых двух случаях. Для минимизации количества ошибок, которые могут возникнуть при переносе, мы рекомендуем:

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

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

2. Разработки фирм-франчайзи 1С. У многих компаний, в том числе и у компании « RG-Soft» () , существуют отработанные методики для решения данной задачи, что позволяет существенно сократить время и бюджет работ по переносу данных.

Ситуация 4:

Переход с ТИПОВОЙ конфигурации С ПЕРЕНОСОМ ДОКУМЕНТОВ ПРОШЛОГО ПЕРИОДА

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

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

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

Ситуация 5:

Переход с НЕТИПОВОЙ конфигурации на платформе «1С:Предприятие 7.7»

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

В зависимости от характера внесенных в программу изменений существуют следующие технологии переноса данных:

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

· если за годы использования конфигурация переработана коренным образом, то настройка типовых инструментов переноса может оказаться более трудоемкой, чем написание собственных обработок для этих целей. Аналогичная ситуация возникает и в случае организации перехода с программы учета, не связанной с платформами 1С. Осуществить такой переход тоже возможно, но заранее придумать универсальный обмен не получится. В каждом конкретном случае нужен индивидуальный подход к проблеме. Наша компания может предложить свои наработки по переносу данных через файлы различных форматов, таких как dbf, xls (Универсальный загрузчик из Excel в 1С), xml.

Еще один момент, о котором стоит упомянуть в связи переходом с платформы 7.7 на 8.2, касается объединения баз данных .

Из-за отсутствия механизма ведения учета нескольких фирм в одной базе многим предприятиям приходилось вести одновременно несколько баз в «1С:Предприятие 7.7». Так как в восьмой версии эта проблема решена, возникает задача объединения нескольких баз в одну в рамках проекта переноса данных. При этом каждая из баз семерки может обладать своими особенностями.

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

1. Унификация документов, относящихся к той или иной организации. Данная проблема легко решается с использованием механизма префиксов. Каждой организации, зарегистрированной в программе, присваивается свой буквенный префикс. Данный префикс прибавляется к номеру документа, тем самым обеспечивая уникальность номеров.

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

3. Возможные трудности, о которых Вам стоит знать

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

3.1. Ошибки в исходных данных

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

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

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

3.2. Различия конфигураций

Еще одна группа ошибок переноса обуславливается технологическими различиями конфигураций. Некоторые хозяйственные операции отражаются в «1С:Предприятие 7.7» несколькими видами документов, а в «1С:Предприятие 8» одним. Например, поступления и материалов и товаров отражается в новой программе одним документом, а в старой - двумя. Таким образом, при попытке переноса документов «Поступление материалов №22» и «Поступление товаров №22» возникает ошибка контроля уникальности. Поскольку запись двух документов с одним номером в заданном периоде невозможна, необходимо искусственно вносить в них отличия и система внесения этих отличий оговаривается заранее.

Например, данная проблема решается прибавлением дополнительного префикса к номеру загружаемого документа. Для каждой особенности документа этот префикс выделяется отдельно. Это может быть характеристика базы, из которой загружаются документы или вид документа, из которого произведена загрузка. Вот пример формирования такого префикса. База филиала в Красноярске дает префикс «КР». Вид документа «Поступление материалов», из которого производится загрузка, дает префикс «М». Так, если номер документа в семерке был 00000031, то восьмерочный номер будет следующим:

«КР» + «М» + «00000031» = «КРМ00000031»

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

3.3. Технические проблемы

Ошибки переноса данных могут возникать и из-за технических особенностей платформы «1С:Предприятие». Скажем, стандартный механизм поиска по наименованию не отличает большие буквы в наименовании элемента справочника от маленьких. При использовании этого механизма возникает путаница. Например, в базе есть два контрагента «л-аудио» и «Л-Аудио». При поиске контрагента «л-аудио» система найдет «Л-Аудио». В результате получится неправильно заполненный документ.

Необходимо также обратить внимание и на саму избираемую методику переноса данных. Описанный выше пример с задвоением контрагентов, при переносе из баз филиалов компании может и не оказаться задвоением на самом деле. У компаний, работающих в разных городах, вполне могут быть и контрагенты, также работающие в разных городах. Филиал компании «Л-Аудио» в Нижнем Новгороде и сама компания «Л-Аудио» в Москве в базах совершенно правомерно могут называться абсолютно одинаково. Чтобы избежать подобной путаницы, нужно выбирать методику переноса заранее. В нашем примере можно разделять контрагентов по разным группам справочника в зависимости от базы-источника. Выбор такой методики повлияет и на механизмы загрузки данных.

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

Заключение

В настоящее время компаний, работающих с использованием «1С:Предприятие 7.7» по-прежнему остается достаточно много. Это связано с такими факторами как непонимание преимуществ новой платформы, нежелание учиться новым технологиям, опасения встретить большое количество трудностей при переходе. На примере «1С:Бухгалтерии» мы постарались показать, что большинство этих причин не такие уж существенные. На всем протяжении своей деятельности мы помогаем своим клиентам справиться с любыми возможными трудностями, связанными с внедрением программ на платформе «1С:Предприятие 8». Если Вас заинтересовал вопрос перехода или у Вас есть какие-либо другие вопросы, касающиеся платформы «1С:Предприятие 8» и созданных на ней конфигураций – специалисты компании «RG-Soft» к Вашим услугам!