mcnonino

Se eu entendi direito a desativação da NFe 3.10, pelo menos para o modelo 65 (NFCe) ficou para 01/10/2018?

O layout da Danfe NFCe prevê sim a inclusão do valor do frete. Verifique na página 15 do "manual de padrões técnicos do DANFE NFCe e QR Code" na versão 4.1 que tem um exemplo lá.

Apenas para colaborar com o assunto, vou expor o que aconteceu conosco. Temos alguns clientes usando o sat Sweda a algum tempo, todos funcionando corretamente. A cerca de 1 mês instalamos em um primeiro cliente o sat Elgin. Foram instalados 2 sats Elgin em 2 computadores (novos) distintos. Desde então, este mesmo problema do sat não retornar o XML da venda começou a ocorrer esporadicamente em apenas 1 dos computadores. Passada 1 semana, invertemos os sats entre os computadores, numa tentativa de identificar se o problema era no sat. O que aconteceu é que o problema continuou no mesmo computador, mesmo com um sat diferente, o que dá para concluir que o problema não era no aparelho em si. Depois disso foi feita a substituição do computador por um outro. Isto já tem cerca de 1 semana e estamos monitorando para ver se resolveu. Não sabia dessa possibilidade de ativar o Log da DLL da Elgin. Se voltar a acontecer o erro vou ativar esta opção.

Daniel, apenas para confirmar se eu entendi corretamente a alteração. 1) tzSistema: O componente pegará o fuso horário do windows (que era o padrão do Trunk2); 2) tzPCN: O componente calculará automaticamente o fuso horário (que era o padrão do Trunk1); 3) tzManual: O componente pegará o fuso horário indicado em TimeZoneStr; 4) O default será tzSistema; 5) Aqui uma dúvida: como preencher o TimeZoneStr? (Ex.: "-3", "-0300" ou "-03:00") E muito obrigado pela alteração. Vai ajudar muito.

Sim, eu sei. Na verdade essa era a maneira que estava implementado no trunk1, correto? Os ECFS não mudam automaticamente, mas existem comandos que podem ser enviados pelo programa para que a impressora fiscal entre ou saia do horário de verão. Se fosse possível informar o "TimeZone" para o componente, este controle de entrar ou sair do horário de verão poderia ser feito pelo programa e não dependeria da configuração do Windows.

Estou totalmente de acordo com a possibilidade de se criar uma maneira de informar o fuso horário para o componente ACBr, sem depender apenas do Windows. Tivemos alguns casos nesse fim de semana em que os computadores (principalmente Windows XP) saíram do horário de verão no domingo e daí passou a dar erro na transmissão da nota. A solução foi atrasar o horário desses computadores em 1 hora, o que fez com que esses computadores ficassem em um horário diferente do correto. Se houvesse uma maneira de informar o fuso pelo componente passaria a ser possível implementar uma lógica de entrada/saída de horário de verão diretamente no sistema, assim como acontece com as impressoras fiscais.

Apenas como feed back para quem está passando por um problema semelhante, eu atualizei o arquivo satdll.dll para a versão mais recente (2.0.1.4) disponível no site da Sweda e o problema foi solucionado.

Aqui também de vez em quando está dando o erro de "acess violation" no cancelamento do Sat utilizando o aparelho da Sweda. Estou investigando o problema e se descobrir algo eu posto aqui.

Rodrigo O Paraná ainda não implementou essa alteração.

Acho que o Juliomar interpretou errado o que estamos discutindo. O que o Dércio e eu estamos alertando é o fato de que no dia 03/11 todos os softwares que rodam NFCe podem parar de funcionar, e isso não tem nada a ver com o ACBr, mas sim com o fato de que não haverá um período de transição para se mudar da especificação antiga para a nova, o que na minha opinião é uma falha grave do Encat, que é o órgão responsável por propor as mudanças no projeto de NFe.

Dércio Eu também citei esta questão em um outro post mas infelizmente "atravessaram" a pergunta e o post acabou indo para um outro caminho. Na minha opinião e interpretação, a informação do qrCode deveria ser opcional, afinal pela especificação a ocorrência do grupo "infNFeSupl "é de 0-1, mas o colega Italo tem outra interpretação, o que indica que o assunto pode gerar dupla interpretação. Eu gostei da sua sugestão, mas aqui no Paraná estamos com um problema adicional: a nota técnica 2015.002 não foi implementada ainda para homologação, pelo menos no que se refere a este campo novo campo "qrCode", ou seja, não temos como testar. E se ela não foi implementada ainda, quem garante que no dia 03/11/2015 vai estar funcionando para produção?

