Conversation
Porta o app Bling ERP (app_id 102418) do repositório app-bling-erp-v2 para
o monorepo, usando a API v3 do Bling: exportação de pedidos e produtos,
importação de estoque, pedidos e categorias, e renovação automática dos
tokens OAuth.
Funções: `blingerp-onStoreEvent` (eventos da loja), `blingerp-callback`
(callbacks de estoque/pedidos do Bling), `blingerp-authCallback` (fluxo de
autorização OAuth) e `blingerp-cronRefreshToken`.
A fila do app v1 em Firestore (`queue/{storeId}/events` + `running_events`)
foi substituída pelo PubSub de eventos do monorepo, e o `appSdk` multi-loja
pelo `@cloudcommerce/api`. Tokens ficam em `blingTokens/{storeId}` e o cache
de situações de venda em `blingStatuses/{storeId}`.
Correções sobre o comportamento do app v1:
- atualização de produto com variações falhava com 400 no Bling, porque as
variações eram enviadas sem ID (a listagem `/produtos?codigo=` devolve o
produto resumido);
- preço por variação era perdido na exportação (o Bling aplica o preço do
produto pai), agora corrigido com PUT por variação divergente;
- callback de estoque de variação sem SKU no Bling era descartado, agora usa
o ID do Bling como referência;
- configuração "Importar produto" não tinha efeito, pois o callback forçava
`canCreateNew: false`;
- status "Devolvido" era enviado como fulfillment inválido;
- limite diário da API gravava a flag invertida, liberando novas chamadas;
- grades de variação importadas viram `size`/`age_group`/`gender` como no
sentido inverso, em vez de slug do rótulo;
- sem situação correspondente no Bling, o pedido não falha mais: registra
aviso e segue exportado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Erros em exportações disparadas por evento da loja (não pela fila manual) só apareciam no log do Cloud Functions, ficando invisíveis para o lojista no painel. Sucessos de importação continuam fora do log para não inundá-lo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Porta o app Bling ERP (
app_id102418) do repositório app-bling-erp-v2 para o monorepo, usando a API v3 do Bling.Funções
blingerp-onStoreEventapplications-dataSetblingerp-callbackblingerp-authCallbackcodedo fluxo OAuth e grava os tokensblingerp-cronRefreshTokenaccess_tokenantes de expirarMudanças de arquitetura em relação ao app v1
queue/{storeId}/events+running_events+handle-queue) deu lugar ao PubSub de eventos do monorepo (maxInstances: 1) com a fila emdatado app;appSdkmulti-loja substituído por@cloudcommerce/apicom as credenciais da própria loja;blingTokens/{storeId}e cache das situações de venda emblingStatuses/{storeId}, no projeto Firebase da loja;products/skus:{sku}no lugar do ElasticSearch.Correções sobre o comportamento do v1
Encontradas ao portar e ao validar contra a API real:
/produtos?codigo=devolve o produto resumido, semvariacoes, então oPUTia sem os IDs e o Bling rejeitava como se fossem novas variações;PUT /produtos/{idVariacao}apenas para as divergentes;canCreateNew: false;fulfillment_statusinválido;other_configera lido comoouther_config(typo), então o tipo de contato nunca era aplicado;quantity), causando lançamento redundante a cada exportação;Grades de variação importadas passam a mapear para
size/age_group/gender(antes sóCorera normalizada), mantendo o round-trip estável com a exportação.Testes
packages/apps/bling-erp/tests/— 37 testes comnode --test, offline, sem credenciais: pedido e produto nos dois sentidos, mapeamento de status (incluindoparse_statuscustomizado), endereço/CEP, parcelamento, prazo de entrega com dias úteis e feriados, variações sem SKU e normalização de grades.scripts/bling-smoke.mjsfaz uma varredura read-only na API do Bling validando credenciais e todos os endpoints usados.Validação em produção
Loja de teste (1011) + conta Bling de teste, com as funções deployadas em um projeto Firebase real:
blingerp-authCallback→ tokens no Firestore;blingerp-onStoreEvent→ pedido criado no Bling com contato, item vinculado, frete, etiqueta e parcela;delivered→ "Atendido") e round-trip de status;blingerp-cronRefreshTokenexecutando e validando o token.Notas
admin_settings) continua no repositórioapp-bling-erp-v2; este pacote traz apenas o runtime;ignore_triggersnas configurações do app para o app central parar de processá-la;pnpm-lock.yamlnão foi atualizado neste PR — o CI instala com--no-frozen-lockfile.🤖 Generated with Claude Code