Painel de líderes

Estes links talvez possam lhe ajudar: http://www.afrac.org.br/mapas/ http://www.bematech.com.br/plataformafiscalmapa/

Creio q o Italo está correto. No caso de Uberlândia/MG por exemplo, os CEP´s são por logradouro (não são por cidade nem por bairro). Mas veja que no Brasil, também existe o controle de CEP por faixa dentro do logradouro como é o caso da cidade de São Paulo. E, no caso do Exterior, o CEP poderá conter letras e números. Veja isso: A Estrutura do CEP brasileiro possui uma orientação geográfica, hierarquizada e classificada conforme otipo de destinatário (quem recebe a correspondência). Há uma divisão "principal" entre os municípios brasileiros com relação à entrega a pessoas comuns: 1. Os municípios com CEP único para todos os logradouros; No caso do CEP único, variam-se seus 5 primeiros dígitos (prefixo) e mantêm-se o sufixo 000 Exemplo: Município de Anchieta, Estado de Santa Catarina: CEP 89970-000 2. Municípios que possuem faixas de CEP para seus logradouros. Já no caso dos municípios com Faixas de CEP, podem variar seus prefixos e sufixos. A variação do SUFIXO ou alguns dos últimos dígitos do prefixo pode ocorrer pelas seguintes causas: 1 - Logradouros: Faixa de Sufixos utilizada: 000 a 899 Este código pode variar conforme o tamanho ou localização de um mesmo logradouro. Normalmente, quando um logradouro é longo, seu CEP muda seu sufixo para se saber a faixa de numeração a ser atendida. Exemplo: Rua Maranhão - Município de São Caetano do Sul, Estado de São Paulo R Maranhão - do início até a numeração 539/540: CEP 09541-000 R Maranhão - da numeração 541/542 até o final: CEP 09541-001 Outro exemplo é sua localização. Caso um logradouro divida ou cruze bairros, distritos ou outro limite administrativo municipal, ou até mesmo não faça divisa mas classificou-se somente pelo lado par/ímpar da numeração, em alguns casos há a mudança do sufixo. Exemplo: Rua José Bonifácio - Município de São Paulo, Estado de São Paulo R José Bonifácio - numeração do lado par: CEP 01003-000 R José Bonifácio - numeração do lado ímpar: CEP 01003-001 OBS: Podem acontecer os dois casos ao mesmo tempo. Exemplo: Avenida Paulista - Município de São Paulo, Estado de São Paulo Av Paulista - até 610 - lado par: CEP 01310-000 Av Paulista - de 612 a 1510 - lado par: CEP 01310-100 Av Paulista - de 1512 a 2132 - lado par: CEP 01310-200 Av Paulista - de 2134 ao fim - lado par: CEP 01310-300 Av Paulista - até 609 - lado ímpar: CEP 01311-000 Av Paulista - de 611 a 1045 - lado ímpar: CEP 01311-100 Av Paulista - de 1047 a 1865 - lado ímpar: CEP 01311-200 Av Paulista - de 1867 ao fim - lado ímpar: CEP 01311-300 2 - Códigos Especiais: Faixa de Sufixos utilizada: 900 a 959 3 - CEPs Promocionais: Faixa de Sufixos utilizada: 960 a 969 4 - Unidades dos Correios: Faixa de Sufixos utilizada: 970 a 989 e 999. 5 - Caixas Postais Comunitárias: Faixa de Sufixos utilizada: 990 a 998 A base de dados do correio com a relacão dos cep com bairros, cidades e estados relacionados foi por muito tempo gratuita para qualquer cidadão no site dos correios mas agora chama-se e-dne ou Diretório Nacional de Endereços que pode ser comprada no site dos correios. Maiores Informações: Estrutura do CEP brasileiro - http://www.correios.com.br/servicos/cep

Boa tarde Allan, Na sua aplicação é possível o cupom de numero 500 fazer referencia a NFC-e de numero 485? Supondo que a diferença se refere aos cupons cancelados antes da emissão da NFC-e. Se for possível, não vejo problema nenhum.

