Italo Giurizzato Junior

Boa tarde Cristiane, Configure o componente para salvar os arquivos soap. Anexe o arquivo de envio para que possamos analisar.

Boa tarde Sergio, Eu aconselho você atribuir uma string vazia as outras 3 que não são utilizadas.

Boa tarde Jairo, Sem os arquivos soap de envio e de retorno não tem como eu lhe informar.

Mauricio, O provedor em questão é o SystemPro? Se sim, todos os fontes estão atualizados? Pois esse provedor consta para mim que já estava funcionando 100%.

Favor atualizar os fontes e testar novamente.

Não, isso é o retorno do provedor. O componente só gera o que envia.

Rafael, Recuperar o protocolo desse MDF-e não tem nada haver com o seu encerramento. O encerramento é um evento, ou seja, você deve montar o evento de encerrando e enviar ele. Para recuperar o protocolo, basta carregar o componente com esse XML através do LoadFromFile e depois executar o método Consultar.

Você abriu esse XML com um navegador?

Maurício, Não seria interessante comentar a linha logo abaixo do IF também?

Boa tarde Fábio, Se você abrir o arquivo INI desse provedor ( pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ) vai notar que foi incluído somente as URLs para os métodos Cancelar NFS-e e Gerar. Sendo assim você deve usar o método Gerar e não o Enviar.

Ok, mas qual é o método: Enviar, Gerar ou EnviarSincrono?

Maurício, No arquivo INI do provedor note que foi colocado " * " para todos os campos da seção [SoapAction], o motivo é simples para esse provedor não existe uma URLs (por exemplo) para o SoapAction dos métodos. Se deixarmos em branco o componente vai levantar uma exceção acusando que o SoapAction não foi definido. Sendo assim vamos fazer um teste. Na unit ACBrDFeWebService - procedure InicializarServico comente a linha que verifica se a propriedade SoapAction é uma string vazia. Aguardo retorno.

Boa tarde a todos, O componente ACBrNFSe não interfere na velocidade que o provedor processa as notas recebidas, só faltava essa, tenha paciência. O componente apenas estabelece uma conexão com o provedor para enviar e obter o retorno. Como já disse mil vezes, quem fez a migração do componente ACBrNFSe para o Trunk2 foi eu. Consegui com um colega do fórum um certificado de uma empresa cuja cidade é atendida pelo provedor Ginfes. Testei todos os métodos, sempre usando o programa exemplo. Nunca entrei no site do provedor para saber se nota tinha sido processada ou não. Com o componente configurado para Consultar o lote após o envio e usando o método Enviar e menos de 15 segundos o XML da NFS-e estava salvo no disco. Já disse também que o tempo pode variar de provedor para provedor e mesmo sendo o mesmo provedor pode variar de cidade para cidade. Não é o caso do Ginfes, mas existem provedores que alem do método Enviar disponibiliza o método Gerar. O Gerar é mais rápido, primeiro por aceitar somente um RPS, segundo que o retorno do envio através desse método já é o XML da NFS-e ou a lista de erros. Já o método Enviar nos retorna apenas o protocolo que acusa o recebimento do lote pelo provedor. Em seguida se faz necessário consultar a situação desse lote, essa consulta o provedor simplesmente nos retorna a situação informado uma das 4 situações: Lote não recebido, Lote em processamento, Lote Processado com erro, Lote Processado com Sucesso. A rotina que realiza essa consulta é capaz de repetir a consulta por varias vezes enquanto a resposta for Lote em processamento. O componente dispões de 3 propriedades para configurar essa consulta, podemos definir o tempo que ele vai esperar para realizar a primeira consulta, o tempo entre uma consulta e outra e numero de tentativas. Se o retorno for Lote processado com erro ou com sucesso o próximo passo é consultar do lote, teremos como resposta a lista de erros caso tenha sido processado com erro, ou o XML das notas caso tenha sido processado com sucesso. Repito mais uma vez quando configuramos o componente para consultar o lote apos o envio, se utilizarmos o método Enviar essas duas consultas são executadas automaticamente e na sequencia correta.

