Ошиблись в проведённом заказе? Cancel, Amend и Update Items в ERPNext без разрушения учёта

Проведённый документ в ERPNext исправляют тремя способами: Update Items меняет количество и цену строк без отмены, Cancel отменяет документ, а Amend создаёт его новую редакцию с суффиксом -1. Ниже: что выбрать в каждом случае, в каком порядке отменять связанные документы и откуда берётся Insufficient Permissions.

Что вообще можно менять после Submit в ERPNext

Проведённый (Submitted) документ в ERPNext заблокирован от прямой правки: так устроена система статусов документа. Черновик (Draft) редактируется свободно, проведённый нет, а отменённый (Cancelled) остаётся в истории и больше не влияет ни на склад, ни на проводки. Отсюда три пути исправления, и выбирать нужно самый узкий, который решает задачу. Узкий путь означает меньше затронутых документов и меньше шансов нарушить связи.

Первый путь: Update Items. Это правка строк заказа (количество и цена) без отмены самого документа. Он есть у заказов, например у Purchase Order и Sales Order. Второй путь: Cancel и Amend, когда нужно менять шапку или документ в целом. Третий путь: не править вообще, а закрыть остаток или создать корректирующий документ (например, возврат поставщику). Продукт, внутри которого мы настраиваем эти процессы, описан на странице ERPNext под ключ.

Почему важно не отменять по привычке. Отмена проведённого документа переписывает историю учёта. В складском и бухгалтерском слое ERPNext отменённая проводка не стирается, а гасится: у записей в Stock Ledger Entry и GL Entry есть признак отмены, и они остаются в журнале. Поэтому «просто отменить, как ничего не было» нельзя: вторая запись всегда остаётся, и аудит её видит. Отсюда правило: сначала выбираем способ, потом нажимаем кнопку.

Ниже список ситуаций и подходящего инструмента. Он повторяет схему «дерево решений» из инфографики. | Ситуация | Инструмент | Что затрагивается | |---|---|---| | Неверное количество или цена строки заказа | Update Items | Только строки этого заказа | | В строке уже получен товар, и она лишняя | Не удалять строку, закрыть остаток | Статус заказа | | Неверный поставщик или другая ошибка в шапке | Cancel и Amend | Заказ и все зависимые документы | | Кнопка Update Items недоступна | Проверить права и Workflow | Настройки доступа |

Update Items: как поправить количество и цену, не отменяя заказ

Update Items открывает диалог со строками проведённого заказа. В нём можно изменить количество и цену существующих позиций и добавить новые. Код ERPNext (версия 15, функция update_child_qty_rate) накладывает ограничения, которые хорошо знать заранее, потому что именно о них спотыкаются пользователи. Нельзя уменьшить количество в закупке ниже уже полученного. Нельзя поставить цену так, чтобы сумма строки стала меньше уже выставленной в счетах. Нулевое количество запрещено, если в настройках закупок не разрешены нулевые количества в заказе.

Удаление строк ограничено ещё жёстче. Строку заказа поставщику нельзя удалить, если по ней уже есть поступление или счёт: система отвечает ошибкой вида «Cannot delete item which has already been received» (то же для выставленных счетов). Значит, если по позиции уже пришёл товар, «лишнюю» строку убирать не надо: правильно закрыть остаток заказа или оформить возврат. Для недопоставленного остатка у проведённого заказа есть действия в меню Status (закрыть заказ, а в свежих версиях и отдельные позиции); точное название действия смотрите в своей версии.

Для заказа с субподрядом (Subcontracting Order) правка ограничена: если по закупке уже создан заказ на субподряд, обновить позиции нельзя, а если сырьё уже обработано, количество менять нельзя. Для обычных закупок материалов это не нужно, но в кейсах с давальческим сырьём пригодится.

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

• Количество нельзя сделать меньше полученного
• Цену нельзя сделать такой, чтобы сумма была меньше выставленной в счетах
• Строку с поступлением или счётом удалить нельзя
• Нулевое количество разрешено только по настройке в закупках

Cancel и Amend: в каком порядке отменять связанные документы

Когда правка затрагивает шапку или документ целиком, приходится отменять. Если у заказа поставщику есть поступление и счёт, отменить заказ нельзя, пока они проведены: Frappe проверяет связи и выдаёт ошибку «Cannot delete or cancel because ... is linked with ...». Порядок обратный созданию: сначала отменяем зависимые документы (счёт поставщика, потом поступление), затем сам заказ. Только после этого можно сделать Amend.

В интерфейсе есть и ускоренный вариант. В диалоге отмены предлагается вариант «Cancel All Documents»: система собирает связанные проведённые документы и отменяет их по очереди (за это отвечает метод cancel_all_linked_docs). Я пользуюсь этим осторожно: пока вы не увидели список, вы не знаете, что исчезнет, а в списке бывают проводки, о которых вы забыли. Сначала посмотрите связи в панели Connections, а потом решайте.

Amend это кнопка на отменённом документе: она создаёт новый черновик с теми же данными и ссылкой на отменённый (поле amended_from). Код проверяет, что источником может быть только документ в статусе Cancelled. Новая редакция получает то же имя с суффиксом: по умолчанию действует правило «Amend Counter», то есть PO-0001 превращается в PO-0001-1, при следующей правке в PO-0001-2. В Document Naming Settings можно выбрать вместо этого Default Naming, и тогда новая редакция получит обычный новый номер; правило можно задать отдельно для типа документа.

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

Порядок отмены и пересоздания показан на схеме после раздела: счёт отменяем первым, затем поступление, затем заказ, затем Amend и повторное проведение.

