BigWings

Segundo a Sefaz-RO a desativação vai ocorrer em 01/10/2015. http://www.portal.sefin.ro.gov.br/site/conteudo.action?id=3785 Os endereços novos já estão no trunk há algum tempo.

Alguém pode confirmar se essa impressora funciona com o protocolo da Epson?

Veja se não está passando o IdToken / IdCSC errado. Alterei a URL para o Id padrão (000001) e retornou a NFCe. http://www.dfeportal.fazenda.pr.gov.br/dfe-portal/rest/servico/consultaNFCe?chNFe=41150710830634000125650010000000161000000165&nVersao=100&tpAmb=2&cDest=87753359134&dhEmi=323031352d30372d32325431363a35363a30342d30333a3030&vNF=19.98&vICMS=0.00&digVal=4c6d39773445386f634e6561536e2b577869626b374a725a772b593d&cIdToken=000001&cHashQRCode=F947676E73B581FF2555BCC0B33B92B1249DEC77

Não faço boletos sem vencimento, por isso não levei isso em consideração. De fato a alteração que fiz ficou incompatível com a versão anterior, para datas de vencimento anteriores a 07/10/1997, onde apareceria 0000 (sem vencimento). No manual que anexei consta o seguinte: Entretanto, já no parágrafo seguinte: Não compreendi bem a diferença entre boletos sem vencimento, e os contra-apresentação... De qualquer forma, estou anexando a unit para manter compatibilidade com o código anterior. ACBrBoleto.pas

A última vez que liguei no suporte da Elgin me informaram que não era possível a impressão direta nessa impressora, apenas via spooler do Windows.

O DANFE em FastReport não mostra tarja de cancelamento, apenas no campo de protocolo aparece a literal "PROTOCOLO DE HOMOLOGAÇÃO DO CANCELAMENTO". Para que apareça a tarja você tem que editar o DANFE.fr3.

Bom dia a todos. O fator de vencimento, da maneira que é calculado no ACBrBoleto, gera um valor errado com datas de vencimento superiores a 21/02/2025, que é quando ele chegará a 9999. Um novo algoritmo para vencimentos a partir de 22/02/2025 foi disponibilizada aqui: http://www.abbc.org.br/images/content/manual%20operacional.pdf Já implementei no meu código a alteração, segue anexo. ACBrBoleto.pas

Obrigado pelas respostas, e pela fundamentação que já posso usar para justificar o procedimento. Fiquei na dúvida se poderia gerar novo XML porque, como o leandroaoa disse, o QR-Code contém vários elementos, inclusive o digestValue do XML, este que seria alterado gerando novo XML com alteração nos dados, o que imaginei que tornaria a primeira nota inválida. Farei o teste na próxima oportunidade e a consulta dos dois QR-Codes pra confirmar. Obrigado mais uma vez.

.

Banco da Amazônia é de meu interesse e posso implementar. Mas tenho aqui apenas o layout para cobrança não registrada. Você vai trabalhar com registrada ou não registrada?

Desconsiderem o teste que fiz, ainda estou com as URLs antigas da SVRS, e testei com o componente setado para NF-e, e não NFC-e. Depois que olhei no código do ACBr, vi que ele fazia distinção para obtenção da URL para cada modelo, se eu mudo para NFC-e, nas URLs antigas, recebo mensagem "URL não disponível para esta UF", ou algo assim.

Já aconteceu comigo e descobri que o problema era na tag indFinal, que quando setada como cfConsumidorFinal, aceita CPF ou CNPJ em branco. Desde então apenas na NFC-e coloco essa tag como cfConsumidorFinal, para NF-e deixo cfNao.

Não, usei meu próprio certificado A1.

Normal aqui: Versão Layout : 3.10 Ambiente : 1 Versão Aplicativo : SVAN_3.1.0 Status Código : 107 Status Descrição : Servico em Operacao UF : PA Recebimento : 06/05/2015 12:23:14 Tempo Médio : 1 Retorno : Observação : Agora, se mudar a propriedade Configuracoes.Geral.FormaEmissao para teSVCRS: Versão Layout : 3.10 Ambiente : 1 Versão Aplicativo : SVRS201411141702 Status Código : 114 Status Descrição : Rejeicao: SVC-RS desabilitada pela SEFAZ de Origem UF : PA Recebimento : 06/05/2015 12:23:14 Tempo Médio : 1 Retorno : Observação :

O Webservice rejeita automaticamente a emissão de NFC-e para contribuinte do ICMS. Então mesmo para empresas locais que vão creditar o imposto, é preciso emitir uma NF-e no lugar.

