Pular para conteúdo

BUGS_FIX_LOG — Pedido de Compra Omie

Atualizado: 2026-07-13 · por: sessão automática · fix Distribuir MO Opção C (match só por descrição) · rev: 4

Cronologia dos bugs corrigidos nos workflows MO/MP e suas causas-raiz. Ordem cronológica decrescente.

2026-07-13 — Distribuir MO: Opção C — match só por descrição (código BPEX ≠ código Omie)

Sintoma: PC 1982 (exec 638948, empresa ONIX, fornecedor DJ Aços) falhou com _codigo_produto_resolvido = null mesmo após o fix de 2026-07-08. O produto era BPX48056191-MO ("MO 25 X 50 E=1,95 C=1,80 GALVANIZADA 3000 X 1200").

Causa-raiz: O Omie ONIX tem esse produto cadastrado sob o código BPX44274494-MO (codigo_produto 11392976417) — DIFERENTE do código que o BPEX enviou (BPX48056191-MO). O Omie retornou total_de_registros: 1 com a descrição idêntica, mas o list.find(x => x.codigo === bCod) da Opção B falhou porque os códigos divergem. Provavelmente o sistema de orçamento gerou um novo id para esse item sem verificar se a descrição já existia no Omie (bug de padronização reportado ao Marcelo/Jackson via WhatsApp em 2026-07-13 para investigação).

Fix aplicado — Opção C (descrição-only match):

O nó Distribuir codigo_produto MO passou de Opção B (código+descrição) para Opção C (só descrição):

// ANTES (Opção B): encontra por código, verifica descrição
const p = list.find(x => String(x.codigo).trim() === String(bCod).trim()) || null;
if (p && norm(p.descricao) === norm(bDesc)) { lookup[bDesc] = p.codigo_produto; }

// DEPOIS (Opção C): encontra direto por descrição normalizada
const p = list.find(x => norm(x.descricao) === norm(bDesc)) || null;
if (p) { lookup[bDesc] = p.codigo_produto; }

Seguro porque: a busca ListarProdutosResumido já filtra por filtrar_apenas_descricao (a descrição do BPEX), então o resultado sempre tem total_de_registros ≤ 1 para descrições únicas. Se vier 0 resultados → list.length === 0 → skip → _codigo_produto_resolvido = null → Code2 reporta "produto não cadastrado". Se vier 1 → match pela descrição → usa o codigo_produto Omie correto.

Deploy: via Pinia store (updateNodeById) + Ctrl+S + deactivate/activate com versionId a371204c-753f-45f8-bcbd-2c82d8389d00. Workflow ativo em 2026-07-13 ~12:42 BRT.

Nota: a mensagem de erro para Marcelo/Jackson informando sobre a possível falha de padronização de códigos no sistema de orçamento foi enviada via WhatsApp Bepex (conv 156) em 2026-07-13.

2026-07-08 — Distribuir lookup por descrição Omie vs BEPEX (MO) + humanizador Code2 com 3 categorias de erro

Sintoma: Pedido de compra MO 1982 (exec 636655, empresa ONIX, fornecedor DJ Aços) falhava com "Deu errado: Um ou mais dos produtos não está cadastrado no Omie". O produto BPX63706388-MO existia no Omie (codigo_produto 11482415509) e era encontrado corretamente pelo Acha código do produto (total_de_registros=1).

Causa-raiz: O nó Distribuir codigo_produto MO (id 7a315ba0-df52-4eb6-9d63-1c84c883ce00) construía o lookup usando a descrição do Omie como chave, mas fazia a busca usando a descrição do BEPEX. Quando as descrições diferiam mesmo só em espaçamento (Omie: "MO F. OBL. ALT. 4X25MM EC=8X32MME=3,18MMINOX 3000 X 1250" vs BEPEX: "MO F. OBL. ALT. 4X25MM EC=8X32MM E=3,18MM INOX 3000 X 1250"), o lookup retornava undefined → _codigo_produto_resolvido = null → o Omie rejeitava com Informe a tag [cProduto] → o humanizador reportava "produto não cadastrado" (falso positivo).

É o mesmo bug corrigido no MP em 2026-05-14 (entrada abaixo), que nunca foi portado para o MO. No MP o fix foi no Set Achado (que exportava a descrição errada); no MO não há Set Achado — o lookup é direto no Distribuir, então o fix vai lá.

Fix aplicado (em produção WwDzIseoYVxbzJZK, versionId 7bf1e010-b260-4701-89eb-85d83456e9a6):

