Gr@c@

Essa mensagem estava dando por falta da nova cadeia de certificado v2. Vocês instalaram?

Janis A contingencia FSDA pode ser impressa no A4 comum? Não seria o papel moeda? Qual o procedimento que você está adotando no componente ACBrCTe para emissão nessa modalidade? No plantão fiscal aqui de MG, me informaram que, quando não fosse possível emitir CT-e na modalidade normal, poderia emitir um CTRC modelo 8, uma vez que o CT-e em MG ainda é voluntário.

Segue abaixo comunicado do SEFAZ/MG Prezados, Nos termos da Nota Técnica 2011/006 informamos que os WebServices utilizados na transmissão de eventos relacionados à NF-e foram alterados. Os endereços novos para configuração dos aplicativos emissores de NF-e passam a ser: • Ambiente de Homologação: https://hnfe.fazenda.mg.gov.br/nfe2/ser ... pcaoEvento • Ambiente de Produção: https://nfe.fazenda.mg.gov.br/nfe2/serv ... pcaoEvento Aproveitamos para alertar que o prazo máximo para a adaptação das empresas a esse novo WebService é até 30/11/2012. A partir de 01/12/2012 o WebService específico de cancelamento será desativado. Aos contribuintes que utilizam o Aplicativo Emissor Gratuito informamos que o Aplicativo será atualizado pelos desenvolvedores não sendo necessária qualquer ação para a adaptação aos novos endereços. Em relação à NF-e, o atendimento ao público externo está sendo realizado apenas pelas AF’s e pela Central de Atendimento. Telefones Central de Atendimento: 155 para Minas Gerais; (31) 3303.7995 para outros estados e países e uso em celular

Amigo, acabei de ler em outro forum(UNINFE): "A partir de hoje, a SEFAZ-SP começa a operar em homologação com o certificado v2. Sugiro fazer teste (envio de nota ou uma simples consulta à uma NFe de SP)." Será que não seria esse o seu problema?Talvez essa cadeia ainda não esteja valendo. Que eu saiba as cadeias de certificados são complementares e uma não substitui a outra. Mas vai saber se a instalação da V2 não afetou a V1...

Os meus clientes de SP ainda estão trabalhando com a cadeia de certificado V1. Nenhum deles instalou a nova cadeia ainda. Você já verificou no site da Microsoft se existe um hotfix especifico para windows server 2003 ? E depois de todos os procedimentos (instalação da cadeia de certificado v2, instalação do hotfix ou atraso da micro em 1 hora) você reinicializou o windows? Dá uma olhada nesse link http://www.iti.gov.br/twiki/bin/view/Ce ... iodaACRaiz Engraçado que nesse link já consta uma cadeia de certificado V3.

o windows xp tem que ter service pack 3 O hotfix não funcionou em algum de meus clientes (acredito q alguns devam ter windows não original ou algum bloqueio de antivirus corporativo). A única solução foi mesmo atrasar o relogio.

Em MG, empresas com certificado digital Serpro é necessário seguir esses 2 passos: 1-instalar a nova cadeia de certificado do icp-brasil V2 2-Atrasar o relogio do windows em 1 hora (ou instalar o hotfix de correção do windows ref a horário de verão) Em alguns empresas com certificado digital Certisign é necessário apenas o primeiro passo: 1-instalar a nova cadeia de certificado do icp-brasil V2

Os certificados da Serpro estão dando incompatibilidade com horário do windows. Peça ao cliente para atrasar em 1hora o horário do windows. Além disso, instale a nova cadeia de certificado V2 do icp-Brasil.

Resolvi atrasando em 1 hora o horário do micro. Uma verdadeira POG.

