Jump to content

click.png

click.png

click.png

click.png click.png click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

Rodrigo Sidney

Membros
  • Posts

    100
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

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

Rodrigo Sidney's Achievements

Enthusiast

Enthusiast (6/14)

  • Reacting Well Rare
  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later

Recent Badges

14

Reputation

1

Community Answers

  1. Muito obrigado pela resposta. Concordo plenamente com você, perguntei aqui pra confirmar se não estavamos sendo muito rigorosos. Mas é exatamente esse o caminho. Temos o embasamento legal de como deve ser feito e vamos passar isso pra eles. Caso consigam um termo de ocorrência junto ao fisco pra não emitir a via do estabelecimento tudo bem, caso contrário segue a impressão automática. Obrigado a todos
  2. Exatamente, é bem melhor impimir a segunda via do que ter que atender essas condições para fazer só a guarda do XML. O problema que enfretamos é que a Sefaz de Minas não conseguiu estabilizar os webservices da NFC-e até hoje e entra muito em contingência aumentando muito o gasto de papel. Temos clientes que reclamam muito e não entendem que a culpa não é nossa e apontam que existem comércios na cidade descumprindo essa obrigatoriedade. Então, no fim das contas, estamos pensando até em permitir que o usuário desative a impressão da segunda via e se responsabilize junto a fiscalização caso tenha algum problema deixando essa responsabilidade pra ele. (Para os que estão reclamando mais e deixando claro a responsabilidade deles) Já que existe essa possibilidade de obter a declaração para fazer apenas a guarda do xml e imprimir quando fiscalização vier, talvez o nosso sistema esteja assumindo a responsabilidade sem dar essa opção.
  3. Obrigado pela resposta Juliomar, penso da mesma forma. É que em Minas Gerais estamos tendo muitos problemas com instabilidade da Sefaz então entra muito em contingência. Nossos clientes ficam reclamando de ter que imprimir a segunda via e sabemos que alguns comércios da cidade não imprimem a segunda via em contingência, apenas a via do cliente (De forma irregular). Por isso ficamos nessa encruzilhada entre deixar o sistema operando da forma correta de forma automática ou delegar a responsabilidade para o usuário. Para a ECF era mais simples porque o usuário não tinha opção, o sistema era homologado para operar seguindo 100% a legislação e não tinha choro Mas entendo a irritação deles porque a instabilidade dos Webservices da SEFAZ MG está uma novela interminável
  4. O problema do Ambiente de Homologação foi resolvido. Era realmente um problema com a Sefaz de MG Entrando em contato com a Sefaz eles deram a seguinte resposta: "Conforme parecer da superintendência responsável, informamos que tivemos algumas ocorrências de instabilidade em nossos sistemas, e que os referidos problemas já foram sanados. Favor tentar novamente." Já em relação ao ambiente de Produção os problemas continuam e continua a mensagem de aviso no site do SPED MG : http://www.sped.fazenda.mg.gov.br/spedmg/nfce/ "O ambiente de autorização de NFC-e está apresentando instabilidade. O problema também está ocorrendo na funcionalidade de consulta de NFC-e. Estamos trabalhando para solucionar o problema o mais rápido possível."
  5. Boa tarde pessoal, Essa dúvida não é em relação a implementação em si e sim sobre qual seria o comportamento mais correto nessa situação. Segundo o Manual do Danf-e da NFC-e a impressão do Danf-e pode ser dispensada em duas situações: "Ainda na hipótese contingência, deverá ser impressa uma segunda via do DANFE NFC-e que deverá permanecer a disposição do Fisco no estabelecimento até que tenha sido transmitida e autorizada a respectiva NFC-e emitida em contingência. Esta obrigação poderá, a critério da Unidade Federada, ser dispensada. Alternativamente à impressão da segunda via do DANFE NFC-e quando de emissão em contingência, o contribuinte poderá optar pela guarda eletrônica, em local seguro, do respectivo arquivo XML da NFC-e que deve possibilitar impressão do respectivo DANFE NFC-e para apresentação ao fisco quando solicitado." Então a dúvida é se o sistema deveria deixar essa decisão de imprimir ou não a segunda via da NFC-e em contingência a critério do usuário ou já fazer a impressão automática? Peço desculpas se essa pergunta estiver fora dos padrões do Fórum e pode ser removida mas é uma dúvida importante que tivemos e queria a opnião de vocês que vêem isso na prática todos os dias. Obrigado
  6. Recebi o seguinte retorno da Sefaz de MG na quinta-feira, dia 26 sobre esse problema, mas a Sefaz ainda esta com problemas: "Senhores contribuintes, boa tarde! A STI já detectou o problema e está trabalhando na solução do mesmo. Orientamos aos contribuintes que, em caso de dificuldade na autorização do documento eletrônico, utilizem a contingência." Estava esperando que a Sefaz corrigisse o problema mas como estão demorando muito vou utilizar as alterações sugeridas pelo Ítalo. Aqui o problema ainda estava acontecendo na Inutilização de NFC-e, fiz uma alteração no arquivo do Ítalo para corrigir o retorno da Sefaz também para a função TNFeInutilizacao.TratarResposta ACBrNFeWebServices.pas
  7. Também estamos com esse problema mas é um erro da Sefaz, eles tem que corrigir a mensagem de retorno. De acordo com eles a previsão para normalizar o serviço é hoje: "Informamos que o ambiente de emissão da NFC-e em modo normal encontra-se em manutenção corretiva, com previsão de retorno a partir de quinta-feira, dia 26/09. Neste período os contribuintes deverão emitir as NFC-e em modo de CONTINGÊNCIA OFF-LINE." Entrei em contato pelo "Fale Conosco" e eles disseram que essa previsão é tanto para o ambiente de homologação quanto o de produção
  8. Estou com o mesmo problema, Ao cancelar uma NFC-e utilizando o cancelamento por substituição devido a problemas com time out, mando gerar novamente e uso a função Assinar porém ao tentar cancelar recebo um erro indicando que o DigestValue do documento não confere. Realmente o DigestValue gerado no xml é diferente do anterior. Consigo verificar isso simplesmente renomeando o xml de uma nota autorizada e gerando novamente já vem com DigestValue diferente.
  9. Boa tarde Felipe, Isso parecia ser o mais correto mesmo, só fiquei na dúvida porque as documentações sempre fazem referencia a data de emissão e não achei nenhuma explicação mais detalhada. Mas nesse caso a data do movimento é que deveria ser mais importante mesmo. Utilizando a mesma data do movimento da redução Z para os Registros 60 m e para os Registros 60 d correspondentes o arquivo é aceito pelo validador sem rejeições. Muito obrigado
  10. Pessoal, ao validar o Sintegra obtenho nas críticas do validador os avisos de que existem "Registros 60 diários sem o registro mestre correspondente" Isso só acontece em meses que existem cupons fiscais emitidos depois da meia noite e antes de tirar a redução Z do dia anterior Quando isso acontece a data de emissão que consta no registro 60 d fica diferente da data de emissão do registro 60 m que deveria ser o seu pai. Ex: 60M20181019BE0911101000112316810012D04566604567600225800400000000000882990000000235023452 60A20181019BE0911101000112316810560000000000000 60D20181019BE091110100011231681272 000000000100000000000000020240000000000000000F 0000000000000 60D20181020BE09111010001123168118 000000000100000000000000004400000000000000000F 0000000000000 A última linha do exemplo representa um item de cupom emitido depois da meia noite por isso tem data do dia 20 diferindo da data do Registro 60m pai que tem data do dia 19 e causando a mensagem de erro da validação já que ele não possui registro mestre correspondente A dúvida é como devo tratar a data de emissão dos Registros 60d relativos a cupons emitidos após a meia noite e antes de tirar a redução Z do dia anterior? Onde posso encontrar mais informações sobre a composição do Registro 60m?
  11. A mesma que eu estava usando antes, foi a Sefaz que corrigiu lá, SSLCryptLib = cryWinCrypt SSLHttpLib = httpWinHttp SSLXmlSignLib = xsMsXml SSLType = LT_TLSv1_2
  12. Pessoal, aqui voltou a funcionar. Agora esta transmitindo em homologação utilizando a forma de emissão normal ? Só que continua dando problema em contingência SVC-AN com Rejeição = 2999-Falha nao tratada.
  13. As Sefaz continuam aceitando o protocolo SSL mesmo após a desativação do NF-e 3.10 tanto que sistemas como o Windows XP e Windows 7 desatualizado conseguem transmitir notas O problema é que depois que a Sefaz de Minas desativou o SSL em homologação começou a rejeitar a emissão das notas indicando "XML da area de dados codificado diferente de UTF-8" Essa rejeição não faz sentido, já verifiquei e não encontrei nada de errado
  14. Estou tendo o mesmo problema ao transmitir NF-e Retorna a Rejeição: XML da area de dados codificado diferente de UTF-8 Ao tentar transmitir usando Contingência SVC-AN recebo a rejeição: 2999 - Falha não tratada Verificando o XML no validador da Sefaz do RS não indica nenhum problema no XML nem na validação dos Schemas Antes da Sefaz desativar o SSL funcionava normalmente
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.