Boa tarde Guilherme, Por favor atualize os fontes e teste novamente.

Boa tarde a todos, No meu entendimento, a aplicação deve sempre utiliza o numero da nota a ser emitida o numero da anterior + 1. Desta forma não teremos problemas. Fora isso pode-se criar uma rotina que checa se existe algum buraco, ou seja sequencia das notas quebrado, por exemplo, temos a nota de numero 500, 502, 503, ... detectado a falha a rotina deve registrar em uma tabela os números de notas não utilizados, neste caso a de numero 501. Essa tabela tem que possuir também outros campos que indica se o numero foi inutilizado ou não, data de inutilização, numero de protocolo, e justificativa. Desta forma o form de inutilização de numeração só estaria disponível para inutilizar os números que constam na tabela como não inutilizados. Após a inutilização de todos, não teria como o usuário inutilizar outro numero. Ficando assim o sistema protegido contra erros.

Achei aqui no layout a solução: No caso do uso de uma Impressora Fiscal, recomenda-se registrar as formas de pagamento e eventuais descontos concedidos pelo estabelecimento somente após a realização da operação de TEF, convivendo assim com as restrições de determinados modelos de equipamentos que não permitem:  Registrar um desconto após ter registrado uma forma de pagamento (tipicamente, dinheiro);  Registrar mais de um desconto. Desculpa ai pessoal, deveria ter lido o manual completo antes de postar a dúvida. Baseado nesta parte do layout já é possível implementar mais tranquilamente.

Teste com esta versão: ACBrMonitor.zip ACBrMonitor.zip

Por favor siga as regras do fórum, para um novo assunto(problema), novo tópico.

Bom dia galera!!! Depois de vários testes, descobri o meu problema. No ACBrECF tem a propriedade Retentar, por default ela vem como True, então o componente fica tentando fazer a operação e não retorna a mensagem de erro. Basta trocar a propriedade para false, que o erro é retornado pelo ACBrECF. Vlw!!!

Sim Irá Funcionar Perfeitamente...

Teste com esta versão: ACBrMonitor.zip

Fiz um pequeno ajuste no ACBrMonitorPLUS e testei com um SAT da Dimep com sucesso. Segue abaixo o executável atualizado e o LOG com os comandos usados. ACBrMonitor.zip LOG.TXT

Ou seja, é pior ainda que uma tabela de bairros da cidade.

Bom dia Wislei, Não é só nas capitais que temos vários CEPs, na cidade que moro ( 180 mil habitantes ) temos vários CEPs. A minha sugestão é você ter uma segunda tabela para armazenar os CEPs. Inclua nessa segunda tabela um campo com o código IBGE da cidade para relacionar com a primeira. Algo do Tipo: Tabela: Cidades Campos: CodIBGE, NomeCidade, SiglaUF, .... Tabela: CEPs Campos: CodIBGE, CEP, Logradouro, ....

Leandro Araújo : Valeu pela dica... Chegou uma nova impressora aqui... e estava pulando 4 etiquetas, mas com sua resposta, não perdi muito tempo... Muito obrigado...

Só não tenho instalado em meu micro na versão XE8 pois não consegui tempo para instalar ainda mas em todas elas funcionando e com o ACBrInstall!!! veja existem até facilitadores e que mostram com exatidão o erro que pode vir a ocorrer devido a arquivos perdidos no micro ou instalações antigas falta de gerenciadores de relatórios mas sem instalar é a primeira vez! Mas uma coisa sobre a evolução!! se alguém perceber não existem pacotes diferentes pra instalar o ACBr em diferentes versões mas um único diferentemente de componentes pagos profissionais que tem um pacote para cada versão do delphi

