Store ALL-ON 2401. ready-for-handling → ProntoSeparar. MEDIDO: updi-getvendas 1× (a CRIAÇÃO do pedido, não o PaymentApproved) e crmbonus-stock-update 1× (a reserva). O destino da rota de estoque é `Ifood`; quem executa é o CrmBonusIntegrator, e por isso o endpoint observado é do CrmBonus. varejo-create-order 0×: separação não ocorre em ProntoSeparar. vtex-stock-update 0×: loopback exclui a origem.

Store ALL-ON 2401. handling → EmFaturamento: passa por ProntoSeparar (reserva estoque no CrmBonus, 1×) e dispara InvoicingStarted (Updi). updi-getvendas 2× = criação + faturamento. varejo-change-status 0×: SeparationFinished vive ADIANTE de EmFaturamento e o webhook não o alcança. crmbonus-order-status 0× (origem-VTEX sem ECCrmBonusSequence).

Store REALISTA 2921 (um ERP, dois canais). handling → passa por ProntoSeparar e dispara InvoicingStarted. Só `Updi` recebe: a loja não tem CrmBonusIntegrator, então a reserva de estoque que a 2401 faz aqui NÃO acontece (crmbonus-stock-update 0×), e não há rota de SepFinish (varejo 0×). O contraste com all-on-emfaturamento é o ponto: mesma transição, uma linha na aba de outbound em vez de duas.

Store REALISTA 2921 com status `invoiced`, que nenhum cenário cobria. invoiced + deliveryChannel=delivery → ProntoDespachar (com pickup-in-point seria ProntoRetirar — VtexMarketplaceStatusToHaassOrderStatusMapper). O ERP recebe; `vtex-invoice` NÃO acontece, porque IntegrateInvoice é comando do operador e não do webhook.

Store REALISTA 2921. canceled → IntegrateOrderCancelled com UM destino (Updi). O contraste com all-on-cancelado é direto: lá a mesma tag roteia Ifood E Updi, e o cancelamento sai por dois caminhos.

Store 2922: config no nível de LOJA, um ERP (Updi), canais SITE + IFOOD. Venda via VTEX em ready-for-handling. É o par MÍNIMO que produz as DUAS pernas: updi-getvendas (criar pedido no ERP, via IntegrateOrderCreated) e crmbonus-stock-update (atualizar estoque; o destino da rota é `Ifood`, e o CrmBonusIntegrator é quem executa). Contraste com a 2921, que tem MKPlace em vez de IFOOD e por isso produz só a perna do ERP.

Store ALL-ON 2401 com status `invoiced` — o quinto e último status de entrada que a tela oferece, e o único que nenhum cenário cobria. MEDIDO: produz updi-getvendas E crmbonus-stock-update (a reserva da criação), e NÃO vtex-invoice — IntegrateInvoice é comando do operador.

Pedido que NASCE no CrmBonus, não na VTEX: POST /api/v2.0/CrmBonusOrder/Save. Escolhe a org pelo `sellerId` (= Store.SystemCode), então roda na loja realista 2921 — o ECId gerado carrega os dois: IFOOD-2921-<data>-CRMB-<run>-01. SalesChannelId é IFOOD, chumbado no controller. PROVA A ENTRADA pelo canal, não o fan-out: a descida ao Updi acontece (medido no log), mas a captura entra por fila e o traceId do cenário não atravessa esse salto, então a correlação não a alcança — afirmá-la seria falhar por instrumentação. Gap registrado.

Pedido que NASCE no MKPlace: POST /api/v2.0/MKPlaceWebhook/Order. A rota só exige `_id` e resolve a org de configuração GLOBAL (MKPlaceWebhookBusinessUnitId/StoreId/SellerSystemCode), apontada para a 2921 pelo seed — não há como escolher a loja por cenário. Prova a ENTRADA pelo canal; o que o pedido produz depois depende do inbox, e por isso as expectativas aqui são de ausência do que NÃO deve acontecer.

Store ALL-ON 2401. payment-pending → PagamentoPendente: IntegrateOrderCreated (Updi, updi-getvendas) + ReserveStock (CrmBonus; Vtex dropada por loopback). SEM separação (varejo-create-order 0×). Prova o gating por status do Map.

