Italo Giurizzato Junior

Boa tarde Marcelo, Teste desta forma: MyLote :=dm04.NotaComRps.FieldByName('RPS').AsInteger; MyRps :=dm04.NotaComRps.FieldByName('RPS').AsInteger; dm00.acbrNFSe.EnviarSincrono(MyLote); with dm00.acbrNFSe do begin rCodigo :=WebServices.EnviarLoteRPS.RetEnvLote.InfRec.MsgRetorno[ 0 ].Codigo; rMsg :=WebServices.EnviarLoteRPS.RetEnvLote.InfRec.MsgRetorno[ 0 ].Mensagem; rCorrecao :=WebServices.EnviarLoteRPS.RetEnvLote.InfRec.MsgRetorno[ 0 ].Correcao; end; showmessage(rCodigo+' - '+rmsg+' - '+rCorrecao);

ALA, A leitura que você se refere do XML, é através do carregamento do mesmo através do LoadFromFile?

Boa tarde Guerreiro, Já tentou aumentar o valor da propriedade Timeout?

Boa tarde, O seu fonte esta desatualizado, não consigo realizar o merge, por favor atualize todos os fontes de todas as pastas e reinstale os componentes. Depois aplique a alteração e envie novamente para mim. Desde já muito obrigado pela colaboração.

Boa tarde ALA, Se não me falha a memória o componente já lê essa informação.

Boa tarde Gabriel, Ambos os provedores seguem a versão 1 do layout da ABRASF. Mas existe uma diferença entre eles, o provedor DBSeller requer que somente o Lote seja assinado, já o provedor BHISS requer que os RPS mais o Lote sejam assinados. O que deve esta ocorrendo no momento da assinatura é que o OpenSSL + xsXmlSec não consegue assinar o Lote por encontrar outra assinatura que no caso é do RPS. E quanto ao cancelamento o provedor DBSeller não requer que o pedido de cancelamento seja assinado, já o provedor BHISS requer. Acredito que o OpenSSL + xsXmlSec não esteja encontrando corretamento o DTD.

Boa tarde ALA, Não, o ACBr não tem nada a respeito, para mim é novidade.

Boa tarde Bruno, Ou a regra escrita no manual esta errada ou a regra foi implementada errada na SEFAZ. Seria interessante verificar se em outra UF aceita o minimo de 5 notas.

Boa tarde Joceandro, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Campos, Desculpe entendi errado. Neste caso você deve renomear os schemas para resolver o problema. tiposGeralMDFe_v3.00 para tiposGeralMDFe_v3.00-Capicom tiposGeralMDFe_v3.00-OPENSSL para tiposGeralMDFe_v3.00

Boa tarde a todos, Foi realizado um Refactoring nas units pcnAuxiliar e ACBrDFeUtil visando eliminar funções em duplicidade. Segue a lista de funções removidas, movidas, renomeadas. Função movida da unit pcnAuxiliar para a ACBrDFeUtil: GerarCodigoNumerico. Função renomeada da unit pcnAuxiliar: de: ExtrairnNFChaveAcesso para ExtrairCodigoChaveAcesso essa mudança no nome se faz necessário uma vez que "nNF" induz que a função só serve para extrair o código numérico de uma chave de NF-e, sendo que na verdade serve para extrair o código numérico de uma chave de NF-e, CT-e, MDF-e e BP-e. Funções removidas da unit pcnAuxiliar: GerarChave, GerarChaveCTe, SomenteNumeros, RetornarCodigoNumerico, RetornarCodigoNumericoCTe, RetornarDigito e RetornarModelo. Em seus lugares devemos utilizar: GerarChaveAcesso (unit ACBrDFeUtil) em vez de GerarChave ou GerarChaveCTe OnlyNumber (unit ACBrUtil) em vez de SomenteNumeros ExtrairCodigoChaveAcesso (unit pcnAuxiliar) em vez de RetornarCodigoNumerico, RetornarCodigoNumericoCTe ExtrairDigitoChaveAcesso (unit pcnAuxiliar) em vez de RetornarDigito ExtrairModeloChaveAcesso (unit pcnAuxiliar) em vez de RetornarModelo Desculpe algum transtorno, mas não podemos ter uma função implementada com nomes diferentes com a mesma finalidade.

Boa tarde Jonathan, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Klerysson, Todos os fontes de todas as pastas estão atualizados? Se sim, reinstalou os componentes?

Bom dia Campos, Lendo a cartilha do MDF-e que esta disponível no Portal Nacional do MDF-e, o transportador autônomo não pode emitir o MDF-e. Quem tem permissão de emitir o MDF-e? Os emitentes de NF-e e CT-e. Veja: 1.2 - Em um transporte interestadual sem interveniência de empresa transportadora, sendo ambas as partes envolvidas na operação, remetente e destinatário, emitentes de NF-e, de quem será a obrigação de emitir o MDF-e? Regra geral, a obrigação de manifestar a carga é atribuída à pessoa que realiza o transporte. Em caso de transporte de carga própria, estará obrigado aquele que o realiza, podendo ser tanto o remetente quanto o destinatário. Por exceção, se uma das partes opta pela contratação de transportador autônomo de cargas (TAC), a obrigação será do contratante (remetente ou destinatário), desde que emitente de NF-e.

