Italo Giurizzato Junior

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.

Bom dia @JOSE CARLOS ALVES JUNIOR, Muito obrigado pela colaboração, já foi criado a TK-6549 para realizar a alteração.

Olá Pessoal, No componente ACBrNFSeX o caracter a ser utilizado como quebra de linha tínhamos definido como padrão o ";" (ponto e virgula) e não era possível mudar ele através de uma propriedade de configuração. Mas ai surgiu uma necessidade de permitir essa configuração. Sendo assim o componente agora possui a propriedade QuebradeLinha cujo caracter padrão é o "|", mas você pode mudar da seguinte forma: ACBrNFSeX1.Configuracoes.WebServices.QuebradeLinha := ';'; A propriedade QuebradeLinha é do tipo string, logo é possível informar uma sequencia de caracteres em vez de apenas um, por exemplo: "\n\s". Sempre tenham em mente que, se na unit provider do provedor o caracter de quebra de linha for diferente do configurado, o componente vai realizar a troca do configurado pelo que se encontra na unit provider. Por exemplo: Na configuração consta que o caracter é ";" ponto e virgula, mas na unit provider do provedor consta que deve ser "@" arroba, o componente vai trocar o ponto e virgula pelo arroba ao gerar o conteúdo da tag.

Bom dia @oribeiro, Caso não esteja, favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça os testes usando o programa exemplo. A cidade de Itu/SP já esta "configurada" para o provedor Giss (GissOnline).

Boa tarde @Joao Pedro Pereira, Já esta no SVN.

Boa tarde @oribeiro, Você só esqueceu de informar de qual cidade é esse comunicado. Não temos como fazer nada sem saber qual é a cidade.

Olá Pessoal, O grupo sobre o Responsável Técnico esta presente em diversos DF-e, tais como: BP-e, CT-e CT-e OS, GTV-e, CT-e Simplificado, NF3-e, NFCom, NF-e, NFC-e e MDF-e. Para a maioria dos DF-e não existe uma obrigatoriedade de informar o Responsável Técnico, mas não custa nada informar os seus dados ao gerar o XML. Mas para a NF-e e NFC-e temos a NT 2018/005 versão 1.40 que determina que para as UF: AM, MS, PE, PR, SC e TO devemos informar, pois existe a obrigatoriedade, caso contrario a nota vai ser rejeitada: 972 - Obrigatória as informações do responsável técnico. Como alimentar o componente com as informações do Responsável Técnico? {Informações do Responsável Técnico pela emissão do DF-e} infRespTec.CNPJ := ''; infRespTec.xContato := ''; infRespTec.email := ''; infRespTec.fone := ''; Para quem gera o arquivo INI que é utilizado no ACBrMonitor e no ACBrLib devemos incluir a seção: infRespTec: [infRespTec] CNPJ = ''; xContato = ''; email = ''; fone = ''; Outra informação importante se refere ao CSRT (Código de Segurança do Responsável Técnico) que a SEFAZ-PR vai passar a exigir a partir de 03/02/2025 em ambiente de homologação para o modelo 55 (NF-e) e a partir de 01/04/2025 em produção. O CSRT bem como o idCSRT é obtido através de um credenciamento feito no Portal da SEFAZ, como dito acima hoje somente PR que esta exigindo esse credenciamento. Os componentes listados acima já possuem duas propriedades de configuração que são utilizadas para informar o idCSRT e o CSRT. Configuracoes.RespTec.IdCSRT := 0; Configuracoes.RespTec.CSRT := ''; Notem que o IdCSRT é uma informação numérica, já o CSRT é alfa numérica. Lembrando que essas duas propriedades de configuração só devem ser informadas no componente neste momento para quem emitir NF-e no PR, se não informar a nota vai ser rejeitada: 975 - Obrigatória a informação do identificador do CSRT e do Hash do CSRT. Pode ser que no futuro as demais SEFAZ venham a exigir também não só para NF-e como também para outros DF-e. Abaixo temos as regras de validação na integra sobre o Responsável Técnico que se encontra na NT 2018/005 versão 1.40:

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

Boa tarde @Danny, Já esta no SVN.