Tive um caso onde uma NFC-e foi emitida em contingência off-line e, ao tentar autorizar a mesma depois ela foi rejeitada com a mensagem "Rejeição: NFC-e para destinatario contribuinte ICMS". A nota era pra pessoa física, a tag indIEDest foi gerada com valor 1 por um erro no cadastro do consumidor. Não posso corrigir a informação, assinar e transmitir novamente porque vai alterar o QR-Code, tornando a nota entregue ao consumidor inválida. Ainda não entrei em contato com a Sefaz, queria saber se alguém aqui já teve essa experiência, e como resolveu.

Fiz este teste hoje e também tive o mesmo problema. O DANFCe parou no meio do item 202. Colocando um sleep com um buffer de 40 linhas, conforme o Alan sugeriu, resolveu o problema. Daruma DR700L é o modelo. Upd: Se eu ativar a impressão em duas linhas por item, o DANFCe imprime completo, mas enquanto imprime recebo a mensagem de time-out.

Nada a haver com serviço. A tag ICMSSN contém os campos para NF-e em regime Simples Nacional. No seu XML o CSOSN não foi informado, por isso o erro.

Tenho usado sem problema na MP-4200 TH (Não fiscal). Com a fiscal acredito que não possa usar.

Boa tarde. Eu tinha uma configuração interna no sistema que permitia alterar a versão do XML, em caso de erros com a versão mais nova. Por acaso estava selecionada a ve300. Já alterei de volta e resolveu, mas demorei um tempinho até descobrir que o erro estava sendo gerado no código do ACBr. Mas entendi que não se deve usar. Obrigado.

Ao chamar a função ACBrNFE1.NotasFiscais.Assinar no layout 3.00 ocorre o erro "'' não é um número de ponto flutuante válido", Pelo que vi o erro está na unit pcnConversa.pas, na função GetVersaoNFe, que não faz o teste se o layout é ve300.

Estou tentando enviar o comando #27 #229 para a Daruma para obter as configurações dela, entre elas o número de colunas, tabela de comandos e página de código. Consegui fazer com outros componentes de comunicação serial (VaComm), mas com o ACBr não estou sabendo fazer. Como obter o retorno da impressora depois de enviar o comando? ACBrNFeDANFeESCPOS1.Device.Porta := 'COM1'; ACBrNFeDANFeESCPOS1.Device.Ativar; try ACBrNFeDANFeESCPOS1.Device.EnviaString(#27#229); Memo1.Lines.Add(ACBrNFeDANFeESCPOS1.Device.LeString(100, 10)); finally ACBrNFeDANFeESCPOS1.Device.Desativar; end; Este código dá timeout, independente do tempo que coloco como parametro na LeString() --- Consegui: ACBrNFeDANFeESCPOS1.Device.Porta := 'COM1'; ACBrNFeDANFeESCPOS1.Device.Ativar; try ACBrNFeDANFeESCPOS1.Device.EnviaString(#27#229); Memo1.Lines.Add(ACBrNFeDANFeESCPOS1.Device.Serial.RecvPacket(100)); finally ACBrNFeDANFeESCPOS1.Device.Desativar; end;

Geralmente nessa mensagem aparece o motivo da rejeição.

Todas as propostas que fiz acima já estão no fonte que anexei. O manual estipula um tamanho mínimo do QR-Code de 25 x 25 mm. Sobre a largura do papel, estava vendo o tool da Daruma tem opção de configurar a largura, nos modelos H e M chega a 52 caracteres no tamanho normal. Talvez o ideal seja criar uma propriedade configurável pelo usuário.

Sugestões: - Trocar o nome "Inscrição Estadual" no cabeçalho para "IE", já que com inscrições com 20 digitos mais o nome completo ultrapassam a largura da Daruma. - Quebrar a linha após o texto "Consulte pela chave de acesso em" e "Procotolo de Autorização" que tem o mesmo problema e desta forma fica numa estética melhor. - Usar a largura "3" no QR-Code na Daruma, ele gera um código menor, e acima do mínimo especificado no Manual de Integração. - Criar uma variável que controle a largura do papel para cada modelo. Fiz alteração também na impressão dos itens, para deixar os campos melhor tabulados, aumentando e diminuindo o campo descrição conforme necessário. Acho que o ideal seria fazer a impressão em duas linhas para não haver truncamento excessivo na descrição. Segue a minha unit com as alterações. ACBrNFeDANFeESCPOS.pas