Refente a serie diferenciada do DPEC em MG, eu me equivoquei. O que tem que ser diferente é o numero da nota. Segue o link: http://www.fazenda.mg.gov.br/noticias/C ... eceita.htm ABRE ASPAS Não poderá ser utilizado o mesmo número de NF-e de emissão normal quando houver alteração para as emissões de contingência FS, DPEC ou FS-DA. Se o emissor tentar transmitir a NF-e de n.º 10 série 1 com tipo de emissão normal e, por não receber o retorno do processamento dessa NF-e, quiser emitir NF-e em contingência para essa mesma operação, terá que gerar outro arquivo XML utilizando o número 11 série 1 (ou número 1 série 2) para circular com a mercadoria. Se, ao normalizar o sistema, as NF-e n.º 10 série 1 e 11 série 1 forem autorizadas, o emitente deverá cancelar a NF-e n.º 10 série 1 para corrigir a situação tributária. Isto evitará que, ao tentar transmitir a NF-e em contingência, haja rejeição por duplicidade de numeração (se a NF-e transmitida antes da contingência, COM O MESMO NÚMERO, for autorizada), além do problema com a chave de acesso constante do DANFE em contingência que pode divergir da chave autorizada anteriormente. FECHA ASPAS Então, não posso enviar o mesmo numero de nota, uma vez que aqui em MG temos o tão temido problema "Lote em Processamento..." Tenho que enviar um outro numero. E somente depois, quando finalizar o envio do DPEC, tratar essas notas (inutilizando a numeração da primeira nota ou cancelando). Complicado isso, uma vez que a primeira nota (q tentei enviar em tpemis Normal) terá que ficar vinculada à segunda (q enviei em DPEC), sendo que a DPEC que será válida. Além disso, ainda tem o problema do limite de 24hs para cancelamento. Se passar, tem q fazer um retorno de mercadoria não entregue. Como vocês de MG estão lidando com esse DPEC ?

Não sei se vocês já solucionaram esse problema, mas as dlls da capicom devem ser instaladas "como administrador" para funcionar no Windows 7 e certificado Serasa Expirian. Além disso, o instalador das dlls está jogando em pasta errada do windows, por isso elas aparentemente são registradas mas não são jogadas na pasta correta do windows. Tem que colocar as dlls manualmente na pasta system32 do windows.

Eu já li muito o Manual de Integração e o Manual de Contingência. E também já analisei o demo do ACBr. Várias vezes . Também já li o link citado pelo André, que esclarece muito. Mas a minha pergunta foi específica para MG porque há um tempo atrás foi divulgado um post sobre a necessidade de se ter uma serie especifica para DPEC devido a problemas de duplicidade. Na verdade, eu já desenvolvi todas as contingências, exceto o DPEC, justamente porque não consigo solucionar todas as minhas dúvidas, que são: 1-serie e numeração especifica ou poderá ser a mesma série de tipo de emissão normal? 2-Se tiver que ser serie e numeração diferente, ao fazer o re-envio, devo alterar a serie e numeração que uso no envio tipo normal e o Ide.tpEmis volta para teNormal? 3-como é apenas um resumo da NF-e, o que fazer se a nota for rejeitada ao se fazer o re-envio? 4-Se enviar o DPEC no fim do mês e o re-envio no mes seguinte (ainda dentro do prazo de re-envio), como fica a contabilização da nota? O DPEC será considerado válido? 5-Quanto ao passo-a-passo, na verdade, durante todo o meu desenvolvimento com o ACBr foi a primeira vez que pedi um passo-a-passo por não estar plenamente segura quanto ao demo. E como o DPEC é uma opção que pode ser usada quando o usuário quiser, a experiência de outros programadores que desenvolveram o DPEC e que possam compartilhar conhecimento e experiência no DPEC (como possíveis problemas no re-envio), ajudaria muito .

DPEC em MG já está funcional? Para DPEC de CT-e em MG é necessário ter uma série e numeração de CT-e especifica? Alguém poderia postar o passo-a-passo de como fazer um CT-e em DPEC através do ACBr?

Para DPEC em MG é necessário ter uma série de NF-e especifica? Alguém poderia postar o passo-a-passo de como fazer uma NF-e em DPEC através do ACBr?

Obrigada Ítalo, ficou ok.

Eu passei por esse problema e foi uma dor de cabeça até descobrir o que estava interferindo no meu aplicativo. Aplicativos bancários e Aplicativo emissor de NF-e ou CT-e não deverão estar na mesma máquina. Porém, o pessoal da CEF me disse que tem como ir nas configurações do aplicativo bancário e colocar o meu aplicativo como confiável.

