ncc.star

Oi Italo! Acredito que eu me expressei mal, não é colocar "90 - ICMS outros", é só colocar o 90 na frente da frase que já está, ficando assim: "90 - ICMS DEVIDO A UF DE ORIGEM DA PRESTACAO, QUANDO DIFERENTE DA UF DO EMITENTE" Encontrei também um erro de ortografia em outro CST: 81 - ICMS DEVICO À OUTRA UF

Boa tarde Italo! Concordo e inclusive foi isso que eu justifiquei pra ele. Acontece que daí ele me questionou que no campo 243, a Classificação Tributária do Serviço é 90 - ICMS outros, daí ele me falou que deveria ser da forma que alterei acima.

Quando for cstICMSOutraUF no DACTE estão me questionando que deveria ser: '90 - ICMS DEVIDO A UF DE ORIGEM DA PRESTACAO, QUANDO DIFERENTE DA UF DO EMITENTE', A principio achei que não seria correto, entretanto mesmo quando for outras UF o CST é realmente 90 - ICMS outros. Fiz a alteração e o arquivo está em anexo para avaliação. pcnConversao.pas

Testando DistribuicaoDFe do MDF-e ocorreu a seguinte rejeição: "Usar somente o namespace padrão do MDF-e" Alterei em pmdfeDistDFeInt, linha 102, alterei Gerador.wGrupo('distDFeInt ' + NAME_SPACE + ' versao="' + Versao + '"'); para Gerador.wGrupo('distDFeInt ' + NAME_SPACE_MDFE + ' versao="' + Versao + '"'); pmdfeDistDFeInt.pas

Agora parece ter voltado ao normal.

Estamos com esse mesmo problema. O MDF-e está cancelado e não deixa cancelar o CT-e porque diz que está vinculado com um MDF-e.

Quando vamos autorizar o MDF-e dá o retorno: <cStat>999</cStat><xMotivo>Falha no processo de validacao MDF-e</xMotivo>

Tentei encerrar um MDF-e em homologação, também obtive este erro não catalogado. Também estamos enfrentando problemas na autorização de MDF-e, tanto em homologação como em produção.

Eles liberaram a contingência. Em contingência autoriza normal.

Estamos com o mesmo problema. Estava autorizando até ontem, hoje começou a dar problema. Parece ser algum problema no SEFAZ do PR, pois em homologação no sefaz do RS está normal.

Verifiquei que no site http://iws.ibpt.org.br/Help que há web services disponíveis para consultar as tabelas de imposto. Alguém conseguiu realizar alguma consulta? Há alguma previsão de adicionar este recurso no componente ACBrIBPTax?

Com o MDF-e acontece o mesmo. Segue o XSD alterado do MDF-e. Envio também novamente XSD do CT-e. Não sei porque antes anexou 2 arquivos, eu tinha excluído 1. tiposGeralMDFe_v1.00-OPENSSL.xsd tiposGeralCTe_v2.00-OPENSSL.xsd

Em anexo o arquivo XSD alterado. Acredito que poderia ser colocado no Trunk2, pelo que eu vi na NF-e foi feito a mesma coisa. O que diferencia a validação dos dados utilizando a versão Capicom e OpenSSL? Essa diferença poderia afetar outras verificações? Meu receio é que usando OpenSSL teria outros erros que não ocorreriam na versão Capicom, a exemplo do ISENTO. tiposGeralCTe_v2.00_OPENSSL.xsd tiposGeralCTe_v2.00-OPENSLL.xsd

Boa tarde. Migrei para o Trunk2 e estou testando utilizando openssl (sempre usei capicom) e tive o mesmo problema relatado pelo Diego. Quando a IE do destinatário for ISENTO ocorre o erro "Elemento 'IE': 'ISENTO' is not a valid value of the local atomic type." Já utilizando Capicom valida normalmente. Se alterar o schema invertendo a posição da seguinte forma: <xs:pattern value="ISENTO|[0-9]{0,14}|PR[0-9]{4,8}"/> autoriza normal. É só esse caso que ocorre esse problema, ou tem mais coisas a alterar no schema quando usa OpenSSL? Seria o caso de ter duas versões de schemas?

