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