Italo Giurizzato Junior

Boa tarde @devFortes, Você poderia anexar as units que você fez alterações para que possamos validar?

Boa tarde @gladston, Chegou a testar os demais métodos de envio que eu mencionei na postagem anterior?

Bom dia a todos, Como assim usar o 0076 em vez de 1058 para indicar que o pais é Brasil? Quanto a alíquota tentem informar o valor zero. Se a mensagem de erro realmente estiver correta (coisa que eu duvido) não devemos informar a alíquota.

Bom dia @Valdir Dill, Nos testes que fiz, informei o mesmo CNPJ do emitente como sendo a Empresa de Emissão Própria.

Boa tarde @pcbonetti, Já esta no SVN.

@marcelo.tomas.grupoacert, Não tem.

Boa tarde @Gabriel Bobello, Muito obrigado pela colaboração, já esta no SVN.

Boa tarde @João Antônio, Já esta no SVN.

Boa tarde @Adrian Kempinski, Complementando o que o @Juliomar Marchetti já lhe passou: A unit pcteCTeR responsável pela leitura do XML por usar a unit pcnLeitor não esta conseguindo ler corretamente o grupo toma, pois dentro desse grupo tem uma tag também chamada toma. A unit pcnLeitor possui uma deficiência nesse tipo de situação. Caso não esteja conseguindo ler corretamente o XML do CT-e Simplificado mais precisamente o grupo toma, sugiro que reinstale o ACBr marcando a opção para usar o ACBrXmlDocument.

Boa tarde @gladston, Complementando o que o @Juliomar Marchetti, lhe passou. O webservice do Giss possui 3 modos de envio: Envio de lote no modo assíncrono , Envio de lote no modo síncrono (o que você testou) e o Envio unitário. O programa exemplo do componente tem um botão para cada um desses 3 modos que você pode testar e ver o resultado de cada um. Mas uma coisa é certa, o componente esta estabelecendo um conexão com o webservice, o envio esta ocorrendo e o webservice esta respondendo. Uma prova disso é a mensagem: Erro(s): Código : E999 Mensagem: Erro de execução de serviço. Correção: Tentar novamente Por ser um webservice novo, pode conter vários problemas. Para você ter uma ideia, se tentar realizar uma das consultas disponíveis sem a mesma estiver assinada é retornado uma mensagem de erro informando que o RPS não esta assinado. A mensagem esta um tanto quanto errada, pois em uma consulta não consta o XML do RPS. A mensagem correta deveria ser: XML de pedido de consulta não assinado. É nessas horas que pedimos a Deus que nos de paciência e não força.

Boa tarde @RodrigoAlvim, Compare a procedure que faz a configuração do componente do programa exemplo com o da sua aplicação. Não foi salvo o arquivo (soap) de retorno ao enviar o lote de rps para o webservice do provedor?

Bom dia @powerlog, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes. Agora temos uma propriedade de configuração chamada ExibeCampoDuplicada cujo valor padrão é True. Configure ela com o valor False para que o quadro Duplicada não seja impresso no DANFE.

Bom dia @marcelo.tomas.grupoacert, Uma ideia seria ter uma cópia da aplicação em outra pasta, alterar o arquivo ACBrNFSeXServicos.ini informando o provedor antigo e salvar o arquivo INI alterado na mesma pasta do executável.

Bom dia @Atalias, Chegou a realizar os testes em ambiente de homologação? Se sim, qual foi o resultado?

Bom dia @awendisch, Fizemos uma alteração no componente. Agora a classe que contem as informações de cancelamento consta com um novo campo chamado CodMunicipio. Se ele não for preenchido o componente assume o código do município do emitente da nota. Por favor atualize todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes. Foi feita uma alteração no programa exemplo tanto em Delphi quanto em Lazarus exemplificando como passar essa informação. Ficamos no aguardo de um retorno.

Bom dia @HERALDO, Estamos com problemas para disponibilizar a nova versão do ACBrMonitor no fórum, mas fique atendo que em breve sai a nova versão.

Bom dia @gladston, Se deseja fazer testes em homologação para a cidade de Goytacazes, basta alterar o arquivo ACBrNFSeXServicos.ini da mesma forma que foi alterado para a cidade de Jundiai. Depois siga as instruções que estão no inicio do arquivo INI.

Bom dia @tryideas sistemas, Checando o seu XML do RPS gerado pela Lib notei a ausência da tag Município do Prestador e também do Tomador. A tag CodigoServico116 esta vazia. Não sei se você gera o XML ou o arquivo INI. No caso do arquivo INI se faz necessário incluir o campo xMunicipio nas seções do Prestador e Tomador com o nome do município. No que se refere ao CodigoServico116 ficou faltando incluir o campo codLCServico dentro da seção de itens (Itens001 por exemplo). Exemplo: [Itens001] codLCServico = 123

Bom dia @João Antônio, Muito obrigado pela colaboração, já foi criado a TK-6079 para atualizar o arquivo.

Bom dia @lucasyu01, Apesar de constar no comunicado que a versão utilizada pelo GissOnline é a 2.04 do layout da ABRASF, nos meus testes foi necessário informar tanto no cabeçalho quanto no lote a versão 1.00. Não sei se eles mudaram, pois o correto seria constar 2.04 em vez de 1.00 Por favor entre em contato com o provedor e solicite um XML (de preferencia soap) de exemplo para que possamos fazer as devidas correções.

@André Luiz Franzoi, Protocola uma reclamação na prefeitura.

Boa tarde @André Luiz Franzoi, Mas tcValoresNfse se refere ao tipo complexo de valores da NFS-e e não do RPS. No que se refere ao RPS o tipo complexo é o: tcValoresDeclaracaoServico.

Boa tarde @Eduardo Resende Lara, Muitas cidades atendidas pelo provedor Ginfes estão migrando para o GissOnline. Favor entrar em contato com a prefeitura se eles não vão ou se já migraram.

Boa tarde @lucasyu01, Os dados do prestador bem como o certificado digital é de um prestador de Santos/SP ? Você fez alteração no arquivo ACBrNFSeXServicos.ini para que o envio ocorresse para o novo webservices (GissOnLine) ?

Boa tarde @Dirlenio Batista, A carinha de tristeza é pela sua ausência no Dia do ACBr. Fico no aguardo do retorno dos seus testes.