Italo, Obrigado por responder. Você deve até estar correto, mas que no mínimo o texto dá margem a dupla interpretação, isto dá. Se você verificar a regra de validação ZX01-10, lá diz "Rejeição: NF-e com o grupo de Informações Suplementares". E a regra de validação ZX01-20 diz "Rejeição: Nota Fiscal sem a informação do QR-Code ", o que está correto pois o campo é obrigatório desde que o grupo Informações Suplementares exista. Mas se ele não existir, não deveria dar erro. Veja o caso do grupo "Formas de Pagamento (YA01)" que é similar a este, e que tem um texto bem mais claro: YA01-10 NF-e não deve possuir o grupo de Formas de Pagamento (tag:pag) Obrig. 768 Rej. Rejeição: NF-e não deve possuir o grupo de Formas de Pagamento; YA01-20 NFC-e deve possuir o grupo de Formas de Pagamento (tag:pag) Facult. 769 Rej. Rejeição: A critério da UF NFC-e deve possuir o grupo de Formas de Pagamento Na verdade estou levantando a discussão aqui porque se for mesmo obrigatório o campo "qrCode", seremos obrigados a atualizar todos os clientes em um único dia (03/11). Imagine uma software house que possui centenas de softwares rodando...Vai ficar totalmente inviável. Mauricio

Estou estudando as alterações da nota técnica 2015.002, e me deparei com o seguinte erro: "Rejeição: Nota Fiscal sem a informação do QR-Code ". No texto da nota técnica está escrito: "Incluído no leiaute da Nota Fiscal, um grupo opcional de Informações Suplementares, contendo um texto que representa o conteúdo do QR-Code impresso no DANFE - NFC-e. Veja que este grupo de informações está no mesmo nível do grupo “infNFe”, não afetando portanto a assinatura digital da Nota Fiscal. " Pela minha interpretação, o grupo "Informações Suplementares" que contém o campo "qrCode" é opcional. No entanto, segundo relatos de pessoas aqui do forum, se este grupo não for informado, está retornando o erro. Pergunto: seria a minha interpretação que está errada ou seria um erro de implementação do Sefaz? Mauricio

Daniel Minha aplicação estava dando uma mensagem de "Memory Leak". Corrigi fazendo a seguinte alteração na unit pcnCFe: destructor TDetCollectionItem.Destroy; begin //as 2 linhas abaixo não existem e foram acrescentadas FProd.Free; FImposto.Free; inherited; end; Seria interessante corrigir nos fontes do projeto. Obrigado, Mauricio

Daniel Acho que encontrei um pequeno "bug" na classe TCOFINS da unit pcnCFe. Trata-se da propriedade vBCProd. Pelo que eu pesquisei esta tag não existe na especificação do XML do CFe. Penso que seria interessante removê-la. Mauricio

O problema é que você está adicionado uma nova nota fiscal cada vez que você usa o Add, conforme visto no trecho de código acima. Você precisa atribuir os dados do emitente sem o comando Add.

Isaque Pinheiro Acredito que você está se baseando no que seria mais lógico, e concordo com você. Mas é sempre bom consultar a legislação específica de cada estado. Aqui no Paraná, por mais incrível que possa parecer, eles pedem para alimentar os registros do tipo 61 quando se tratar de NFCe.

Você não pode passar para o gerenciador TEF o valor de R$ 25,00. Você deve passar o valor de R$ 20,00, que é o valor original da venda. Então neste teste específico, no retorno da resposta do gerenciador TEF é que você vai identificar que houve uma alteração de valor, no caso um saque de R$ 5,00. Ao tratar este retorno, você precisará então mudar o valor original da sua forma de pagamento de R$ 20,00 para R$ 25,00 e enviar esse valor para a impressora fiscal, para que a mesma possa imprimir os R$ 5,00 de troco. Fazendo dessa forma o gerenciador mandará o texto a ser impresso com o: Valor Total (Final) R$ 25,00 Valor Original R$ 20,00 Troco (Saque) R$ 5,00 Espero ter ajudado.

