daniel.afonso

Boa tarde, aparentemente deu certo, não retornou erros após a transmissão. Usei o método Emitir. Porém não sei se é coisa do provedor não tem retorno de código de verificação e demais informações. Sabem dizer se é assim mesmo ?

Passei um valor default para o campo referente ao fone_destinatario, no caso de não estar preenchido. Depois deu o retorno : "O seguinte campo nao pode ficar vazio: Sistema Gerador", onde preenchi a propriedade verAplic com o nome da aplicação. Estou seguindo validando os retornos e fazendo os ajustes necessários, assim que der certo aviso aqui.

Bom dia Italo, Estou repassando o teste e dessa vez estou passando somente o número do CNPJ do emitente para os parâmetros WSUser e para o CNPJ do prestador. Deu outro retorno agora "TAG fone_destinatario não encontrada." Fiz o teste preenchendo o parâmetro Prestador.Contato.Telefone e depois sem preencher, deu o mesmo retorno nas duas tentativas. 0000004304-ger-nfse-soap.xml 0000004304-lista-nfse-ger.xml 0000004304-lista-nfse-ger-soap.xml 0000004304-ger-nfse.xml

Sim, passando o CNPJ do emitente, e das duas formas, formatado ou só com números está gerando o token de qualquer forma que passa.

Sim Italo, os dados estão sendo passado nestes campos mesmo. O token está sendo gerado, no momento de emitir que está retornando que o CNPJ do prestador não pertence ao login informado.

E também está retornando que o CNPJ do prestador não pertence ao login informado. Estranho porque é o mesmo CNPJ que faço o login na aplicação Sigissweb.

Mudei o SSLType para LT_TLSv1_2 aí gerou o token. Outra dúvida é, esse token que é gerado eu uso o mesmo sempre ou toda nota que for enviar eu tenho que gerar outro ?

Bom dia Retomando a emissão da NFS-e para o município de Santa Bárbara d'Oeste, não estou conseguindo nem gerar o token. No manual do provedor diz que o webservice possui um usuário diferente da aplicação SigissWeb. É necessário gerar essa senha lá na aplicação tanto para produção quanto para homologação. Gerei essa chave lá para ambiente de homologação, mas não está dando certo ainda. A aba XML de retorno não preenche nada, e o soap que é gerado só tem o json com o cnpj e a senha. Atte.

Boa tarde. Estou com outra demanda no momento, assim que retomar farei o mesmo.

Boa tarde Também estou fazendo a implementação do município de Santa Bárbara D'Oeste no ACBrNFSeX. Gerei a chave direto no sistema da prefeitura e estou passando ela na propriedade ACBrNFSeX.Configuracoes.Geral.Emitente.WSChaveAutoriz, e mesmo assim dá o retorno abaixo:X999 - Erro de Conexão: Erro Interno: 0 Erro HTTP: 401 URL: https://wshml.sigissweb.com/rest/nfes Extra content at the end of the document.

Pois é, bem estranho mesmo. Mas depois de ter atualizado os fontes e reinstalar o componente, parece estar tudo certo agora.

Atualizei os fontes para a versão mais recente e migrei a emissão para este município para o componente novo ACBrNFSeX. Abri um chamando no SP156, e retornaram informando que no exemplo que enviei para eles não estava gerando a tag X509Certificate. Parecido com o problema que tive na emissão para Campinas. Aparentemente tudo certo.

Eu estava pegando usando a propriedade NotaFiscais: "ACBrNFSeX.NotasFiscais.Items[0].NFSe.CodigoVerificacao", então vi no programa exemplo que no ChecarResposta usa "ACBrNFSeX.WebService.Emite.CodVerificacao", aí deu certo. Algumas informações vem preenchida e outras não nas duas formas. Agora é questão de validar mesmo onde tem e onde não e tratar. Aparentemente tudo certo agora depois da migração para o novo componente. Muito obrigado pela ajuda pessoal.

Nota transmitida com sucesso, consultei no sistema da prefeitura e tudo certo também. Porém não veio as informações no retorno, Código de Verificação e o Nro. da Nota.

Bom dia Confirmei com o cliente, aí entra questão tributária mesmo. Ela sempre verificar com o contador essa questão de retenção antes de emitir a nota. Fiz um teste onde não é retido o ISS na fonte, e não teve retorno de erro usando o método de teste. Vou agora realizar um teste em ambiente de produção e verificar se a nota aparece lá no sistema da prefeitura. Que é o problema que originou este tópico, onde com o componente antigo dava como transmitido mas não conseguia ver a nota no sistema da prefeitura, talvez por conta das inconsistências da assinatura, etc.

Estava exatamente fazendo este teste Italo. Estou usando o método Emitir passando o parâmetro meTeste, e passando o ISS Retido como stNormal e aparentemente deu certo. Não trouxe retornos de erros. Porém não entendi bem, porque se a nota tem retenção não teria que passar stRetencao ?

Bom dia, No meu caso aqui, a nota tem ISS Retido e estou passando R no tipo de recolhimento. Mesmo assim está dando o mesmo retorno. 0000002386-env-lot.xml 0000002386-env-lot-soap.xml 0000002386-rec.xml 0000002386-rec-soap.xml

Na verdade o retorno anterior pode ignorar. É este aqui: 1497 - Verificar se nao houve informacao de retencao indevida no RPS para empresa fora de Campinas ou consulte a situacao cadastral no link http://situacao.campinas.sp.gov.br/ No manual diz para alterar o tipo de recolhimento para A.