O problema que a legislação dá essa brecha para os estados obrigarem ou não a emissão do MDF-e. Até então nós tínhamos clientes que nem sabiam o que era MDF-e porque nunca foi exigido deles, mesmo em cargas fracionadas. Parece que nesse caso de transporte intermunicipal é "equivoco" do governo dos estados que gostam de arranjar formas de aumentar a arrecadação. Mesmo se não tiverem postos de fiscalização, essa brecha abre oportunidade para realizar fiscalizações e multarem. Se entrarmos em contato com eles para pedir o "porque é obrigatório?", se encontrarmos alguém que responda, a resposta vai ser "por que sim".

Olá Ítalo. Não sei se já viu ou se já foi discutido aqui no fórum a respeito do MDF-e começar a ser obrigatório para CT-e Lotação. Já tem alguns embarcadores exigindo e também relatos que alguns estados já estão exigindo também. Quando eu ouvi a primeira vez achei que não fazia sentido até ler no link abaixo. Acredito que essa obrigatoriedade se dê por causa do projeto Brasil-ID, pois a sua integração é com o Ambiente Nacional MDF-e. Na minha opinião, lá se vai uma das premissas do documento eletrônico que é a economia de papel, pois cada carga, independente se é lotação ou não vai ter que ter o MDF-e. https://www.confaz.fazenda.gov.br/legislacao/ajustes/2010/aj_021_10

Olá! Estou com o mesmo problema para importar o retorno do Banco do Brasil e fazendo essa alteração sugerida pelo Fenix resolveu. Será alterado no SVN também?

Olá. Percebi uma diferença no XML salvo e no autorizado que eu baixei do portal da NF-e. O XML salvo fica com as tags cEAN dessa forma: <cEAN/> e <cEANTrib/> O XML autorizado fica assim: <cEAN /> e <cEANTrib /> Não consegui descobrir porque isso acontece. Isso pode ocasionar problemas na assinatura digital? Para vocês também está ocorrendo isso?

Perfeito! Ficou Ok. Muito obrigado!

Oi Italo. E é possível alterar para se não encontrar conteúdo nessa tag, não entrar aí? Ou fazer de outra forma que não dê o erro?

Fiz um teste agora. Leitor fica um XML somente com as tags: <Codigo>, <Mensagem> e <Correcao> Anexei o conteúdo. Leitor.xml

Bom dia! Em pnfsConsSitLoteRpsResposta.pas, aprox. na linha 227: InfSit.FMsgRetorno.FIdentificacaoRps.Tipo := Leitor.rCampo(tcStr, 'Tipo'); no Leitor.rCampo(tcStr, 'Tipo') o retorno está retornando conteúdo vazio, então eu fiz essa alteração: if Leitor.rCampo(tcStr, 'Tipo')<>'' then InfSit.FMsgRetorno.FIdentificacaoRps.Tipo := Leitor.rCampo(tcStr, 'Tipo'); Segue em anexo o arquivo para avaliação para colocar no svn. pnfsConsSitLoteRpsResposta.pas

Bom dia Ítalo. Eu encaminhei os arquivos no seu e-mail, pois são XML em produção e eu não posso disponibilizar aqui.

Olá Ítalo. Além desse detalhe, aleatoriamente acontece algo estranho. Antes de enviar o CT-e pra SEFAZ eu salvo uma cópia em um diretório de log dessa forma: ACBrCTe1.Conhecimentos.Items[0].SaveToFile(fileName); Além disso eu também mantenho o XML no banco de dados. Acontece que o arquivo que eu salvo em disco e também no banco de dados, a tag CTe fica assim: <CTe xmlns="http://www.portalfiscal.inf.br/cte"> já no arquivo que eu baixei do site da SEFAZ autorizou somente assim: <CTe> Comparei os dois XML e a única diferença nesse caso foi isso. Ocasiona assim problema no cálculo do DigestValue. Não sei o que fazer.

Ola Ítalo. O arquivo que fica em "Configuracoes.Geral.PathSalvar" possui o atributo ID. Já o arquivo que fica dentro de "Configuracoes.Arquivos.PathCTe" ficou sem o atributo ID.