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

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

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

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

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

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

• Принудительная обработка зависших квитанций (получающих ошибки push ERP).
  
• Создайте новую квитанцию, которая сторнирует "зависшую" квитанцию: если первая квитанция имеет количество 1, то обратная квитанция должна иметь количество -1; и наоборот.
• Убедитесь, что новая квитанция также получает ошибку push ERP (предложение: в этом может помочь пометка Delivery Complete или закрытие заказа для получения в 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 невозможно. Если пользователь случайно обработал квитанцию, необходимо следовать одному из первых двух вариантов.
• Для сайтов, настроенных с интеграцией файлового канала, квитанция будет помещена в очередь на экспорт сразу после утверждения. Таким образом, принудительный процесс не остановит его экспорт в первый раз. Однако при этом поступление не будет поставлено в очередь в следующий раз, и этот сценарий происходит только при получении ошибки передачи ERP.
• Ariba не поддерживает отмену квитанций. Получать и впоследствии сторнировать можно только с отрицательным получением, но не отменять/удалять/устаревать утвержденную квитанцию.

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

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

SAP Ariba Buying and Invoicing