Store ALL-ON 2401. canceled → Cancelado: IntegrateOrderCancelled (Updi, updi-getvendas) + DropReserveStock. O DROP não exclui a origem (loopback assimétrico) → o estoque vai a CrmBonus E Vtex (vtex-stock-update REAPARECE, diferente do forward). crmbonus-order-status = 0× (origem-VTEX sem ECCrmBonusSequence).

Store ALL-OFF 2402 (nenhuma linha FlowSettingValue → tudo cai no DefaultValue='false'). EmFaturamento não produz fan-out: varejo-change-status 0× (ausência). Prova que sem config nada sai.

Store 2801 tem SepFinish @ Store/2801=true → resolve no próprio nível Store (o mais específico). varejo-change-status.

Store 2802 NÃO tem linha de SepFinish. Sobe a hierarquia: Store(nada)→BU/2700(true) → resolve via BusinessUnit. Prova que a loja não configurada usa a config da BU (e que BU vence FG/Company — mais específico).

Store 2803 (BU 2701, sem linha de SepFinish na Store nem na BU 2701). Sobe: Store(nada)→BU 2701(nada)→FG/2600(true) → resolve via FranchiseeGroup. Prova o fallback até o FG quando Store e BU não têm config.

Store 2804 (FG 2601, BU 2702, ambos sem linha). Sobe até o topo: Store→BU 2702(nada)→FG 2601(nada)→Company/2500(true) → resolve via Company. Prova o fallback até a Company.

Store 2805 tem SepFinish @ Store/2805=FALSE, mesmo com BU/2700 e Company/2500 = true. O mais específico ganha (Store) → resolve OFF: varejo-change-status 0×. Prova a precedência do override no nível Store + que não vaza para as irmãs (2802 resolve BU normalmente).

Store 2806 tem SepFinish @ Store/2806 + SalesChannelId=1 (SITE). O pedido VTEX resolve SITE(1) e casa a linha de canal → varejo-change-status. Prova a dimensão de canal na resolução.

Pedido de R$200 com split 90/10 e nada estornado. Devolução total: o DELETE tem de sair com amount 20000 e split 18000 (loja) + 2000 (comissão). É o caminho feliz — se a comissão não entrar aqui, o defeito dos 90% voltou.

Pedido de R$200 (2 × R$100), nada estornado. Devolve R$100: DELETE com amount 10000 e split 9000 + 1000 — a comissão é devolvida proporcionalmente, não só no total.

O DEFEITO do estorno que não acontecia. Os payables já refletem o primeiro estorno de R$100, então a primeira aprovação é no-op legítimo (nada a estornar). A segunda devolução de R$100 tem de sair: DELETE com amount 10000 (9000 + 1000). Antes do fix o alvo era o valor de UM Refund, o cálculo achava que os R$100 já cobriam tudo e o segundo estorno era descartado como 'já estornado no gateway' — devolução registrada no HAASS e valor capturado na Pagar.me.

O DEFEITO dos 90%. O split da charge tem loja + comissão, mas os payables trazem só a loja — nem a heurística nem a inferência classificam o recipient de comissão. Antes do fix saía DELETE com os 90% da loja e os 10% ficavam capturados, em silêncio. Agora o builder falha: ZERO DELETE, e o pedido vai para EstornoFalhou pelo fault consumer (a transição não é observável aqui — o assert é a ausência do estorno com as leituras presentes).

Payables mostram o pedido inteiro já estornado (capacidade zero nos dois recipients). O cálculo devolve distribuição vazia e o handler faz early-return: ZERO DELETE. É a idempotência por capacidade — protege o reprocesso do consumer (retry 5×) de estornar duas vezes. Aqui o 0× é o resultado CORRETO, e é o que distingue este cenário do 'sem comissão': lá o dinheiro estava lá e não sabíamos de quem cobrar.

Operador marca AlreadyRefundedInAcquirer (já estornou no painel da adquirente). O fluxo tem de pular o gateway INTEIRO — nem DELETE nem as leituras de order/payables — e gravar RefundSource = Manual. Exige que o operador do harness tenha perfil AdminMaster; sem isso o ConfirmRefundRequest devolve 401 e o passo fica vermelho.

