Gr@c@

Estou enfrentando esse mesmo problema. O validador informa Valor Calculado = 4 e Conteudo do Campo = 5. Empresa com regime de incidência = cumulativo Fiz o update do componente do ACBrSpedFiscal hoje (12/03/2012) mas o erro continua. E eu só estou informando COD_INC_TRIB = 2 COD_TIPO_CONT = codIndTipoConExclAliqBasica IND_REG_CUM = codRegimeCompetEscritDetalhada (esse campo só se aplica se COD_INC_TRIB = 2 que é o caso) No caso não informo IND_APRO_CRED pois só se aplica se COD_IND_TRIB = 1 ou 3 mas estão sendo gerados 5 campos |0110|2|1|1|1| acho que deveria ser |0110|2|1|1|

Haveria possibilidade de se parametrizar esses endereços de web services no ACBr, assim como as demais configurações que já são feitas atualmente?

No documento cita: DANFE Simplificado Nas operações realizadas fora do estabelecimento o DANFE poderá ser impresso em formato simplificado, não sendo admitida a emissão em contingência utilizando DPEC ou a impressão de DANFE em formulário de segurança. Para a impressão do DANFE Simplificado poderá ser utilizado qualquer tipo de papel com largura mínima de 55 milímetros, com exceção de papel jornal, desde que seja garantido o contraste necessário para assegurar leitura do código de barras nos equipamentos normais do mercado Acho que seria como aquelas antigas notas de Manifesto.

Nota Técnica 2012.001 Define as especificações técnicas para a emissão do DANFE Simplificado. http://www.nfe.fazenda.gov.br/portal/

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.