Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 27-12-2013 em todas as áreas

  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.

The popup will be closed in 10 segundos...
The popup will be closed in 10 segundos...