italo.giurizzato.junior

Bom dia Asterix, Na verdade o consultar status do serviço não serve para nada, somente para saber se essa funcionalidade esta funcionando. Digo isso, pois ela não retorna o status dos demais serviços. Para você ter uma ideia a SEFAZ já cogita em remover essa funcionalidade. Se ao enviar você obter como retorno o Status = 999 isso significa que o Web Service esta com problemas e não tem nada haver com o seu XML.

Bom dia Graça e Juliomar, Mil desculpas, disponibilizei antes de testar aqui. Muito obrigado Juliomar pela correção.

Bom dia Graça, No modo Assíncrono temos inicialmente o retorno do numero do recibo para depois termos o retorno do protocolo de autorização caso o processamento tenha ocorrido com sucesso. Necessito saber se nesse modo de envio você esta obtendo o recibo? Se sim, o problema esta no arquivo -pro-rec.xml que esta vazio, correto? Neste caso sugiro que você abra o fonte: ACBrNFeWebServices.pas e altere a linha 2332: if FConfiguracoes.Geral.Salvar then begin FPathArqResp := Recibo+'-pro-rec.xml'; FConfiguracoes.Geral.Save(FPathArqResp, FRetWS); <---- linha 2332 end; if FConfiguracoes.Geral.Salvar then begin FPathArqResp := Recibo+'-pro-rec.xml'; FConfiguracoes.Geral.Save(FPathArqResp, FRetornoWS); end; Essa alteração de FRetWS para FRetornoWS vai fazer com que o componente salve em disco o XML na integra retornado pelo WebService. Com isso temos como verificar o que esta ocorrendo. Por favor faça isso e post em anexo o -prorec.xml

Bom dia Gill, Se possível post como anexo tanto o XML do RPS quanto o da NFS-e para que eu possa verificar.

Antonio, Se possível post como anexo o XML da NFS-e de Bauru. Eu lhe digo se segue o padrão ABRASF ou não.

Boa tarde Daniel, A rejeição que você se refere é a do título do tópico, correto? Já verificou se o problema não é o credenciamento no ambiente de homologação? Verifique se a empresa referente ao certificado que você esta utilizando esta credenciada nos dois ambientes: homologação e produção.

Boa tarde Antonio, Você chegou a abrir o XML da NFS-e de Bauru utilizando o navegador (Internet Explorer por exemplo) e outro XML de outra cidade por exemplo Araraquara, Ribeirão Preto, São José do Rio Preto? Se não me falha a memória Bauru não segue o padrão ABRASF. O componente atende o padrão ABRASF e DSF.

Boa tarde Dênio, A validação sempre é feita em cima do lote, quanto a assinatura o meu conselho caso você vai desenvolver um monitor é: Em vez da sua aplicação salvar na pasta o XML do RPS, salvar um TXT com os dados do RPS. O monitor lê o TXT alimenta o componente com os dados lidos e se encarrega de fazer o resto. Porque fazer desta forma, pois alguns provedores requerem que o XML do RPS seja assinado e outros não, uns requer que o lote seja assinado e outros não, outros possui algumas particularidades a mais no XML ou até mesmo a inversão de uma TAG em relação a outra. Quanto ao problema com o DANFSE, com certeza você deve ter alguma DCU antiga em alguma pasta que o Delphi esta tendo acesso.

Fernando, Já respondido no outro tópico.

Bom dia Rigotti, Muito obrigado, alteração realizada e disponibilizada.

Bom dia Fernando, Favor atualizar os fontes e testar novamente.

Bom dia Antonio, Você esta carregando o XML do RPS ou da NFS-e? Todos os fontes estão atualizados?

Bom dia Emerson, infEvento.tpEvento := teCCe;

Bom dia Cesar, Os seus testes com a versão 3.10 se refere a UF = 29, ou seja, Bahia, correto? Realizei algumas alterações no componente visando a versão 3.10 da NF-e para a Bahia. Favor atualizar os fontes e realizar os testes.

