Italo Giurizzato Junior

Bom dia Diego, Não vou aceitar a sua correção, pelo simples fato do respectivo provedor possuir 3 métodos de envio: Enviar, EnviarSincrono e Gerar. Abra o link abaixo através de um navegador e vera os serviços: RecepcionarLoteRpsRequest, RecepcionarLoteRpsSincronoRequest e GerarNfseRequest. http://notabelford.modernizacaopublica.com.br:8054/homologacao/webservices/NFEServices.jws?wsdl Métodos estes definidos no arquivo INI como sendo Recepcionar, RecSincrono e Gerar. A sua alteração MATA o método Enviar (Recepcionar), pois você esta deixando ele igual ao Gerar. Segundo o padrão ABRASF o método Enviar nos permite o envio de um lote com até 50 RPS no modo assíncrono, já o EnviarSincrono nos permite o envio de um lote com até 50 RPS no modo síncrono, e o Gerar nos permite o envio de apenas um RPS no modo síncrono. Por favor refaça a sua alteração.

Bom dia Sergio, Segundo o Manual do CT-e versão 3.00 o grupo <peri> que contem as informações sobre produtos perigosos, agora só será gerado caso o modal for aéreo. Vide páginas 191-193. No MDF-e se você estiver alimentando corretamente o componente é para ser gerado sim o grupo <peri>. Anexe o fragmento de código do MDF-e onde você alimenta o componente com as informações sobre produtos perigosos.

Bom dia Claudio, Depois que alterou o ACBr.inc, você reinstalou os componentes com o ACBrInstall_Trunk2?

Zottis, Você estava com problemas em um provedor e agora esta postando sobre outro. Por favor não misture as coisas, para um novo problema, favor criar uma nova postagem. Pois agora eu não sei em qual provedor esta ocorrendo o erro HTTP 500.

Alexandre, Veja como esta no Schema: Analisando melhor o Schema pode ser usando para substituir ou não, mas veja esta bem diferente da estrutura de um RPS. <xsd:element name="GerarNovaNfseEnvio"> <xsd:complexType> <xsd:sequence> <xsd:element name="Prestador" type="tcIdentificacaoPrestador" minOccurs="1" maxOccurs="1" /> <xsd:element name="InformacaoNfse" type="tcInfNovaNfse" minOccurs="1" maxOccurs="1" /> <xsd:element ref="dsig:Signature" minOccurs="0" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:complexType name="tcInfNovaNfse"> <xsd:sequence> <xsd:element name="NaturezaOperacao" type="tsNaturezaOperacao" minOccurs="1" maxOccurs="1" /> <xsd:element name="RegimeEspecialTributacao" type="tsRegimeEspecialTributacao" minOccurs="0" maxOccurs="1" /> <xsd:element name="OptanteSimplesNacional" type="tsSimNao" minOccurs="1" maxOccurs="1" /> <xsd:element name="IncentivadorCultural" type="tsSimNao" minOccurs="1" maxOccurs="1" /> <xsd:element name="Status" type="tsStatusNfse" minOccurs="1" maxOccurs="1" /> <xsd:element name="Competencia" type="xsd:dateTime" minOccurs="1" maxOccurs="1" /> <xsd:element name="NfseSubstituida" type="tsNumeroNfse" minOccurs="0" maxOccurs="1" /> <xsd:element name="OutrasInformacoes" type="tsOutrasInformacoes" minOccurs="0" maxOccurs="1" /> <xsd:element name="Servico" type="tcDadosServico" minOccurs="1" maxOccurs="1" /> <xsd:element name="Tomador" type="tcDadosTomador" minOccurs="0" maxOccurs="1" /> <xsd:element name="IntermediarioServico" type="tcIdentificacaoIntermediarioServico" minOccurs="0" maxOccurs="1" /> <xsd:element name="ContrucaoCivil" type="tcDadosConstrucaoCivil" minOccurs="0" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="id" type="tsIdTag" /> </xsd:complexType> <xsd:complexType name="tcInfRps"> <xsd:sequence> <xsd:element name="IdentificacaoRps" type="tcIdentificacaoRps" minOccurs="1" maxOccurs="1" /> <xsd:element name="DataEmissao" type="xsd:dateTime" minOccurs="1" maxOccurs="1" /> <xsd:element name="NaturezaOperacao" type="tsNaturezaOperacao" minOccurs="1" maxOccurs="1" /> <xsd:element name="RegimeEspecialTributacao" type="tsRegimeEspecialTributacao" minOccurs="0" maxOccurs="1" /> <xsd:element name="OptanteSimplesNacional" type="tsSimNao" minOccurs="1" maxOccurs="1" /> <xsd:element name="IncentivadorCultural" type="tsSimNao" minOccurs="1" maxOccurs="1" /> <xsd:element name="Status" type="tsStatusRps" minOccurs="1" maxOccurs="1" /> <xsd:element name="RpsSubstituido" type="tcIdentificacaoRps" minOccurs="0" maxOccurs="1" /> <xsd:element name="OutrasInformacoes" type="tsOutrasInformacoes" minOccurs="0" maxOccurs="1" /> <xsd:element name="Servico" type="tcDadosServico" minOccurs="1" maxOccurs="1" /> <xsd:element name="Prestador" type="tcIdentificacaoPrestador" minOccurs="1" maxOccurs="1" /> <xsd:element name="Tomador" type="tcDadosTomador" minOccurs="0" maxOccurs="1" /> <xsd:element name="IntermediarioServico" type="tcIdentificacaoIntermediarioServico" minOccurs="0" maxOccurs="1" /> <xsd:element name="ContrucaoCivil" type="tcDadosConstrucaoCivil" minOccurs="0" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="id" type="tsIdTag" /> </xsd:complexType>

Alexandre, Quanto ele estar pronto para uso é uma coisa, mas qual é a sua finalidade? Pois pelo Schema a finalidade dele não é recepcionar um RPS e converte-lo a NFS-e e sim realizar a substituição de uma NFS-e já existente por outra.

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.