0003 — Valores tipados no pipeline, formatação ZIM no cliente¶
Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-07-11 · Decidido em: 2026-07-11
Contexto¶
O X-Adm roda sobre ZIM, cujo modelo de dados difere de um Postgres comum: campos Character de
comprimento variável (espaço à esquerda/embutido é significativo, trailing é ignorado), numéricos
VastInt escalados (inteiro com N decimais implícitos), e — crucial — o valor armazenado difere
do exibido (a máscara 9/Z/? e os separadores são só apresentação). Ver
Tratamento de dados no ZIM.
Esses dados cruzam Postgres → PowerSync → SQLite → cliente Java → ZIM. PowerSync/SQLite são fracamente tipados. A dúvida: em que ponto formatar para o formato de armazenamento do ZIM (largura, escala, padding)?
Decisão¶
Os campos viajam tipados/semânticos no pipeline (NUMERIC, TEXT, DATE no Postgres) — não
pré-formatados. A formatação para o ZIM acontece no cliente, na fronteira com o zimrtmu, onde a
equipe do ERP conhece largura, escala e máscara exatas de cada campo.
Consequências¶
- O pipeline carrega dados limpos; a lógica específica do ZIM fica num único ponto (o cliente/ERP).
- O cliente precisa aplicar as regras de formatação por tipo — especificadas em
integracao-zim.md §3 (Character com espaços significativos verbatim,
BigDecimal/escala fixa semdouble, datasAAAAMMDD, "branco não nulo"). - Fica em aberto o contrato de entrada do
zimrtmu(valor-armazenado vs mascarado; largura/escala por campo) — Pendências P3. Até lá, ops-javaé exemplo simulado.
Alternativas consideradas¶
- Pré-formatar tudo como TEXT verbatim no transform (o maxsul-pied produziria a string exata do ZIM e o cliente só repassaria): rejeitada nesta fase — concentra a formatação onde há menos conhecimento do alvo ZIM. Pode ser reavaliada se o cliente acumular lógica de formatação demais.