Painel de líderes

Estou com o sistema pro novo serviço, mas não, ainda tenho problemas na assinatura.... estou conversando com o Pedro do SimplISS, estou pedindo pra ele verificar com o pessoal do dev deles pra validar a assinatura nos padrões das outras cidades q eles atendem e funciona... NFe , NFSe de outros municípios. Enfim... eh muito mais fácil eles ajustarem... seguir o mesmo padrão... até pra implantações futuras em outras cidades... nossos clientes começaram a pressionar agora também, sem faturar essas notas... quando tiver uma posição posto aqui...

Bom dia pessoal. Afim de facilitar a tratativa desta situação, estamos criando um novo parâmetro de forma similar ao que já foi feito em situações semelhantes; Att.

Bom dia. Verifique se você preenche os campos : nfe.Dest.idEstrangeiro; nfe.Dest.enderDest.cPais; De acordo com o código no ACBr, ele precisa desses campos para preencher: if nfe.infNFe.Versao >= 3 then begin if (nfe.Dest.idEstrangeiro <> '') or ((nfe.Dest.enderDest.cPais <> 0) and (nfe.Dest.enderDest.cPais <> 1058)) then Gerador.wCampo(tcStr, 'E03a', 'idEstrangeiro', 00, 20, 1, nfe.Dest.idEstrangeiro, DSC_IDESTR) else Gerador.wCampoCNPJCPF('E02', 'E03', nfe.Dest.CNPJCPF, IsNFe); end else Gerador.wCampoCNPJCPF('E02', 'E03', nfe.Dest.CNPJCPF, IsNFe);

Agora pela manhã serviço não está 100% operacional, continue recebendo erros diversos para validar NFCe.

Boa tarde Senhores (Felipe E. Resende Mesquita, Daniel Simoes e Juliomar Marchetti) No tópico anterior postado na terça-feira 24/09, funcionou perfeitamente após reverter tudo no SVN. Trabalhei na quarta e quinta-feira sem nenhum problema. Hoje pela manhã o problema reapareceu. Saliento que na pasta ABCr está tudo perfeito e atualizado sem nenhum tipo de problema, entretanto, o windows 10 fez uma atualização pela manhã. Não efetuei ainda nenhum procedimento para tentar a correção, uma vez que preferi reportar a vocês sobre o ocorrido. Acham que pode ter sido pela atualização do windows? Qual o procedimento devo adotar? Diante mão, já agradeço antecipadamente.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde. Você viu este tópico ? Att.

no meu caso sempre recebo isso... tanto no GerarNfse quanto no RecepcionarLote. <ListaMensagemRetorno> <MensagemRetorno> <Codigo>E1020</Codigo> <Mensagem>Erro na assinatura.</Mensagem> <Correcao>CPF/CNPJ do prestador ou contador não condizente com CPF/CNPJ da assinatura.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> tivemos diversos contatos com eles, porém sempre pedem para refazer o teste ou alterar uma tag e outra... mas sempre paramos nisso. como um amigo aqui ja comentou.. acho que o erro se dá pelo Subject do certificado utilizado não estar no formato "Empresa:CNPJ". estamos com nosso cliente tentando fazer outro certificado para atender essa validação ridícula... triste... essa empresa ganhou disparado o troféu de "Pior Webservice dos últimos tempos"...

Todos os bancos permitem salvar o extrato em formato de arquivo OFX para integração. O ACBr não tem componente pra isso, mas neste tópico tem indicações de outros:

Veja acho que sua dll deve de estar junto a seu executável pois se ele ficar no system32 corre um grande risco de um outro aplicativo substituir ele

Já estudou o fonte do ACBr que faz essa conversão? Na unit pcnRetDistDFeInt.pas tem o código: StrAux := RetornarConteudoEntre(Leitor.Grupo, '>', '</docZip'); FdocZip.Items[i].FInfZip := StrAux; StrDecod := UnZip(DecodeBase64(StrAux)); Na terceira linha você deve ter o XML. Basta adaptar para o teu caso.

