Авансы поставщикам в Syrve — исследовательский backlog

Бизнес-сценарий

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

Инвариант целевого расчёта:

BankTransaction.Amount = DocumentSettlementAmount + SupplierAdvanceAmount.

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

Что подтверждено

• В Syrve существует штатный счёт авансов поставщикам.
• В Syrve существует тип операции Advances to supplier.
• Авансы учитываются отдельно от задолженности поставщикам.
• В будущем остаток банковской операции должен направляться на штатный авансовый счёт Syrve.

Что не подтверждено

Для безопасной реализации пока отсутствует подтверждённая write-трасса:

• метода записи и его endpoint/RPC;
• XML request/response contract;
• знака суммы и корреспонденции счетов;
• привязки применения аванса к конкретной накладной;
• частичного применения одного аванса;
• применения нескольких авансов/документов;
• readback созданного и применённого аванса;
• external id, идемпотентности и неизвестного результата записи;
• отмены, сторно и повторного применения;
• различий RMS и CHAIN.

Необходимая исследовательская трасса

На отдельном тестовом контуре необходимо:

1. Создать тестовый аванс поставщику и снять полный request/response.
2. Применить часть аванса к проведённой накладной и снять request/response и readback.
3. Отменить или сторнировать применение и сам аванс, зафиксировав все операции и итоговые остатки.
4. Проверить поведение в RMS и CHAIN, идемпотентность и повторный readback.

Готовое задание для отдельного исследования и реализации в репозитории connector: IikoConnector supplier settlement prompt.

Границы текущей реализации

В myhoreca-pay существует только чистая foundation-модель SupplierSettlementPlan: положительный остаток после FIFO становится строкой-требованием SupplierAdvance со статусом TransportUnavailable, без ExternalAdvanceId. Такая строка делает план неисполняемым и не считается внешней записью, readback или бухгалтерским авансом.

SupplierSettlementPostingOperationPlanner показывает будущие отдельные document-settlement и advance operations с независимыми idempotency key/request hash/evidence полями. Это не production-очередь: advance operation всегда non-runnable, а действующий document workflow остаётся PaymentAllocation 1:1 SyrvePaymentPosting.

Runtime-реализация авансов, EF-таблицы, очередь, transport, применение и reversal отсутствуют. Нельзя использовать RemainingAmount или foundation plan как бухгалтерский источник истины и нельзя создавать параллельный advance ledger без подтверждённого контракта Syrve. Банковская операция с требованием аванса не считается полностью проведённой.

Термины Overpayment/Underpayment в текущем workflow исторически неоднозначны и остаются отдельным техническим долгом. До подтверждения write-трассы они не должны приводить к созданию аванса или менять действующую финансовую модель.