Cleber, Como assim o seu cliente tem mais de um certificado digital? Esses certificados tem CNPJ diferentes?

Boa noite Cleber, Porque você seleciona o certificado antes do envio? Porque não deixa ele já configurado no componente?

ALA, O provedor é o EL que já esta implementado. Favor ver como foi adicionado as demais cidades que usam esse provedor.

Boa tarde Klerysson, Você não esta conseguindo enviar com os fontes e programa exemplo disponibilizados no Trunk2?

Boa tarde ALA, Já verificou se esta cidade consta no arquivo Cidades.INI ? Se não consta, favor entrar em contato com a prefeitura da respectiva cidade e questiona-los sobre a empresa contratada para implantar a NFS-e. De posse dessa informação checar se já existe um arquivo INI para esta empresa (provedor). Se não existe, entrar em contato com a prefeitura ou com a empresa para saber se segue o layout da ABRASF e solicitar, URLs de homologação, produção, Schemas e manuais.

Boa tarde Antonio, Algo do tipo consultar o status de serviço? Se sim, a resposta é não. Alias essa consulta no caso da NF-e não serve absolutamente para nada, pois o Web Service responsável por autorizar a NF-e pode estar funcionando, mas o de Recepção de Evento não. Se ele retorna-se um status de cada Web Service seria muito útil, mas ele só retorna se ele esta funcionando ou não.

Luciano, Não faça isso, esta errado. Nunca consulte antes de enviar, simplesmente envia. Se após o envio você obter o Status igual a zero, significa que o CT-e OS não foi autorizado, não foi denegado e muito menos rejeitado. Sendo assim, você deve carregar o XML no componente e consultar, pois ocorreu um erro. Se não a consulta for bem sucedida, você terá uma das 3 situações apresentadas acima. Se foi autorizado ou denegado imprima o DACTE. Se foi rejeitado, o usuário tem que fazer as devidas correções e enviar novamente. Lembre-se que uma das rejeições é: Documento Inexistente na Base de Dados, neste caso fica claro que ao enviar o problema ocorreu no envio e não no retorno. Se você ficar consultando toda vez antes do envio, a SEFAZ poderá bloquear o emitente do CT-e OS por um período, por consumo indevido do Web Service.

Bom dia ALA, Veja bem, após o envio do lote temos como resposta o numero do protocolo (entenda como sendo o numero do recibo quando enviamos o lote de NF-e). Essa informação é utilizada para consultar a situação do lote enviado (método ConsultarSituacao) e consultar o resultado do lote processado (método ConsultarLoteRps). Ao consultar a situação de um lote é retornado apenas uma informação (um numero), que se ser 1 significa que o lote não foi recebido, 2 = lote em processamento, 3 = lote processado com falhas, 4 = lote processado com sucesso. Sendo assim as propriedades NomeArq e Numero apontadas pelas últimas duas setas estão vazias mesmos, só serão preenchidas quando o componente obter o retorno do provedor com o XML da NFS-e, isso ocorre quando realizamos a Consulta ao Lote de RPS.

Luciano, Eu não faria isso. Se utilize da consulta quando algo der errado, ou seja, enviou e o XML ficou sem o protocolo de autorização, ai sim devemos realizar uma consulta. Lembre-se que ao enviar pode ocorre falha no envio ou falha no retorno. Se ocorreu uma falha, para saber se foi no envio ou no retorno, basta se utilizar do método consultar. Se não ocorreu nenhuma falha, o CT-e OS poderá ser Autorizados, Denegado ou Rejeitado. Se ele for Rejeitado devemos efetuar as devidas correções nos dados incorretos e enviar novamente, uma vez que um documento rejeitado não é armazenado na base de dados da SEFAZ. Simplifique a vida do usuário, coloque apenas um botão [Emitir] que faça tudo, ou seja, alimente o componente com os dados do CT-e OS, gere, assina, valida, envia e imprima o DACTE (caso autorizado ou denegado).

Bom dia Marcelo, Os XMLs de Inutilização de Números, por ser algo muito raro, alias tem que ser raro a inutilização de números, logo foi previso somente a separação por CNPJ, portanto o GetPathInu só possui um parâmetro que é o CNPJ. Já no caso dos eventos, os mesmos são separados por pastas, sendo assim, temos que informar o tipo de evento para que o mesmo pegue a pasta correta.

Bom dia Luciano, Você esta fazendo errado, o correto não é tentar enviar novamente, pois você não sabe se o problema ocorreu no envio ou no retorno do protocolo. Sendo assim, após detectar que ocorreu um problema e o CT-e OS enviado esta sem o protocolo de autorização, o correto é realizar uma consulta, se o CT-e OS foi enviado com sucesso ao realizar a consulta será retornado o protocolo de autorização (lembre-se carregar o componente com o dados do CT-e OS em questão antes da consulta) e o XML será atualizado. Caso o problema foi no envio, será retornado a mensagem que o CT-e OS não consta na base de dados, ai sim você envia novamente.