Mudança 1 — nó Distribuir codigo_produto MO (Opção B do Rafael): - Substituição completa do jsCode: o lookup agora usa a descrição do BEPEX como chave (não a do Omie) - O produto é localizado na lista Omie por código BPX (list.find(x => String(x.codigo).trim() === String(bCod).trim())) — não mais assumindo posição [0] - O reuso do codigo_produto só ocorre se: (1) o produto retornado tem o mesmo codigo BPX do orçamento E (2) as descrições batem após normalização de espaços e caixa (norm = s => s.toUpperCase().replace(/\s+/g,'').trim()) - Qualquer outra divergência → _codigo_produto_resolvido = null → Code2 reporta mensagem clara (não mais falso "não cadastrado")

Mudança 2 — nó Code2 (humanizador do Error Trigger): - Reescrita completa do ramo de diagnóstico de produto: agora classifica em 3 categorias distintas (em vez de uma só): 1. descricaoDivergente — produto achou pelo código mas descrição difere além de espaço/caixa → msg clara pedindo correção no Omie 2. naoCadastrado — total_de_registros = 0 → produto realmente não existe no Omie 3. produtoDivergente — produto encontrado por descrição mas código BPX não retornou na lista (caso raro) - Corrigido typo "empressa" → "empresa" na mensagem de empresa emissora não definida - Mantidos todos os mapeamentos existentes (nValUnit, Consumo redundante, Pedido já cadastrado, etc.)

Validação pré-deploy: - Lógica do Distribuir testada localmente (node/bash): 5/5 cenários passaram — resolve BPX63706388-MO (espaçamento diferente ✅), bloqueia código diferente ✅, bloqueia descrição realmente diferente ✅, resolve caixa diferente ✅, bloqueia produto não encontrado ✅ - Verificação pós-PATCH: dist_ok=true | norm_in_dist=true | code2_ok=true | typo_fixed=true | active=true

Pedido 1982 ainda pendente de reintegração — verificado que exec 636665 (success, 14:11) processou pedido 1983 (diferente). Pedido 1982 precisa ser redisparado via webhook GET após confirmação do Rafael (cria PC real no Omie ONIX).

Backup: _backup/WwDzIseoYVxbzJZK_pre_fix_distribuir_code2_2026-07-08.json (jsCode anterior dos dois nós + versionId e0a2076a).

2026-07-07 — Normalização de descrição de alumínio (mesmo código, ordem do token "ALUMINIO" divergente) — MP

Contexto: dois pedidos de MP falharam e revelaram DOIS problemas distintos de descrição:

  • PC 1967 (exec 626684 / prod 631147) — falha do SISTEMA DE ORÇAMENTO, não do workflow. O item BPX007081 chegou com omie.mp.descricao = "BPX007081 - 3000 x 1000 x 3.0 SAE 1008 (PC)" — descrição poluída com o próprio código na frente e sufixo "(PC)". Os demais itens vieram limpos. Reportado ao Marcelo no grupo "OMIE e Sistema de Orçamento" (2026-07-07); confirmou parecer específico do item e está investigando. Sem fix no n8n — é dado de origem no BPEX.

  • PC 1976 (exec 631147) — divergência de FORMATO entre BPEX e Omie no alumínio. O item BPX009859 chegou com descrição limpa "6000 x 1000 x 1.2 ALUMINIO", mas o Omie tem o MESMO produto cadastrado (via SYNC, 29/06) como "ALUMINIO 6000 x 1000 x 1.2" — só muda a POSIÇÃO da palavra "ALUMINIO". Busca por descrição (ListarProdutosResumido) retorna 0 → ramo por código → Stop and Error codigo conflito (guarda-corpo funcionando: mesmo código, descrição diferente).

Fix aplicado (em produção 66DDyQXmXQqyV3Ah) — decisão do Rafael: para alumínio, e só para alumínio, tratar as duas descrições como idênticas quando a única diferença é a posição do token "ALUMINIO" e espaçamento. Medida TEMPORÁRIA até normalizar a base de alumínio no Omie.

Inseridos 2 nós no ramo TRUE do IF Existe pelo codigo: - Alum equivalente? (IF, boolean) — pelo menos uma descrição contém "ALUMINIO" E, removido o token "ALUMINIO" e normalizados espaços (.split('ALUMINIO').join('').replace(/ +/g,' ').trim(), uppercase), as descrições são idênticas. - Set Reaproveitado (Set) — reusa codigo_produto do Omie (do ConsultarProduto por codigo) com a descricao do BEPEX (pro lookup do Distribuir bater). Liga em Merge Achado/Criado entrada 2 (Merge passou a numberInputs: 3).

