Gr@c@

por enquanto só temos isso: SEF/MG prevê implantação da NFC-e para o início de 2019 11/06/18 A Secretaria de Estado de Fazenda está finalizando a contratação necessária para adequação da área de Tecnologia da Informação (TI) a fim de viabilizar a emissão de Nota Fiscal do Consumidor Eletrônica (NFC-e) em Minas Gerais.A estimativa da SEF/MG é que no segundo semestre de 2018 seja possível dar início à homologação da funcionalidade e, na sequência, colocar em prática um piloto com algumas empresas. Concluído o piloto, será possível agregar, gradativamente, contribuintes voluntários.A legislação com o cronograma de obrigatoriedade será publicada também no próximo semestre, com previsão de início em 2019.

André, esse erro ocorre ao tentar enviar a NFe 4.00. Antes o nItemPed passava com menos de 6 algarismos, inclusive tem um tópico de alguém solicitando para remover os zeros a esquerda desse campo no ACBr. O correto agora é formatar 000001 e não 1? Nesse caso dessa nota, os itens de 1 a 9 não foram rejeitados e eles também possuiam as tags xPed e nItemPed . O erro foi só do 10 em diante. (nos itens dessa nota, o nItemPed é o mesmo numero do item porque a NF foi feita importando-se um pedido de compra). Então item 1 da nota o xPed = 2525 nItemPed = 1 item 2 da nota o xPed = 2525 nItemPed = 2..... item 10 da nota o xPed = 2525 nItemPed = 10...>>>>a partir daqui começou o erro. Seria o mesmo caso do Atomic Type, campo com 2 caracteres como vem ocorrendo com uTrib = 'Kg'? Editando: é isso mesmo. Todas as notas houve rejeição só a partir do nItemPed > 9 (não havia prestado atenção nesse fato). Terei que formatar o campo da mesma forma como tive que fazer no MDF-e com o campo cInt.

Quando tPag = fpCartaoCredito ou tPag = fpCartaoDebito estou informando tpIntegra = tiNaoInformado e não informo as tags tBand,CNPJ e cAut. Até agora não tive nenhum cliente no Maranhão com rejeição de NFC-e ou NF-e, inclusive hoje mesmo emitiram NFC-e e não houve rejeição. Não uso o tpIntegra = 1 porque acredito que seria a integração do TEF. Mas vou implementar a opção do tpIntegra = tiPagNaoIntegrado e habilitar os campos tBand,CNPJ e cAut para que o usuário informe manualmente (sendo que tenho as administradoras cadastradas com seus rescpectivos cnpj, então o usuário selecionará a administradora ao invés de informar cnpj). Só me preocupa essa Resolução Administrativa 05/2018 do SEFAZ/MA, que não está muito clara. Embora não fale em TEF e sim em NFC-e vinculada ao comprovante de Débito/Crédito. No caso do seu cliente onde houve rejeição, tentou tpIntegra = tiNaoInformado?

os campos que informam são prod.xPed e prod.nItemPed. Não estou informando a tag de compras. No entanto o erro vem como [<det nItem='10'><prod>nItemPed] Item do Pedido de Compra da DI - adição - Tamanho menor que o permitido. Antes o prod.nItemPed não precisava dos zeros a esquerda, inclusive parecem que foram removidos no ACBr. Todas as notas com as tags prod.xPed e prod.nItemPed estão sendo rejeitadas desde ontem a tarde. (18/06/2018 após as 15:00hs) -<det nItem="1"> -<prod> <cProd>27047</cProd> <cEAN>SEM GTIN</cEAN> <xProd>BOMBA COMB CORSA MPFI S10 BLAZER</xProd> <NCM>87089990</NCM> <CEST>0107500</CEST> <EXTIPI>00</EXTIPI> <CFOP>5405</CFOP> <uCom>PC</uCom> <qCom>1.0000</qCom> <vUnCom>158.2000000000</vUnCom> <vProd>158.20</vProd> <cEANTrib>SEM GTIN</cEANTrib> <uTrib>PC</uTrib> <qTrib>1.0000</qTrib> <vUnTrib>158.2000000000</vUnTrib> <vDesc>48.20</vDesc> <vOutro>1.50</vOutro> <indTot>1</indTot> <xPed>145943</xPed> <nItemPed>1</nItemPed> </prod>

Ainda não me relataram nenhum problema e estou torcendo muito que não relatem

A partir de hoje à tarde aqui em MG, começou a dar esse erro "[<det nItem='10'><prod>nItemPed] Item do Pedido de Compra da DI - adição - Tamanho menor que o permitido Em seguida Schema Inválido. Esse erro não estava ocorrendo até então. Inclusive fizemos nota igual a que foi autorizada somente mudando o numero da nota.

Depois que saiu essa NT 1.60 as notas fiscais estão sendo rejeitadas com Schema inválido, dando erro "Item do pedido de compra da DI-Adicao - Tamanho menor que o esperado) e essas tags nem estão sendo enviadas na montagem do xml. Será que os schemas já foram alterados aqui em MG e esse troço endoidou geral? E até hoje (antes de sair essa 1.60) estava tudo normal. Fizemos até uma nf igual a uma que foi autorizada mais cedo (completamente igual, só mudando a numeração) e ela foi rejeitada.

