Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

Wesley Oliveira

Membros
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

7 Neutral

About Wesley Oliveira

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Location
    Vila Velha/ES

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Acabei de achar o problema. Foi feito uma alteração no código do ACBr pra Assinar o XML no ato da Validação, porém o nosso sistema faz uma validação de dados antes de permitir o envio, o que fazia a assinatura do xml. Após essa validação é onde estava sendo definido o tipo de emissão para 7 - SVC e, ao validar novamente, por já ter sido assinado, não fazia de novo. Atualizei o fonte do ACBr e reverti essa alteração manual e o XML foi autorizado sem problemas. Agradeço demais a disposição em ajudar. Pode considerar resolvido. Após esse procedimento, pude identificar que o XML que es
  2. Aqui o XML solicitado. 0-env-lot.xml
  3. Boa tarde, Estou com problema ao enviar NF-e para o ambiente SVC-RS a partir de clientes da Bahia. Os servidores da SEFAZ-BA foram desabilitados desde ontem devido a ataques, então direcionamos os clientes a utilizarem a emissão em contingência pelo ambiente SVC-RS. O problema que estou tendo é que TODAS AS NOTAS estão sendo rejeitadas com código 297 - Assinatura diferente do calculado, mas as notas enviadas com os mesmos parâmetros (exceto ambiente) para qualquer outra SEFAZ está autorizando normalmente. Inclusive, quando passo os XML gerados pelo meu sistema no validador da SEFAZ-R
  4. Já entendi o que estava ocorrendo. Eu não havia atualizado a unit pcnSignature. Estou com outro erro agora, de rejeição 851. Vou continuar fazendo testes.
  5. Boa noite. Após a mudança de obrigatoriedade do QRCode, estou recebendo a rejeição 297 quando tento enviar o xml. Seguem em anexo 2 XMLs referente ao mesmo CT-e (Montados ligeiramente diferentes) e ambos retornam essa rejeição. Já verifiquei os cadastros e não encontrei nada com caracteres especiais e/ou quebras de linha, espaços em branco no início ou no fim, nada disso. Aqui estão as configurações que estou usando no componente: fAcbrCte.Configuracoes.Geral.Salvar := True; fAcbrCte.Configuracoes.Geral.VersaoDF := ve300; fAcbrCte.Configuracoes.Geral.Ident
  6. Obrigado, foi bastante detalhado e esclarecedor. Estou mostrando estes argumentos ao pessoal do suporte aqui para que entrem em contato com o cliente que solicitou a mudança no sistema. Diz o suporte que, segundo o cliente, algumas empresas já estariam adaptando os Danfe para acomodar as "novas" descrições, mas ainda não recebi nenhum material desse para que eu pudesse ao menos postar aqui para vocês. Eu, particularmente, compartilho da idéia que a única coisa obrigatória nesse campo é o código, que já está corretamente sendo enviado e exibido. Mais uma vez, obrigado pelas explicaçõ
  7. Foi o que pensei. Até entrei em contato com uma consultoria fiscal que temos, mas o espaço para descrição é pouco e não permite anexos, não consegui dar todos os detalhes e tudo que recebi de resposta foi que "se a NT diz que é assim, tem que ser assim". Aguardemos as próximas opiniões. Obrigado!
  8. Olá a todos. A NT 2018.005 trouxe uma alteração na descrição do campo de Modalidade de Frete para algumas descrições bem grandes, por sinal. Entretanto, o layout atual do DANFE que o ACBr disponibiliza tanto não cabe as novas descrições, quanto a função que converte o tipo de modalidade na descrição também não segue o que está ditado na NT (arquivos atualizados hoje, 16/09). Há alguma previsão de alteração ou esta alteração não é obrigatória, como parece ser? Abaixo, a função atualizada do ACBr que faz esta conversão, vs. as descrições da NT. Obrigado pela atenção. function modFr
  9. Bom dia! Tenho os fontes atualizados do DANFE e estou em dúvida sobre o layout: Tanto o manual versão 6.00, quanto a última NT de layout (Ajustes Sinief 04/2019) retiraram dos grupos F (Local de Retirada) e G (Local de Entrega) alguns dados, tais como: Razão Social; IE; CEP; Telefone; E-mail; País; Porém, o DANFE agora tem espaço para exibição da Razão Social, IE, CEP e Telefone. Não achei em lugar nenhum se houve alguma alteração mais recente no layout do DANFE para excluir estes campos ou se a SEFAZ realmente comeu mosca. Alguém sabe me dizer?
  10. Bom dia. Tentei aqui e continua com o mesmo erro..
  11. Olá! Estou começando a implementação do Reinf no meu sistema e ao tentar gerar os XML (Assinatura) está dando o erro "Falha ao localizar o nó de Assinatura" Tentei comparar com o que está sendo feito na aplicação exemplo do Reinf, mas aqui pra mim o exemplo apresenta o mesmo erro. A configuração do ACBr feita no sistema é essa: { Configurações Gerais Reinf } fACBrReinf.Configuracoes.Geral.FormaEmissao := teNormal; fACBrReinf.Configuracoes.Geral.ExibirErroSchema := True; fACBrReinf.Configuracoes.Geral.SSLLib := libCapicom; fACBrReinf.Configuracoes.Geral.Ver
  12. A quem interessar, precisei alterar manualmente a linha (pcnNFeW.pas): //Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 0, nfe.Cobr.Fat.vDesc, DSC_VDESC); Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC); Para "forçar" gerar a tag vDesc mesmo com o valor zerado. Assim parou de dar a rejeição 905 e também de criticar o layout do campo vDesc.
  13. Boa tarde pessoal! Estou com problema com essa tag Fat também. Eu estou informando conforme a nota técnica pede: <cobr> <fat> <nFat>15951</nFat> <vOrig>2874.90</vOrig> <vLiq>2874.90</vLiq> </fat> <dup> ... </dup> </cobr> Mas continuo recebendo mensage 905 Rejeição: Campos do grupo Fatura não informados. Estou em ambiente de Homologação, Espírito Santo. Comparei com o XML que o amigo marcoprodata postou anteriormente e está com a estrutura correta. Tentei até forçar a criação da tag <vDesc>
  14. No meu caso descobri que o arquivo ACBrNFeServicos.ini estava com um erro (não sei se é padrão ou se foi alterado aqui, usamos o Delphi 7). Nas linhas [WSDL_V4_MG] e [SOAP_V4_MG] a url estava faltando um "L" (portalfisca.inf.br). Apenas nessas linhas eu identifiquei esse problema.
×
×
  • Create New...