Примеры задач и кейсы по 1С

1. Отрицательные остатки: проверять нужно фактический итог

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

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

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

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

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

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

2. Дубли документов: сначала единый ключ, потом действие

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

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

Для входящей строки заранее задайте правило:

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

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

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

3. Массовая отправка: пакетная команда должна оставаться управляемой

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

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

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

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

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

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

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

Как выбрать место для контроля

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

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

Общий чек-лист перед запуском

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

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