Painel de líderes

Resposta da SEFAZ MG: Ref. a mensagem: 424.294 - DOCUMENTOS ELETRÔNICOS > CT-e OS > TRANSMISSÃO Senhor(a), Conforme retorno do setor responsável, a versão 3.00a do CT-e, subirá amanhã, dia 28/08/2019 até o meio dia. Favor aguardar. À disposição.

No portal da SEFAZ-MG consta que seria implantado ontem a partir das 09:00h. http://www.sped.fazenda.mg.gov.br/spedmg/cte/ Mas não consta aviso que realmente fizeram a implantação. Fiz testes há pouco e aparentemente ainda não foi atualizado.

Bom dia. Como empresa desenvolvedora temos apenas o CNPJ da própria habilitada para homologação (e a política da empresa não permite uso de dados do cliente para testes). Portanto a mesma empresa que emite CTe na homologação, emite a NFe também. Recebi novo retorno da SEF hoje informando que fizeram mais correções ontem no ambiente de homologação, e consegui emitir alguns hoje, e outros ainda com algumas rejeições ainda não façam muito sentido. O problema era lá mesmo (MG tem um histórico de dar dor de cabeça pra gente a cada nova implementação de recurso)

Bom dia Maikon, Essa tag nos schemas da versão 3.00 ela era obrigatória, já na versão 3.00a ela deixou de existir. Isso faz com que tivéssemos 2 schemas, um para cada ambiente. Eu mudei o schema deixando a tag como opcional, desta forma seria possível usar o mesmo schema para ambos os ambientes. Pois atribuindo o valor zero ao campo pICMSInterPart ele não seria gerado (para o ambiente de homologação) e atribuindo o valor 100 para ser gerado no ambiente de produção. Fiz uma alteração no componente para deixar a geração da tag opcional em vez de obrigatória. Agora com a liberação da versão 3.00a em produção, podemos passar a usar o schema da SEFAZ e devemos comentar a linha que gera a respectiva tag.

Boa noite correção no svn obrigado

Também estou com esse problema, ja acertei a tag de partilha, está zerado, esse problema está ocorrendo com um cliente em MG, está passando o Qrcode tmb.,aqui tmb fiz a troca do schema de homologação e o outro processo e ainda continua o erro de falha nos schema 7763-env-lot.xml No seu xml, só remover a tag de icms de partilha que é pra resolver

Só pra avisar. Realmente era problema no sefaz-mt. Desculpem o transtorno e obrigado pela atenção.

Boa tarde. Você chegou a visualizar o manual do ACBrMonitorPlus? https://acbr.sourceforge.io/ACBrMonitor/ModeloCFeINI.html Att.

Como disse, vou fazer os testes de homologação, dando tudo certo anexo o .INI. Dercide.

Boa tarde. Você chegou a fazer a inclusão e testar? Se sim, anexe o ini alterado ao tópico. Att.

Boa tarde Douglas, Que eu me recordo o layout seguido pela prefeitura de Blumenau não é ABRASF, só se mudou agora. Favor verificar se esse exemplo de XML realmente é do provedor NotaBlu. Pois os Schemas de validação que temos não bate com esse layout.

Bom dia Ítalo, era esta alinha de raciocínio que eu estava! Vou eu mesmo entrar em contato com a seguradora e tentar entender melhor oque ela esta querendo. Obrigado pela ajuda!

Deixando um retorno, após a troca pela nova DLL, as vendas voltaram ao normal. Vou deixar a DLL para quem precise. dllsat.rar

Pessoal, bom dia, achei o erro...vou explicar Meus clientes pedem que seja possível "ver" o arquivo antes de enviar, então o que faço, na NF-e, carrego o componente com os dados da nota, e coloquei um botão para visualizar, com o seguinte código: dmNfe.nfe.NotasFiscais.GerarNFe; dmNfe.nfe.NotasFiscais.Imprimir; Funcionar normal, mas no CT-e dava o erro de geração quando eu fazia a mesma coisa (no caso , gerando o cte e tentando dar um preview). Corrigi assim : dmCte.cte.Conhecimentos.GerarCTe; dmCte.cte.Conhecimentos.Items[0].GravarXML('visualizado.xml',dm._pathsys); dmCte.cte.Conhecimentos.Clear; dmCte.cte.Conhecimentos.LoadFromFile(dm._pathsys+'visualizado.xml'); dmCte.cte.Conhecimentos.Imprimir; Gero um arquivo temporário que seria o XML do ct-e e carrego o mesmo para o preview. Agradeço a atenção de todos. Obrigado.