Cria na loja 1000 um pedido VIVO (ready-for-handling → ProntoSeparar) e ELEGIVEL para troca: pagamento em cartao, entrega delivery, itens de uma loja so. Nao abre janela nenhuma — a janela nasce depois, quando VOCE cancelar o pedido em /v2/orders escolhendo um motivo do grupo LOJA (SPEC 057). Motivo do grupo CLIENTE cancela e NAO abre janela. Depois de cancelar, o pedido entra em AguardandoNovoSeller e aparece em /v2/change-seller para as lojas 1001 e 1002. O pagamento e o detalhe que mais derruba este roteiro: o default do simulador e Pix, que a SellerChangeEligibilityPolicy nega — por isso aqui e creditCard, e por isso nao adianta ajustar depois (o pagamento e gravado na criacao e o reimport nao o reescreve).

O outro gatilho da janela, e o original (SPECs 044-048): quem avisa que a loja perdeu o pedido e o CANAL, nao o operador. O pedido do seller chega cancelado e o sinal mora no pedido PAI — `marketplaceStatus = window-to-change-seller`. Sai pronto para capturar: va direto a /v2/change-seller logado pela loja 1001 ou 1002. Qualquer outro valor de marketplaceStatus FECHA a candidatura (SPEC 048) — e o mesmo sinal nos dois sentidos. O assert de `vtex-cancel-order` em 0x e o que distingue janela ABERTA de recusada: quando a elegibilidade reprova, o use case cancela o pedido pai no canal e essa chamada aparece. Zero chamada com o TTL ausente tambem seria 0x, mas ai o pedido nao aparece na lista — se a lista vier vazia, e o TTL (OrderInChangeSellerHoursToLive na BU 1000).

A troca INTEIRA sem tela: cria o pedido na loja 1000 pela descida da SystemHope (cartao, delivery, um SKU), cancela como LOJA (o que abre a janela — motivo do grupo CLIENTE nao abriria), e captura pela irma 1001. O que o cenario afirma e o que so existe em execucao: `systemhope-move-location` (o FulfillmentOrder foi movido para a Location da loja que assumiu) e `systemhope-get-order` (a segunda perna buscou o pedido reatribuido, de onde o pedido da 1001 nasce pelo import). O cancelamento tambem afirma AUSENCIA de `systemhope-cancel`: pedido oferecido as irmas segue vivo na Shopify, e cancelar la seria irreversivel. Se o passo 2 disser que o pedido nao foi resolvido, o import nao concluiu — confira Sync.ImportItem (SupplierId 8, EntityTypeId 4), nao o cenario.

O mesmo pedido, pago em Pix. A `SellerChangeEligibilityPolicy` nega Pix, boleto, Pagar na Loja e Pagaleve — o que os quatro tem em comum e nao permitir reatribuir a cobranca a outra loja. O cancelamento ACONTECE (HTTP 200); o que nao acontece e a oferta, e o desfecho vem no CORPO (`sellerChangeWindow: RefusedByPolicy`), nao no status. E por isso que o passo declara `expectWindow`: sem ele este cenario ficaria verde tambem quando a janela abrisse, que e exatamente o defeito que ele existe para pegar. Sem janela nao ha captura, entao o passo 3 nao existe e a prova e a ausencia de `systemhope-move-location`.

A captura responde OK ao operador e a reatribuicao falha DEPOIS, no parceiro: o `systemhope-move-location` deste pedido devolve 422. E o desenho que torna a recusa compensavel — no instante da chamada existe um pedido so, entao devolver o pedido para AguardandoNovoSeller e reabrir a candidatura nao esbarra em referencia externa duplicada. Duas afirmacoes: o move-location acontece UMA vez (4xx e terminal na esteira de saida — `OutboundDispatcher` classifica 400-499 como Terminal —, entao 2 aqui significa retry indevido) e o `systemhope-get-order` NAO acontece (buscar o pedido reatribuido depois de uma recusa criaria o pedido da loja nova para uma troca que nao houve). O reparo — janela reaberta pelo ator, pedido de volta a vitrine — nao passa pelo parceiro e por isso nao aparece no call-log: confira em ChangeSellerOrder (ReassignFailedAt preenchido) ou na tela.