--- name: card-desenvolvimento description: > Gera cards de desenvolvimento completos e estruturados a partir de solicitações informais de implementação. Use esta skill sempre que o usuário passar uma solicitação, chamado, HIST ou pedido de melhoria para transformar em card. Triggers incluem: qualquer texto com HIST, SOL, número de ZMAP, pedido de montar card, gerar card, criar card, transformar em card, ou qualquer solicitação informal de funcionalidade/melhoria de sistema. Mesmo que a solicitação seja curta ou informal, use esta skill para expandi-la no padrão completo de card de desenvolvimento. --- # Skill: Geração de Card de Desenvolvimento Transforma solicitações informais em cards de desenvolvimento completos, no padrão definido pelo time, prontos para serem copiados ao Jira. --- ## Fluxo de trabalho ### Etapa 1 — Receber e interpretar a solicitação A solicitação chegará em formato livre, por exemplo: ``` 27297 - HIST001: Retirar campo "NÃO É DOCUMENTO FISCAL..." e aumentar fonte dos valores totais. ``` Extraia imediatamente: - **Número ZMAP**: número antes do traço (ex: `27297`) — usado no título do card - **Código da história**: (ex: `HIST001`, `SOL001`) — usado internamente - **Descrição resumida**: o que foi pedido em linguagem informal --- ### Etapa 2 — Revisar a BDC (OBRIGATÓRIO) **Esta etapa é obrigatória antes de gerar qualquer card.** O objetivo é garantir que o conhecimento do sistema usado na geração do card esteja atualizado, pois a BDC é atualizada a cada deploy e pode conter informações mais recentes do que as registradas nesta skill. #### 2.1 — Verificar atualizações recentes Sempre acesse a página de atualizações recentes da BDC para identificar se houve mudanças no módulo afetado pela solicitação: ``` https://bdc.zweb.com.br/categorias/atualizacoes-recentes/ ``` Leia os títulos das últimas atualizações e, se alguma mencionar o módulo ou funcionalidade da solicitação, acesse o artigo completo. #### 2.2 — Consultar o artigo do módulo afetado Identifique o módulo relacionado à solicitação e busque o artigo correspondente na BDC. Use a pesquisa do site ou acesse diretamente pela estrutura de categorias: ``` https://bdc.zweb.com.br/categorias/manuais/ ``` Categorias disponíveis: Cadastros, Configurações Gerais, Documentos, Financeiro, Fiscal, Integrações, Tutoriais. Acesse o artigo do módulo e compare com o conhecimento já registrado nesta skill. Se houver divergências ou informações novas, use a versão mais recente da BDC como referência para gerar o card. #### 2.3 — O que fazer com o resultado - **Se encontrou atualizações relevantes:** incorpore as novas informações ao card (novos campos, regras alteradas, comportamentos modificados) - **Se não encontrou nada novo:** use o conhecimento já registrado nesta skill e prossiga para a Etapa 3 - **Em caso de dúvida sobre algum campo ou regra:** sinalize no card com `{verificar na BDC}` para que o dev consulte antes de implementar Não cite URLs da BDC diretamente no card; incorpore o conhecimento nas seções correspondentes. --- ### Etapa 3 — Entrevista ao usuário Após consultar a BDC, faça perguntas focadas para preencher os pontos que não ficaram claros. Sempre pergunte: 1. **Sistema/módulo afetado**: Zweb? Zpos? Qual tela ou funcionalidade exatamente? 2. **Layouts/modelos afetados**: 80mm? A4? ½ A4? Todos? 3. **Referências visuais ou funcionais**: Se mencionar outro sistema/modelo (ex: "igual ao GPRO"), pergunte detalhes: como funciona esse modelo? Tem print ou documentação? 4. **Impacto em outros módulos**: A alteração afeta alguma outra tela, relatório ou integração? 5. **Restrições conhecidas**: Há algo que NÃO pode ser alterado (fiscal, cálculo, dados)? Não faça mais de 5 perguntas por vez. Se a solicitação for clara o suficiente, pode reduzir. --- ### Etapa 4 — Gerar protótipo MVP (quando aplicável) Antes de escrever o card, avalie se a solicitação envolve algum dos casos abaixo. Se sim, gere o protótipo **antes** do card e inclua o link na seção correspondente. #### Quando gerar um protótipo MVP Gere um protótipo sempre que a solicitação envolver: - Nova tela, formulário ou modal - Alteração de layout de impressão (80mm, A4, ½ A4, DANFE, etiqueta) - Novo fluxo de navegação ou sequência de passos - Alteração visual significativa (reorganização de campos, destaque de informações, remoção de elementos) - Relatório com novo formato ou estrutura - Componente de interface reutilizável **Não é necessário gerar protótipo** para: correções de bug, alterações de regra de negócio sem impacto visual, ajustes de cálculo, integrações de backend, configurações sem tela. #### Formato do protótipo Escolha o formato mais adequado ao contexto: - **HTML interativo** — para telas, formulários, modais, fluxos com múltiplos estados - **PDF** — para layouts de impressão (cupons 80mm, A4, ½ A4, DANFE, boleto) - **SVG** — para diagramas de fluxo, mapas de navegação O protótipo deve: - Seguir o padrão visual do Zweb (fundo branco, azul #1a73e8, fonte sem serifa, badges coloridos) - Ser fiel aos campos e seções reais do módulo afetado (conforme BDC) - Incluir dados fictícios mas realistas para facilitar a validação pelo PO - Ser gerado como arquivo disponibilizado para download #### Como incluir no card Após gerar o protótipo, inclua a referência no card dentro do RF que descreve a tela ou layout: ``` > 📎 **Protótipo validado:** [MVP - {descrição}]({link_do_arquivo}) ``` E também nos Critérios de Aceitação: ``` - O layout implementado estar em conformidade com o protótipo validado pelo PO. ``` --- ### Etapa 5 — Gerar o card Com as informações coletadas e o protótipo gerado (quando aplicável), escreva o card completo no padrão abaixo. **Regras de numeração**: todos os códigos (SOL, RN, RF, RNF, HIST, CA) começam em 001 a cada card. --- ## Template do Card ```markdown ## Solicitação Aceita [Análise] **SOL001:** {descrição fiel da solicitação original, sem parafrasear demais} --- ## Visão e Problema [Product Owner] ### Contexto e Problema do usuário **Situação Atual (As-Is):** {descreva o comportamento atual do sistema, o que existe hoje que gera o problema} **O impacto identificado:** {liste os impactos negativos da situação atual para o usuário/negócio} **Estado Futuro (To-Be):** {descreva como o sistema deverá se comportar após a implementação} --- ## Histórias do usuário **HIST001:** Como {perfil do usuário}, quero {ação desejada}, para {benefício/objetivo}. {adicionar HIST002, HIST003... se houver mais de um perfil ou cenário relevante} --- ## Regras de negócio [Product Owner] **RN001:** {regra de negócio 1} **RN002:** {regra de negócio 2} {...} --- ## Requisitos funcionais [Product Owner & Dev] **RF001:** {requisito funcional 1} **RF002:** {requisito funcional 2} {...} --- ## Requisitos não funcionais [Product Owner & Dev] **RNF001 (Performance):** {requisito de performance, se aplicável} **RNF002 (Consistência):** {padrão visual/comportamental} **RNF003 (Usabilidade):** {facilidade de uso} **RNF004 (Compatibilidade):** {compatibilidade com ambientes, dispositivos, formatos} **RNF005 (Confiabilidade):** {integridade dos dados, margens, quebras, etc.} {adicionar outros RNFs se necessário} --- ## Critérios de aceitação [Product Owner & Tester] O projeto será considerado aprovado pelo time de qualidade quando forem atendidos os seguintes critérios de aceitação: - {critério direto derivado de RF001} - {critério direto derivado de RF002} - {critério direto derivado de RF003} - {critério adicional de negócio, se houver} - PO e UX aprovarem o novo modelo visual. ← incluir sempre que houver alteração visual ``` --- ## Regras de geração ### Título do card O título deve seguir o padrão: ``` {NÚMERO_ZMAP} - {Título descritivo curto em português} ``` Exemplo: `27297 - Novo layout Pedido de Venda` ### Seções obrigatórias Todas as seções abaixo são **sempre** geradas, mesmo que com poucos itens: - Solicitação Aceita - Visão e Problema - Histórias do usuário - Regras de negócio - Requisitos funcionais - Requisitos não funcionais - Critérios de aceitação ### Critérios de aceitação - Deve haver ao menos um critério por RF gerado - Critérios devem ser objetivos e verificáveis (sim/não) - Incluir critério de aprovação de PO/UX sempre que houver alteração de interface ### Referências a outros sistemas Se o usuário mencionar outro sistema ou modelo como referência (ex: "igual ao GPRO"): - Inclua como RN: `O layout deve seguir o padrão visual do {sistema/modelo} como referência` - Inclua como RF: `Implementar {elemento} conforme padrão do {sistema/modelo}` - **Não invente** como esse modelo funciona; pergunte ou deixe como `{detalhar com dev/PO}` ### Uso da BDC - Se encontrar documentação relevante na BDC, use para enriquecer RNs e RFs - Não cite a URL diretamente no card; incorpore o conhecimento nas seções - Se não encontrar nada relevante, prossiga com o que foi informado --- ## Exemplo de entrada e saída **Entrada:** ``` 27297 - HIST001: Retirar campo "NÃO É DOCUMENTO FISCAL..." e aumentar fonte dos valores totais. Se basear no layout do GPRO, fontes maiores mais legível para o cliente. ``` **Saída esperada:** card completo no padrão acima, com título `27297 - Novo layout Pedido de Venda`, todas as seções preenchidas, RNs e RFs derivados da solicitação e do contexto do módulo Pedido de Venda consultado na BDC. --- ## Contexto do sistema Zweb Use este conhecimento para enriquecer cards sem precisar perguntar o óbvio. ### Estrutura de menus - **Cadastros** → Estoque (Produtos, Grupos), Clientes, Fornecedores - **Financeiro** → Contas, Transferências, Receitas, Despesas, Formas de pagamento - **Documentos** → DAV's (Pedidos de venda, Orçamentos, Ordem de serviço), NF-e, NFC-e - **Fiscal** → NF-e, NFC-e, MDF-e, Configurações, Documentos e caixas - **Integrações** → E-commerce, Marketplace, APIs ### Módulo Pedido de Venda (DAV) Caminho: `Documentos > DAV's > Pedidos de venda` **Listagem:** colunas Data, Número, Cliente, Vendedor, Pagamento, Situação, Total R$, Data de envio, Data de entrega, Canal de venda. **Situações possíveis:** Editando, Exportado, Reservado (reserva qtd. do produto). **Cadastro — seções:** - Dados do cliente: Cliente (obrigatório), CPF/CNPJ, RG/IE - Itens: Descrição, Unidade, Quantidade, Valor unitário R$, Desconto (% ou R$), Total R$; rodapé com Desconto total, Frete, Despesas adicionais, Total R$ destacado - Formas de pagamento - Informações adicionais **Ações disponíveis:** Impressões (dropdown), Imprimir, Cancelar, Salvar. Tabela de preços e Importar no cabeçalho. **Impressão:** suporta modelos 80mm (térmica), A4 e 1/2 A4. Compatível com PDF. Impressão pode ser automática ou manual. **Validações conhecidas:** "Valor do item deve ser maior que zero". ### Módulo Produtos Caminho: `Cadastros > Estoque > Produtos` **Campos principais:** Código, Descrição, Grade, Controles específicos, E-commerce e Marketplace, Quantidade, Qtde. Atacado maior que, Qtde. reservada, Qtde. mínima, Preço, Preço de atacado, Custo, Custo médio, Unidade de medida, Grupo, Fornecedor preferencial, Tipo do produto, Referência, Código de barras, Lucro bruto, Peso bruto, Peso líquido, Observações. **Seções expansíveis:** Dados fiscais, Reforma tributária, Comissão. **Ações:** Movimentação do item, Cancelar, Clonar, Salvar. ### Módulo Financeiro — Contas Caminho: `Financeiro > Outros > Contas` **Campos:** Nome, Banco, Agência, Número da conta, Status (Ativo/Inativo), Saldo R$. ### Padrão visual do sistema - Menu superior fixo azul com logo Zweb - Breadcrumb no topo de cada tela - Botão primário azul (Salvar, Cadastrar) no canto superior ou inferior direito - Listagens com filtros, busca, colunas configuráveis e impressão - Status em badges coloridos (azul = Ativo/Editando, verde = Exportado) - Formulários em seções expansíveis (acordeão) - Toasts de erro no canto superior direito --- ## Módulos adicionais do Zweb ### Módulo Clientes Caminho: `Cadastros > Clientes` **Listagem:** Nome/Razão, Nome fantasia, CPF/CNPJ, RG/IE, Vendedor, E-mail, Telefone, Logradouro. **Favoritos (menu rápido):** Clientes, Fornecedores, Produtos, Pedidos de venda, Venda gerencial, NF-e. ### Módulo Tabela de Preços Caminho: `Cadastros > Estoque > Tabela de preços` **Seção Identificação:** Descrição da tabela*, Fator de ajuste*, Tipo de fator* (Desconto/Acréscimo), Tabela de preços por (Clientes/Produtos), Status (toggle), Ajustar valores para terminar com R$, botão "Recalcular valores". **Seção Produtos:** listagem com Código, Produto, Código de barras, Qtde. Estoque, Preço de venda R$, Preço calculado. Opção: "Atualizar tabela de acordo com preço do produto no estoque" e "Mostrar somente itens que não estão em outras listas". ### Módulo Financeiro — Despesas Caminho: `Financeiro > Despesas` **Listagem:** Data de vencimento, Data de cadastro, Documento, Conta, Categoria, Fornecedor, Descrição, Pago em, Parcela, Valor R$, Pago R$, Status. **Status de despesas:** Paga (verde), Em atraso (vermelho), A vencer (laranja). **Parcelas:** exibidas no formato X/Y (ex: 1/7, 3/7). ### Módulo Fiscal — Configurações NF-e Caminho: `Fiscal > Configurações > NF-e` **Configurações disponíveis (toggles):** - Permitir seleção de vendedor - Habilitar quantidade atacado - Incluir frete na base de cálculo de ICMS - Incluir seguro na base de cálculo de ICMS - Incluir IPI na base de cálculo de ICMS - Incluir outras despesas na base de cálculo de ICMS - Subtrair o valor do ICMS desonerado do total da nota fiscal de venda - Desconto condicional/incondicional - Excluir valor do ICMS da base do PIS/COFINS - Habilitar verificação de desconto (em %) - Enviar EAN do item no arquivo XML (impresso no DANFE) - Utilizar referência do produto como código no XML (cProd) - NT 2023.004 **Layout do DANFE:** dropdown (ex: A4 - Retrato) ### Módulo Documentos — Relatórios Caminho: `Documentos > Relatórios` **Relatórios disponíveis:** Pedidos de venda, Orçamentos, Resumo de vendas, Pedidos importados, Relatório de OS, Comissões. Cada um com botão "Gerar relatório". --- ## Padrões aprendidos de cards anteriores ### Card tipo: Nova funcionalidade em módulo existente Exemplo: Etiquetas a partir de NF-e de compra **Padrão de RFs:** organizar por módulo afetado quando a funcionalidade impacta mais de um lugar. ``` Módulo Compras RF001: ... RF002: ... Módulo Produtos RF003: ... RF004: ... ``` **Padrão de Histórias:** criar uma HIST por perfil de usuário distinto (operador, estoquista, contador, etc.) **Padrão de RNFs:** para novas funcionalidades, sempre incluir: - Performance (carregamento de dados) - Arquitetura (reaproveitamento de estrutura existente) - Usabilidade (redução de etapas) - Compatibilidade (impressoras, formatos, ambientes) ### Card tipo: Paridade entre módulos (mesmo campo/comportamento em módulos diferentes) Exemplo: Desoneração de ICMS no módulo Compras (paridade com NF-e) **Padrão de RNFs:** sempre incluir: - Consistência Sistêmica (comportamento idêntico entre módulos) - Usabilidade (mesmo padrão visual e hierarquia) - Integridade Fiscal (validação antes do salvamento) **Padrão de RNs:** referenciar explicitamente o módulo de origem como referência: - "Os campos/regras devem seguir exatamente o mesmo padrão do módulo X" - "O preenchimento será opcional" - "Os valores não devem impactar regras automáticas existentes" ### Seção "Rotinas a serem repassadas [QA]" Cards mais completos incluem cenários de teste no formato Gherkin (Dado/Quando/Então). Incluir esta seção quando a solicitação envolver: - Novas funcionalidades com fluxo claro - Regras fiscais ou de cálculo - Comportamento condicional (com/sem dados, com/sem XML, etc.) Formato: ``` Cenário N — {nome do cenário} Dado {contexto inicial} Quando {ação do usuário} Então {resultado esperado} E {resultado adicional, se houver} ``` **Perguntar ao usuário** se deseja incluir os cenários QA no card, pois nem todos os cards os possuem. ### Contexto fiscal importante - **ICMS Desonerado:** campo disponível na NF-e, com Valor R$ e Motivo da desoneração. Quando uma solicitação envolver paridade fiscal entre módulos, sempre verificar se há campos de desoneração, CST, CSOSN, NCM que também precisam de paridade. - **Importação de XML:** fluxo alternativo ao lançamento manual. Funcionalidades que dependem de XML devem ter equivalente manual quando possível. - **Ambientes:** Produção (peso fiscal real) e Homologação (testes). Alterações fiscais devem ser testadas em homologação primeiro. --- ## Sistema ZPOS O ZPOS é um **aplicativo Android (APK)** desenvolvido pela Zucchetti, instalado em maquininhas de pagamento (terminais POS). Diferente do Zweb (sistema web de gestão), o ZPOS roda diretamente no hardware do terminal. ### O que é o ZPOS - Aplicativo instalado em terminais POS (Point of Sale) - Funciona como intermediador entre o terminal físico e o Zweb - Responsável pela comunicação de transações de cartão (autorização, NSU, etc.) - Distribuidoras/empresas que utilizam: Gedor, SmallSoft, Clipp Pro, Zweb ### Terminais compatíveis (modelos homologados) - Ingenico A8 - Sunmi P2 - GPOS700X - Positivo L300 - Stone S920 / Q92 (sem ZPOS, integração direta) - Clover (configuração específica) ### Administradoras integradas Stone, PagBank, Vero (Banrisul), Rede, Cielo, Sipag, Clover, Caixa, Bin, Sicredi ### Versões mínimas por administradora | Administradora | Versão ZPOS mínima | |---|---| | Vero, PagBank, Rede | 2.2.6 | | Fiserv (Sicredi, Caixa, Bin), Clover | 2.2.7 | | Stone | 2.3.6 | | Cielo | 2.3.5 | ### Fluxo de uso 1. ZPOS instalado na maquininha exibe número de série e status 2. No Zweb: Configurações gerais > seção ZPOS > cadastro da maquininha (serial, caixa, integradora) 3. Na venda: informar valor, parcelamento, administradora, bandeira > "Finalizar (Alt+F3)" > selecionar "POS INTEGRADO" 4. ZPOS processa o pagamento e retorna nº autorização e NSU automaticamente ao Zweb ### Configurações no Zweb Caminho: ícone de configurações > Configurações gerais > seção ZPOS Campos de cadastro da maquininha: - Imprimir documento POS (obrigatório em RS e MS por lei) - Caixa (vincular ao caixa cadastrado) - Integradora - Número de série (POS) - Identificação interna (apelido) ### Implantações e releases O ZPOS é distribuído como APK para múltiplas empresas (Gedor, SmallSoft, Clipp Pro, Zweb). Cada empresa pode ter sua própria versão do APK com configurações distintas. O controle de releases é feito separadamente do Zweb. ### Considerações para cards envolvendo ZPOS Ao gerar cards que impactem o ZPOS, sempre verificar: - Qual(is) empresa(s)/distribuidor(es) serão afetados (Gedor, SmallSoft, Clipp Pro, Zweb) - Se a mudança exige nova versão do APK ou apenas configuração no Zweb - Compatibilidade com terminais já homologados - Se há obrigatoriedade legal estadual envolvida (impressão de documento fiscal no POS) - Se a mudança afeta o fluxo de autorização/NSU e a integridade da transação --- ## Conhecimento completo da BDC Zweb ### Módulo Compras Caminho: `Fiscal > Compras` **Introdução:** gerencia notas de entrada, controle de estoque, custos e informações fiscais. Suporta lançamento manual e importação de XML. **Listagem:** botão "Cadastrar NF de compra". Ações: editar, excluir, filtrar, buscar, imprimir, personalizar via "Ações". **Formas de lançamento:** - **Manual:** seções Informações fiscais (chave de acesso, número, série, modelo, comprador, natureza de operação, CFOP, datas), Fornecedor, Produtos, Cálculo dos impostos, Transportador/volume, Formas de pagamento, Informações adicionais - **Importação por XML:** arquivo selecionado manualmente - **Manifestação do destinatário:** via `Fiscal > Manifestos` **CFOP de compra:** inicia com **1** (mesmo estado) ou **2** (outro estado). **Manifestos — status possíveis:** Sem status, Manifestado, NF Importada, Cancelada, Fora do prazo. Tipo XML: Completo ou Resumido. **Vinculação de produtos na importação XML:** sistema tenta vincular automaticamente por: parametrização → código de barras → descrição. Se não localizado, exige intervenção manual. Ações por item: localizar, parametrizar/desparametrizar, cadastrar produto, editar cadastro. **Fator de conversão:** relação entre unidade comprada e unidade de estoque. --- ### Módulo DAVs — Orçamentos e Pedidos de Venda Caminho: `Documentos > DAVs` **Orçamento:** proposta comercial sem obrigatoriedade. Pode ser exportado para Pedido de Venda (após isso, não pode ser alterado). **Campos do Orçamento:** - Tabela de preços / Importação de kit (de `Cadastros > Estoque`) - Dados do cliente (selecionar ou cadastrar) - Itens: Descrição, Quantidade, Valor unitário, Desconto (% ou R$), Total - Desconto total, Frete - Informações adicionais: Formas de pagamento, Situação, Vendedor, Validade, Observações - Impressões: A4 inteira, metade A4, simplificada 80mm **Pedido de Venda:** formalização da compra. Pode ser importado para NF-e, NFC-e ou PDV. **Campos adicionais no Pedido de Venda (vs. Orçamento):** - Formas de pagamento: Validade, Conta de destino, Plano de contas, Situação, Vendedor **Importação do Pedido de Venda para:** - NF-e - PDV (NFC-e ou Venda Gerencial) **Situações (DAV):** cadastradas em `Documentos > DAVs > Situações`. Podem ser marcadas para Orçamento e/ou Pedido de Venda, com cor personalizada. **Busca de produtos (padrão em todo o sistema):** - Mais de 25 caracteres → busca exata - Até 25 caracteres não numéricos → busca por "contém" - Apenas números → código interno, código de barras ou referência numérica - `#` + número → busca por código interno --- ### Módulo PDV (Venda Gerencial e NFC-e) **Tipos de PDV:** - **Venda Gerencial:** `Documentos > Venda Gerencial > PDV` — imprime documento interno, NFC-e emitida depois - **NFC-e:** `Fiscal > NFC-e > PDV` — transmite XML para SEFAZ ao finalizar **Fluxo de venda no PDV:** 1. Selecionar caixa e informar valor de abertura 2. Lançar produtos por código, descrição ou código de barras (F2) 3. Padrão `Quantidade * Produto` (ex: `3*Jaqueta`) para múltiplas unidades 4. Remover item: `-` + número do item 5. Informar formas de pagamento (saldo deve zerar) 6. Finalizar: `Alt+F3` ou botão "Finalizar" **Controle de caixa:** abertura, fechamento, sangria e suprimento. **Estados especiais:** SP e CE usam SAT/MFE em vez de NFC-e. --- ### Módulo NF-e Caminho: `Fiscal > NF-e` **Configuração prévia:** `Fiscal > Configurações > Documentos e caixas` - Modelo: 55-NF-e - Ambiente: Produção (peso fiscal) ou Homologação (testes) - Série e próximo número - Imprimir no terminal ao autorizar - Enviar intermediador **Ações disponíveis por nota:** Cancelar, Carta de Correção, ECONF (Evento de Conciliação Financeira), Ator interessado, Consultar pela chave, Protocolar recibo, Visualizar DANFE, Imprimir DANFE no Terminal, Gerar boleto, Enviar e-mail, Gerar XML, Clonar NF-e, Reenviar XML ao Minhas Notas, Enviar pelo WhatsApp, Emitir MDF-e **Importação para NF-e:** Ordem de Serviço, Pedido de Venda, Venda Gerencial, NFC-e, Kit **Seções do cadastro NF-e:** Natureza, Destinatário, Itens, Cálculo dos impostos, Transportador/Volume, Formas de pagamento, Dados adicionais, Controles específicos **Carta de Correção:** apenas informações que não impactam cálculo de impostos, identificação de remetente/destinatário ou datas de emissão/saída. --- ### Reforma Tributária no Zweb **Novos impostos:** - **CBS** (substitui PIS e COFINS) — federal - **IBS** (substitui ICMS e ISS) — estados e municípios - **IS** (substitui IPI, para produtos nocivos à saúde/ambiente) — vigência a partir de 2027 **Alterações no cadastro de Produtos/Serviços — seção "Reforma Tributária":** - Class. trib. IBS/CBS, CST IBS/CBS (preenchimento automático) - Class. trib. regular / CST regular (para casos de suspensão) - IBS: % Diferimento Mun./UF, % Redução Mun./UF, Cód. crédito presumido, % Alíq. crédito presumido - CBS: % Diferimento, % Redução, Cód. crédito presumido, % Alíq. crédito presumido - IS: CST IS, Class. trib. IS, % Alíquota específica, % Alíquota IS (vigência 2027) - Código ANP (produtos petróleo/GLP) **Auto-sugestão:** ao selecionar classificação tributária, campos relacionados são liberados e preenchidos automaticamente. **Replicar alterações:** aplica mudanças de um produto para todos que compartilham a mesma configuração. **NT 2025.002-RTC:** grupo de tributação monofásica e IS gerados a partir de 01/04/2027. --- ### Outros módulos mapeados na BDC **Cadastros:** - Clientes, Fornecedores, Produtos, Serviços - Inventário de estoque - Etiquetas (configuração de modelos) - Unidades de medida - Tabela de preços - Controle de grade (produtos com variações) - Kits (agrupamento de produtos) - Agenda **Configurações Gerais:** - Primeiro acesso, Cadastro de usuários, Configurações gerais - Terminal ZWeb (download e instalação) - PDV Híbrido - Configurações de tributação - Importar dados via XML **Documentos:** - PDV (Venda Gerencial e NFC-e) - DAVs (Orçamentos e Pedidos de Venda) - Ordem de Serviço (OS) - Ordem de Compra - Romaneio de Carga **Fiscal:** - Reforma Tributária, PDV, SAT/MFE, NF-e, NFC-e, NFS-e, MDF-e - Compras, Manifestos - Perfis de tributação, Tributações, Benefícios Fiscais - Naturezas de Operação, Parametrização de Tributos, CFOP - SPED Fiscal (EFD), SINTEGRA - Devoluções (NF-e venda, NFC-e, NF-e compra) - Minhas notas, Nota de retorno de mercadoria - NFS-e com Focus (integração) **Financeiro:** - Receitas, Despesas, Transferências, Contas - Formas de pagamento, Plano de Contas e DRE - Boletos (Sicoob, Inter, Sicredi, Santander) - ZPOS (Caixa, Bin, Sicredi) **Integrações:** - E-commerce (Zeta/Clipp) - Mercado Livre - E-commerce e Marketplace --- ## Referência: Sistema GPRO (Gdoor) O GPRO é o sistema desktop da família Zucchetti/Gdoor, amplamente utilizado como **referência de funcionalidades maduras** para implementação no Zweb. Quando uma solicitação mencionar "igual ao GPRO", "como no GPRO" ou "se basear no GPRO", consulte este contexto. **Importante:** O GPRO é um sistema Windows (desktop/instalado), enquanto o Zweb é web. Ao referenciar o GPRO, adapte os conceitos para o contexto web do Zweb — sem janelas flutuantes, com navegação por breadcrumb, botões no rodapé, etc. **BDC do GPRO:** https://bdc.gdoor.com.br/ --- ### Estrutura de módulos do GPRO **Instalação do sistema:** download, instalação, atualização, requisitos mínimos (Firebird). **Configurações do sistema:** configurações gerais, tributação, certificado digital, ZPOS, PDV móvel. **Cadastros:** Emitente, Clientes, Fornecedores, Transportadoras, Vendedores, Usuários/permissões, Estoque (produtos, variações, composição, kits, lotes/validades, fator de conversão, inventário, balanço), Clube de fidelidade, Promoções (Scanntech), Gcoletor. **Controle financeiro:** Contas a receber, Contas a pagar, Boletos, Bancos, Livro caixa, Cheques, Taxas de cartão. **Faturamento:** NF-e, NFC-e, CF-e (SAT/MFE), Cupom Fiscal (ECF), NFS-e, CT-e, MDF-e. **Arquivos fiscais:** Gfiscal, SPED, Sintegra. **Módulos de movimentação:** Pré-venda, Pré-venda gerencial, Orçamento, DAV, DAV-OS, Pedido de venda, Pedido de compra, Compras, Cotação de compra, Manifestação do destinatário (MD-e), Nota de importação. **Módulos auxiliares:** Relatórios, Etiquetas, Consulta de preços, Backup (local e nuvem), Ferramentas de suporte. **Módulos adicionais:** Gfood, Glink, Gcontábil, Gct-e, Gservice, Gview, PDV móvel (Android/iOS), Ótica (OS). --- ### Módulo Etiquetas — GPRO (referência) **Acesso:** pelo módulo Estoque > Impressos > Etiquetas, ou diretamente de uma nota de compra. **Tipos de etiqueta:** Produtos, Clientes, Fornecedores, Ordem de Serviço. **Configuração do layout:** - Nome do modelo - Tipo de papel: Bobina (impressão contínua) ou Folha - Medidas da folha: Altura, Largura, Etiquetas por linha, Linhas por página - Margens: esquerda, direita, superior, inferior - Medidas da etiqueta: Altura, Largura, Espaçamento **Campos configuráveis por etiqueta:** - Qualquer campo do cadastro de produto (descrição, preço, código de barras, referência, etc.) - Campos de texto livre (TEXTO1 a TEXTO9) - Posição: Esquerda/Coluna, Topo/Linha - Dimensão: Altura, Largura - Fonte, Tamanho, Cor, Negrito, Itálico, Sublinhado, Alinhamento, Quebra de linha - Rotação em graus, Cor de fundo, Tamanho automático - Código de barras: Zoom, Mostrar código, Tipo de barras, Largura da barra **Formas de impressão:** - **Listados:** todos os produtos do estoque (com filtro agrupa) - **Relacionados:** produtos específicos — por nota de compra ou seleção manual por código/descrição **Integração com Compras:** ao abrir uma nota de compra, o botão "Etiquetas" carrega diretamente os produtos e quantidades da nota para geração de etiquetas. --- ### Módulo Pedido de Venda — GPRO (referência) **Integração:** Clientes, Estoque, Vendedores, Transportadoras, Contas a receber, Faturamento. **Cabeçalho:** Número (automático), Cliente (com busca progressiva), CNPJ/CPF, IE/RG, Contato, CEP, UF, Município, Logradouro, Complemento, Número, Bairro, Telefone, Data de emissão, Previsão de entrega, Vendedor, Transportadora, Forma de pagamento. **Itens:** - Nome do produto (aceita código, código de barras, leitura de leitor) - Unidade de medida, Q. Ped. (quantidade pedida), Q. Sal. (saldo a entregar) - Valor unitário, Desconto %, Total - Totalizadores: Produtos, Descontos, Total do pedido - Campo de informações complementares (impresso no pedido e na NF-e) **Rodapé (botões padrão do GPRO):** Listagem, Ficha, Editar, Novo (Ctrl+N), Desfazer (Ctrl+Z), Salvar (Ctrl+S), Apagar (Ctrl+Del), Agrupa, Campos, Imprime, Impresso, E-mail. **Listagem:** mostra todos os pedidos. Ícone "dinheiro" = tem financeiro. Ícone "caixinha azul" = movimentou estoque. **Funcionalidades especiais:** - Controle de entrega parcial (Q. Sal. atualizado a cada faturamento) - Vínculos com NF-e - Conferência do pedido - Gerar/estornar financeiro - Movimentar/estornar estoque --- ### Módulo Compras — GPRO (referência) **Status das notas:** - **Em processamento:** XML importado mas processo não concluído (salvo, não concluído) — não gera estoque nem financeiro - **Pendente:** processo de importação concluído mas nota apenas salva — não gera estoque nem financeiro - **Concluído:** nota finalizada (clicado em "concluir") — gera estoque e movimentação financeira **Funcionalidades exclusivas do GPRO (referência para implementar no Zweb):** - **Precificação:** tela dedicada para analisar variações de preço de compra vs. preço de venda, com histórico de compras por item e sugestão de novo preço - **Alteração em massa:** atualização em lote de dados cadastrais dos produtos da nota - **Comparação:** confronto entre pedido de compra e nota recebida - **Controle de validade:** controle de lotes e datas de vencimento dos itens da nota - **Etiquetas integradas:** botão na nota de compra que carrega produtos e quantidades para impressão direta - **Cotação de compra:** comparação de preços entre fornecedores antes da compra **Cabeçalho da nota:** Nº da nota, Modelo, Série, Data de emissão, Data/hora de entrada, Data/hora de chegada, Natureza de operação, CFOP. --- ### Módulo PDV — GPRO (referência) **Tipos:** NFC-e, SAT/MFE (SP e CE), ECF (cupom fiscal legado), Pré-venda, Pré-venda gerencial. **Atalhos padrão do PDV GPRO:** F2 (busca produto), F12 (finalizar), etc. Listagem completa em `bdc.gdoor.com.br/artigos/teclas-de-atalho/`. **Controle de caixa:** abertura, suprimento, sangria, fechamento normal e fechamento cego. **Troca de mercadorias:** geração de crédito de troca, emissão de cupom com abatimento, nota de devolução. **PDV Móvel:** app Android e iOS para vendas em campo, integrado ao sistema desktop. --- ### Como usar a referência GPRO nos cards Quando a solicitação mencionar o GPRO como referência: 1. **Identifique qual módulo/funcionalidade** do GPRO está sendo referenciada 2. **Consulte este contexto** para entender como funciona no GPRO 3. **Adapte para o Zweb:** traduza campos, fluxos e comportamentos para o padrão web do Zweb (sem janelas flutuantes, breadcrumb, acordeão, badges, etc.) 4. **Inclua no card:** `RN: O comportamento deve seguir o padrão do módulo {X} do GPRO, adaptado ao contexto web do Zweb` 5. **Se necessário:** gere um protótipo MVP mostrando como ficaria no visual do Zweb Se houver dúvida sobre como uma funcionalidade específica do GPRO funciona, consulte diretamente: `https://bdc.gdoor.com.br/artigos/{modulo}/` --- ## Módulo MDF-e (Manifesto Eletrônico de Documentos Fiscais) Caminho: `Fiscal > MDF-e > Cadastrar MDF-e` **Aviso de ambiente:** banner rosa no topo indica "Ambiente de homologação" quando não estiver em produção. **Ações disponíveis:** Cancelar, Salvar, Transmitir (botões no rodapé inferior direito). ### Seções do cadastro (acordeão): #### 1. Dados gerais - **Tipo do emitente** (dropdown): ex. "Transportador de Carga Própria" - **Motorista** (campo de busca com autocomplete): lista motoristas cadastrados #### 2. Veículos - **Caminhão*** (busca com autocomplete, ex: VEJ5415) — obrigatório - **1º Reboque** (desabilitado até selecionar caminhão) - **2º Reboque** (desabilitado até selecionar caminhão) - **3º Reboque** (desabilitado até selecionar caminhão) #### 3. Documentos vinculados - Tipo: **NF-e própria** (radio) | **NF-e de terceiro** (radio) - **Número/Chave** (dropdown com busca + botão de importação de arquivo) #### 4. Carga transportada - **Produto predominante*** (texto livre) — obrigatório - **NCM do produto predominante*** (dropdown "Selecione um NCM") — obrigatório - **Valor total R$*** — obrigatório - **Peso bruto total*** — obrigatório - **Unidade*** (dropdown) — obrigatório - **Tipo de carga*** (dropdown) — obrigatório #### 5. Dados da viagem **Carregamento:** - CEP*, UF* (dropdown), Município* (dropdown), UF percurso (dropdown) **Descarregamento:** - CEP*, UF* (dropdown), Município* (dropdown), Data, Hora - **Informações complementares** (textarea) #### 6. Pagamento - **Responsável*** (texto) — obrigatório - **CPF/CNPJ*** — obrigatório - **Tipo de pagamento*** (dropdown) — obrigatório - **Total contrato*** (valor R$, padrão 0,00) — obrigatório - **Código banco*** — obrigatório - **Código agência*** — obrigatório - **CNPJ IPEF*** — obrigatório - **ID estrangeiro** (opcional) + botão importar arquivo #### 7. Dados do seguro - **Responsável pelo seguro*** (dropdown) — obrigatório - **CPF/CNPJ responsável*** — obrigatório - **Seguradora*** — obrigatório - **CNPJ seguradora*** — obrigatório - **Número da apólice** (opcional) - **Número da averbação** (opcional) + botão importar arquivo #### 8. Vale-pedágio - **Categoria de combinação veicular** (dropdown, opcional) - **Empresa fornecedora do vale-pedágio*** (dropdown com ícone de info) — obrigatório - **CPF/CNPJ responsável pelo pagamento*** — obrigatório - **Número do comprovante de compra*** — obrigatório - **Tipo do vale-pedágio*** (dropdown) — obrigatório - **Valor R$*** (padrão 0,00) — obrigatório + botão importar arquivo ### Observações para cards envolvendo MDF-e - Campos com * são obrigatórios para transmissão - O MDF-e é obrigatório para transporte de cargas em rodovias com NF-e - Sempre verificar se alterações impactam a transmissão para a SEFAZ - Seções são independentes (acordeão) — alterações em uma não afetam as demais - Ambiente de homologação x produção deve ser considerado em qualquer card fiscal --- ## MDF-e — Listagem (Zweb) Caminho: `Fiscal > MDF-e` **Colunas:** Número, Série, UF - Embarque, UF - Desembarque, Status, Data viagem, Emissão, Chave de acesso. **Status disponíveis:** - **Editando** (badge laranja) — MDF-e em edição, ainda não transmitido - **Em processamento** (badge cinza) — transmitido, aguardando retorno da SEFAZ - **Autorizado** — transmitido e autorizado pela SEFAZ - **Encerrado** — viagem encerrada - **Cancelado** — cancelado antes do encerramento **Menu Ações (dropdown no canto superior direito da listagem):** - Consultar pela chave - Enviar XML - Gerar XML - Imprimir DAMDFE **Botão principal:** "Cadastrar MDF-e" (azul, canto superior direito) **Ações por linha:** editar (ícone lápis), excluir (ícone ×) --- ## MDF-e — Contexto normativo (MOC v3.00a — Receita Federal, abril/2019) ### O que é o MDF-e Modelo **58**. Documento fiscal eletrônico que registra o manifesto de carga para transporte. Obrigatório para: - Transportadores de carga própria que emitem NF-e com transporte próprio em rodovias - Transportadores de carga de terceiros que emitem CT-e ### Conceitos fundamentais **DAMDFE:** Documento Auxiliar do MDF-e, impresso para acompanhar a carga durante o transporte. Deve conter QR Code para consulta pública. **Chave de Acesso:** 44 dígitos — cUF + AAMM + CNPJ + mod + serie + nMDF + cNF + cDV. **Emitentes:** - **Transportador de Carga Própria:** empresa que transporta sua própria mercadoria (vincula NF-e) - **Transportador de Carga de Terceiros:** prestador de serviço de transporte (vincula CT-e) **Série reservada:** 890–899 para emissão em contingência. ### Ciclo de vida ``` Emitido → Autorizado → [Em transporte] → Encerrado ↓ Cancelado (apenas antes do início do transporte, prazo: 24h) ``` - **Encerramento é obrigatório** ao final de cada viagem - MDF-e não encerrado **impede nova emissão** (rejeição por "uso indevido") - **MDF-e com carregamento posterior:** permite emissão antes do carregamento completo; novos DF-e são incluídos via evento ### Eventos disponíveis | Evento | Quando usar | |---|---| | **Cancelamento** | Antes do início do transporte, até 24h após autorização | | **Encerramento** | Ao final da viagem — **obrigatório** | | **Inclusão de Condutor** | Trocar ou adicionar motorista após autorização | | **Inclusão de DF-e** | Vincular NF-e ou CT-e adicionais em carregamento posterior | ### Web Services | Serviço | Tipo | |---|---| | Recepção Assíncrono | Envio para autorização em lote | | Recepção Síncrono *(novo na v3.00a)* | Envio com retorno imediato | | Retorno Recepção | Consulta resultado do lote | | Consulta Situação | Consulta MDF-e pela chave de acesso | | Consulta Não Encerrados | Lista MDF-e autorizados e pendentes de encerramento | | Consulta Status Serviço | Verifica disponibilidade da SEFAZ | | Registro de Eventos | Cancelamento, encerramento, inclusão de condutor/DF-e | ### Regras de negócio críticas para cards - **Encerramento obrigatório:** o sistema deve bloquear nova emissão enquanto houver MDF-e não encerrado - **Cancelamento com prazo:** somente até 24h após autorização e antes do início do transporte - **Inclusão de DF-e posterior:** evento que permite adicionar NF-e/CT-e ao MDF-e já autorizado - **Contingência:** séries 890–899 reservadas; MDF-e emitido em contingência deve ser regularizado após restabelecimento do serviço - **QR Code obrigatório no DAMDFE:** tanto em emissão normal quanto em contingência - **Ambiente:** homologação (testes) e produção (peso fiscal) — banner rosa indica homologação no Zweb - **Validação de chave de acesso:** regras unificadas na v3.00a (consolidação das NT 2017–2018) ### Considerações para cards envolvendo MDF-e Ao gerar um card que afete o MDF-e, sempre verificar: - O evento afetado (encerramento, cancelamento, inclusão de DF-e, inclusão de condutor) - Se a mudança impacta a transmissão XML para a SEFAZ (schema, validações) - Se afeta o DAMDFE impresso (layout, QR Code) - Se há impacto no controle de MDF-e não encerrados - Compatibilidade com ambiente de homologação e produção - Se a mudança é um novo campo no XML ou apenas visual/operacional no Zweb