Bom dia Italo, Reinstalei todo o ACBr e fiz as atualizações no aplicativo e funcionou corretamente, o envelope do método RecepcionarLoteRpsRequest deveria estar mesmo com problema, muito obrigado.

Testei aqui também e consegui transmitir e cancelar em homologação

Bom dia Chegou a verificar como é obtido o retorno utilizando o Demo da NFe do Projeto ACBr? Neste exemplo pode ver como ler todas as tas de retorno do XML, incluindo o cStat...

Então, tive um baita problema desde ontem tentando passar algo lá. Como eu troquei meu schema antigo do homologação pro outro, passou a dar problema, mas resumindo, eles não alteraram nada, nem o qrcode nem a tag de icmsinterpart... Ta passando tudo como antes apenas. A sefaz de MG, é a que mais dá problema entre todas que eu tenho aqui

Bom dia Italo vou atualizar e fazer novos testes e mando um retorno muito Obrigado.

Bom dia Daniel, Favor atualizar os fontes e faça novos testes.

Funcionou. Muito obrigada Sr. Juliomar.

Tente em outra máquina... se o problema persistir contacte o fabricante

Bom dia, Italo. Sim a empresa possui tanto NF-e quanto CT-e. De início a Sef - MG reconheceu que havia um erro na validação mesmo, e que havia corrigido no servidor de homologação. Então fiz a transmissão novamente e o retorno foi o 873 mesmo a data do hash estando superior a data de transmissão do CT-e, como exigido na NT. Nesse caso já reportei novamente a eles e estou aguardando respostas. Ainda vou testar o cenário que a Jeanny falou para verificar se comigo também vai voltar a dar a rejeição 999.

Bom dia se estiver usando o Fast-Report o motivo é que deve recompilar os pacotes usando o Recompile.exe mudando para Brazil a Linguagem assim as caixas de diálogos passarão ao nosso idioma.

Se for registrar a MIDAS.dll tem que ver se está com a versão correta de acordo com a versão do Delphi que está usando. Você pode também declarar MidasLib no uses do seu .dpr assim não precisa registrar a dll.

há é subi uma alteração sugerida agora a pouco será que não ajudaria? atualiza o svn e reinstala o ACBr

Boa Noite Jésika, Isto ocorre por que você está passando o parâmetro em inglês (true), passando este em português (verdadeiro) a caixa de diálogo citada ficará em português.

Enviei correção para o repositório, rev. 17533. A forma que encontrei foi usando a var. TotalPages e ativando o DoublePass, assim como é feito no DANFE. Favor atualize os fontes e teste com o fr3 do repositório.

eu testei quando eu tinha um celular mais antigo e funcionou, com o novo android não testei, da uma pesquisada sobre Android Permission pode ser que te ajude. ou de uma aprofundada no assunto com base nos links que te passei no post anterior. sobre permissões: http://docwiki.embarcadero.com/RADStudio/Rio/en/Android_Permission_Model se vc usa delphi menor que 10.2: https://github.com/CarlosHe/AndroidPermission não sei se o seu problema é com permissão, mas um dos principais problemas que vejo é esse por causa da permissão de usar a câmera e salvar arquivos.

Sem dúvida. A implementação só deve estar em ambiente de produção no dia especificado.

Veja o tópico abaixo, parece o mesmo caso:

Bom dia Paulo, Certificado A3 (Cartão ou Token) é problemático, na medida do possível procure sempre orientar os seus clientes a comprarem o certificado A1. Apesar do prazo de validade ser apenas de 1 ano, mas as vantagens são maiores e não costumam dar dor de cabeça.

Bom dia, Todo MDF-e precisa ser cancelado ou encerrado. Só podemos cancelar um MDF-e caso o transporte não tenha sido realizado. Logo não é o caso, uma vez que o transporte da carga teve inicio, mas infelizmente não chegou ao seu destino. Já o Encerramento de um MDF-e não significa que a carga foi entregue. Pois devemos encerrar um MDF-e quando ocorre mudanças, como por exemplo, acréscimos ou retirada de mercadorias da carga original, mudança de caminhão, ou mudança de motorista. Que eu saiba não existe um evento emitido pela transportadora que diz que ocorreu um sinistro e que a carga não chegou ao seu destino.

