Italo Giurizzato Junior

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 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?

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 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.

Bom dia Edmar, Muito obrigado pela colaboração, assim que possível estarei enviando para o repositório.

Boa noite Edmar, Favor fazer as alterações que você julga necessário e faça os testes, estando tudo OK, anexe a unit aqui mesmo, para que possamos analisar e estando tudo OK, enviaremos para o repositório.

Boa noite, Muito obrigado pela colaboração, vamos analisar e estando tudo OK, enviaremos para o repositório.

Boa noite, É um pouco complicado, pois a detecção é feita através do código do município do emitente da nota e isso é feito na unit que faz a leitura do XML.

Boa noite a todos, Pelo que pude ver através do link que o Diego postou, não segue o padrão ABRASF.

Boa noite ALA, Entre em contato para sabermos a resposta deles.

Boa noite Heto, Muito obrigado, vou analisar estando tudo Ok, mando para o repositório.

Boa noite Jimmy, Estranho, pois a URL de homologação: http://testewebserver.averba.com.br/index.soap?wsdl ainda esta funcionando.

Boa noite Rogério, Existe os eventos de Manifestação do Destinatário e existe a Manifestação de Documentos Fiscais Eletrônicos - MDF-e, documento este emitido pelas transportadoras e pelas empresas que realizam o transporte de carga própria.

Bom dia Heto, Você uma alteração no componente ou na sua aplicação? Se foi no componente favor anexar a unit alteração para que possamos avaliar.