Régys Silveira

Estou verificando com o departamento financeiro.

Segue em anexo a tabela de requisitos por estados, para quem não sabe agora na nova ER alguns requisitos são cobrados ou aceitos por UF, ou seja, os testes são feitos para cada UF conforme o que foi acordado no ato cotepe. Perfil de Requisitos.pdf

Disponibilizei o pacote para instalação do ACBrLFD, já foi testado em delphi 2010 e XE3 e está instalando normalmente, basta atualizar o repositório e utilizar o arquivo "<acbr>\pacotes\ACBr_LFD.dpk"

Disponibilize aqui no fórum, assim os colegas testam e podemos subir quando estiver ok, basta anexar ao post.

Cupom não fiscal necessita de ter um item não fiscal cadastrado na impressora, e ele não vai permitir enviar texto livre, se você falava de um relatório gerencial, se imprimir ele após o cupom fiscal a impressora vai bloquear o cancelamento, já que o ultimo documento emitido não é um cupom fiscal e sim um relatório gerencial, impressoras fiscais cancelam somente o ultimo cupom fiscal emitido se não foi impresso nada após ele.

O CDC deve ser usado unica e exclusivamente para a impressão do comprovante de credito e debito para vendas com cartão, nenhuma outra situação é permitido o uso, mesmo fora do paf-ecf.

Veja a ER 2.01 só vai ter validade a partir de 1 de junho, aguarde que os componentes serão adaptados para ela em tempo.

Por nada, Basta clicar no botão Resolvido do post que lhe ajudou.

Mas veja, tanto a NF-e quanto o NFC-e tem os XMLs assinados e os DANFEs nada mais são do que documentos de transitação não possuindo nenhum efeito fiscal, se você alterar o XML a assinatura não mais baterá e o arquivo não será considerado válido, fora que existem meios para checar a autenticidade dos arquivos nos webservices tanto da NF-e quanto para o publico que utilizar a NFC-e. Você está se focando no DANFE, o DANFE nunca teve ou terá validade fiscal.

Fiquei de fazer o .dpk para ele, estou demorando um pouco porque estou migrando meus apps para XE3 dai não sobrou muito tempo para fazer o .dpk, vou ver se consigo liberar ainda hoje.

Por favor façam uma pesquisa antes de abrir tópicos com perguntas que já existem, como o Isaque disse o ACBr já está preparado a um bom tempo, pesquisem e vão encontrar o que procuram.

Paulinho, não precisa, basta colocar o cancelamento das Pre-Vendas no evento OnDepoisReducaoZ do ACBrECF, ai você trata, se data movimento igual a data atual, cancela data - 1, se data movimento < data atual ou diferente data -2, simples assim.

Só para ficar claro para quem for ler o Post no futuro. O Paf-ECF nunca obrigou a remologar quando se faz alteração no sistema, e sim, quando vence o laudo, você pode fazer qualquer alteração que quiser, desde que informe o novo MD5 aos SEFAZ dos estados onde o software é utilizado fazendo a atualização. Quanto a homologar, se você trabalha com TEF mesmo usando o NFC-e vai continuar tendo que homologar o TEF, e agora a obrigação é anual, diferente do Paf-ECF que a obrigação é de 2 em 2 anos.

Eu enviei uma correção mais cedo para isso, bastaria atualizar o repositório e recompilar.

Já existem tópicos tratando desse assunto, por favor use a pesquisa.

Os arquivos já foram disponibilizados no SVN, basta atualizar o ACBr, só não tem o pacote ainda como o colega disse anteriormente, mas já estou providenciando.

Sua pergunta ou afirmação ficaram bem confusas, se entendi direito você diz que não existe o pacote para instalação do componente, realmente, verifiquei aqui é foi feito pacote somente para lazarus, vou enviar o pacote de instalação para delphi agora a tarde.

A principal diferença entre as duas homologações é que para o simples nacional não serão cobrados alguns requisitos, na verdade são vários requisitos, penso que isso vai ajudar muita gente que trabalha somente com pequenos comércios, os que trabalham com grandes comércios continua praticamente a mesma coisa. Outra mudança legal é que agora não poderá haver mudança na ER pelo prazo de 1 ano a não ser para corrigir erros.

Não sei se entendi bem sua dúvida, mas o certificado é usado para assinar os arquivos, não é somente uma questão de gravar os dados em algum lugar para usar depois, o certificado A1 com certeza pode ser copiado porque é um arquivo comum, mas ao exportar o certificado será criada uma senha pelo usuário e você precisará dela, já o A3 é impossível copiar ele como um arquivo normal, porque ele roda como o Igor disse direto do token ou cartão, o A3 é mais seguro justamente por conta dessa funcionalidade. Se o seu problema é ter o certificado centralizado, pode fazer um app para assinar arquivos ou mesmo usar um método na camada do servidor para isso assim você tem o certificado em centralizado nesse servidor, se o seu aplicativo for 3 camadas é bem simples de fazer inclusive.

Pode ser que você tenha algum arquivo .dcu compilado com versão antiga e ainda sendo utilizado, verifique isso.

Para os testes que requerem o cancelamento de pre-venda você pode ou não finalizar o cupom, tanto faz, desde que grave os dados para o arquivo de movimento corretamente. Uma coisa muito comum é o programador não gravar o R07 nessa situação mesmo fechando o cupom com alguma forma de pagamento ou o contrário, gravar o R07 e não fechar em nenhuma forma de pagamento. Para não ter erro use os eventos do ACBrECF "OnDepois..." Seguir a dica do cleber é legal, porque ai você sempre tem o cupom fechado e sem erro, mas não é obrigatório.

É minha opinião particular, eu gostei muito do modem Daruma, robusto e de funcionamento e instalação simples. Quanto a operadora, vai depender do plano, eu já testei em planos empresariais e funcionou muito bom com a vivo e OI, Tim sempre tem problema e Claro não tenho nenhum cliente.

Poderia fazer um documento PDF com as imagens e legenda e posta aqui? Acho que fica mais simples para quem for utilizar no dia-a-dia.

Está funcionando, inclusive alguns colegas já homologaram com ele.

Não consegui reproduzir o erro, poderia dar mais informações, talvez um trecho de código para ajudar a entendermos melhor seu problema.