Gr@c@

vc está com todos os fontes do ACBr atualizados?

veja esse tópico por favor

Questionei esse banco sobre a possibilidade de integração e também o link para download do material de integração, mas eles não deram nenhum retorno.

Fechando o tópico por não ter encontrado mais nenhuma legislação além da citada acima. Como meu aplicativo já é configurável, continua a cargo do cliente usar o CFOP que desejar.

tpEmit=1 ; 1 - Transportadora (emite CT-e);

As informações que não constam no layout do DAMDFe podem ser colocadas no campo reservado para "observações". O ACBr segue o padrão de DAMDFe estabelecido no Manual. Alterar a estrutura do DAMDFe deixando-o diferente do que manda o manual também pode ser motivo de multa.

Eu recebi essa resposta do SEFAZ/MG ontem. Veja se te esclarece algo: Esclarecemos que a transmissão da NFC-e já está disponível, mas o tempo de resposta para a autorização das notas está maior que o desejado, o que ainda pode impactar na transmissão em modo normal e nos serviços relacionados a consultas da NFC-e. A STI está atuando com prioridade na solução dos referidos problemas para viabilizar uma solução o quanto antes. Os contribuintes que estiverem com problemas para autorizar as notas em modo normal, poderão continuar utilizando a contingência off-line. Alertamos para o fato de que o sistema recepcionará as NFC-e emitidas em contingência off-line neste período mesmo após o prazo previsto na legislação. Com relação à escrituração das NFC-e, considerando-se os problemas ocorridos nos últimos dias que impactaram na utilização da contingência off-line por muitos contribuintes para posterior autorização das NFC-e, esclarecemos que a escrituração deve levar em conta a data de emissão do documento, ainda que divergente da data de autorização. Ademais, esclarece-se que embora o tempo de autorização da NFC-e esteja maior do que o desejável, ainda assim está sendo possível a autorização das notas. Cumpre informar ainda que o contribuinte tem o prazo até dia 15 para entrega do Sintegra e até o dia 25 para entrega da EFD, sendo que o fato de a autorização da NFC-e ser posterior a data de emissão (e em mês diferente, nesta situação), nada interfere nesse caso, sendo que contribuinte deve incluir na escrituração referente ao mês em que a operação efetivamente ocorreu (data de emissão do documento).

MG está instável para emissão de qualquer documento: NFC-e,NFe, CT-e. Ao que parece, estão mexendo no servidor de produção.

Somente hoje chegou a resposta de uma reclamação que fiz junto ao Fale Conosco do SEFAZ/MG. Segue resposta, comprovando que o problema realmente era do lado do SEFAZ/MG. " A STI informa que o arquivo de retorno estava alterado por conta da instabilidade do sistema, no entanto, afirma que foi corrigido. Favor tentar novamente. "Qualquer outra informação ou esclarecimento sobre dispositivos da legislação tributária, que não se revista das características e dos requisitos próprios de consulta (RPTA/MG, artigo 37, aprovada pelo Decreto nº. 44.747 de 03 de março de 2008), será prestado verbalmente ao interessado pela Administração Fazendária do município de circunscrição do contribuinte, conforme disposto no art. 48 do diploma legal citado”. *As dúvidas esclarecidas por esta mensagem têm caráter de orientação não gerando o efeito decorrente da consulta formal. "

Realmente, MG está devolvendo um retorno incorreto da NFC-e (isso quando vem o retorno). Mas o SEFAZ já assumiu que está com problemas, não creio que seja caso de se alterar algo no ACBr. O ACBr lê o formato conf a legislação nacional. Quem deve fazer a correção é o SEFAZ/MG. Acho que infelizmente temos que aguardar as correções que serão feitas pós paralisação.

Estou com um único caso onde o contabilista está exigindo que NF-e para consumidor final saia com o CFOP 6102 e não 6108 a fim de não pagar DIFAL. O motivo é que os clientes dessa loja são pessoas fisicas que revendem (eles não tem Inscrição Estadual). Porém a informação que tenho é essa abaixo. A solicitação desse contabilista procede? Obs: ele não conseguiu me apresentar nenhuma legislação. CFOP 6108 - Venda de mercadoria adquirida ou recebida de terceiros, destinada a não contribuinte Classificam-se neste código as vendas de mercadorias adquiridas ou recebidas de terceiros para industrialização ou comercialização, que não tenham sido objeto de qualquer processo industrial no estabelecimento, destinadas a não contribuintes. Quaisquer operações de venda destinadas a não contribuintes deverão ser classificadas neste código.

Que eu saiba a subcontratação exige o DocAnterior emitido pela transportadora contratante. Transportadora Contrantante -> emite o CT-e oficial, declarante na tag de infdoc as NF-e de origem Transportadora SubContratada -> emite o CT-e de subcontratação para efeito de recebimento declarando na tag infdoc a NF-e de origem e na tag DocAnterior o CT-e emitido pela contrantante. Note que para ser um CT-e de subcontratação, a transportadora subcontratada tem que realizar o transporte do início ao fim, caso contrário, configuraria um CT-e de Redespacho. Por esse motivo, a cidade de origem tem que ser a mesma nos dois CT-es, tanto no normal quanto no de subcontratação. Se você tentou fazer um CT-e normal e foi rejeitado pelo SEFAZ é porque o SEFAZ verificou que se o tomador também é uma transportadora emitente de CT-e.