Você pode montar a chave de acesso informando os dados da nota pelo método GerarChaveAcesso da unit ACBrUtil. Com a chave basta fazer a consulta pelo ACBrNFe para obter o protocolo de autorização. Claro que você precisa informar todos os dados que compõe a chave, como o código numérico e o tipo de emissão, então se não os armazenou previamente não vai ter a chave correta. Quando a mensagem é de duplicidade com diferença na chave de acesso também é retornada a chave correta.

Boa tarde Ernesto, O correto é usar a rotina do componente para realizar a assinatura.

Bom dia. Você testou com a versão mais recente? Se não testou, sugiro compilar ou realizar a assinatura do SAC Trial e realizar novos testes. Link com orientações sobre o SAC Trial At.

Acho que eu estava com o componente destualizado. Fiz atualização e deu certo Obrigado.

Vi que foi criado um guia passo a passo era o que eu precisava, aqui. podem marcar como "respondido".;

@Daniel Simoes o IP que estava errado, obrigado pela informação, deu certo.

resolvido muito obrigado pela contribuição...

Serviço normalizado.

Boa noite Colegas o sistema NFC-e em MG ja voltou ao normal

@Italo Jurisato Junior pelo que vi não. Essa é na verdade uma nova implementação, acredito que precisarei incluir mais cidades do estado de Goiás lá. Aquele método trata o código do município para impressão do nome do município. Nos testes que fiz funcionou como já estava e como deverá ser a partir de agora.

