Cenários
Cenários nomeados: provisionam as respostas passivas, disparam o webhook order-notice com um
traceId e aferem o fan-out (chamadas esperadas × recebidas) correlacionado por esse trace.
Rodar é feito pela Api (POST /_sim/scenarios/{id}/run); o resultado é lido do arquivo.
Legenda:
OUT ▲ Simulation → HAASS (ação)
IN ▼ HAASS → Simulation (recebida)
·
OBRIGATÓRIA decide pass/fail
CATÁLOGO verificação (soft-delete)
NÃO ESPERADA fora do previsto
Grupo
Conector (por categoria — multi, AND)
Filtro (AND): Vtex & VarejoOnline & CrmBonus & MKPlace
Canal de venda
ERP
Bonus
Integrador
Meio de pagamento
Outros
Vtex = canal-fonte de todo cenário. Integrador = conecta o
HAASS ao meio final (CrmBonus → iFood; SystemHope → Shopify). Clientes sem integrador
integram direto com o provider. Ver
specs/Integration/023.
REALISTA (2921) — VTEX-EmFaturamento, um ERP só sem execução
realista-emfaturamento
· orderId: 00-{{run}}-01
· esperadas: 5
org: StatusFlow cluster3-realista
› StatusFlow BU cluster3-bu (2920)
› StatusFlow Store realista-1erp (2921)
ERPs: 1
· canais da loja: SITE, MKPlace
CrmBonus → iFood (integrador)
MKPlace
Updi
VarejoOnline
Vtex
Detalhes — descrição, previsto × recebido, timeline
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.
Previsto × recebido
sem execução — só o previsto
OUT ▲ OUTBOUND — ações (Simulation → HAASS)
| Chamada | Previsto | Veio | |
|---|---|---|---|
| · |
AÇÃO
POST
notice handling
/api/v1.0/vtex/order-notice |
1 | — |
IN ▼ IN — Obrigatórias (decidem pass/fail)
| Chamada | Previsto | Veio | |
|---|---|---|---|
| · |
OBRIGATÓRIA
Updi — o único ERP da loja
endpoint=updi-getvendas |
1+ | — |
| · |
OBRIGATÓRIA
CrmBonus estoque — 0×: sem CrmBonusIntegrator na loja
endpoint=crmbonus-stock-update |
0..0 | — |
| · |
OBRIGATÓRIA
VarejoOnline — 0×: a 2921 não roteia SepFinish
endpoint=varejo-change-status |
0..0 | — |
| · |
OBRIGATÓRIA
Vtex estoque — 0×: sem push de estoque nesta loja
endpoint=vtex-stock-update |
0..0 | — |
| · |
OBRIGATÓRIA
MKPlace — 0×: despacho/entrega não ocorrem em EmFaturamento
endpoint=mkplace-tracking |
0..0 | — |
CENARIO 1 (2922) — um ERP + canal Ifood: pedido E estoque sem execução
cenario1-pedido-e-estoque
· orderId: 00-{{run}}-01
· esperadas: 5
org: StatusFlow cluster3-realista
› StatusFlow BU cluster3-bu (2920)
› StatusFlow Store cenario1-1erp-ifood (2922)
ERPs: 1
· canais da loja: SITE, IFOOD
CrmBonus → iFood (integrador)
MKPlace
Updi
VarejoOnline
Vtex
Detalhes — descrição, previsto × recebido, timeline
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.
Previsto × recebido
sem execução — só o previsto
OUT ▲ OUTBOUND — ações (Simulation → HAASS)
| Chamada | Previsto | Veio | |
|---|---|---|---|
| · |
AÇÃO
POST
notice ready-for-handling
/api/v1.0/vtex/order-notice |
1 | — |
IN ▼ IN — Obrigatórias (decidem pass/fail)
| Chamada | Previsto | Veio | |
|---|---|---|---|
| · |
OBRIGATÓRIA
Updi — criar pedido no ERP
endpoint=updi-getvendas |
1+ | — |
| · |
OBRIGATÓRIA
Ifood — atualizar estoque (executa CrmBonusIntegrator)
endpoint=crmbonus-stock-update |
1+ | — |
| · |
OBRIGATÓRIA
Vtex estoque — 0×: loopback exclui a origem do pedido
endpoint=vtex-stock-update |
0..0 | — |
| · |
OBRIGATÓRIA
VarejoOnline — 0×: esta loja não roteia SepFinish
endpoint=varejo-change-status |
0..0 | — |
| · |
OBRIGATÓRIA
MKPlace — 0×: não é canal desta loja
endpoint=mkplace-tracking |
0..0 | — |
JSON