Italo Giurizzato Junior

Boa tarde Alessandro, Sim, você deve atualizar os schemas. Dentro da pasta ...\Exemplos\ACBrDFe\Schemas\NFe temos todos eles atualizados.

Rafael, Esse XML foi gerado pelo ACBr? Se sim porque os valores dos atributos estão entre pipe em vez de aspas?

Boa tarde Alessandro, Acredito que seria interessante antes de realizar o envio, salvar no banco o XML gerado, assinado e validado, assim você não ocorre esse risco de nem sequer ter o XML da venda, você não acha? E ao receber o protocolo de autorização salvar em um outro campo o XML completo, ou seja, assinado e com o protocolo de autorização.

Boa tarde Adailson, No meu entendimento uma coisa não tem nada haver com outra, mas procure um bom contador para se ter a certeza.

Boa tarde Rafael, Se você utiliza o componente ACBrCTe lembre-se que existe uma propriedade CTeCancelado no DACTE e que devemos atribuir o valor True para que a tarja seja impressa.

Boa tarde Alexandre, Acho que você se refere a TAG vProd, correto? Se sim, me diga qual é a informação referente ao tamanho desse TAG ( campo #110 ) página 54 da Nota Técnica 2013/005 versão 1.22 ?

Boa tarde João, Verifica se não existe nenhuma DCU perdida no HD cujo Delphi tem acesso.

Boa tarde Rene, No Trunk o componente colocava o encode no inicio do cabeçalho e mensagem de dados. Por outro lado no Trunk2 o componente não coloca. Mas isso é fácil de se resolver, veja: 1. Abra o arquivo Abaco.INI que esta dentro da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI 2. Procure pela seção [ConsNFSeRps] altere o valor das duas primeiras propriedades de Zero para Um [ConsNFSeRps] IncluiEncodingCab=0 IncluiEncodingDados=0 mude para: [ConsNFSeRps] IncluiEncodingCab=1 IncluiEncodingDados=1 Eu acredito que a mensagem de erro que o provedor esta retornando esta errada. Por favor faça esse teste e nos de um retorno.

Boa tarde Werner, Em vez de gerar, assinar e salvar e depois carregar e enviar, porque não realizar o processo de uma vez? 1. Alimenta o componente com os dados da venda; 2. Execute o método Enviar (internamente ele gera o xml, assina, valida e salva em disco). Use o método Consultar apenas caso ocorra algum erro e o XML fica sem o protocolo, ai sim você carrega o XML usando o LoadFromFile, mas atribua o valor False ao segundo parâmetro desse método para que o mesmo não recrie o XML.

Bom dia a todos, Se não estiver usando o ACBrInstall_Trunk2, será necessário recompilar o pacote PCNComum.

Bom dia Clederson, Se eu entendi direito, você tem clientes que possui mais de uma maquina que emite as notas, e estas ficam salvas nas maquinas que as emitem. Neste caso, em vez de salva na maquina local, porque não salvar no servidor? Ou pode até salvar na maquina local e salvar no banco de dados.

Bom dia Antonio, Todos os provedores implementados no ACBrNFSe, nenhum deles que seguem o padrão ABRASF possui um web service para consultar o CNPJ. Sendo assim, proponho que você foque no que mais interessa, ou seja, no envio, consulta e cancelamento das notas de serviço.

Bom dia a todos, Queiram me desculpar mas ainda não vi nenhuma vantagem em criar essas propriedades no componente. Resolvi esse problema de uma outra forma. Na minha aplicação tenho uma tabela no banco de dados de parametrização ( algo semelhante a do programa exemplo ) inclui nessa tabela um campo para informar o CPF/CNPJ do Contador. Ao alimentar o componente com os dados pertinentes a venda verifico se esse campo não esta vazio, caso afirmativo o seu conteúdo é ADD em autXML. Esta semana fiz algo parecido com a NFS-e, ou seja, incluir 6 propriedades novas no componente referentes ao Emitente da nota, mas isso fez com que o código fonte de uma das Units do componente fosse reduzido em 17 Kbytes. No meu entendimento, neste caso a implementação foi vantajosa.

Bom dia Leandro, Porque você não coloca os componentes em um DataModule? Em vez de ficar criando e destruindo toda hora que vai utilizar.

Bom dia Juliomar, Em MG as empresas são obrigadas a informar a data e hora de saída na NF-e. Se não informar a SEFAZ-MG até autoriza a nota mas depois tem que entrar no site (se não me falha a memória) e informar. Dimas, se a mercadoria ainda não saiu da loja e se esta dentro do prazo, você deve cancelar a nota e fazer outra. Verifique a possibilidade de fazer uma CC-e.

Bom dia Marciano, Suponha que uma empresa contribuinte de ICMS ( industria de implemento agriculta por exemplo ) venha comprar uma mesa de escritório para repor outra que quebrou ou um fogão para fazer café para os seus funcionários. Você concorda que, podemos considera-la como sendo um consumidor final? Uma vez que ela não vai usar esses produtos como matéria prima em sua produção e muito menos revender.

Bom dia, Essa mensagem é disparada quando o componente, não encontra o Schema desejado dentro da pasta indicada por PathSchema, motivos: 1. O arquivo realmente não existe dentro da pasta; 2. O nome do arquivo é outro; 3. O componente esta configurado de forma errada (ModeloDF e VersaoDF). Procure ter uma unica rotina de configuração do componente ( inclua em um DataModule por exemplo ) e toda vez que for usar o componente chamar sempre a mesma rotina. Quem costuma ter varias rotinas de configuração corre o risco de uma delas esta com o Modelo e Versão correta e na outra não, provocando esse tipo de erro.

Bom dia João, Após atualizar os fontes, você compilou a aplicação com a opção Build?

Bom dia Rene, Você deve estar fazendo confusão, mesmo na versão do antiga (Trunk) o método ConsultarNFSeporRps nunca teve um parâmetro para informar o numero do protocolo. Os únicos métodos que possuem é ConsultarSituacao e ConsultarLoteRps. Veja: function ConsultarSituacao(AProtocolo: String; const ANumLote: String = ''): Boolean; function ConsultarLoteRps(ANumLote, AProtocolo: String): Boolean; function ConsultarNFSeporRps(ANumero, ASerie, ATipo: String): Boolean; A unica diferença que notei em relação aos dois arquivos que você postou é que o 7170 possui o encoding tanto no cabeçalho quanto na mensagem de dados, já no 7190 não tem. Em qual deles esta ocorrendo o problema?

Bom dia Werner, Vários desenvolvedores tem o costume de gerar o XML, assina e salvar em disco. Depois carrega usando o LoadFromFile para poder enviar. O método LoadFromFile possui um parâmetro que por padrão gera novamente o XML, esse processo pode acabar removendo algum carácter ou trocar por outro, causando uma diferença no DigestValue. Um carácter que costuma dar problema é o "&" (e comercial) incluído muitas vezes no nome de empresas.

Daniel, Contribuição enviada para o repositório. Obrigado Alexandre.

Boa tarde Rene, Foram incluída uma meia duzia de propriedades novas de configuração, se elas não forem preenchidas vai com certeza ocorrer erros. São elas: ACBrNFSe1.Configuracoes.Geral.Emitente.CNPJ := sCNPJ; ACBrNFSe1.Configuracoes.Geral.Emitente.InscMun := sIM; ACBrNFSe1.Configuracoes.Geral.Emitente.RazSocial := sRazao; ACBrNFSe1.Configuracoes.Geral.Emitente.WebUser := sUsuario; ACBrNFSe1.Configuracoes.Geral.Emitente.WebSenha := sSenha; ACBrNFSe1.Configuracoes.Geral.Emitente.WebFraseSecr := sFrase;

Boa tarde Werner, Esse problema é comum quando se faz alteração em um XML assinado.

Boa tarde Cleiver, Favor atualizar os fontes, foram feitas diversas alterações, quem sabe o problema tenha sido resolvido.

Boa tarde Daniel, Eu já acompanho esse caso a algum tempo. O problema é que o XML da NF-e em questão não é gerado pelo ACBr e sim por uma outra solução e os caras fizeram uma lambança no XML note que os conteúdos dos atributos da TAG nfeProc são delimitados com apostrofes e o resto com aspas e isso faz com que o componente se perca. Se tivessem feito da forma correta ou seja sempre usar aspas a leitura ocorreria sem nenhum problema. Dai podemos ver a qualidade das demais soluções.