Painel de líderes

Correções enviadas ao SVN.

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Bom dia a todos, 18/06/2019 Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do CT-e/CT-e OS e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 22 de Julho de 2019 e em produção a partir do dia 26 de Agosto de 2019, contempla a atualização do schema do CT-e, criação do Evento Comprovante de Entrega dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do CT-e, cuja especificação das configurações para impressão no DACTE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DACTE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DACTE. Da mesma forma, as RV G238 a G243 e N135 a N140 passarão a ser aplicadas em 02/09/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção.

Implantação da versão 3.00a em Homologação Foi implantada a versão 3.00a do MDF-e na SVRS no ambiente de homologação às 13h30min do dia 14/06/2019. A versão de produção deverá ser implantada no dia 15 de julho de 2019. O componente ACBrMDFe já contempla essa nova versão. Esta faltando fazer o novo DAMDFE que vai conter além do código de barras o QR-Code, mas o novo DAMDFE só vai passar a ser exigido a partir de outubro de 2019. Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do MDF-e e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 14 de junho de 2019 e em produção a partir do dia 15 de julho de 2019, contempla a atualização do schema do MDF-e dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Da mesma forma, as RV (regras de validação) G096 a G101 passarão a ser aplicadas em 01/07/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção. Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DAMDFE) da versão 3.00a clique aqui para ter acesso.

Boa tarde Alfredo, O componente já possui esse provedor implementado. Basta você abrir o arquivo Cidades.ini e acrescentar a cidade em questão aos moldes das demais para o mesmo provedor. Feito isso, basta iniciar os testes com o programa exemplo.

Eu estava alimentando a tag "PrestadorServico" so coloquei a que você indicou e funcionou

Boa tarde Allan, No XML (62-env-lot.xml) note que no grupo referente ao prestador nem sequer foi informado o CNPJ do mesmo. Na rotina que alimenta o componente você não informou o CNPJ e a IM do Prestador de Serviço. Prestador.CNPJ := edtEmitCNPJ.Text; Prestador.InscricaoMunicipal := edtEmitIM.Text;

Boa Tarde Luiz, A chave de acesso quando a emissão for em contingência será diferente de uma chave de BPe Normal pois você precisa trocar a Forma de Emissão. A Chave de Acesso do BP-e é composta por: Código da UF + AAMM da emissão + CNPJ do Emitente + Modelo + Série + Número do BP-e + Forma de Emissão + Código Numérico + DV Atente-se a isso. No ACBr quando você trocar a Forma de Emissão do bilhete e chamar o método Enviar ou Assinar ele vai gerar a chave correta.

Alguém enfrentando problema para processar Lotes GNRE via WebService ou importação do XML. Recentemente começou a apresentar o erro abaixo, mas isso apenas ocorre para o estado de SC. O layout está conforme documentação e sempre passou no processamento, apenas de dias para cá gera a pendência. Exemplo do XML. <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <TLote_GNRE versao="2.00" xmlns="http://www.gnre.pe.gov.br"> <guias> <TDadosGNRE> <c01_UfFavorecida>SC</c01_UfFavorecida> <c02_receita>100099</c02_receita> <c26_produto>20</c26_produto> <c27_tipoIdentificacaoEmitente>1</c27_tipoIdentificacaoEmitente> <c03_idContribuinteEmitente> <CNPJ>57398729000185</CNPJ> </c03_idContribuinteEmitente> <c28_tipoDocOrigem>10</c28_tipoDocOrigem> <c04_docOrigem>651347</c04_docOrigem> <c06_valorPrincipal>76.44</c06_valorPrincipal> <c10_valorTotal>76.44</c10_valorTotal> <c14_dataVencimento>2019-06-21</c14_dataVencimento> <c16_razaoSocialEmitente>MONTECARLO LTDA</c16_razaoSocialEmitente> <c18_enderecoEmitente>RUA AAAA</c18_enderecoEmitente> <c19_municipioEmitente>50308</c19_municipioEmitente> <c20_ufEnderecoEmitente>SP</c20_ufEnderecoEmitente> <c21_cepEmitente>02094051</c21_cepEmitente> <c22_telefoneEmitente>1130081000</c22_telefoneEmitente> <c34_tipoIdentificacaoDestinatario>1</c34_tipoIdentificacaoDestinatario> <c35_idContribuinteDestinatario> <CNPJ>06036900000175</CNPJ> </c35_idContribuinteDestinatario> <c36_inscricaoEstadualDestinatario>254694713</c36_inscricaoEstadualDestinatario> <c37_razaoSocialDestinatario>BALDESSAR LTDA ME</c37_razaoSocialDestinatario> <c38_municipioDestinatario>11751</c38_municipioDestinatario> <c33_dataPagamento>2019-06-21</c33_dataPagamento> <c05_referencia> <mes>06</mes> <ano>2019</ano> </c05_referencia> <c39_camposExtras> <campoExtra> <codigo>84</codigo> <tipo>T</tipo> <valor>35190657398729000185550010006513471006513470</valor> </campoExtra> </c39_camposExtras> </TDadosGNRE> </guias> </TLote_GNRE>

