Italo Giurizzato Junior

Boa tarde Jarbas, E mesmo assim o problema persiste. Vai ser necessário entrar em contato com o provedor para saber o porque desse problema.

Bom dia Jarbas, Esse erro ocorreu ao executar qual método?

Bom dia Luís, Você esta se referindo ao método que valida as regras de negócio que se encontra no componente. Se esta levando em consideração somente as duas condições conforme a imagem, então esta errado, pois essa regra não se aplica para alguns CFOP conforme consta no manual conforme a primeira imagem que você anexou. O correto seria incluir a checagem desses CFOP. Caso você deseja contribuir e fazer a alteração, ficaremos gratos. Altere a unit e anexe aqui para que possamos avaliar. Desde já muito obrigado pela colaboração.

Bom dia Marcos, Esse XML se refere a consulta a uma nota que se encontra cancelada, correto? Você teria o XML de uma consulta de uma nota que não esta cancelada? Essa tag <notaExiste> pode conter outros valores?

Bom dia, Já esta no SVN.

Bom dia Nelson, Analisando a sua colaboração fiquei com uma duvida. Se o valor de COMPILERVERSION >= 22 ele cria o TS e destrói, mas se não for? Nas versões anteriores não se faz necessário criar? Não seria o caso de usarmos a função FormatFloatBr que se encontra na unit ACBrUtil.Base, pois me parece que ela contempla a sua alteração.

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

Bom dia Carlos, As imagens não foram anexadas.

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

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

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