Olá pessoal, Segue abaixo um resumo mais detalhado da NT 2019/001 abrangendo todas as versões dessa NT. Resumo das versões v1.00/v1.10/v1.20 (entrada em produção 02/09/2019) Dificultar utilização de código de segurança fraco: • Regra de validação B03-10: Verificar formatação do cNF • Rejeição 897: Código numérico em formato inválido. Melhorar o controle de documentos referenciados e da identificação do destinatário: • Alterada a Regra de Validação BA10-40 (55), possibilitando a utilização do CNPJ 8 (será levado em consideração os 8 primeiros dígitos do CNPJ ou CNPJ Base), com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Rejeição 320: Contranota de Produtor referência somente NF de outro emitente. • Criada a Regra de Validação BA10-50 (55), exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Rejeição 922: Contranota de Produtor só pode referenciar NF-e ou NF de Produtor Modelo 4. • Criada a Regra de Validação BA20-20 (55), impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Rejeição 923: Referenciado documento de operação interna em operação interestadual ou com o exterior. • Criada a Regra de Validação BA20-30 (55), impedindo referência a um Cupom Fiscal, a critério da unidade federada. Rejeição 924: Informado Cupom Fiscal referenciado. • Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Rejeição 925: NF-e com identificação de estrangeiro e IE informada para destinatário. • Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Rejeição 926: Operação com Exterior e país de destino igual a Brasil. • Criada a Regra de Validação E16a-40 (55), exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Rejeição 696: Operação com não contribuinte deve indicar operação com consumidor final. Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão: • Criada a Regra de Validação N12-85, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal. • Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado o código de benefício fiscal para CST sem benefício fiscal. • Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Rejeição 934: Não informado valor do ICMS desonerado ou o Motivo de desoneração. • Criada a Regra de Validação N12-94, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Rejeição 931: Informado código de benefício fiscal incompatível com CST e UF. • Criada a Regra de Validação N12-97 (55), exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Rejeição 929: Informado CST de diferimento sem as informações de diferimento. • Criada a Regra de Validação N18-10 (55), exigindo a informação do percentual da margem de valor adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Rejeição 931: Informada modalidade de determinação da BC da ST como MVA e não informado o campo pMVAST. • Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Rejeição 933: Informada modalidade de determinação da BC da ST como MVA e informado o campo pMVAST. Criação de valor máximo para a base de cálculo do ICMS, por unidade federada: • Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Rejeição 935: Valor total da Base de Cálculo superior ao valor limite estabelecido. Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC (somente 55): • Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços. Obs.: todas as regras acima são validas somente para a NF-e (55), leva em consideração as informações: IE, CNPJ, CPF e UF. As regras acessam o Cadastro de Contribuinte da UF. Regra: 5E17-10 - Rejeição 233: IE do destinatário não cadastrada. Regra: 5E17-20 - Rejeição 234: IE do destinatário não vinculada ao CNPJ. Regra: 5E17-30 - Rejeição 624: IE do destinatário não vinculada ao CPF. Regra: 5E17-40 – Rejeição 302: Uso Denegado - Irregularidade fiscal do destinatário. Regra: 5E17-43 – Rejeição 305: Destinatário bloqueado na UF. Regra: 5E17-46 – Rejeição 306: IE do destinatário não está ativa na UF. Regra: 5E17-50 – Rejeição 232: IE do destinatário não informada. Regra: 5E17-60 – Rejeição 303: Uso Denegado - Destinatário não habilitado a operar na UF. Regra: 5E17-63 – Rejeição 305: Destinatário bloqueado na UF. Regra: 5E17-70 – Rejeição 246: CNPJ do Destinatário não cadastrado. Regra: 5E17-80 – Rejeição 623: CPF do Destinatário não cadastrado. • Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NFe como destinatário na operação com mercadoria ou prestação de serviços. Obs.: todas as regras acima são validas somente para o Evento EPEC da NF-e (55), leva em consideração as informações: IE, CNPJ, CPF e UF. As regras acessam o Cadastro de Contribuinte da UF. Regra: 6P31-10 - Rejeição 233: IE do destinatário não cadastrada. Regra: 6P31-20 - Rejeição 234: IE do destinatário não vinculada ao CNPJ. Regra: 6P31-30 - Rejeição 624: IE do destinatário não vinculada ao CPF. Regra: 6P31-40 – Rejeição 302: Uso Denegado - Irregularidade fiscal do destinatário. Regra: 6P31-43 – Rejeição 305: Destinatário bloqueado na UF. Regra: 6P31-46 – Rejeição 306: IE do destinatário não está ativa na UF. Regra: 6P31-50 – Rejeição 232: IE do destinatário não informada. Regra: 6P31-60 – Rejeição 303: Uso Denegado - Destinatário não habilitado a operar na UF. Regra: 6P31-63 – Rejeição 305: Destinatário bloqueado na UF. • Criação de regra de validação H02-10 correspondente rejeição 927, para informar os números dos itens em ordem sequencial. Rejeição 927: Número do item fora da ordem sequencial. • Criado novo Valor para o Campo N18: A tag modBCST passa a aceitar a opção “6=Valor da Operação”. v1.30: Informados os locais de publicação das tabelas de códigos de benefícios fiscais e de regras de validação opcionais por unidade federada. Publicada a tabela cBenef x CST atualizada até 30/08/2019 Novas datas de vigência para algumas regras de validação. Comentários Sobre o Código de Benefício Fiscal: O código de benefício fiscal (tag: cBenef), por tratar de situações particulares de cada unidade federada, tem sua definição também especificada pelas UF que o utilizam. Estas definições constam de tabela publicada no Portal Nacional da NF-e, na área “Diversos” da aba “Documentos”. Esta tabela tem sofrido atualizações com frequência maior do que a desejável, em virtude do fato que o uso dos códigos pelas empresas no ambiente de homologação tem evidenciado a necessidade de ações de correção de natureza emergencial por parte das Administrações Tributárias envolvidas. É esperado que em futuro próximo a tabela tenha a estabilidade necessária. Novas Datas de Vigência para Algumas Regras de Validação: Em função de necessidades ditadas pelas legislações de algumas unidades federadas, e atendendo a pleitos de contribuintes e de entidades associativas, as datas de início de exigência das regras de validação N12-85, N12-86, N12-90, N12-94 e N12-97 obedecerão ao disposto na tabela a seguir: UF N12-85 N12-86 N12-90 N12-94 N12-97 MT 01/01/2020 01/01/2020 01/01/2020 01/01/2020 * E3 E3 E3 E3 PR 02/09/2019 02/09/2019 * 01/10/2019 02/09/2019 E2 E2 E2 E2 RJ 01/10/2019 01/10/2019 01/10/2019 01/10/2019 01/10/2019 E1, E3 E1, E3 E1, E3 E1, E3 E1, E3 RS 01/10/2019 01/10/2019 * 01/10/2019 * E2, E3, E4 E2, E3, E4 E2, E3, E4 Demais UFs * * * * * (*) Regra de validação não será aplicada Regra de validação: N12-85 – Exige o código de benefício fiscal quando se utiliza um CST de benefício fiscal. N12-86 – Impede que se informe o código de benefício fiscal para CST de benefício fiscal. N12-90 – Exige valor do ICMS desonerado e o motivo da desoneração. N12-94 – Exige que o CST corresponda ao tipo de código de benefício fiscal informado. N12-97 – Exige informações sobre o diferimento quando se utiliza um CST de diferimento. Exceções para aplicação das Regras de validação(E): E1 – Exceção 1: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria; E2 – Exceção 2: a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação Interestadual ou com o Exterior; E3 - a RV não se aplica quando Finalidade de emissão da NFe (tag: finNFe) igual a NFe de ajuste; E4 - a RV não se aplica quando Finalidade Tipo de Operação (tag: tpNF) igual a Entrada. As datas aqui definidas, com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFCe, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no estado do Rio Grande do Sul, no caso das regras N12-85, N12-86 e N12-94, o ambiente de autorização em produção, até 31/03/2020, e o ambiente de autorização em homologação até 09/02/2020, aceitarão três situações para o campo cBenef: * NULO (sem preenchimento do campo); * com a descrição "SEM CBENEF"; ou * com o código do benefício; Neste último caso, é realizada a devida validação de compatibilidade com o CST informado.

