Painel de líderes

Enviei uma possível correção. Queira por favor atualizar, testar e reportar qualquer problema. Fiz algumas alterações, mas segui a sua ideia. Muito obrigado pela sugestão.

Bom dia, coyote. Acredito que sem o manual fica complicado identificar se comunica ou não. Porém você pode realizar os testes, usando os modelos existentes no ACBr. Geralmente a maioria das balanças usam um protocolo semelhante.

Boa tarde. Tive exatamente esse problema no início do mês com o Sat Linker II, desvincular de um CNPJ para ativar em outro. No seu log esta ocorrendo o mesmo erro que tive: Erro validando assinatura SEFAZ. Liguei no suporte da Elgin, analisaram o log e me informaram que esse erro é quando o Sat perde sua assinatura durante o processo de reset. Acabei tento que enviar o equipamento para a garantia.

Olá, Para quem utiliza o ACBrMonitorPLUS e está tendo problemas de rejeição: 938, poderá realizar a configuração descrita acima, a partir da versão 1.2.0.55. Segue abaixo a tela para configuração:

Enviei uma alteração ao SVN baseado na sugestão disponibilizada pelo Waldir. Com alguns ajustes A maior diferença é que mantive a versão 1 do modelo MGV5 para balanças muito antigas criando um novo modelo (modToledoMGV5V1). Por favor queiram atualizar, testar e reportar qualquer problema.

Veja que está enviando em homologação e não produção.

BigWings e Waldir Paim, problema resolvido, realmente era a tag pST que não estava aceitando o valor 18, coloquei 0 e transmitiu a nota depois que resolvi a outra rejeição! Muito obrigado!

A rejeição do seu XML não tem a ver com o erro de Schema citado neste tópico. Veja na validação do site SEFAZ (imagem 2) que seu XML apresenta erro de Schemas referente campo vlICMSSubstituto... Será disponibilizado hoje uma versão do Monitor com opção de gerar ou não essa tag. Para mais detalhes sobre esse problema, acompanhe o tópico:

Usei este link copiei os arquivos/pastas e deu ok no Windows 7. Para testar, fiz apenas uma consulta status do serviço e uma consulta status a uma chave NFC-e. Teria mais algum teste simples a fazer?

Segue unit alterada com simplificação da regra e correção do CST 60 que estava como obrigatório. pcnNFeW.pas

Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação, tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. Vamos a uma explicação mais longa... O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já sabia era rejeitado... Isso é praticamente um ataque de DDOS, nos servidores do SEFAZ... Quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós não sabemos como seu sistema funciona, nem conhecemos os seus clientes. Ainda mais, o ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe, o item "2.1 Código de Segurança do Responsável Técnico - CSRT" que nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

Show,,,, agora esta enviando na hora. Valeu meu caro... Boa PASCOA......

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Realmente o problema era o ambiente no momento do envio. Mais uma vez BigWings solucionando meus problemas, obrigado amigo de asas grandes!!!

Boa tarde Eduardo, Se esta ocorrendo esse erro de duplicidade com diferença de chave a explicação é simples. Ao enviar novamente o XML esta sendo gerado também novamente, mas como o valor de cNF esta com o valor zero o componente se encarrega de gerar um condigo aleatório, pois o valor de cNF faz parte da composição da chave. E por orientação da SEFAZ o valor de cNF tem que ser um numero aleatório. Caso aja a necessidade de gerar novamente o XML, é prudente que ao gerar pela primeira vez o XML o valor de cNF seja um numero aleatório e armazenado no banco de dados, desta forma ao gerar o XML novamente devemos atribuir a cNF o valor que consta no banco de dados, assim não ocorre esse erro.

Ok. Obrigado.

Dercide, consegui falar com o pessoal do RLZ, eles me passaram que adicionaram um timer para o processamento da transmissão assíncrona, isso começou essa semana por isso as notas estão dando timeout no retorno, solicitaram que fizesse a transmissão de forma Síncrona, fiz a alteração aqui utilizando EnviaSincrono() e está funcionando.

Já foi enviado uma correção para o SVN.

Desculpa, verifiquei na documentação e eu estava enviando o comando errado: o certo é usar cnc e nao cnf Comando Status Resposta Descrição vou alterar o código e verificar

Opa, boa tarde! No Demo do ACBrNFe tem o retorno da inutilização. 'tpAmb:' ACBrNFe1.WebServices.Inutilizacao.tpAmb 'verAplic:' ACBrNFe1.WebServices.Inutilizacao.verAplic 'cStat:' ACBrNFe1.WebServices.Inutilizacao.cStat 'xMotivo:' ACBrNFe1.WebServices.Inutilizacao.xMotivo 'cUF:' ACBrNFe1.WebServices.Inutilizacao.cUF 'Ano:' ACBrNFe1.WebServices.Inutilizacao.Ano 'CNPJ:' ACBrNFe1.WebServices.Inutilizacao.CNPJ 'Modelo:' ACBrNFe1.WebServices.Inutilizacao.Modelo 'Serie:' ACBrNFe1.WebServices.Inutilizacao.Serie 'NumeroInicial:' ACBrNFe1.WebServices.Inutilizacao.NumeroInicial 'NumeroFinal:' ACBrNFe1.WebServices.Inutilizacao.NumeroFinal 'dhRecbto:' ACBrNFe1.WebServices.Inutilizacao.dhRecbto 'Protocolo:' ACBrNFe1.WebServices.Inutilizacao.Protocolo Se tentar inutilizar o mesmo modelo/serie/número novamente. Terá de retorno uma rejeição com o número do protocolo da primeira inutilização.

