Italo Giurizzato Junior

Boa tarde @Danny, Se o problema é ao ler o XML de retorno da consulta o XML do RPS que você anexou não tem nenhuma serventia para nós. Você precisa configurar o componente para salvar os arquivos Soap. Fazer um novo teste de consulta e anexar o XML Soap de retorno da referida consulta para que possamos analisar o seu conteúdo.

Bom dia @Heckler Milas, Já esta no SVN. Não movemos a propriedade de MarcaDaqua para a unit ACBrDFeReport pois acreditamos que se o DF-e que não usa ou não permite a impressão da mesma, a propriedade não deve aparecer.

Boa tarde @oribeiro, O erro que você esta tendo muitos outros desenvolvedores também estão. O problema não é no pedido de cancelamento e sim no provedor. Favor abrir um protocolo junto a prefeitura reportando o problema. Tem que reclamar na prefeitura, pois se tentar conversar com alguém do provedor vão lhe deixar mais de 1 hora esperando no telefone e não vão resolver o problema. Quanto mais prestadores de serviços abrirem um protocolo junto a prefeitura, mas rápido eles vão corrigir.

Bom dia @willian_delan, Já esta no SVN a inclusão do Params.

Bom dia @Sandro Felipe Adad, Já esta no SVN.

Bom dia @Ronaldo.Bispo, Já esta no SVN.

Bom dia @oribeiro, Eu acredito que a versão mais nova da DLL já aceita o código 1058. Leia a noticia abaixo:

Boa tarde @Diego Reckziegel, Já esta no SVN.

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

Bom dia @Atalias, O retorno com o numero do protocolo só diz que o RPS foi recepcionado pelo o webservice e não que esta tudo Ok. Se faz necessário consultar para saber o resultado do processamento. Se no portal não consta a nota, isso significa que o RPS não foi aceito, tem algum dado errado nele. Só consultando o lote para saber o que esta errado.

Bom dia @Fernando Cattelan Vieira, Veja se o tópico abaixo lhe ajuda na questão da alíquota.

Bom dia @oribeiro, Pela mensagem de erro me leva a crer que você esta com os Schemas desatualizados. Pois a definição do tipo Alíquota consta que ela possui 4 dígitos.

Bom dia @Heckler Milas, Estou analisando a sua contribuição e notei: 1. Os seus fontes estão desatualizados em relação ao SVN. 2. O arquivo ACBrCTeDACTeRLRetrato.dfm que se encontra no SVN contem 227 KB e o que você nos enviou para analise tem somente 217 KB. Algumas units apensar de estarem desatualizar eu consegui ajustar, mas esse arquivo mencionado acima esta muito estranho essa diferença de 10 KB. Ao meu ver, você vai ter que deletar esse arquivo, baixar ele novamente do SVN para por fim incluir o objeto referente a marca d'agua.

Bom dia @Ildevir, Muito obrigado pela colaboração, já foi enviado para o SVN a alteração. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia @willian_delan, Já esta no SVN.

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

Boa tarde @Patrick Knopf, Você esta com os schemas desatualizados.

@osmarbentojr, Acabei de fazer um teste usando o programa exemplo. Simplesmente fiz a alteração abaixo: Ide.tpServ := tsTranspPessoas; //tsTranspValores; Na procedure AlimentarCTeOS. Usei o botão Gerar CTe, o XML foi gerado, assinado e validado. Ao instalar o ACBr você esta marcando a opção para usar o ACBrXmlDocument? Caso não esteja marcando, reinstale novamente com essa opção marcada.

Bom dia @Diego Reckziegel, Já esta no SVN.

Bom dia @osmarbentojr, Desculpa, eu estava entendo o seu problema de forma errada. Já foi criado a TK-6562 para analise do problema.

Boa tarde @brunotbp, Já esta no SVN.

Boa tarde @osmarbentojr, No que se refere ao CT-e OS no programa exemplo é mostrado como gerar um XML de CT-e OS para transporte de valores, quanto a isso você esta correto. Agora se a sua aplicação vai emitir um CT-e OS para transporte de pessoas (fretamento) vai ter que mudar o valor do campo tpServ e alimentar os campos pertinentes a esse tipo de serviço. Caso você não saiba quais são esses campos sugiro a leitura do manual, pois os nomes que damos para campos tem a mesma nomenclatura do manual.

Bom dia @brunotbp, Vamos lhe avisar aqui mesmo. Basta aguardar.

Olá Pessoal, Quando iniciamos os testes com o Provedor Giss descobrimos que ao informar o código do pais deveríamos informar 0076 em vez de 1058. O código 1058 se refere ao código IBGE do Brasil e o código 0076? Pois bem, descobri que o Provedor Giss em vez de usar o código IGBE dos países em seu webservice, acabou adotando o código ISO. Resumindo o código 0076 é o código ISO do Brasil. Foi implementando duas novas funções de conversão, uma para converter o código IBGE para ISO e a outra que converte de ISO para IBGE. A orientação abaixo é para somente quem usa o provedor Giss: Se você esta informando o código 0076 ao campo CodigoPais, deve alterar para 1058, pois o componente vai realizar a troca, caso contrario o seu RPS vai ser rejeitado, acusando que o código do pais esta errado. O objetivo dessa mudança é manter um padrão para todos os provedores ao alimentar o componente, informando sempre o código IBGE do pais e caso o provedor se utiliza de outro código como é o caso do Giss que usa o código ISO o componente se responsabiliza por realizar a conversão.

Boa tarde @JOSE CARLOS ALVES JUNIOR, Já esta no SVN.