Italo Giurizzato Junior

Bom dia, Se eu entendi o provedor esta gerando o XML da nota com uma formatação para data diferente para cada método, isso? Ao emitir a data vem no formato A, ao Consultar o formato da data é B? Ai ferra mesmo. Acredito que a solução não é nós ficarmos fazendo gambiarra para resolver isso e sim entrar em contato com o provedor e pedir para ele definir um padrão na formatação das datas independente do método que esta gerando o XML da nota. Se o provedor não der atenção, bombardear a prefeitura com protocolos relatando o problema.

Bom dia Antonio, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia Rubens, Já esta no SVN.

Bom dia Luis, Já esta no SVN. Observação, os seus fontes estão desatualizados.

Bom dia Dangelo, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia Jhonlenon, Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Bom dia Dangelo, Já inclui na minha lista de tarefas para analisar o problema. TK-2907

Bom dia, Veja este link: Portal da Nota Fiscal da Energia Elétrica Eletrônica - SVRS Você vai notar que SP ainda não consta como sendo um Autorizador próprio ou que vai se utilizar dos serviços da SVRS. Isso explica a rejeição 226.

Bom dia Carlos, Vamos aguardar então.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Francisco, Vai ser necessário entrar em contato com o provedor e relação o problema, pois eu também não encontrei nada que pudesse estar gerando esse erro.

Boa tarde, Neste caso não seria a questão de informar que o contribuinte não é Optante Simples Nacional ? Mas o melhor é conversar com um bom contador.

O erro é de validação, portanto em um primeiro momento não tem nada haver com o provedor. Você não pegou outro schema? O que temos no SVN do provedor BHISS a definição do campo RegimeEspecialTributação é: <xsd:simpleType name="tsRegimeEspecialTributacao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2|3|4|5|6"/> </xsd:restriction> </xsd:simpleType> Como você pode ver só aceita valores de 1 até 6

Boa tarde Wazen, Você esta usando o componente novo ou o antigo?

Boa tarde Luis, Muito obrigado pela colaboração, já esta na minha lista de tarefas. TK-2906

Boa tarde Nelson, Já se encontra em nossa lista de tarefas para ser analisado. TK-2905 Muito obrigado pela contribuição.

Boa tarde Carlos, Fazer um novo teste de envio com o programa exemplo configurado para salvar os arquivos Envelope Soap. Anexe os arquivos gerados para que eu possa analisar.

Boa tarde, A mensagem é clara, esta sendo informado o valor 8 para o campo RegimeEspecialTributacao e esse valor não é esperado. Favor verificar se o valor correto é 8, caso afirmativo vai ser necessário solicitar junto a prefeitura ou provedor um novo schema que contempla esse valor.

Boa tarde JhonLenon, Já inclui na minha lista de tarefas. TK-2904

Boa tarde Maurício, O erro de Timeout ocorre em ambiente de homologação ou de produção?

Boa tarde Luiz, A ideia é o seguinte: A lista de Resumos sempre será preenchida independente do provedor retornar o XML completo ou não. Desta forma a sua aplicação vai se basear nas informações que estão nessa lista de resumos para uma tomada de decisão ou simplesmente guardar essas informações no banco de dados. Por outro a lista de notas (TNotasFiscais) só vai ser alimentada se o provedor retornar o XML completo da nota. No meu entendimento se a quantidade de itens de TNotasFiscais for maior do que zero, nos leva a crer que o componente esta carregado com informações de uma nota ou Rps. E um desenvolvedor desavisado vai querer imprimir o DANFSE e consequentemente a maioria dos campos vão estar em branco. O preenchimento da lista de resumos foi inicialmente implementada no provedor ISSDSF, uma vez que ele retorna um resumo ao consultar o lote. E foi implementado na unit base utilizada pelos provedores que seguem a versão 1 do layout da ABRASF também no consultar o lote. A ideia é expandir para os provedores que seguem a versão 2 da ABRASF e aqueles que tem layout próprio. E também expandir para outros tipos de consulta. Para isso peço a ajuda de todos vocês nos testes.

Boa tarde, Na maquina do cliente tem proxy? Se sim, foi passado as informações necessárias para o componente, como senha, porta, etc ? Se não tem, o componente não esta com as configurações do proxy preenchidas? Verificou também se o antivírus não esta boqueando o acesso?

Boa tarde Neto, Peguei a URL que abre no navegador e coloquei no SoapUI. Os serviços de emissão, consultas e cancelamento não foram implementados no webservice, não vai funcionar mesmo. Veja a diferença: No caso do Tiplanv2 temos todos os serviços incluídos no NfseWSServiceSoap, já do Tributus, não tem nada incluído em nfseSOAPsoap11 Eu baixe do site da referida cidade um arquivo zipado que tem exemplos, manuais e tem um arquivo chamado nfse.wsdl, este contem todos os serviços, mas olha a URL que consta no final: <wsdl:service name="NfseWSService"> <wsdl:port binding="ws:nfseSOAP" name="nfseSOAP"> <soap:address location="http://ws.pbh.gov.br"/> </wsdl:port> </wsdl:service> pbh = Prefeitura de Belo Horizonte. Não tem como, vai ser necessário entrar em contato com o provedor e caso os caras não atenderem, o jeito vai ser pedir para os seus clientes protocolarem um documento na prefeitura relatando o problema.

Boa tarde Carlos, Muito obrigado pelo XML. Comparando o seu XML com o XML exemplo que o iTecSys anexou a versão é exatamente a mesma, ou seja, 2.03 O que muda é que o componente esta convertendo a mensagem de cabeçalho e de dados em string e no exemplo foi utilizado o CDATA. Essa alteração pode ser feita na unit Provider do provedor. O meu receio é que isso poderá gerar um efeito colateral para a cidade de Niteroi/RJ que se utiliza do mesmo provedor e versão do WebService.

Boa tarde, Já esta no SVN.