Obrigado pela resposta, tive que instalar o certificado digital e leitor no servidor também, de outra forma não consegui fazer funcionar... Grato

Boa tarde Adilson, Favor entrar em contato com o provedor e questionar sobre o procedimento de realização de testes. Me parece que existe um CNPJ e senha especifico para o ambiente de homologação.

Boa tarde Jean, Estranho, no caso do Ginfes ele retorna o XML da NFS-e e coloca na propriedade XMLNFSe para que você possa salvar o mesmo no Banco de Dados. Mas lembre-se que o XML da NFS-e só é retornado quando é realizado a consulta ao Lote ou a Consulta a NFS-e por RPS ou a Consulta a NFS-e.

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Bom dia Ricardo, A geração do código (cNF) recomendado pela SEFAZ é de que ele seja um numero aleatório. Essa recomendação vem de longa data, não é de agora. Lhe pergunto: Qual é a dificuldade de gerar esse código usando a função GerarCodigoDFe que nós implementamos, que por sinal além de gerar o código já valida o mesmo? Qual é a dificuldade de após gerar o mesmo salvar juntamente com os demais dados da nota? Agora, quem desejar criar a sua própria rotina de geração de código, seja através de data, hora, data de aniversário fique a vontade.

Boa tarde, edsonsimoespereira. Veja o tópico abaixo:

Aqui temos um verificador de updates rodando com o Windows em todas as máquinas e notificando caso encontre uma nova atualização. (não é necessário estar em todos os PC's. Mas como isso é instalado junto com o sistema e na prática não muda muita coisa. Deixamos assim) Quando o usuário clica para instalar a atualização em uma máquina qualquer, exibe uma janela com as melhorias, novidades, correções... Após o término do download do update, é gravado em um banco de dados especifico e temporário as informações do update, como: Nome, versão/build, data, novidades, MD5. Também gravamos o executável do InstallShield nesse banco (sim, gravamos um arquivo de mais de 700MB). Conforme print abaixo. Quando termina a instalação do update e o usuário inicia o sistema, os scripts necessários para o funcionamento da nova versão/build são rodados no SQL Server. (não precisa ser o servidor) Depois do banco de dados também estar atualizado, as demais máquinas "acusam" diferentes versões entre o executável e o banco de dados, possibilitando a atualização do sistema nesses outros computadores. Nesse momento ao invés de baixar o update novamente, acessamos o banco de dados temporário onde tem o arquivo já baixado e apenas instalamos. Quando o usuário abrir o sistema, os scripts não serão rodados pois já foram. Observação 01: Não importa se mais de um computador baixar a atualização ao mesmo tempo, antes de gravar o arquivo do InstallShield no banco, é verificado se ele já não existe. Observação 02: Os updates são controlados por CNPJ, UF... Já que as vezes é necessário uma correção imediata apenas no estado X. E ainda verificamos se o cliente está apto a receber o update já que o mesmo pode ter problemas financeiros, contrato de manutenção cancelado (não dando direitos a updates de versão, apenas build dentro da versão que o cliente adquiriu). Observação 03: Depois de todos os PC's atualizados, os dados da versão nova e o arquivo da versão são apagado desse banco de dados temporário. Observação 04: Existem atualizações criticas, nesse caso não fica a critério do usuário a instalação. O próprio atualizador, se encarrega de baixar e executar a instalação. Observação 05: Após o término da atualização no PC, solicitamos o registro da licença novamente para controlarmos qual é a versão que o cliente está utilizando. (de forma online e transparente já que as licenças são controladas por um HWID e não por um serial previamente cadastrado). Aqui controlamos por MD5. Ou seja, ao executar o sistema e algum arquivo (bpl, exe, dll..) não bater com o MD5 do executável. Não será possível executar o sistema.

Pessoal bom dia! Depois de muito sofrimento e dor de cabeça consegui, com a ajuda de um amigo, solucionar o problema. Apenas precisa dar permissão ao Usuário Todos, com Controle Total na pasta C:\Windows\System32\spool\PRINTERS onde a impressora está instalada fisicamente e o erro de File Access denied está resolvido. Simples assim...