Você vai precisar mudar a lógica do seu sistema para poder implementar o troco e o desconto. Em primeiro lugar você não poderá mais sub-totalizar o cupom antes de chamar as formas de pagamento. Você precisará também "bufferizar" cada uma das formas de pagamento, enviando as formas de pagamento para a impressora somente depois de o usuário ter escolhido as mesmas. Em relação ao "Saque", você precisa ler o arquivo de retorno do TEF e, caso o mesmo tenha ocorrido, você precisa mudar o valor da forma de pagamento originalmente informada. Exemplo: o valor do cupom foi de R$ 10,00. O usuário seleciona receber R$ 10,00 em cartão. Você chama o módulo TEF e caso o operador selecione um saque de R$ 5,00, você precisa mudar a sua forma de pagamento para R$ 15,00 e enviar esse valor para a impressora que se encarregará de dar o troco automaticamente no valor correto. Em relação ao "Desconto", você precisa ler essas informação também do arquivo de retorno do TEF, e caso o mesmo tenha ocorrido, você precisa sub-totalizar o seu cupom já levando em conta esse desconto e também alterar o valor original informado para a forma de pagamento selecionada de maneira a refletir o valor desse desconto. Espero ter ajudado.

No meu entendimento funciona da seguinte forma: Se você está vendendo o produto "Feijoada", este produto vai ficando com estoque negativo conforme você vai vendendo, uma vez que você não compra "Feijoada" de um fornecedor. Portanto você precisa gerar todo dia uma nota fiscal de entrada do produto "Feijoada" para zerar este estoque negativo. Por outro lado, você comprou insumos para fazer esta feijoada. Como estes insumos não são vendidos diretamente, você precisa fazer uma outra nota fiscal, desta vez de saída, para dar a baixa no estoque desses insumos. No entanto eu aconselho você a entrar em contato com a homologadora para ver se eles possuem o mesmo entendimento.

Quando você for fazer o registro do seu software PAF-ECF nas secretarias de fazendas de cada um dos estados, você terá que incluir a informação do MD5 do software que foi homologado. Desta forma eles tem como saber de que se trata de um software homologado ou não.

Roney Melo Acredito que o problema seja o seguinte: você está usando uma impressora Epson, e se você observar o texto que é retornado para ser impresso no cupom TEF, você vai ver logo após a linha de impressão do comprovante TEF que é: VLR SAQUE:20,00 teria que imprimir: <ARQC:> --> 8D163FBD66378F16 Observe que em <ARQC:> o texto está dentro dos sinais de menor e maior <>. Na impressora Epson, todo texto que vem dentro de <> é interpretado pela impressora como uma formatação. Por exemplo <AN>Teste de negrito<DN> fará com que seja impresso o texto em negrito. Como a impressora não entende que formatação usar para <ARQC:>, ela retorna um erro. A única solução que vejo seria você alterar o texto <ARQC:> para (ARQC:), ou seja trocar os sinais de maior e menor pelo parênteses, isto antes de imprimir o cupom TEF, para evitar o erro. O único problema é que o TEF proibe a alteração de qualquer caracter na impresão. Mas infelizmente não vejo outra solução que não seja essa para o seu caso. Mauricio

Régys Silveira Na verdade não. Se eu faço uma venda de R$ 2,00 e passo em cartão com R$ 1,00 e mais um cartão com R$ 1,00 a impressora imprime corretamente em 2 vinculados sem nenhum problema. Talvez o problema seja, como o Daniel Simões comentou, em impressoras mais antigas. Mas até onde eu sei, funciona também na MP-2100, pois já homologuei usando essa impressora também Mauricio

Juliomar Abaixo o cupom fiscal: O primeiro vinculado: O segundo vinculado: O terceiro e último vinculado: Quanto ao código, como mencionado anteriormente, eu não uso o ACBR, mas sim a DLL da Bematech. A chamada para abrir o vinculado seria algo do tipo: //primeiro vinculado: Bematech_FI_AbreComprovanteNaoFiscalVinculado(pchar('TEF'),pchar('00000000000050'),pchar('000864')); //segundo vinculado: Bematech_FI_AbreComprovanteNaoFiscalVinculado(pchar('TEF'),pchar('00000000000030'),pchar('000864')); //terceiro vinculado: Bematech_FI_AbreComprovanteNaoFiscalVinculado(pchar('TEF'),pchar('00000000000020'),pchar('000864')); Grato, Mauricio

Olá Daniel, tudo bem? Eu frequento o forum já a algum tempo, sempre com o objetivo de ficar atualizado sobre questões de automação comercial. Lendo seu comentário abaixo, surgiu uma dúvida: Já não é a primeira vez que vejo a afirmação acima mencionada aqui no forum. Você tem certeza dessa informação? Pergunto isso pois já homologuei TEF várias vezes com Bematech e sempre abri 2 ou mais vinculados para uma mesma forma de pagamento e nunca tive problemas. Eu não uso o ACBR para comunicação com impressora fiscal, e sim a própria DLL da Bematech. Pelo menos na DLL, nunca tive esse tipo de restrição. Grato pela atenção, Mauricio