Квитанции создаются в Ariba, однако они не могут быть отправлены в ERP (внешнюю систему) из-за ошибок push ERP. Некоторые из них являются отрицательными (обратные поступления), и они также не выполняются.

Общие сведения о потоке операций для квитанций:

• После утверждения квитанции Ariba попытается отправить ее в ERP (на основе настройки интеграции). В случае сбоя система по умолчанию будет пытаться отправить в общей сложности 25 раз на основе параметра Application.Receiving.MaxRetriesToSendPushFailedReceipts. Для получения дополнительной информации см. статью базы знаний.
• Повторные попытки составляют около 6 часов друг от друга и позволят окно продолжительностью около 6 дней для выявления и устранения ошибки на стороне ERP. Если вы хотите, чтобы квитанции повторно отправлялись чаще, можно активировать параметр Application.Receiving.EnableProcessPendingReceiptsFrequently, чтобы квитанции повторно отправлялись каждые 3 часа.
• В случаях, когда исправление ошибки занимает больше 25 повторных попыток (или любого значения, настроенного в параметре Application.Receiving.MaxRetriesToSendPushFailedReceipts), то случай может быть записан в журнал для запроса увеличения максимального числа повторных попыток отправки квитанций. Обратите внимание, что это изменение параметра повлияет на все квитанции в статусе "Ожидает обработки" и квитанции в статусе "Обработка", только если для параметра Application.Receiving.EnableProcessPendingReceipts установлено значение "true".

В ситуациях, когда ошибку невозможно исправить, можно использовать следующие подходы:

Опция 1:
Принудительная обработка квитанции в Ariba с помощью кнопки Инициировать обработку в заголовке квитанции. Затем создайте поступление вручную в ERP. Такой подход рекомендуется, поскольку он более простой и простой.

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

• Принудительная обработка зависших квитанций (получающего ошибки push ERP).
  
• Создайте новую квитанцию, которая сторнирует зависшую квитанцию: если первая квитанция имеет количество 1, обратная квитанция должна иметь количество -1 и наоборот.
• Убедитесь, что новое поступление также получает ошибку push ERP (предложение: пометка полной поставки или закрытие заказа для получения в ERP, а не Ariba, может помочь).
• После этого новая квитанция сторно также должна иметь статус Обработано принудительно.
• В результате заказ в Ariba будет оставлен с двумя квитанциями, отменяющими друг друга.
• Теперь необходимо убедиться, что все созданные новые квитанции будут успешно поступать в ERP, а затем создать новую квитанцию.

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

Опция 3:
Третьим способом является редактирование квитанции с ошибкой push ERP, установка для параметра "Принятая сумма/число принятых" значения 0 и повторная отправка. Однако следует использовать зависимую кнопку Закрыть заказ в квитанции, так как система не разрешает отправку квитанции с нулевым количеством/суммой, если вы не закрываете заказ. Обратите внимание, что заказ на закупку по-прежнему можно открыть повторно.

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

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

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

• Если сайт настроен для интеграции квитанций с Ariba Network (AN), обратите внимание, что квитанции с принудительной обработкой все равно будут отправляться в AN. В этом случае Ariba и AN будут синхронизированы, но система ERP будет рассинхронизирована. 
• Инициирование повторной отправки обработанных квитанций в ERP невозможно, если пользователь случайно инициировал обработку квитанции, тогда необходимо использовать один из первых двух вариантов.
• Для сайтов, настроенных с интеграцией файлового канала, квитанция будет поставлена в очередь на экспорт сразу после утверждения. Таким образом, принудительный процесс не остановит его от экспорта в первый раз. Однако она остановит поступление от постановки в очередь в следующий раз, и этот сценарий произойдет только при получении ошибки push ERP.
• Ariba не поддерживает отмену квитанций. Получение и сторнирование возможно только при отрицательном получении, но нельзя отменить/удалить/отметить как устаревшую утвержденную квитанцию.

Для получения дополнительной информации о конкретных документах о получении см. ниже:

• Экспорт данных квитанции
• Настройка получения и управление ими
• Рабочий процесс экспорта квитанций с ошибками
• Экспорт квитанций в SAP ERP
• Ошибки экспорта квитанций

SAP Ariba Buying and Invoicing