Caro Alexandro, Como a RFB, Receita Federal do Brasil ainda não normatizou a exclusão do icms da base do PIS e COFINS, recomenda-se que a emissão dos documentos fiscais sejam conforme as notas técnicas, e na escrituração fiscal assim como na EFD Contribuições seja feita a devida dedução do icms e informando a decisão judicial liminar com o referido número do processo. A Software House enquanto geradora dos documentos fiscais deve atender as especificações das notas técnicas do CONFAZ e o RICMS dos Estados. "É mais seguro". No caso do SAT em SP, realmente nem tem como proceder diferente. Grande abs e precisando acesse www.sacfiscal.com.br

Boa tarde. Deixo aqui o procedimento para quem possa necessitar. Tive que ir no painel de controle, no gerenciador de dispositivos e nas propriedades da porta coloquei a velocidade correta 115200 e também tive que alterar o controle de fluxo para xon e xoff. Com o controle de fluxo em nenhum que é o padrão no gerenciador, a mesma não aciona e não retorna os status. Dentro do posprinter tem esta possibilidade mas mesmo assim não ativava. Obrigado pela ajuda.

Consulte neste site https://portal.fazenda.sp.gov.br/servicos/sat/Paginas/Modelos-SAT.aspx as versões suportadas por cada modelo de equipamento, geralmente as versões convivem por um período.

Boa tarde a todos! Peço para que realizem a pesquisa, antes de abrir um novo tópico:

Imagine @EMBarbosa você já me ajudou e muito!!!! Percebi que é de uso livre ele e aparece só no XML pro governo... Já vi alguns preencher xCampo: PEDIDO xTexto: Numero do Pedido. Então vou ver com meu cliente o que informar. Obrigado pela ajuda. Se for isso mesmo o que eu disse acima, não sei como fecha esse tópico mas os responsáveis podem fechar por favor

Boa tarde, As alterações feitas por tdpsistemas foram enviadas para o repositório. Revision: 17733

ok, obrigado.

Tentou o contato com a Software Express/SkyTef/Certificadora? Eles geralmente respondem rápido esse tipo de questão.

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

Bom dia. MG esta instável desde o dia 20/09, seus problemas ocorriam antes dessa data? Att.

