Italo Giurizzato Junior

Bom dia Zottis, Pedi para você anexar o XML e não colar o seu conteúdo como parte da postagem. Veja o XML de envio que você colou, da para analisar alguma coisa desse jeito?

Juliana, Fiz algumas alterações no arquivo INI do provedor para que o mesmo possa ser utilizado pelas duas cidades. Ainda hoje estarei enviando para o repositório. Mas isso não garante que vai funcionar. Quanto ao erro de requisição não enviada, tente alterar o valor da propriedade de configuração: SSLLib.

Bom dia Alexandre, O problema é que o componente não esta preparado para utilizar esse método para o respectivo provedor. E tem outra coisa, analisando o arquivo XSD notei que o método Gerar desse provedor na verdade é destinado a substituir uma NFS-e já existem. Diferente do método Gerar estabelecido pela ABRASF que tem como objetivo enviar um único RPS e obter a NFS-e correspondente.

Bom dia Duarte, Favor entrar em contato com o provedor pois, segundo o Schema temos: <xsd:simpleType name="tsRegimeEspecialTributacao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2|3|4|5|6"/> <xsd:whiteSpace value="collapse"/> </xsd:restriction> </xsd:simpleType> E o XML gerado (caso 3) temos: <ns4:RegimeEspecialTributacao>6</ns4:RegimeEspecialTributacao> Logo o XML do RPS esta de acordo com o Schema e o mesmo foi rejeitado com a justificativa que o código de tributação não existe? A não ser que a rejeição esteja se referindo ao código de tributação do município e não ao código de Regime Especial de Tributação. <ns4:CodigoTributacaoMunicipio>3143906</ns4:CodigoTributacaoMunicipio> Pode ser que o código 3143906 esteja errado.

Bom dia Sandro, Alem de acrescentar a cidade no arquivo Cidades.ini será necessário criar um arquivo INI para essa cidade uma vez que ela tem o seu próprio Web Service. Para criar o arquivo INI no caso o ISSJoinville você pode tomar como base qual quer um que tenha em seu conteúdo: [ XML ] VersaoDados=2.01 VersaoXML=2.00 Isso indica que o XML segue a versão 2 do layout da ABRASF. Será necessário saber quais são as URLs de homologação e de produção, e se a URL é unica para todos os serviços ou se existe uma para cada serviço. De posse dessas URLs, ao digitar em um navegar temos acesso ao WSDL e com isso vamos descobrir as URLs dos SoapAction de cada serviço. E temos algumas informações de como montar os envelopes dos mesmos, que a parte mais chata. E para que o componente reconheça esse novo provedor será necessário realizar a alteração em alguns fontes. Vê o que você fazer, anexa os arquivos que foram alterados e criados aqui mesmo no fórum, depois juntos vamos lapidando.

Bom dia Maiquel, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Cleyton, Esse XML se refere ao RPS, precisamos dos XMLs de envio do lote e do retorno. Favor configurar o componente para salvar os arquivos de envio e de retorno. Configuracoes.Geral.Salvar := True; Outra coisa procure sempre iniciar os testes com o programa exemplo.

Bom dia Juliana, Você poderia postar as URLs de homologação e de produção informadas pelo provedor para a respectiva cidade?

Bom dia Walfrido, Tentou mudar o valor da propriedade de configuração SSLLib?

Bom dia Mauricí, Você esta com todos os fontes de todas as pastas atualizados? Você fez teses com o programa exemplo?

Bom dia Walter, Lembre-se que existe o CT-e de Redespacho e CT-e de Redespacho Intermediário. O CT-e de Redespacho é quando uma segunda transportadora pega a carga da primeira transportadora e leva até o destinatário. Acredito eu que neste caso você pode ocultar a banda que exibe os dados do Remetente e exibir os dados do Expedidor (primeira transportadora). Já o CT-e de Redespacho Intermediário é quando uma segunda transportadora pega a carga da primeira transportadora e leva até uma terceira transportadora. Neste caso você pode ocultar a banda que exibe os dados do Remetente e exibir os dados do Expedidor (primeira transportadora), por fim ocultar a banda que exibe os dados do Destinatário e exibir os dados do Recebedor (terceira transportadora). Eu também não detenho conhecimento em Fortes Report, caso contrario o ajudaria.

Bom dia a todos, É possível fazermos alterações no layout de um documento auxiliar no caso o DACTE, mas temos que tomar o cuidado, pois não podemos remover informações que constam no layout publicado pela SEFAZ, apenas acrescentar algo que o contribuinte julgue necessário.

Bom dia a todos, Se não me falha a memória já foi emitido um CT-e Substituto, e este foi feito errado, sendo assim assim não é permitido emitir um outro CT-e Substituto para substituir um CT-e Substituto. Vai ocorrer rejeição: 570 - Rejeição: CT-e a ser substituído não pode ter sido substituído anteriormente.