Rewire: IF Existe pelo codigo TRUE → Alum equivalente?; Alum equivalente? TRUE → Set Reaproveitado, FALSE → Stop and Error codigo conflito. Ramo FALSE do IF Existe (IncluirProduto) intocado.

Escopo restrito. Alumínio com dimensão diferente, ou qualquer item não-alumínio com descrição divergente, continuam parando no Stop and Error (guarda-corpo preservado).

Validação em produção — 2026-07-07 ✅ - Lógica do predicado publicado testada localmente: 10/10 cenários (reuso dispara certo; não vaza p/ não-alumínio; dimensão diferente para; separador decimal ,/. para; sem exceção em descrição vazia/undefined). - Exec 633727 (webhook, PC 1976 real, 2 itens de alumínio) — sucesso ponta a ponta: - Alum equivalente? = TRUE p/ BPX009859 → Set Reaproveitado reusou codigo_produto 11478630960. - BPX007454 bateu por descrição (Set Achado, 2307080524). - Distribuir resolveu os 2 itens (0 nulls); adiciona pedido de compra → Omie PC nº 3911 (nCodPed 11482259050); status de sucesso → callback confirmado.

Limitação conhecida: a equivalência cobre só posição do token "ALUMINIO" + espaçamento. Outras divergências no alumínio (separador decimal 1,2 vs 1.2, abreviações) ainda param no guarda-corpo — intencional/conservador até a base do Omie ser normalizada.

