Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 27-12-2013 em Posts

  1. Bom dia a todos, Dentro de alguns minutos vou estar disponibilizando os fontes do componente ACBrNFe com as alterações necessárias para suportar a nova versão 3.10 da NF-e e NFC-e. A liberação do ambiente de homologação ocorreu no dia 02/12/2013 para ambos os modelos de documentos fiscais. Quanto ao de produção esta previsto a liberação para o dia 06/01/2014 ( NFC-e ) e 10/03/2014 ( NF-e ). A versão 2.00 da NF-e vai ser aceita até 01/12/2014, data também prevista para o término da versão 3.00 da NFC-e. Para deixar o componente configuravel a nivel de execução foi acrescentado uma nova propriedade chamada: VersaoDF = Versão do Documento Fiscal. Dica de configuração para que o componente gere o XML no modelo e versão correta: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve200; No exemplo acima o XML a ser gerado vai ser o da NF-e na versão 2.00 Valores aceitos pela propriedade ModeloDF: moNFe e moNFCe. Quando o modelo for moNFe, os valores aceitos pela propriedade VersaoDF são: ve200 e ve310. Quando o modelo for moNFCe, os valores aceitos pela propriedade VersaoDF são: ve300 e ve310. Como o componente esta ganhando uma nova propriedade, se faz necessário a compilação do pacote de instalação do mesmo ou a sua reinstalação com o ACBrInstall, caso contrario essa nova propriedade não vai aparecer no Object Inspector. Favor reportar erros e problemas.
    1 ponto
  2. Boa tarde. Primeiro não precisa fazer outro post edite o anterior com as novas informações, pois senão sera considerado spam. Segundo qual TEF você esta utilizando. Terceiro ser for dial e multicartão esta correto o funcionamento do programa.
    1 ponto
  3. tricon.paulo, Recompile o PCN2.dpk novamente que deve resolver.
    1 ponto
  4. Bom dia a todos, Notem que chegamos a um impasse. Se informamos a Inscrição Municipal sem o hifem, o componente valida o XML pois esta em conformidade com o Schema, mas por outro lado o WebService ao receber o XML o rejeita pois a IM não confere com a que esta no cadastro (com hifem). Se informarmos a IM com o hifem (conforme cadastro junto a prefeitura) o componente não valida e consequentemente o XML não é enviado. Ariel essa história de: "informaram que é impossível alterá-lo" para mim é falta de vontade. E fica claro que a implantação da NFS-e ( prefeitura e provedor ) foi feita com pouca troca de informação. O provedor deveria ter comunicado a prefeitura que a Inscrição Municipal só pode conter digitos no cadastro do contribuinte, caso contrario o XML não vai ser processado. Portanto existem algumas soluções para esse problema: 1. A prefeitura corrigir o cadastro; 2. O provedor alterar a rotina de validação, ao comparar a IM do XML com o cadatro, remover da linfomação lida o hifem; 3. O provedor alterar o Schema fazendo com que a TAG IM aceite uma string e não somente digitos. 4. Você realizar a alteração no Schema. Eu acredito que o provedor não vai realizar alteração nenhum, pelo simples fato de que se esta funcionando, não há motivo de alteração. A prefeitura já deixou claro que não vai alterar, não porque é impossível, mas por falta de vontade. Portanto sobrou você meu caro Ariel.
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.