Bom dia ALA, No Manual do MDF-e versão 3.00, o layout do DAMDFE diz que devemos imprimir o Valor Total ou o Peso Total?

Alesteves, Ai que esta o problema, um CT-e Substituto não pode ser Substituído. Veja a regra G139 que consta na página 49 do Manual do CT-e versão 3.00 Se Tipo do CT-e= 3 (Substituição): - O CT-e substituído não pode ter sido substituído anteriormente. Se tentar vai ocorrer a rejeição de numero: 570 - Rejeição: CT-e a ser substituído não pode ter sido substituído anteriormente. Só podemos emitir um CT-e Substituto fazendo referencia a um CT-e Normal e este não pode ter sido substituído anteriormente.

Bom dia Alesteves, Pelo que entendi o CT-e Normal já possui um CT-e Substituto, correto? E no CT-e Substituto foi informado incorretamente o Tomador do serviço, correto? Se sim, para as duas perguntas, se não me falha a memória você não pode emitir um CT-e Substituto para substituir um outro CT-e Substituto.

Marcos, Favor entrar em contato com a Betha e expor o problema, diga que antes estava funcionando sem problemas e agora começou a retornar a mensagem de assinatura invalida. Pode ser alguma alteração indevida que eles fizeram ou algo que tenhamos que ajustar por conta de algumas mudanças deles.

Bom dia Diego, A fiscalização se vai ser realizada ou não é outra história, mas note que logo na cláusula primeira diz: transporte interestadual e intermunicipal. No meu entendimento todo transporte realizado é entre uma cidade e outra. A diferença é que se a cidade destino da carga se encontrar em outro estado o transporte é interestadual. E quando a cidade destino se encontrar no mesmo estado o transporte é intermunicipal. Isso me faz acreditar que o termo: operações ou prestações internas usado no paragrafo 8 se refere ao transporte dentro do município.

Bom dia Rubens, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Zottis, Favor anexar o XML de retorno de um cancelamento para que possamos analisar o problema.

Bom dia Marcos, Notei que na montagem do ID de cancelamento esta sendo informado o CNPJ formatado, ou seja, com pontos, barras e traços, tire também a formatação da Inscrição Municipal. Feito os ajustes faça novos testes.

Bom dia, Os dados do Tomador informado no grupo Toma4 realmente é diferente do Remetente e do Destinatário. Mas me diga uma coisa, você informou os dados do Receber e do Expedidor?

Pedro, O "D" no final representa o digito verificador que deve ser calculado conforme o exemplo que consta na página 94 da Nota Técnica 2013/005. A tag nDI tem que receber uma informação numérica e não alfa-numérica.

Bom dia Jair, O ambiente de produção é para estar liberado desde o dia 04/12/2017, mas a versão 3.10 vai continuar sendo aceita até 02/07/2018 segundo a Nota Técnica 2016/002 versão 1.41

Bom dia a todos, Pessoal, primeiramente vamos a página 185 do Manual da NF-e (manual versão 6.0), campo #118 - nDI temos a seguinte descrição: Número do Documento de Importação (DI, DSI, DIRE, ...) Isso nos leva a crer que a tag nDI pode ser usada para informar o numero da DI ou DSI ou DIRE entre outros. Vamos agora a Function que o Marcelo postou responsável por validar a informação informada na tag nDI: // AValue = TAANNNNNNND // Onde: T Identifica o tipo de documento ( 2 = DI e 4 = DSI ) // AA Ano corrente da geração do documento // NNNNNNN Número sequencial dentro do Ano ( 7 ou 8 dígitos ) // D Dígito Verificador, Módulo 11, Pesos de 2 a 9 AValue := OnlyNumber(AValue); Notem que o primeiro digito do numero indica o tipo de informação, ou seja, se for 2 é uma DI, caso seja 4 se trata de uma DSI. Os próximos dois digitos se refere ao ano, por exemplo: 17 se refere a 2017, em seguida temos o numero propriamente dito com 7 ou 8 dígitos e por fim o digito verificador. Vamos agora ao numero que o Pedro postou: 201721432843. Supondo que 2017 seja o ano então o restante 21432843 é o numero sequencial dentro do ano. Note que o numero sequencial tem 8 dígitos que esta dentro do esperado que é de 7 a 8. Vamos reduzir 2017 para 17 para ficar com apenas 2 dígitos e vamos acrescentar o digito 2 no inicio para indicar que se trata de um DI. "2" + "17" + "21432843" = "21721432843". Mas ainda falta calcular o digito verificar e acrescentar no final. Resultado final: 21721432843D, onde D é o digito verificador. O digito verificador é calculado através do módulo 11 com pesos variando de 2 a 9. A function ValidaDIDSI(AValue: String), foi implementada com base na página 94 da Nota Técnica 2013/005, nessa NT consta como é feito o calculo do digito verificador. Espero ter ajudado.