Consegui resolver o problema, tinha que declarar no demo o MidasLib apos feito isso consegui rodar o danfe no fastreport

Saudações Segui vosso procedimento. Deu certinho. Grato meu velho!!! Claudiomir

Pessoal em primeiro lugar, gostaria de agradecer pela paciência de todos em me aguentar (risos), mas hoje consegui resolver o meu problema instalando o Delphi em outra máquina. Eu creio que o problema tenha ocorrido não por causa do Fortes Reports, mas sim por alguma dependência dele, já que antigamente, tinha a mania de copiar os arquivos das pastas dos componentes e coloca-los dentro da pasta lib do Delphi. (Posso ter colocado alí derrepente uma instalação antiga do Fortes ou de alguma dependência dele por exemplo, o que dificultaria para encontrar o problema.) Em resumo, minha recomendação para quem tá tendo o mesmo problema que o meu é se possível (uso máquina virtual), fazer uma instalação limpa a partir de um sistema limpo também, pois, no meu caso, busquei por arquivos repetidos no meu sistema (minha instalação windows) com programa do tipo RANSACK por exemplo e não achei nada. Então na dúvida mesmo para uma efetiva solução, refaça a instalação de um sistema limpo. Gente agradeço mesmo aí todas a dicas e espero aí quem sabe se der certo eu contribuir com o projeto também. Tópico soluciona ! Abraços

Obrigado Italo Dessa forma deu certo. Abraços

Se você consegue utilizar dlls fique de olho no desenvolvimento da ACBrLib. Com certeza vai te ajudar.

Credenciamento Para informações sobre o Credenciamento clique aqui e acesse nossa sessão de Requisitos Fiscais por UF .

Bom dia Marcelo, lembre-se que o DistribuicaoDFe pode retornar: Resumo de Notas, Notas Completas, Resumo de Eventos e Eventos Completos. Esse buraco pode ser referente a resumo de eventos ou eventos completos.

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

Veja que a mensagem só vai ser mostrada caso a variável "EstadoECF" não for nem 'V', nem 'P' e nem 'N'. Então, se pergunte, de onde vem o valor dessa variável "EstadoECF"? Faça o debug pra responder essa pergunta.

Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.

Bom dia todos, 19/06/2019 Implantações da Consulta QR Code e do WS Sincrono de MDF-e Foram implantados na SEFAZ Virtual RS os serviços de consulta QR Code e Recepção Síncrona de MDF-e no ambiente de homologação. As empresas já podem testar conforme especificado no MOC 3.00a, as URL´s dos serviços contam no menu Serviços deste portal. Obs: A consulta QR Code pelo smartphone poderá apresentar erro de certificado digital, o usuário poderá clicar em avançado e pedir para acessar mesmo assim, ou instalar o certificado raiz brasileira v2 em seu dispositivo pelo link: http://acraiz.icpbrasil.gov.br/credenciadas/RAIZ/ICP-Brasilv2.crt. Só será necessário baixar a primeira vez. Esta foi uma mudança feita pelo próprio ITI, responsável pelo ICP-Brasil, na forma como as raízes são baixadas pelos navegadores de smartphone. Até o final da semana que vem vamos disponibilizar as alterações necessárias no componente ACBrMDFe para que seja possível o envio de MDF-e no modo Síncrono.

