EMBarbosa

Você precisaria montar uma aplicação "n-tier" para isso: Uma aplicação enviaria os dados para que outra aplicação fizesse a assinatura, processar e enviar o xml. Não é uma funcionalidade do ACBr que você quer. Você precisaria montar uma aplicação preparada pra isso.

Sugiro você procurar um componente que permita essa alteração. Talvez da TMS, Devart, etc... Lembro de já ter me deparado com algo parecido e era muito complicado mexer com isso na VCL.

Entendo. E como eu disse acima, misturar ICMS e ISS sempre gera confusão. Também não estou afirmando se é certo ou não agregar ou não o ICMS, mesmo porque um contador deveria te orientar nesse sentido. Estou analisando pelo xml. Note que o COFINS não é "filho" do ISS. Ele é uma tag separada. Então acredito que na totalização ele deveria entrar também.

Antes de mais nada, esses erros parecem terem sido levantados não pelo ACBrMonitor mas pelos schemas. Verifique que estejam devidamente atualizados. Além disso, poderia por favor anexar o log gerado pelo acbrMonitor? Não tenho certeza, mas pode ser que esteja considerando apenas o valor do ICMS. Afinal o valor "vNF" fica dentro da tag "ICMSTot". Misturar ISS com ICMS sempre deu uma confusão. O produto/Item 2 tem COFINS declarado no xml sim. Veja: Creio que sim. Não tenho certeza, mas pode ser que as validações por serem facultativas não estão sendo gerando rejeição.

Obrigado pelo retorno.

Então é diferente do tópico em que estava. Movi sua dúvida para um novo tópico. Quais componentes de emissão você está utilizando para Boleto? Fortes Report ou Fast Report? Usa o mesmo para a emissão de NF-e? Qual? É possível por favor detalhar um passo a passo para reproduzir o problema?

Rogério, o ACBrInstall_Trunk2.exe que você está usando deve estar desatualizado. Veja na imagem abaixo que a versão atual contem o pacote mencionado na mensagem de erro: Ele deve estar marcado.

ESC/POS é comunicação direta com a impressora. Geralmente, você configura a porta da impressora e os comandos vão pra ela. Então a menos que esteja configurado de uma forma diferente, não passa pelo spool do Windows.

É possível que seus arquivos estejam desatualizados apenas em parte. Veja: Não está assim no SVN. Na revisão 16530 foi subida a atualização para essa função alterando para: function CalcularTamMaximoNossoNumero(const Carteira : String; const NossoNumero : String = ''; const Convenio: String = ''): Integer; override;

Você está colocando 2 cópias e é impresso apenas uma?

Você verificou se há alguma informação nos logs do componente e do SAT? Tentou adicionar algum log na sua aplicação para validar o que está acontecendo?

Tente inverter a ordem, atribuiindo a ECF virtual primeiro. Depois você atribui o modelo. Algo como: ACBrECF.ECFVirtual := ACBrECFVirtualNFCe; ACBrECF.Modelo := ecfECFVirtual;

Isso é basicamente propaganda dos componentes que eles cobram pra você usar.

Você utiliza o FastMM no seu projeto? Em caso negativo, passe a utilizar.

Criamos um tópico na base de conhecimento com um pouco mais de informações que esse post acima: https://www.projetoacbr.com.br/forum/topic/49591-posso-colocar-o-acbr-como-responsável-técnico/

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.

Se você ler a nota técnica 2018.005 vai encontrar o item "2 Sobre a Identificação do Responsável Técnico" com a seguinte frase no parágrafo que explica o objetivo dessa informação (grifo é meu): Veja que a primeira frase menciona que o Responsável técnico não é simplesmente o 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 de NF-e/NFC-e. O ACBrMonitor nesse processo é apenas uma ferramenta, como se fosse um framework/biblioteca/componente que ajuda sua empresa a emitir os documentos. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é, mas também o objetivo. 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. É 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ão sabemos como seu sistema funciona, nem conhecemos os seus clientes. Ainda mais, o ACBrMonitor por si só nunca faz uso de um WebService. Ele é acionado por sua aplicação. Ela então é responsável pela emissão. Creio que não seria necessário pra você, mas só 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 a DJ System ou o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos. Dito isso, reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr.

Eles são templates do Fast Report. Como você tinha mencionado um deles, achamos que estava utilizando o Fast Report.

No arquivo DANFSEPadrao.fr3 está funcionando. '0' e '1' ele imprime SIM. '2' ele imprime Não Não achei no DANFSE.fr3 a impressão de incentivador cultural nos meus testes aqui. Talvez os arquivos fr3 precisem mesmo de uma revisão.

Joia. Que bom que resolveu. Não sei se entendi direito, mas não deveria haver diferença das respostas do método no modo Debug e Release. Se for isso que estiver acontecendo, acho que seria bom verificar um pouco mais.

Você pode fazer o mesmo com o ACBr. Se não me engano, o Git aceita um repositório SVN como fonte. Então você pode criar git-branches locais com as versões do ACBr que você quer manter. A única diferença é que se você você está utilizando os componentes em design-time na IDE, você vai precisar rodar o ACBrInstall sempre que mudar de um branches para o outro.

Se não me engano B é juros ao mês, mas lá em cima você disse que é diário veja: Qual você quer?

Infelizmente, não tem como eu saber qual está valendo e qual não. Talvez seja porque o erro é gerado antes do comando ser executado.

Como você faz o controle de diferentes versões do seu sistema?

Você deve utilizar o campo CodigoMora para informar o tipo.