Uma solução é gerar uma Imagem do Danfe simplificado e imprimir esta imagem. Já existem outros tópicos sobre o assunto onde eu mesmo tive participação. Verifica se impressora em questão consegue imprimir imagens JPG ou apenas PNG.

Esqueci de comentar: Caso aconteça de ter perdido o XML mas você tem as informações do DFe. É possível recurar o arquivo XML. Veja como em:

Boa tarde! Obrigado a todos, estou em teste aqui e pelo momento esta tudo ok...

@EMBarbosa ficou em ordem agora. Obrigado.

Bom dia, Mario! Que eu saiba não existe nenhuma forma legal para realizar esse download. Quem emite um documento fiscal eletrônico tem a obrigação de guardar o XML assinado e protocolado para uma eventual fiscalização do fisco. É lei! Olha o que diz o Ajuste SINIEF 07/05, na cláusula décima: Se existem programas/sites que realizam esse download, é de forma ilícita. Uma dica, armazene os XML's no banco de dados, copie para um HD externo... Qualquer coisa, mas não perca os XML's. Se algum fiscal do fisco for até a empresa e não tiver os XML's não vai dar boa...

Foi enviado a pouco tempo uma atualização! Confere se seus fontes já estão com essas atualizações de hoje.

Vejo que o XML mudou após a configuração, não está mais sendo gerada a tag vICMSSubstituto. A rejeição agora provavelmente é por causa da tag pST, tente informar ela zerada.

Bom dia, utilize uma versão mais atualizada do ACBrMonitor, sua versão é bem antiga, pode ter ocorrido alterações.

Ola Juliana bom dia, ainda não anexei porque nenhum cliente reclamou novamente do erro, estou aguardando quando der o erro ai eu anexo os xmls. Obrigado pela atenção. Luciano...

Foi criada uma nova propriedade no componente para controlar a geração das novas tags. Veja o tópico abaixo:

Bom dia Gean, Analisando o fonte referente a impressão do Extrato do SAT (feito em EscPos) notei o seguinte: 1. Para imprimir o valor referente ao desconto de um item basta alimentar o campo: vDesc do produto e a propriedade ImprimeDescAcrescItem deve estar ativa. 2. Para imprimir o valor referente ao acréscimo de um item basta alimentar o campo: vOutro do produto e a propriedade ImprimeDescAcrescItem deve estar ativa. 3. Para imprimir o valor referente ao rateio de desconto de um item basta alimentar o campo: vRatDesc do produto e a propriedade ImprimeDescAcrescItem deve estar ativa. 4. Para imprimir o valor referente ao rateio de acréscimo de um item basta alimentar o campo: vRatAcr do produto e a propriedade ImprimeDescAcrescItem deve estar ativa. 5. Para imprimir o nome do vendedor e outras informações, você pode alimentar o campo: infCpl de InfAdic (essas informações vão constar no XML). Faça um teste quem sabe é isso que você deseja.

Puxa vida =( Ok, farei isso, obrigado pela ajuda

Baixe o Lazarus em 32 bits

Mesmo problema aqui, começou dia 16 a tarde, e ontem estava muito ruim, raramente autorizava de primeira, hoje melhorou um pouco mas ainda longe de ficar bom...

Provavelmente falta a DLL citadas no Post...

Bom dia. É sempre interessante relatar também a solução. Att.

Bom dia, claudiomiguelmuller. Acredito que esses são os testes iniciais, agora basta realizar a emissão da NFC-e em homologação para testes.

Bom dia Houve melhorias de codificação na questão de unificação de códigos utilizados também por outros projetos. Vamos verificar a questão deste campo...

Existe sim, vamos adicionar a nossa lista de tarefas... mas se desejar contribuir poderá implementar essa leitura e anexar o fonte aqui que atualizamos no SVN.

O comando "Imprimir"... já deve comandar o corte de papel... então experimente remover a linha "ACBrPosPrinter1.CortarPapel" Quando a Impressora aciona equipamentos externos, como a Guilhotina e Gaveta, ela pode ficar temporariamente indisponível... portanto pode ser necessário um Sleep(200) após o comando " AbrirGaveta" Sim, a modificação parece correta... e só funciona se a DLL da Epson estiver disponível para carga (o melhor local, é na mesma pasta do seu .EXE)

Obrigado consegui resolver o problema

Boa tarde. Essa função retorna somente as posições livres para uso, as 6 primeiras são referentes ao número do convênio. Att.

Já aplicamos uma correção no ACBrMonitorPLUS, para resolver o problema em definitivo... Devemos subir uma nova versão amanhã...

Para contornar o problema até que seja ajustado, pode informar os campos da seguinte forma, assim não será gerado no xml: [Entrega] ... PaisCod=0 Pais=

Mas note no código fonte desse banco função (LerRetorno) que não é alimentados os dados do sacado no momento da leitura do retorno, Na leitura de retorno da maioria dos Bancos é lido apenas campos de identificação do Título e os dados necessário para atualização das ocorrências do Banco. Demais campos que existam no retorno, precisa ser implementado na função de leitura. O campo padrão de leitura existente em todos os Bancos é o: ACBrBoleto1.Cedente.CNPJCPF. Não é esse campo que precisa?

Bom dia o CSC e o IDCSC estão configurados de forma correta para ambiente de homologação? Normalmente quando existe divergência nesta configuração, ocorre esse erro.

Bom dia! No Zconnection, tente trocar o protocolo por ADO , deixe o librarylocation em branco e em database, coloque uma connection string, como abaixo por exemplo: Provider=SQLOLEDB.1;Password=SenhaDoSQL;Persist Security Info=True;User ID=sa;Initial Catalog=SeuBD;Data Source=NomedoServidor

Fiz mais uma atualização e consegui testar! pra mim funcionou 100%. Por favor teste essa que anexo aqui ACBrCargaBal.pas