Encontrei no cadastro do cliente na prefeitura o código da atividade. Depois pediu o preenchimento da <AliquotaAtividade>, preenchido corretamente também. Agora está dando o retorno abaixo: 1206 - Assinatura do RPS incorreta. Codigo Hash gerado para o campo assinatura do RPS esta invalido. O codigo hash '643b374e2067b58bb41a6c02b0190aa934f02c2b' gerado para o campo Assinatura do RPS nao esta valido. O campo Assinatura deveria estar com o conteudo '00001312154NF 00000000238620221101T NN000000000000100000000000000000062023000212777970000187' convertido no padrao SHA1 para o valor '186db09d63b8255b8645e78967abb49ca76f0fcb'.

Componente atualizado com a versão mais recente. Ao transmitir temos agora os seguintes retornos: 306 - Codigo da Atividade do RPS inexistente.Atividade 006202300 não localizada no cadastro. 0 - ERRO NA CONVERSAO DE RPS EM NOTA FISCAL :null -->Classe :br.com.dsfnet.wsnfe2.validacao.ValidaRps linha:544-->Classe :br.com.dsfnet.wsnfe2.proces.Processamento linha:400-->Classe :br.com.dsfnet.wsnfe2.proces.Processamento linha:279-->Classe :br.com.dsfnet.wsnfe2.proces.Processamento linha:238-->Classe :sun.reflect.GeneratedMethodAccessor449 linha:-1-->Classe :sun.reflect.DelegatingMethodAccessorImpl linha:25-->Classe :java.lang.reflect.Method linha:597-->Classe :org.apache.axis.providers.java.RPCProvider linha:397-->Classe :org.apache.axis.providers.java.RPCProvider linha:186-->Classe :org.apache.axis.providers.java.JavaProvider linha:323-->Classe :org.apache.axis.strategies.InvocationStrategy linha:32-->Classe :org.apache.axis.SimpleChain linha:118-->Classe :org.apache.axis.SimpleChain linha:83-->Classe :org.apache.axis.handlers.soap.SOAPService linha:330-->Classe :org.apache.axis.server.AxisServer linha:281-->Classe :org.apache.axis.transport.http.AxisServlet linha:699-->Classe :javax.servlet.http.HttpServlet linha:637-->Classe :org.apache.axis.transport.http.AxisServletBase linha:327-->Classe :javax.servlet.http.HttpServlet linha:717-->Classe :org.apache.catalina.core.ApplicationFilterChain linha:290-->Classe :org.apache.catalina.core.ApplicationFilterChain linha:206-->Classe :org.jboss.web.tomcat.filters.ReplyHeaderFilter linha:96-->Classe :org.apache.catalina.core.ApplicationFilterChain linha:235-->Classe :org.apache.catalina.core.ApplicationFilterChain linha:206-->Classe :org.apache.catalina.core.StandardWrapperValve linha:235-->Classe :org.apache.catalina.core.StandardContextValve linha:191-->Classe :org.jboss.web.tomcat.security.SecurityAssociationValve linha:190-->Classe :org.jboss.web.tomcat.security.JaccContextValve linha:92-->Classe :org.jboss.web.tomcat.security.SecurityContextEstablishmentValve linha:126-->Classe :org.jboss.web.tomcat.security.SecurityContextEstablishmentValve linha:70-->Classe :org.apache.catalina.core.StandardHostValve linha:127-->Classe :org.apache.catalina.valves.ErrorReportValve linha:102-->Classe :org.jboss.web.tomcat.service.jca.CachedConnectionValve linha:158-->Classe :org.apache.catalina.core.StandardEngineValve linha:109-->Classe :org.apache.catalina.connector.CoyoteAdapter linha:330-->Classe :org.apache.coyote.ajp.AjpProcessor linha:436-->Classe :org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler linha:384-->Classe :org.apache.tomcat.util.net.JIoEndpoint$Worker linha:447-->Classe :java.lang.Thread linha:619

Estou atualizando para a versão mais recente para validar se ainda ocorre o problema.

No programa exemplo uso o botão que chama o método ACBrNFSeX1.SSL.SelecionarCertificado, onde preenche o número de série. Executando a opção destacada no print abaixo, também retorna problema com a assinatura. 1129-env-lot-sinc-soap.xml 1129-lista-nfse-sinc.xml 1129-lista-nfse-sinc-soap.xml 1129-env-lot-sinc.xml

Mudei para o componente novo e debugando cheguei até a unit ACBrDFeXsLibXml2 no método Assinar. Tentei preencher as propriedades abaixo além do número de série, porém não deu certo também: ACBrNFSeX.SSL.DadosCertificado.Tipo := tpcA1; ACBrNFSeX.SSL.DadosCertificado.Certificadora := 'AC Certisign'; Não preenche a tag X509Certificate. É possível que esteja faltando alguma configuração ?

Acho que estou entendo o que está ocorrendo. No componente antigo o modo de envio é assíncrono, por isso dá a impressão de que foi transmitido porém ao consultar dá o mesmo erro de "Assinatura Digital InvalidaErro ao verificar assinatura digital: null". Já novo o envio é síncrono então já dá o erro no momento da transmissão. Parece que não está encontrando alguma configuração do certificado mesmo.