Você está equivocado.. o ACBr é compatível com todas as versões do Delphi 7 ao XE8, além do Lazarus/FPC. Problemas pontuais, ocorrem de dependências externas, como no caso citado do post original, onde é citado que o problema são nos geradores de relatórios... Além do mais... o projeto ACBr é código aberto... Se algo não funciona para você... porque você mesmo não tenta corrigir e contribuir com a comunidade, ao invés de simplesmente ficar aguardando que alguém corrija para você ?

Boa tarde Michel, A NFC-e nada mais é uma NF-e com uma pequena alteração, em vez do código do modelo ser 55 é 65. Resumindo: NF-e => Modelo = 55 NFC-e => Modelo = 65 Sendo assim o XML são exatamente iguais e em ambos os casos o XML é considerado documento fiscal válido juridicamente se o mesmo for assinado com um certificado digital tipo A1 ou A3 (cartão ou token) mais o protocolo de autorização retornado pela SEFAZ-Autorizadora do Emitente da nota. Atenção o token que eu fiz referencia acima se refere ao certificado digital tipo A3 vendido em formato pen-drive (token). O DANFE da NF-e é impresso em papel A4, por outro lado o DANFE da NFC-e é impresso em bobina - impressora não fiscal. O DANFE da NF-e possui um código de barras que representa a chave de 44 dígitos. Por outro lado o DANFE da NFC-e não possui esse código de barras e sim um outro tipo de imagem chamado QR-Code. O QR-Code impresso no DANFE da NFC-e não representa a chave e sim uma URL (um endereço de internet) que nos retorna na tela do computador ou celular o DANFE completo da NFC-e. A URL do QR-Code é composta por uma dezena de informações, sendo que uma delas é o CSC - Codigo de Segurança do Contribuinte que no componente é chamado de Token. Por que no componente esta Token em vez de CSC, só para confundir os desenvolvedores, não. Nas primeiras documentações referentes ao QR-Code do DANFE da NFC-e o termo usado era Token, mas agora a documentação mais recente já faz referencia a CSC em vez de Token. Inclusive em breve será disponibilizado a todos os usuários do ACBr uma nova versão dos componentes e uma das alterações é justamente a palavra Token que foi substituída por CSC. Portanto se você ler algo sobre Token relacionado a QR-Code não se trata do certificado e sim o CSC que nada mais é do que um código alfa numérico. Espero ter ajudado.

No que diz respeito aos schemas, arquivos XSD são os mesmos para ambos os modelos de documentos. Agora com relação aos arquivos XML, você pode ou melhor deve separar.

Bom dia a todos, Um esclarecimento sobre a sua postagem Rubens. 1. No inicio, ou seja, no projeto piloto da NFC-e a SEFAZ chamava esse código de segurança de Token, depois resolveram mudar o nome para CSC - Código de Segurança do Contribuinte, pois algumas empresas e desenvolvedores do projeto estavam confundindo com o certificado digital no formado Token, portanto o que foi alterado é apenas o nome dado ao código. 2. Para emitir uma NFC-e, ou seja, gerar o XML, assinar, validar, enviar para SEFAZ, etc. não há necessidade do CSC, uma vez que esse código não esta presente no XML, não é utilizado para realizar a assinatura, logo se o XML for válido pela SEFAZ, será retornado o protocolo de autorização. 3. O CSC só é utilizado para compor a URL usada para gerar o QR-Code, que por sua vez é impresso no DANFE, se o consumidor não possui um leitor de QR-Code, ele pode se utilizar da chave para consultar a nota na SEFAZ. Ao ler o QR-Code que contem um CSC de homologação a SEFAZ vai buscar a nota no ambiente de homologação, como a nota foi emitida no ambiente de produção, será retornado a mensagem de que a nota não existe. Espero ter ajudado.

Jorge, utilize Daruma, nunca me deu dor de cabeça e sempre que necessário dão suporte 100% para nós do ACBr compatibilizarmos e também para os desenvolvedores.

Junior Bindaco, você já está conseguindo uitlizar o provedor EL?

Bom dia, Ninguém ainda despertou interesse sobre o Provedor EL ?