Valeu Juliomar, resolvi o prolema vendo esse vídeo:

Na verdade se tu está ligado com o DataSource a Grid e fizer o locate basta dar o setfocus na grid e ele vai estar parado no registro que filtrou

Boa tarde, Obrigada pela contribuição, adicionada para análise. Att.

Boa tarde. Alguém já integrou Boleto Bancário com o banco Sofisa? Achei o tópico do @robgordon de um ano atrás, mas nele está a orientação para abrir um novo tópico:

Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf

Bom dia, @Italo Jurisato Junior Eu não salvo o XML em disco, mas a propriedade DistribuicaoDFe.retDistDFeInt.docZip.Items.XML ficava em branco. Testei com a alteração proposta e funcionou perfeitamente.

Bom dia Cintia. Já tive esse "problema" uma vez, não exatamente com tecidos, mas a orientação que mais de um contador me envio é de que, se vc não transforma a matéria prima, ela permanece com o mesmo NCM, exemplo, compro arroz cru, e vendo marmita, dai tenho o processo de cozimento do mesmo, e a "unidade" de venda dele já não é mais a mesma, diferente se eu tivesse comprado o arroz, tirado a casca do mesmo, e vendido.

Cintia, eu sou desenvolvedor de indústria textil que manda este tipo de material para tingir. Ao receber, recebo sempre com o mesmo NCM. Ao meu ver o tingimento não muda a NCM. NCM por padrão é tipo de produto/material de composição.

Boa tarde, Cintia Corrêa. Sugiro que procure o seu contador, pois ele será a melhor pessoa para te ajudar.

Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · 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 Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, 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. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: 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. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. 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. Criada a Regra de Validação N18-10, 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. 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. 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. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: 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.  Serviço Autorização EPEC: 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 NF-e como destinatário na operação com mercadoria ou prestação de serviços.

Todo ACBr é OpenSource... use a força, leia os fontes...

Boa noite, tirado da NT: Não precisa atualizar o SAT, está se referindo a versão 0.06, não sei se o SAT vai validar os campos abaixo. xCampoDet Nova redação, efeitos de 01.04.16 a 31.12.16. Identificação do campo. No caso de combustíveis, preencher com “Cód. Produto ANP”. No caso de produtos sujeitos à substituição tributária, preencher com “Cod. CEST”. xTextoDet Nova redação, efeitos de 01.04.16 a 31.12.16. Conteúdo do campo. No caso de combustíveis e/ou lubrificantes, utilizar a codificação de produtos do Sistema de Informações de Movimentação de produtos - SIMP (http://www.anp.gov.br/simp). Informar 999999999 se o produto não possuir código de produto ANP. No caso de produtos sujeitos à substituição tributária, informar o Código CEST., conforme definido no Convênio ICMS 92, de 20-08-2015. Na versão 0.08 o CEST vai ter campo próprio como a NFe tem hoje. Nova redação para efeitos a partir de 01.01.17: Conteúdo do campo. No caso de combustíveis e/ou lubrificantes, quando informado “CFOP 5656 – Venda de combustível ou lubrificante adquirido ou recebido de terceiros destinado a consumidor ou usuário final”, informar código de produto do Sistema de Informações de Movimentação de produtos - SIMP (http://www.anp.gov.br/simp). Informar 999999999 se o produto não possuir código de produto ANP. Nova redação, efeitos a partir de 01.01.17. AC I05w CEST Código Especificador da Substituição Tributária E I01 N 0-1 7 Código CEST que identifica a mercadoria sujeita aos regimes de substituição tributária e de antecipação do recolhimento do imposto. As alterações serão incorporadas na versão 0.08 do leiaute do CF-e-SAT.