Почему Update Items даёт Insufficient Permissions при включённом Workflow

Симптом: пользователь нажимает Update Items и получает окно Insufficient Permissions. Причины в коде v15 две. Первая: у роли нет права на запись (write) по документу, и сообщение вида «You do not have permissions to update items in a Purchase Order». Вторая: к документу подключён Workflow, и текущее состояние не разрешает редактирование этой ролью; сообщение «You are not allowed to update as per the conditions set in ... Workflow». Проверка смотрит на состояние документа в Workflow и поле Allow Edit For в этом состоянии: если там указана роль, которой у пользователя нет, правка запрещена.

На форумах часто советуют другое: добавить правило перехода с действием Update, привязанное к финальному статусу. Проверка по коду показывает, что главное здесь не переход, а роль, разрешённая на редактирование в конечном состоянии. Возможно, оба варианта работают в зависимости от версии и схемы, поэтому при настройке проверьте на тестовом заказе: откройте состояние «Согласовано» в Workflow, посмотрите Allow Edit For и добавьте роль, которой разрешено править проведённый заказ (например, снабженца).

Отдельный случай: отмена через Workflow. Если у роли есть право Cancel в менеджере прав, этого недостаточно, когда документ управляется Workflow. В Workflow нужно описать состояние с docstatus 2 (Cancelled) и переход в него для нужной роли, иначе кнопка отмены не появится. Это знают не все, поэтому «кнопка пропала» часто воспринимают как сбой, хотя это настройка маршрута; о построении маршрутов у нас отдельный материал про маршруты согласования договоров.

Чтобы не получать такие обращения, я при настройке Workflow сразу прописываю, какая роль и в каком состоянии может править проведённый заказ, и добавляю это в инструкцию. Экономия на такой настройке выливается в звонки по пятницам.

«Рама и Стекло»: заказ на фурнитуру с уже оформленной приёмкой

Условный пример, цифры вымышленные. Подрядчик по монтажу окон «Рама и Стекло», 11 рабочих мест: директор, два прораба, снабженец, кладовщик, бухгалтер и монтажные бригады. Снабженец оформил заказ поставщику на фурнитуру: 11 позиций (петли, ручки, уплотнитель, подоконные кронштейны), заказ проведён и согласован. Через два дня склад принял товар по заказу, поступление проведено. На следующий день выяснилось две ошибки: по двум позициям цена в заказе указана с прошлого прайса, а в шапке выбран соседний поставщик с похожим названием.

Разберём по инструменту. Будь ошибка только в цене двух строк, хватило бы Update Items: товар получен, но в счёте цена ещё не выставлена, и код позволит поправить rate, не трогая количество. Но ошибка с поставщиком сидит в шапке, Update Items её не меняет, значит путь Cancel и Amend, а цену поправим заодно в новой редакции. Порядок: счёт ещё не проведён, поэтому сначала отменяем поступление (склад вернёт остатки погашающей проводкой), затем отменяем заказ, делаем Amend (PO-…-1), исправляем поставщика и цену, проводим заново, после чего оформляем поступление ещё раз.

Что мы проверили после правки. Новая редакция заказа проведена, поступление оформлено по ней. В заявке на материалы с объекта заказанное количество вернулось. Остаток на складе объекта соответствует фактически принятому, дубль проводки в Stock Ledger не появился, хотя старые записи остались с признаком отмены. Согласователь получил уведомление о новой редакции, потому что заказ снова прошёл маршрут согласования. Весь цикл занял около часа, из которых большая часть ушла на повторную приёмку на складе.

Вывод для регламента. Если бы ошибки были только в цене, хватило бы Update Items за пять минут. Если бы счёт уже был проведён, пришлось бы отменять ещё и его, а оплата, оформленная по счёту, потребовала бы отдельных действий бухгалтера. Поэтому мы закрепили в инструкции правило: ошибку в проведённом заказе обсуждаем со снабженцем и бухгалтером до нажатия Cancel. Как это выглядит в системе, можно показать на демостенде erp-demo.itfresh.ru по запросу.

Что проверить после правки: связи, склад и бухгалтерский слой

После любой правки я иду по короткому списку. Статус документа: Submitted (после Amend и проведения) или нужное состояние Workflow. Связи: исходная заявка на материалы показывает заказ, поступление ссылается на новую редакцию. Склад: остаток на складе объекта верен, а в Stock Ledger нет лишней действующей проводки (старые записи с признаком отмены остаются, это нормально). Бухгалтерский слой: сумма в счёте поставщика совпадает с заказом, проводки в General Ledger соответствуют новой редакции.

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

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

Где исправления в ERPNext не помогут

Ограничение первое: закрытый период. Если в учёте закрыт период, отмена документов в нём может быть запрещена, и исправляются они уже не отменой, а корректирующими документами текущего периода; как именно организован закрытый период в вашей установке, нужно проверить отдельно. Второе: слой регламентированного учёта в России остаётся в 1С, и исправление в ERPNext не исправляет проводку в 1С автоматически; нужен отдельный обмен или ручная правка.

Третье: версии. Названия кнопок, ограничения Update Items и правила именования Amend проверены по коду v15; в v16 они могут отличаться, и перед внедрением регламента откройте проведённый заказ на стенде вашей версии. Четвёртое: масштаб. Каскадная отмена на большом числе документов (десятки счетов и поступлений) нагружает систему и ломает аудит; для массовых правок нужен отдельный план, а не кнопка. Если вам нужна не такая тяжёлая система учёта для микробизнеса, посмотрите разбор про Dolibarr для микробизнеса и ИП.

Частые вопросы