Backups: workflow pré-fix em outputs/MP_backup_pre_alum_2026-07-07.json; docs em _backup/*.2026-07-07.bak.

2026-05-14 — Set Achado usava descrição do Omie como chave do lookup (MP) — bug 70% das execuções

Sintoma: ~70% das execuções de MP falhavam em adiciona pedido de compra com erro de produto sem código (tag [cProduto]). Em 30% das execuções funcionava normalmente. O bug estava no nó Distribuir codigo_produto.

Causa-raiz: O Distribuir codigo_produto constrói um mapa descricao → codigo_produto a partir dos items do Merge Achado/Criado, e depois faz o reverse-lookup usando item.json.omie.mp.descricao (descrição do BEPEX) como chave. O problema era que:

  • Set Criado exportava descricao = $('Dedupe descrições MP').itemMatching($itemIndex).json.omie.mp.descricao → descrição do BEPEX ✅
  • Set Achado exportava descricao = $json.produto_servico_resumido[0].descricao → descrição retornada pelo Omie ❌

Quando a descrição cadastrada no Omie diferia da descrição do BEPEX (capitalização, espaços, edições manuais), o lookup no Distribuir retornava undefined e _codigo_produto_resolvido ficava null. O Omie rejeitava o IncluirPedCompra por ausência do código do produto.

Produtos auto-criados pelo sistema (ramo Set Criado) sempre usavam descrição do BEPEX, então 100% deles funcionavam. Produtos que já existiam no Omie (ramo Set Achado) falhavam quando as descrições divergiam — o que acontecia na maioria dos casos.

Fix aplicado (em produção 66DDyQXmXQqyV3Ah, versionId 38bb23d8):

Nó Set Achado — campo descricao: 

ANTES: ={{ $json.produto_servico_resumido[0].descricao }}
DEPOIS: ={{ $('Dedupe descrições MP').itemMatching($itemIndex).json.omie.mp.descricao }}

Agora Set Achado e Set Criado usam a mesma fonte (descrição do BEPEX) como chave, garantindo que o lookup no Distribuir sempre bate.

Validação em produção — 2026-05-15 ✅

Três execuções reais de sucesso após o fix, todas com mode: webhook e finished: true:

Exec startedAt (UTC) Duração
440809 2026-05-15T17:07:38 ~3s
440840 2026-05-15T17:20:10 ~4s
440901 2026-05-15T17:42:07 ~6s

Exec 440901 inspecionada nó-a-nó (PC com 8 itens, produto "2000 x 1000 x 1.5 ALUMINIO"): - Set Achado exportou descricao = "2000 x 1000 x 1.5 ALUMINIO" (BEPEX) ✅ - Distribuir resolveu _codigo_produto_resolvido = 11441794768 em todos os 8 itens (antes ficava null) ✅ - adiciona pedido de compra → nCodPed: 11469254950 (Omie criou o PC) ✅ - status de sucesso → "Status da integração alterado" (callback ao BEPEX confirmado) ✅

Bug das 70% completamente eliminado. Workflow MP estável em produção.

2026-05-12 — Validação end-to-end do fix de consumo redundante (MO) — PC 1816 REAL ✅

Exec de produção: 430068 (webhook, PC 1816 real — 9 itens, empresa ONIX, payload original do exec 427584 que tinha falhado)

Resultado: - Split Out → 9 itens ✅ - Dedupe descrições MO → 5 itens (4 descrições duplicadas removidas) ✅ - Acha código do produto → 5 chamadas ao Omie (não 9) ✅ - Distribuir codigo_produto MO → 9 itens (re-expandiu corretamente) ✅ - Edit Fields1 → 9 itens ✅ - Aggregate → 1 ✅ - adiciona pedido de compra → 1 ✅ - status de sucesso → 1 ✅ — callback ao BPEX enviado com sucesso - Consumo redundante NÃO ocorreu ✅ - Execução: status: success ✅

Conclusão: fix de Dedupe+Distribuir validado com o PC real que havia causado o bug. Workflow MO está estável em produção.

2026-05-12 — Validação intermediária (payload sintético)

Exec de teste: 430061 (webhook, modo POST temporário para teste, payload sintético com 3 itens — 2 com omie.mo.descricao = "DUPLICATA-TESTE" e 1 único)

Resultado: - Split Out → 3 itens - Dedupe descrições MO → 2 itens (deduplicou corretamente) ✅ - Distribuir codigo_produto MO → 3 itens (re-expandiu corretamente) ✅ - Fluxo chegou até adiciona pedido de compra (falhou lá por CNPJ/produto de teste inválidos — comportamento esperado) - Consumo redundante NÃO ocorreu — Acha código do produto chamado apenas 2× (não 3×) ✅

Efeito colateral do teste: projeto "PV-TEST-001" (código Omie 11053000007) criado no Omie ATARES — deve ser removido manualmente no painel Omie ATARES.

Descoberta adicional: o Code node usa $input.first().json.body.pedido_compra.empresa.nome para identificar a empresa (não empresa_id). Os appkeys no REFERENCIA_TECNICA.md estavam com Onix e ATARES trocados — corrigido nessa mesma data.

2026-05-12 — Code1/Code2 humanizador enviava erro genérico (MP + MO)

Sintoma: BPEX recebia "Deu errado: The service was not able to process your request" mesmo para erros com mensagem humanizada mapeada (ex: nValUnit, Consumo redundante).

Causa-raiz: o || chain no topo do Code1 (MP) e Code2 (MO) capturava error.message (sempre preenchido pelo n8n como mensagem genérica do HTTP node) e nunca chegava em error.description (onde o Omie coloca o faultstring específico). Todos os includes() de padrões Omie falhavam silenciosamente e o fallback devolvia a mensagem genérica.

// ANTES (bugado — error.message é sempre truthy, description nunca lido)
const errorMessage = exec?.data?.resultData?.error?.message
  || exec?.data?.resultData?.error?.description || ...;

// DEPOIS (correto — concatena os dois, todos os patterns funcionam)
const errorRaw  = exec?.data?.resultData?.error?.message || exec?.error?.message || '';
const errorDesc = exec?.data?.resultData?.error?.description || exec?.error?.description || '';
const errorMessage = errorRaw + ' ' + errorDesc;

Fix aplicado em produção: - Code1 do workflow MP (66DDyQXmXQqyV3Ah) — split errorRaw/errorDesc + concatenação - Code2 do workflow MO (WwDzIseoYVxbzJZK) — mesmo fix + também atualizado o missingDescs para usar runData['Dedupe descrições MO'] em vez de runData['Split Out'] (ver fix de consumo redundante abaixo) - Para o caso já existe no Omie: retorna errorRaw limpo (a mensagem vem do Stop and Error, está em message, não em description) - Para o caso else (erro não mapeado): retorna errorRaw || errorDesc em vez de errorMessage (evita retornar a concatenação inteira)

2026-05-12 — Consumo redundante em MO com itens de descrição duplicada

Sintoma: exec 427584 — PC com 9 itens (5 com mesma descrição BPX68231137-MO) falhava em Acha código do produto com faultstring: "ERROR: Consumo redundante detectado. Aguarde 59 segundos para tentar novamente (REDUNDANT)." faultcode: SOAP-ENV:Client-6.

Causa-raiz: o workflow MO (WwDzIseoYVxbzJZK) foi construído sem etapa de deduplicação antes de Acha código do produto. Com 5 itens de mesma descrição, o nó chamava ListarProdutosResumido 5 vezes com parâmetros idênticos. O Omie detecta consumo redundante na 2ª chamada idêntica. O MP tinha o mesmo problema e foi corrigido com Dedupe descrições MP + Distribuir codigo_produto — o MO não tinha.

Fix aplicado em produção (WwDzIseoYVxbzJZK):

  1. Dedupe descrições MO (Code) inserido entre Split Out e Acha código do produto:
  2. Agrega items únicos por omie.mo.descricao
  3. Preserva pairedItem do item original

  4. Idêntico ao padrão Dedupe descrições MP, adaptado para campo omie.mo

  5. Distribuir codigo_produto MO (Code) inserido entre Acha código do produto e Edit Fields1:

  6. Constrói lookup Omie descricao → codigo_produto a partir do resultado deduplicado
  7. Re-expande com $('Split Out').all(), cada item recebe _codigo_produto_resolvido

  8. Faz spread completo de it.json original + pairedItem: { item: i } manual

  9. Edit Fields1 atualizado (mesmo fix do MP de 2026-05-05):

  10. nCodProd = $json._codigo_produto_resolvido (era $json.produto_servico_resumido[0].codigo_produto)
  11. nQtde = $json.quantidade (era $('Split Out').item.json.quantidade)
  12. nValUnit = $json.valor (era $('Split Out').item.json.valor)

  13. cObs usando $json.X e $('Webhook').first() (era $('Split Out').item.json.X e $('Webhook').item.json.X)

  14. Code2 atualizado com fix do errorMessage (ver seção acima) + missingDescs usando Dedupe descrições MO como fonte de descrições faltantes.

Conexões alteradas: - Split Out → Acha código do produto → Split Out → Dedupe descrições MO → Acha código do produto - Acha código do produto → Edit Fields1 → Acha código do produto → Distribuir codigo_produto MO → Edit Fields1

Pendência de teste: disparar um PC com itens de descrição duplicada para validar que consumo redundante não ocorre.

2026-05-06 — IncluirProduto faltando codigo_produto_integracao (ATARES)

Sintoma: PC 1800 retornava "Deu errado: The service was not able to process your request" no BPEX.

Causa-raiz: o nó IncluirProduto do MP não enviava codigo_produto_integracao no payload. A empresa ATARES (app_key ${OMIE_APP_KEY_ONIX}) tem config "Bloquear código repetido por integração" (ou similar) que torna esse campo obrigatório. Outras empresas aceitavam sem.

Erro Omie: faultstring: "ERROR: O preenchimento da tag [codigo_produto_integracao] é obrigatório!" faultcode: SOAP-ENV:Client-103

Fix aplicado (em produção 66DDyQXmXQqyV3Ah): adicionar codigo_produto_integracao com mesmo valor de codigo BPX: 

"codigo": "{{ $('Dedupe descrições MP').itemMatching($itemIndex).json.omie.mp.codigo }}",
"codigo_produto_integracao": "{{ $('Dedupe descrições MP').itemMatching($itemIndex).json.omie.mp.codigo }}",

Validação: PC 1800 reprocessado, pedido Omie 3700 criado, produto novo BPX009628 cadastrado automático. exec 413139.

Memória criada: reference_omie_atares_codigo_produto_integracao.

2026-05-05 — paired-item quebrado no Edit Fields1 após dedupe+expand (MP)

Sintoma: PCs 1784, 1795, 1799 retornavam "Deu errado: The service was not able to process your request". 3 execuções no dia.

Causa-raiz: o Code "Distribuir codigo_produto" recebia 6 items deduplicados do Merge e retornava 13 items (re-expansão). Setava pairedItem: { item: i } onde i ∈ [0..12]. Esse índice aponta pro input do Code (Merge, que só tem 6), não pro Split Out. Items 6–12 ficavam com paired-item apontando pra items inexistentes. Em downstream, $('Split Out').item.json.X no Edit Fields1 retornava undefined → nQtde: null no body do IncluirPedCompra. Omie rejeitava.

Erro Omie: faultstring: "ERROR: O preenchimento da tag [nQtde] é obrigatório!" faultcode: SOAP-ENV:Client-105

Fix aplicado (em produção 66DDyQXmXQqyV3Ah): trocar $('Split Out').item.json.X por $json.X no Edit Fields1 (o Distribuir já faz spread completo dos campos originais), e $('Webhook').item por $('Webhook').first(): 

nCodProd  = $json._codigo_produto_resolvido
nQtde     = $json.quantidade
nValUnit  = $json.valor
cObs      = =PVJ-{{ $json.pedido_venda.id }}-PCJ-{{ $('Webhook').first().json.body.pedido_compra.id }}-ITJ-{{ $json.id }}

Validação: PC 1784 reprocessado, pedido Omie 3697 criado. exec 411094 (DEV3), depois promovido pro prod.

Memória criada: feedback_n8n_paireditem_manual.

2026-05-04 → 2026-05-05 (cedo) — Auto-criar produto + estratégia conservadora

Sintoma: PCs falhavam silenciosamente quando o produto BPX ainda não estava cadastrado no Omie.

Causa-raiz: o lookup por descrição (ListarProdutosResumido) retornava 0 e o fluxo terminava em erro genérico.

Fix aplicado: 1. Adicionado ramo no IF: se lookup por descrição falhar, consultar por codigo BPX. 2. Se código existir com descrição diferente → Stop and Error codigo conflito (NÃO sobrescreve — caso legítimo de reconciliação manual). 3. Se código não existir → IncluirProduto (cadastra novo) → Set Criado.

Por que conservadora: Rafael recusou estratégia UpsertProduto após eu ter sobrescrito descrição original do BPX008894 em teste. Caso de descrição divergente é dado pra humano resolver.

Mensagem humanizada adicionada no Code1 do Error Trigger para o caso "produto não cadastrado": "Produto(s) não cadastrado(s) no Omie: ".

Validação: múltiplos PCs em 04-05/05 (DEV2 e prod).

2026-05-04 — Code dedupe quebrando paired-item (MP, primeira ocorrência)

Sintoma: "Paired item data for item from node 'Dedupe descrições MP' is unavailable" no Edit Fields1.

Causa-raiz: Code dedupe que agregava items por descrição não preservava pairedItem, então $('Code').item em downstream falhava.

Fix aplicado: no Code do dedupe, preservar pairedItem: it.pairedItem || { item: i } e em "Acha código do produto" usar $('Code').first() (Code tem 1 item só) em vez de $('Code').item.

Memória criada: feedback_n8n_paired_item.

2026-04-29 → 2026-05-04 — Bug do httpMethod (clone)

Sintoma: Após promover clone MP em prod, BPEX retornava 404 no webhook. Outage de 3.5h.

Causa-raiz: ao clonar workflow via REST, eu adicionei httpMethod: 'POST' no Webhook node — assumindo que o default era ruim. Mas o default é GET, e o BPEX manda GET. Setar POST quebrou o roteamento.

Fix: remover httpMethod do node Webhook (deixa default GET).

Lição: não setar httpMethod ao clonar — deixa o default. Skill n8n-bepex tem warning. Errei 2× em deploys consecutivos.

Memória criada: feedback_n8n_webhook_httpmethod.

2026-04-29 — errorWorkflow apontando pro OLD após clone

Sintoma: após desativar workflow original e ativar clone, erros do clone não disparavam Error Trigger (não havia callback ao BPEX).

Causa-raiz: o clone herdou settings.errorWorkflow do original. Quando o original foi desativado, o errorWorkflow ainda apontava pra ele.

Fix: PATCH settings.errorWorkflow pro ID do clone (ou pro Error Trigger compartilhado pflBwIjA8OBpKFHj).

Memória criada: feedback_n8n_clone_errorworkflow.

2026-04-29 — Auto-criar projeto no MO

Sintoma: PCs de MO falhavam silenciosamente quando o projeto (=pedido_venda.id) ainda não estava no Omie.

Fix aplicado: antes de criar o pedido, garantir projeto existe via IncluirProjeto (Onix/Atares/LGR/BPX). Dale ficou de fora — falta permissão "Cadastro de Projetos / Inclusão" no painel Omie da Dale.

Pendência: liberar permissão Dale → memória project_dale_omie_pendencia.

Casos NÃO-bug (divergências legítimas)

PC 1796 (2026-05-06)

Stop and Error codigo conflito com BPX007300 — "Produto com código BPX007300 já existe no Omie com descrição diferente". Esse é o comportamento conservador funcionando como projetado. Não é bug — Andrei/Daiane precisam reconciliar descrições no Omie ou no BPEX e reenviar.