dados retirados de um CT-e de subcontratação emitido em produção: <CFOP>6932</CFOP> <natOp>PREST.SERVICO TRANSPORTE INICIADA EM UNIDADE DA FEDERACAO DI</natOp> <tpImp>1</tpImp> <tpEmis>1</tpEmis> <tpAmb>1</tpAmb> <tpServ>1</tpServ> <cMunIni>4314902</cMunIni> <xMunIni>PORTO ALEGRE</xMunIni> <UFIni>RS</UFIni> <cMunFim>3170206</cMunFim> <xMunFim>UBERLANDIA</xMunFim> <UFFim>MG</UFFim> <retira>1</retira> <indIEToma>1</indIEToma> <toma4> ===> aqui os dados da primeira transportadora que subcontratou a segunda <rem> ===> aqui os dados do remente da mercadoria conf NFiscal <infDoc> ===> aqui vai: chave de acesso da NF-e de origem <docAnt> ===> aqui vai os dados do ct-e emitido pela primeira transportadora -<docAnt> -<emiDocAnt> <CNPJ>cnpj da primeira transportadora</CNPJ> <IE>IE da primeira transportadora</IE> <UF>MG</UF> <xNome>razao social da primeira transportadora</xNome> -<idDocAnt> -<idDocAntEle> <chCTe>311908...................</chCTe> </idDocAntEle> </idDocAnt> </emiDocAnt> </docAnt>

passei por uma situação assim, veja se esse tópico te ajuda. Em todo caso, poderíamos ajudar melhor se você postar o xml.

Coloquei todas as permissões na pasta Embarcadero. Agora consigo o inherit, use ou copy desde que o nome do form não contenha os pontos. Pelo jeito, o problema está na nomenclatura projeto.view.form.pas. Alterando para projetoviewform.pas dá certo. Apesar da permissão ter resolvido em parte, ainda parece haver um bug da IDE.

Não consigo dar copy em formulário salvo no Object Repository. Isso não ocorria no Delphi XE3. Já segui os passos do help da Embarcadero, mas ainda não encontrei o que tenho realmente que fazer. E o suporte da Embarcadero no Brasil é apenas para instalação do Delphi. O nome do form salvo no Object repository é Dangra.View.Cadastro.pas e não Dangra.View.pas, mas também ocorre com forms com nomes simples como FrmCadastro.pas. Alguma sugestão?

Pesquise por Assinatura Digital de Software. Pode ser que resolva o seu problema.

Tive esse problema semana passada pq houve uma alteração contratual da empresa. Tive que solicitar todos os meus credenciamentos para emissão de DF-e em homologação e produção. Se for esse o caso, solicite ao contador que acesse o SIARE e solicite a ativação dos credenciamentos.

Existe um tópico similar

pode ser: -falta de credenciamento em produção -O nome do emitente diferente do nome que está no certificado digital

Você instalou como Administrador? Pode ser problema de permissão.

Boa tarde. Segue definição do estado de Minas Gerais quanto as regras a critério da UF. http://www.sped.fazenda.mg.gov.br/spedmg/noticias/Disponibilizado-consulta-regras-2019.001/

Em abril de 2018, foi publicada a Nota Técnica 2018.002*, que trata exclusivamente sobre regras e penalizações para o consumo indevido na NF-e e NFC-e. Esta NT estabelece algumas regras de vigência nacional, bem como uma estrutura central de penalização. No entanto, os principais fatores, como limite de tentativas e o tempo de bloqueio do usuário, podem ser alterados por cada Sefaz estadual. Por padrão, caso a UF opte por manter os valores padrão estabelecidos pela Nota Técnica 2018.002, a Rejeição por Consumo Indevido ocorre quando: Uma NF-e ou NFC-e for enviada mais de 30 vezes e apresentar a mesma rejeição Um evento apresentar 20 vezes a mesma rejeição Uma Inutilização for enviada mais de 20 vezes e apresentar a mesma rejeição Uma NF-e for consultada mais de 10 vezes em 1 hora Um Recibo for consultado mais de 40 vezes em 1 hora Existem formas de se evitar o uso indevido via banco de dados, através de status de rejeição, nr de tentativas de envio, controlar o intervalo de tentativas de envio, não permitir que o usuário tente reenviar uma nota que está com rejeição devido a falhas de digitação ou falhas de tributação, não solicitar status de serviço antes de operações junto ao SEFAZ, etc...

Aqui em MG a Software House tem que ter IE ativa para fazer qualquer transação de DFe, mesmo em homologação com a simples finalidade de teste de software. Acredito que, no seu caso, teria que ser diretamente com o SEFAZ do seu estado.

Se for MG, você pode fazer a solicitação diretamente pelo SIARE http://www.fazenda.mg.gov.br/empresas/sistemas/siare/ ou, como segunda opção, entrar nesse link http://www.fazenda.mg.gov.br/secretaria/canais_de_atendimento/ e enviar um email solicitando a ativação do seu credenciamento.