#std603

Требования к проведению документов

1.

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

Примеры:

  • в финансово-хозяйственном учете - хозяйственные операции;
  • в производственных системах - производственные операции.
2.1.

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

Непроведенный документ - это черновик:

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

Проведенный документ - это чистовик:

  • документ сформирован и обработан;
  • принято решение, что он участвует в учете.
2.2.

Если у документа есть этапы жизненного цикла, для них можно использовать статусы.

Примеры:

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

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

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

  • требовать дозаполнение отдельных полей;
  • применять проверки и ограничения для конкретного этапа.

До проведения перевод черновика по статусам системой не контролируется.

Примеры поведения:

  • для проведенного документа Заказ клиента:
  • при переводе в статус Не согласован контролируются только основные параметры заказа;
  • при переводе в статус К обеспечению обязательно поле Дата отгрузки (логисту нужна дата поставки);
  • для проведенного документа Расходный кассовый ордер перевод в финальный статус Зарегистрирован в Кассовой книге и подписан главным бухгалтером (руководителем) означает создание бухгалтерских записей и регистрацию отчета кассира в журнале-ордере (или другом регистре, например в бюджетных организациях - в журнале операций).
2.3.

Исключения из правила «большинство документов должны проводиться»:

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

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

2.4.

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

Нельзя решать эту задачу отключением проведения у документа.

3.

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

Движения по регистрам формируйте при проведении:

  • автоматически;
  • вручную.

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

  • пользователь вводит данные события в документ;
  • при проведении система генерирует движения по регистрам;
  • пример: формирование бухгалтерских проводок.

Ручной вариант:

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

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

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

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

Пример:

  • Платежное поручение формируется в финансовом отделе;
  • бухгалтер при проведении не должен менять первичный документ;
  • поэтому Платежное поручение движений не делает;
  • движения формирует отдельный документ Списание с расчетного счета.
5.

Непроведенные и помеченные на удаление документы не должны иметь #std633: активных движений.

6.

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

7.1.1.

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

Исключение: движения по регистру полностью или частично формируются внешними по отношению к документу алгоритмами (см. п. 4).

7.1.2.

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

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

Исключение: обоснованные случаи, где анализ последовательности - часть сути алгоритма (например, партионный учет).

7.2.

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

7.2.1.

Если пользователь может изменять внешние по отношению к документу данные (например, реквизиты НСИ), которые влияют на движения, значения этих реквизитов нужно сохранять в документе.

Если это не делается, изменение таких данных нужно блокировать. В конфигурациях на базе БСП для этого рекомендуется механизм Запрет редактирования реквизитов.

Исключения - см. п. 7.1.2.

7.2.2.

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

Практические приемы:

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

Если исключить зависимость движений от настроек не удалось, нужно реализовать один из вариантов:

  • автоматическую фоновую обработку после изменения настройки;
  • ручной запуск обработки пользователем;
  • если обработка невозможна - предупреждать, что менять настройку после начала учета не рекомендуется.

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

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

7.3.

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

8.

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

См. также
Источник

https://its.1c.ru/db/v8std#content:603