Boa tarde, Qual foi o método executado que resultou nesse erro?

Boa tarde a todos, Aconselho você primeiramente realizarem testes com o programa exemplo. Segundo, no programa exemplo verifique se a propriedade de configuração chamada ConsultaLoteAposEnvio esta com o valor True. Se funcionar com o programa exemplo, vocês devem verificar se na aplicação de vocês o que tem de diferente ou o que esta faltando. Por exemplo no programa exemplo na rotina que configura o componente existe 6 linhas de configuração do Emitente, na aplicação de vocês essas 6 linhas existem?

Boa tarde Maurício, Ainda esta ocorrendo esse último erro que você postou?

Boa tarde Rafael, O XML que você anexou se refere ao XML do MDF-e e não do evento de encerramento. E tem mais esse XML não contem o protocolo de autorização. Você não esta confundindo as coisas? Para mim encerrar significa informar a SEFAZ que todas as mercadorias foram entregues. Como o seu XML esta sem o protocolo de autorização você esta querendo enviar o mesmo para SEFAZ ou obter o protocolo de autorização uma vez que o mesmo foi enviado e não foi retornado o protocolo?

Bom dia Graça, Por ser um Web Service diferente do que é usado pelo ACBrCTe, no meu entendimento o correto seria criar um novo componente para esse fim.

Diogo, Essa mensagem é um retorno do provedor? Se sim a mensagem esta clara eles recebem o RPS mas ainda ele não foi processado. Isso pode ser um problema temporário do provedor ou significa que agora mais empresas estão utilizando o Web Services para emitir as notas e o mesmo não esta conseguindo dar conta de tantas solicitações.

Bom dia Maurício, Será necessário executar o ACBrInstall_Trunk2 para resolver isso.

Bom dia Julio, A mensagem é clara a TAG pICMSInter só aceite percentuais iguais a: 4.00, 7.00 ou 12.00 e foi informado 0.00

Bom dia Diogo, Acredito ser na sua aplicação ou na configuração do componente ou até mesmo no provedor, pois em meus testes com o provedor Ginfes, após o envio do RPS tenho o XML da NFS-e salva em disco em menos de 15 segundos.

Bom dia a todos, Muito estranho essa informação: Suspensa até a versão 3.00 Isso significa que teremos uma nova versão do CT-e? Vamos aguardar os próximos capítulos.

Bom dia Jairo, Você esta usando o programa exemplo, correto? Pois bem verifique se a propriedade ConsultaLoteAposEnvio esta com o valor True. Se sim, quem vai consultar a situação do lote, consultar o lote é o próprio Enviar.

Bom dia Antonio, Primeiro, não poste conteúdo de arquivos como parte da postagem, procure sempre anexar. Segundo no caso de São Paulo o XML do RPS possui uma assinatura onde que devemos pegar alguns dados montar uma string e através desta gerar o Hash e depois assina-lo. O resultado será o conteúdo da TAG Assinatura: <RPS xmlns=""> <Assinatura>asjkdfgaskfasfhsa</Assinatura> <ChaveRPS> E para que ocorra o envio de um RPS, devemos montar a estrutura conforme consta no manual versão 2.4.1 página 25. Essa estrutura é composta por 3 grupos: Cabecalho, RPS e Signature. O grupo Signature é uma assintura igual a usada na NF-e, CT-e, MDF-e e NFS-e. Se tratando de um envio de lote de RPS a estrutura é a mesma, ou seja, temos os mesmos 3 grupos mencionados acima, a diferença é o conteúdo do grupo Cabecalho e como se trata de um lote o grupo RPS poderá ter até 50 ocorrências, ou seja, posso enviar até 50 RPS para o Web Services. O componente ACBrNFSe já esta quase pronto para emitir NFS-e para São Paulo, o que esta faltando é corrigir a Assinatura realizada na String conforme descrito logo no inicio. Sabemos que algumas pessoas conseguiram faze-la se utilizando de DLL extra. Nós estamos trabalhando para realiza-la sem a necessidade de mais uma DLL.