Gr@c@

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.

vc pode postar o xml? Meus clientes de SP estão fazendo nfe normal em produção. O problema não está no SEFAZ.

Amigo, eu tenho clientes que estão enviando notas em SP com a nova versão e os novos schemas (sem âncora) e está tudo ok. Não ocorre o erro de Rejeição cEAN Invalido. Verifique se no seu aplicativo você está checando se o EAN é válido (através da função do ACBr). Se não for um EAN válido você tem que enviar a tag cEAN e cEANTrib vazias (sem nenhum conteudo). Não pode enviar zeros,espaços ou um codigo inválido. Tanto produção como homologação (pelo menos em MG, SP e GO) estão funcionando normal.

Segue resposta do Central de Atendimento do CT-e (em 01/11/2011) sobre até quando será aceita a versão 1.03 em MG A versão 1.04 foi disponibilizada na hora do almoço, favor tentar novamente. A versão 1.03 será aceita até 29/02/2012, a partir de 01/03/2012 apenas a versão 1.04 será aceita. Atenciosamente, Equipe SPED - SEF/MG DED/ DINF/ SAIF

Nessa nova versão não poderei consultar CT-e feitos na versão 1.03? Erro em anexo (homologação e produção)

Alguém sabe dizer se a versão 1.03 não será mais aceita a partir de 01/11/2011? Já enviei inumeros emails ao SEFAZ/MG e nada de resposta.

Foram criados novos tipos (cstICMSSN). // Tipo cstICMSOutraUF, cstICMSSN incluido por Italo em 03/08/2011 (usado no CTe versão 1.04) TpcnCSTIcms = (cst00, cst10, cst20, cst30, cst40, cst41, cst45, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstPart10, cstPart90, cstRep41, cstVazio, cstICMSOutraUF, cstICMSSN); //80 e 81 apenas para CTe result := EnumeradoToStr(t, ['00' , '10' , '20' , '30' , '40' , '41' , '50' , '51' , '60' , '70' , '80' , '81', '90', '10', '90', '41', '90', 'SN'], [cst00, cst10, cst20, cst30, cst40, cst41, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstPart10 , cstPart90 , cstRep41, cstICMSOutraUF, cstICMSSN]); function StrToCSTICMS(var ok: boolean; const s: string): TpcnCSTIcms; begin result := StrToEnumerado(ok, s, ['00', '10', '20', '30', '40', '41', '50', '51', '60', '70', '80', '81', '90', '91', '92'], [cst00, cst10, cst20, cst30, cst40, cst41, cst50, cst51, cst60, cst70, cst80, cst81, cst90, cstICMSOutraUF, cstICMSSN]); end; Como devo declarar as tags para transportadores Simples Nacional? No caso, eu considerava que o CST fosse sempre = 41, mas com esse novo tipo cstICMSSN fiquei confusa quanto à forma de declarar Imp.ICMS.SituTrib := cst41; ==> aqui deverá ser cstICMSSN? O CST será 92? Imp.ICMS.ICMS45.CST := cst41; ==> aqui deverá ser cstICMSSN? O CST será 92? imp.ICMS.ICMSSN.indSN := 1;

Novos schemas no pedaço (PL_006jSemAncora). Que vergonha

Não estou conseguindo emitir CT-e MG seja homologação ou produção desde ontem. Alguém está tendo o mesmo problema?

Não, existem esses: 6401 VENDA PRODUCAO DO ESTABELECIMENTO EM OPERACAO COM PRODUTO SUJEITO AO REGIMESUBSTITUICAO TRIBUTÁRIA, NA CONDICAOCONTRIBUINTE SUBSTITUTO 6402 VENDA PRODUCAO DO ESTABELECIMENTOPRODUTO SUJEITO AO REGIMESUBSTITUICAO TRIBUTÁRIA, EM OPERACAO ENTRE CONTRIBUINTES SUBSTITUTOS DO MESMO PRODUTO 6403 VENDA MERCADORIA ADQUIRIDA OU RECEBIDATERCEIROS EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA, NA CONDICAOCONTRIBUINTE SUBSTITUTO 6404 VENDA MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA, CUJO IMPOSTO JÁ TENHA SIDO RETIDO ANTERIORMENTE 6408 TRANSF.PRODUCAO DO ESTABELECIMENTO EM OPERACAO COM PRODUTO SUJEITO AO REGIMESUBSTITUICAO TRIBUTÁRIA 6409 TRANSF.MERCADORIA ADQUIRIDA OU RECEBIDATERCEIROS EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA 6410 DEVOLUCAO COMPRA P/ INDUSTRIALIZ. EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA 6411 DEVOLUCAO COMPRA P/ COMERCIALIZ. EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA 6412 DEVOLUCAOBEM DO ATIVO IMOBILIZADO, EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA 6413 DEVOLUCAO MERCADORIA DESTINADA AO USO OU CONSUMO, EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA 6414 REMESSA PRODUCAO DO ESTABELECIMENTO P/ VENDA FORA DO ESTABELECIMENTO EM OPERACAO COM PRODUTO SUJEITO AO REGIMESUBSTITUICAO TRIBUTÁRIA 6415 REMESSA MERCADORIA ADQUIRIDA OU RECEBIDATERCEIROS P/ VENDA FORA DO ESTABELECIMENTO, EM OPERACAO COM MERCADORIA SUJEITA AO REGIMESUBSTITUICAO TRIBUTÁRIA

Segue resposta SEFAZ em 26/10/2011 A sua mensagem mereceu toda a atenção da Equipe da SEF/MG e conforme parecer da superintendência responsável, informamos que verificamos ocorrências de instabilidade em nossos sistemas, e a nossa área técnica já está trabalhando para sua normalização. A SEF/MG trabalha incessantemente para melhoria e funcionamento adequado de seus sistemas e eventuais intermitências poder ocorrer, mas sempre no intuito da prestação do melhor atendimento possível. Pedimos sinceras desculpas por estes transtornos, contamos com sua compreensão e solicitamos que aguarde. Agradecemos antecipadamente, nos colocando à disposição para quaisquer outros esclarecimentos que se fizerem necessários. "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. Atenciosamente, Central de Atendimento da SEF/MG Diretoria de Gestão de Atendimento ao Público (DGAP) Superintendência de Arrecadação e Informações Fiscais (SAIF) Secretaria de Estado de Fazenda (SEF/MG) Tel.: 155 (para todo o Estado de MG) / (31) 3303-7995 (para outros estados e países e de celular) Fale Conosco - http://www4.fazenda.mg.gov.br/faleconoscoservico/

Como informar a tag ? o fisco está exigindo o preenchimento dessa tag no xml para produtos classificados pela ONU como perigosos. Não estão aceitando as informações em informações adicionais, porque existe tag especifica para as informações. Sujeito a multa e a enquadramento em crime ambiental em caso de acidente de qualquer natureza. No DACTe a informação é obrigatória também. No meu caso, ocorreu com um cliente que transportava impermeabilizante e solvente (classificado na tabela da ONU na Classe 8 Substâncias corrosivas) comercializado em algumas empresas que revendem impermeabilizantes de paredes e telhados para construções civis.