Emiti um CT-e cuja obsCont é (DADOS ADICIONAIS): LAYOUT:1.04 CARGA:10 USUARIO:ADMIN O DACTe foi impresso corretamente. Ao consultar o CT-e para imprimir uma 2a via, o ObsCont ficou: LAYOUT:1.04 LAYOUT:10 LAYOUT:ADMIN ou seja, a descrição do campo está ficando sempre a descrição da primeira ocorrência, porém o conteudo dos campos fica correto. Ao consultar o CT-e no site de MG em ambiente de homologação está correto, portanto o primeiro envio foi correto: LAYOUT: 1.04 CARGA: 000010 USUARIO: ADMIN

A consulta do CT-e na nova versão já está funcionando. Realmente era problema no serviço de MG.

Bom dia Italo Enviei um email ontem para o cte [[email protected]], com os arquivos xml anexados. Eles consultaram os CT-e e me disseram que todos estão autorizados e protocolados. Segundo eles, estou fazendo errado a construção do xml de consulta. Mas não me apontaram o erro - 2 CONSULTAR 31111186493095000148570050000000931000000933 31111186493095000148570050000000931000000933-ped-sit.xml

Não consigo consultar os CT-e emitidos na versão 104 homologação MG Erro de Falha no Schema Mais alguém com esse problema em MG? 31111186493095000148570050000000931000000933-cte.xml

Legal, tem ACBrNFSe para Contagem/MG Sorry, não tem ACBrNFSe para BH/MG Uberlandia, padrao DSF, ninguém merece Será que vamos ter que adaptar o aplicativo para 5755(+ ou -) cidades brasileiras? Só Brasil mesmo.

Preciso iniciar meu projeto de NFS-e. Mas tenho algumas dúvidas iniciais: 1-O componente ACBrNFSe válido é o da pasta Branches? Ainda está em fase de testes ou alguém já o utiliza em ambiente de produção? 2-Preciso desenvolver a NFS-e, a principio, para 3 cidades: Uberlandia/MG,Contagem/MG e Belo Horizonte/MG. Uberlândia usa o padrão DSF. Seria o mesmo ABRASF do componente ou é um outro padrão ainda não comportado pelo ACBrNFS-e? 3-A instalação do componente da NFS-e pode interferir no componente NF-e ou poderei ter ambos instalados no Delphi 7 sem problemas? 4-Existe uma relação de cidades cujo padrão o ACBrNFS-e comporta?

Não estou conseguindo enviar CST do PIS = 05, porque a TAG fica sempre vazia quando deveria ficar - 05 =====> essa tag não aparece - 2.50 1.65 0.04 o codigo está ficando assim se CST PIS = 05 e a tag PISST não aparece. O problema é que a tag não tem CST como tem as tags PISNT e PISOutr. Então está dando erro dizendo que a a tag está vazia - Será problema com o componente ou com o Web Service de MG? Em São Paulo já estão validando as tags de PIS

Mas quando o codigo de barras está impresso na propria embalagem do produto e a empresa trabalha com cupom fiscal, não tem jeito. O leitor vai ler aquele codigo, mesmo estando errado. Por isso a necessidade de se ter um respaldo junto ao SEFAZ a fim de que a empresa que está revendendo o produto não fique com a responsabilidade "por não informar o codigo de barras na NF-e". O que o SEFAZ quer é rastrear o produto da sua origem (fabricante) até o seu destino final (consumidor). Se o codigo é inválido, ninguém vai conseguir destacar o cEAN, nem mesmo o proprio fabricante, seja ele piratê ou não. E é aí que o bicho pega.

O fato é que existem muitos produtos com codigo de barras falsos no mercado (ou etiquetas impressas incorretamente, seja pela gráfica que fez a embalagem ou pelo proprio fabricante). Tenho um cliente no segmento de supermercado e a quantidade de codigos que não são validos é grande. Por isso valido esses codigos no ato do cadastro do produto (mas nesse caso, tenho que aceitar o codigo de barras mesmo estando errado por causa dos frentes de caixa e porque o codigo de barras está impresso na embalagem do produto e é o que o leitor irá enxergar) e checo novamente esses codigos na geração da NF-e. Se não for um codigo valido, mando as tags cEAN e cEANTrib sem conteudo. Esses codigos de barra que constam nas embalagens mas não são validados pelo SEFAZ são enviados à Central de Atendimento da NF-e para análise e também ao fornecedor do produto.