Boa noite Gill, Você não esta executando o Enviar com o segundo parâmetro valendo true e depois manda executar o Imprimir? O Enviar possui 2 parâmetros sendo que o segundo por padrão vale True isso faz com que assim que ocorre o retorno da NFS-e é impresso o DANFSE. Quanto ao valor da Alíquota: No RPS como deve ser informada: 2,35 ou 0,0235? Na NFS-e retornada pelo provedor como ela aparece: 2,35 ou 0,0235?

Boa noite Marco, Se aparece a mensagem de erro acusando que um identificador não esta definido, isso significa que o a unit onde encontra-se a definição a mesma não foi compilada. Procure sempre compilar com a opção Build. Caso você já tenha feito esse procedimento, com certeza existe uma DCU antiga perdida no HD e o Delphi a esta utilizando em vez da nova.

Boa noite Dênio, Vasculhe o HD da maquina em busca do arquivo qrpt70.bpl se não me falha a memória é esta extensão. Ao encontrar renomeie esse arquivo para qrpt70_xxx, isso deve resolver o problema.

Boa noite Marco, O componente possui na unit pnfsConversao.pas uma function onde informamos o código do serviço e este retorna a sua descrição. O que eu fiz foi possibilitar uma segunda alternativa onde você determina se deseja a descrição que encontra-se na unit ou no arquivo chamado TabServicos.txt O componente agora possui uma propriedade chamada TabServicosExt cujo valor padrão False. Detalhe importante o arquivo TabServicos.txt tem que ser salvo na mesma pasta do executável.

Boa noite Leo, Acredito que não, mas não custa nada informar.

Leo, Neste caso, acredito que não, pois o mais interessado em saber quanto esta pagando de tributos é o consumidor brasileiro. Visto que a lei que obriga e tal informação foi pensada neles, ou seja, no consumidor final.

Bom dia edulamy, Favor baixar do Portal Nacional do CT-e a Nota Técnica 2013/013 que consta a nova estrutura do XML na versão 2.00 O Local de Retirada não fica mais dentro do <infNF> e sim, dentro do <rem> que é muito mais lógico. E outra coisa agora ele se chama Local de Coleta (campo # 131 - Página 129 da NT mencionada acima). O InfNF, infNFe e infOutro estão fora do grupo <rem> eles pertencem agora ao grupo <infDoc> (Página 136).

Bom dia Giovana, Você tem o ambiente de homologação para isso. Realize todos os testes possível com a versão 2.00 em homologação, estando tudo OK migre para o ambiente de produção. O meu conselho é realizar essa migração na virada do mês. Desta forma até dia 30 de abril todos os CT-e são na versão 1.04 e os emitidos a partir de maio serão na versão 2.00. Outra coisa importante, checar se o escritório de contabilidade do seu cliente esta preparado para importar e processar os XMLs do CT-e na versão 2.00 Se sim, ótimo, caso contrario peça para eles acelerarem a atualização das aplicações, pois o prazo esta acabando.

Bom dia a todos, Vejam bem uma coisa é o site da SEFAZ que ainda não esta preparado para apresentar os eventos vinculados ao documento fiscal no caso o CT-e. Ao consultar a situação atual deve constar que o CT-e esta autorizado, o grupo procCTe constando todo o retorno com o protocolo de autorização da SEFAZ, mais os eventos vinculados ao CT-e em questão. Neste caso tem que aparecer a CC-e. Com o advento da CC-e, Cancelamento por evento o XML do CT-e "original", ou seja, com o protocolo de autorização, não deve ser mais alterado. Devemos enviar ao tomador do serviço o XML contendo o evento enviado a SEFAZ, juntamente com o protocolo acusando a sua vinculação ao CT-e.

Bom dia Jefferson, Erro de conversão? Isso é um erro no componente ou trata-se de uma rejeição do provedor? Se é no componente em qual unit ocorre, em qual linha?

Bom dia Lincoln, Você tem certeza que todos os fontes estão atualizados? Não tem nenhum deles com uma bolinha vermelha ou triangulo amarelo?