Pelo jeito, novas alterações: 18/06/2018 - ATENÇÃO: Publicada versão 1.60 da NT 2016.002 e pacote de schemas XML correspondente A versão 1.60 da NT 2016.002 posterga o prazo de desativação da versão 3.10 em 30 dias, define novos prazos para validação do QR-Code da NFC-e, entre outras alterações.Assinado por: Coordenação Técnica do ENCAT

Perfeito. Consegui enviar sem erro com timeout = 20 segundos (timeout menor ocorreu erro). E com esse timeout consultei e cancelei sem nenhum erro.

Depois de muitas tentativas a minha NF-e foi autorizada. Mas ao tentar cancelar deu novamente o erro 12002-timeout. Na terceira tentativa consegui cancelar.

Ainda continuo tentando enviar uma NF-e da minha empresa mesmo (em produção) versão 4. Continua o erro 12002-timeout. E eu já enviei outras notas hoje com o mesmo aplicativo. Clientes que ainda estão com a versão 3.10 estão enviando notas normalmente. O problema é só com a 4.00 mesmo e ainda acredito ser no SEFAZ/MG. Em um outro aplicativo que não usa ACBr instalado em numa empresa aqui na cidade também está ocorrendo o mesmo retorno.

Esse erro está ocorrendo aqui em MG. Cliente acabou de me ligar e até hoje de manhã estava emitindo notas. Então parece ser problemas no SEFAZ/MG.

Qual(is) ferramenta(s) vocês utilizam para armazenamento de dados na nuvem (com criptografia de dados)? Existe alguma opensource que ofereça facilidade de upload e download? Google Drive é seguro? E para fazer a criptografia antes do armazenamento? Qual ferramenta mais indicada?

Pessoal, acompanhem o link

Vou por tentativas 1a tentativa (essa até agora está funcionando 100% em micros com windows 7 ou superior "original" atualizado) SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsLibXML2 SSLType = LT_TLSv1_2 2a Tentativa SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsMSXML SSLType = LT_TLSv1_2 3a Tentativa SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsLibXML2 SSLType = LT_ALL 4a Tentativa SSLLib = libWinCrypt CryptLib = cryWinCrypt XMLSignLib = xsMSXML SSLType = LT_ALL

Nos meus clientes onde deu esse erro foi problema no TLS1.2. Máquinas que não foram atualizadas completamente, windows não original. Nelas tive que usar o LT_All. Porém não uso essa opção "SSLXmlSignLib: xsXmlSec" e xsLibXml2 ou xsMsXml

Vc não precisa migrar para win 10. Meus micros com win7 sp1 licenciados estão funcionando normalmente. Somente máquinas com windows 7 não original estão dando problemas. Mesmo atualizando tudo. E mesmo assim, apenas algumas não funcionam.

Tem alguns micros que não funcionam com xsLibXML2 embora estejam com o windows atualizado e até mesmo foram formatadas antes. Por isso tive que usar o xmMsXml. Você disse "não precisam do ajuste". Mas se fizer o ajuste irá funcionar com o xmMsXml?

Uma dúvida: Tem que renomear o arquivo mesmo quem não usa SSLXmlSignLib = xsXmlSec ou xsLibXML2?

Já encontrei o motivo. O cliente não pode mais comprar nessa inscrição estadual, mas nem o Sintegra nem a Receita Estadual atualizaram a nova inscrição. 303 - Uso Denegado: Destinatário não habilitado a operar na UF: Esta rejeição retorna nos casos em que a Inscrição Estadual do destinatário não corresponde a UF que foi informada na nota. Para prosseguir com a emissão de outras NF-e para este destinatário é necessário que seja feita a verificação correta do cadastro junto à Receita Federal deste destinatário. A nota ficará com o status de denegada, não podendo mais realizar alterações e/ou reenviar, devendo emitir uma nova numeração após verificação dos dados corretos do destinatário.

cliente tentando enviar uma nota NFe 400 - Emitente MG Destinatario PI , mas está ocorrendo esse erro (Destinatario bloqueado na UF). Porém o destinatario está habilitado no sintegra Piaui e na receita estadual.

Minas ainda não liberou o ambiente de testes. Se MG seguir o exemplo de alguns estados como Maranhão, a partir do momento da obrigatoriedade da NFC-e os ECF´s terão que ser encerrados.

Fiz uma nfe pela minha empresa Simples Nacional, usando o mesmo CSOSN = 500 e a nfe foi enviada. Comparando a meu xml com o xml do cliente estão absolutamente iguais. Mesmo cliente, mesmo produto, vBCSTRET /vICMSSTRet/pST não apareceram porque estavam zerados. A unica diferenca entre os xmls é o emitente, mas o enquadramento é o mesmo (CRT=1). Fiz uma outra nfe informando os valores vBCSTREt/vICMSSTRET mas deixei o pST = 0. A NFe foi autorizada gerando a tag pST.

atualizei subversion 15269 20:03:45, quarta-feira, 6 de junho de 2018 mas também não gerou a tag pST para o CSOSN 500 (testei pST = 0 e pST = 20)