Oi @Andremomb Desculpe, eu acabei me confundindo. Estávamos numa conversa sobre MDe, e aqui você falou do MF-e, eu acabei juntando tudo e passando o link para o MDF-e. A documentação do MF-e está no site da SEFAZ do Ceará. http://cfe.sefaz.ce.gov.br/mfe/informacoes/legislacao-estadual#/ Ali, você vai encontrar downloads de informações e manuais, legislação, e etc... Voltando ao campo Esse campo é de informações do Fisco. Quer dizer que ele vai ser preenchido pelo aparelho MF-e. Isso talvez explique o porque não apareceu no cupom. Veja esse tópico:

Bom dia, agora é aguardar a correção em ambiente de homologação... difícil demais

Bom dia Mozart, Muito obrigado pelo retorno, vou analisar melhor a sua contribuição e espero que ainda hoje envio para o repositório.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Como a Retorno pode se tornar muito grande neste caso, desmarque na tela inicial a opção "Exibir linhas de log na tela" e limite a qtd Max de linhas geradas no log, isso vai melhorar muito a performance e evita travar quando se envia comandos seguidos...

Rafaelbudag esta faltando a tag "CodigoTributacaoMunicipio", complemento do tomador. Adicione também os namespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

Conseguir registrar os NFCe que emitidos em contingência. A consulta geral está com erro ainda. http://nfce.fazenda.mg.gov.br/portalnfce/sistema/consultaarg.xhtml Error 404--Not Found From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1: 10.4.5 404 Not Found

Tive o mesmo problema, e no meu caso era o certificado que estava vencido.

O erro estava realmente nas propriedades do componente. No componente estavam corretas, mas no decorrer da execução o código mudava as configurações novamente, ocasionando no erro. Grato pela atenção @Felipe E. Resende Mesquita!

Segue consulta interna na RFB: http://normas.receita.fazenda.gov.br/sijut2consulta/link.action?visao=anotado&idAto=95936

Algumas impressoras possuem várias fontes e você pode trocar a fonte via protocolo. Geralmente pelo menos uma delas possui acentuação básica como algum subconjunto de ASCII. Aí você pode pegar o manual da linguagem e da impressora e tentar, mas nossa experiência é que geralmente não funciona ou funciona muito precariamente. Pode verificar nesse link os manuais que temos e no site do fabricante os manuais da sua. https://svn.code.sf.net/p/acbr/code/tools/Etiqueta

Creio que esta informação não está previsto no layout do Boleto até o momento, mas nada impede de informar manualmente, isso pode ser feito passando no campo "Mensagem". veja onde preencher no manual: https://acbr.sourceforge.io/ACBrMonitor/ModeloTituloArquivoINI.html

Bom dia, Claudio. este erro só está ocorrendo no ambiente de homologação da SEFAZ MG, no ambiente de produção está tudo ok. Provavelmente estão fazendo alguma manutenção no ambiente de homologação.

Obrigado...

Bom dia, Murilo pelo o que entendo sobre ACBrNFe1.DistribuicaoDFe(iUF, CNPJ, ultNSU, ''), esta função retorna uma lista de todos os documentos fiscais emitidos contra o cnpj informado com emissão de no máximo 90 dias e não somente os documentos manifestados.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17722. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Bom dia a todos! Sugiro a todos que realizem a emissão em contingência, segue a resposta da Sefaz: "Entretanto, considerando que a NFC-e em MG ainda se encontra em fase de implantação e devido aos erros ocorridos neste período, será permitida a transmissão das NFC-e em contingência por um prazo maior. Desta forma o contribuinte deverá transmitir os arquivos logo após a cessação dos problemas que impediram a transmissão, ainda que o prazo previsto na legislação já tenha transcorrido.Importante: O sistema da SEF passa por manutenção. Recomendamos usar a contingência."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, FALE CONOSCO - SEF/MG Superintendência de Arrecadação e Informações Fiscais Tel.: 155 para todo o Estado de Minas Gerais (31) 3303-7995 para outros estados e países Para continuar aprimorando nossos serviços, gostaríamos de saber sua opinião sobre esse atendimento. ÓTIMO BOM REGULAR RUIM Gostaria de dar sequência a este atendimento? Clique aqui *Você terá até o dia 30/09/2019 para dar sequência a este atendimento após esta data o mesmo será automaticamente encerrado."