Painel de líderes

COMUNICADO IMPORTANTE Gostaríamos de comunicar que assinamos em 08/05/2019 um contrato que prevê a compra da operação de hardware da Bematech no Brasil pela empresa Elgin. Sujeito à aprovação pelo CADE (Conselho Administrativo de Defesa Econômica), o resultado da junção dessas operações ampliará de forma significativa a competitividade do mercado brasileiro no segmento de automação comercial. A operação Elgin-Bematech amplia a capacidade de inovação e entrega de valor aos clientes por meio da otimização do portfólio de hardware, geração de valor no ecossistema de distribuidores, revendas e assistências técnicas e liderança estratégica com foco na inovação de equipamentos e dispositivos inteligentes. Estamos bastante otimistas com o resultado dessa operação para todos e com os benefícios que em conjunto a nova companhia poderá levar aos seus stakeholders. A TOTVS segue com seu foco no mercado de software, bem como no desenvolvimento de novos negócios, conforme anunciado recentemente, na busca pelo crescimento esperado para esse e os próximos anos. Fonte: https://www.bematech.com.br/sobre-nos/

Olá pessoal, A pesar do titulo fazer referencia a NF-e, mas esse artigo é valido também para a NFC-e, CT-e, CT-e OS, MDF-e e BP-e. Alguns desenvolvedores preferem gerar através da sua aplicação o XML para depois ser lido pelo ACBrMonitor ou pelo componente que vão dar continuidade, ou seja, assinar, validar e enviar para SEFAZ. Vi relatos no fórum que o desenvolvedor gerou o XML com uma determinada chave e o Monitor ou o componente mudaram essa chave. Porque isso ocorre? Essa alteração é provocada porque o valor da tag cNF (se tratando da NF-e e NFC-e) esta com o valor zero ou possui um valor em cNF diferente do que foi usado para compor a chave. Se o valor for zero o componente que é usado pelo Monitor vai gerar um numero aleatório. Agora se o valor de cNF for diferente do que foi usado na chave o componente se encarrega de corrigir a chave. Como é composta a chave? Chave = <Código da UF(2)><Ano de Emissão(2)><Mês de Emissão(2)><CNPJ do Emitente(14)><Modelo(2)><Série da Nota(3)><Numero da Nota(9)><Tipo de Emissão(1)><Código da Nota(8)><Digito Verificador(1)> O <Numero da Nota> é o valor de nNF e o <Código da Nota> é o valor de cNF. Para os demais modelos de documentos fiscais eletrônicos temos: CT-e / CT-e OS <Numero do Conhecimento> = nCT <Código do Conhecimento> = cCT MDF-e <Numero do Manifesto> = nMDF <Código do Manifesto> = cMDF BP-e <Numero do Bilhete> = nBP <Código do Bilhete> = cBP

http://michellcomputing.co.uk/blog/2016/05/windres-installation-on-linux/ isso funcionou

Exatamente. Irei entrar em contato com a Sefaz. Agradeço pela resposta.

Confirmado... o problema está na resposta do WebService do SEFAZ... é imperativo entrar em contato com o SEFAZ e relatar o problema

Boa tarde. A versão do Fortes é esta mesma, e tem sido utilizada com sucesso por grande número de membros da comunidade. Att.

Nao. Faturou corretamente.

Precisa sim instalar o modulo Solicite a software Express.

Olá pessoal, tudo bem com vocês? Pessoal de SC, estão conseguindo enviar o arquivo DRCST compactado e em base64, para o WebService validar a estrutura e dar o retorno? Estou a 2 semanas tentando e nada, se alguém está conseguindo, consegue me ajudar? Tentei enviar o exemplo que está no arquivo da SEF e mesmo assim retorna a mesma mensagem: "ResultCode": "Error", "Data": null, "Messages": [ { "Message": "Conteúdo binário do arquivo ZIP é nulo.", "Type": "Error" } ] } Ferramenta de desenvolvimento, Delphi 10.3.1. Desde já agradeço.

Já temos a Data e Local Definidos... A segunda edição do Dia do ACBr, ocorrerá no Parque Tecnológico de Sorocaba, no dia 14 de Setembro de 2019 (Sábado). Reserve essa data na sua agenda, e não perca a chance de participar do 2o encontro da Maior Comunidade de Open Source para Automação Comercial do Brasil Em breve já devemos iniciar a construção de novo Site para a 2a edição do evento, com mais informações, como Grade, Palestrantes, Valor, duração etc...Além é claro, de abrir o acesso a inscrições com preços promocionais para o 1o Lote... (e lembrem-se que o primeiro inscrito recebe um brinde especial do ACBr) Quer Saber como foi o Evento anterior ? Acesse a página do Evento em: https://www.projetoacbr.com.br/diadoacbr/ Todas as palestras do evento anterior, foram Filmadas. No Link abaixo, você poderá ver a coleção de vídeos disponíveis... https://www.projetoacbr.com.br/forum/video/collection/4-dia-do-acbr-1a-edição/ Algumas palestras são abertas e podem ser assistidas por todos usuários do fórum... As demais estão disponíveis para os participantes do Evento anterior e usuários do SAC do ACBr, Como todas as palestras são filmadas, os usuários que se inscreverem no 2a edição do Dia do ACBr, não perderão nenhuma palestra... mesmo que elas ocorram de forma concomitante.. Quer ser um palestrante ? Se você tem interesse em palestrar ou ministrar Workshops, entre em contato conosco, de forma privada. Já estamos pensando na Grade de palestras e formato do evento... Por favor nos detalhe a sua ideia de palestra e porque você acha que o assunto é estratégico para o conhecimento da comunidade do ACBr.

Realmente no manual o campo é do tipo numérico. Após a mudança para tcStr o XML está sendo gerado com sucesso. Obrigado!

RESOLVIDO!! Somente hoje a Goodcard admitiu que estava com problema no site (até então estavam acusando meu xml) e disse que a partir das 11h de HOJE (09/05/2019) o site já estava lendo os meus xml...Perdi 3 dias quebrando a cabeça com assunto que se essa empresa tivesse um diálogo franco com seus parceiros não teria sequer existido. Fique a experiência. Obrigado à todos que tentaram me ajudar.

Boa tarde Alisson, Mas esse campo segundo o manual é numérico. Mudei o tipo de conversão de tcStr para tcInt, faça uma copia da sua proposta, atualiza os fontes e faça um novo teste.

O Extrato do SAT, segue as orientações do SEFAZ http://svn.code.sf.net/p/acbr/code/tools/SAT/Manual_Orientacao_SAT_v_MO_2_17_07.pdf

Hum...Capicom já está obsoleta. Tente utilizar as configurações abaixo: Veja também o vídeo e anexo do link:

Filipe... Deu certo..... Mas me apareceu umas duvidas. * Para imprimir com RAW em rede? seria RAW:\\Compartilhamento\Impressora ? * O Corte no final do cupom esta cortando em cima do texto das observações, teria como ajustar esse corte para um pouco mais embaixo? Grato.... Rennes.

Pessoal, Acabei descobrindo o que era... o frceInstall não adicionou o path do source do FortesReport no Library do Delphi Eu.. mal acostumada com o ACBR que faz tudo né... tinha esquecido de ver isso... rs Adicionei e compilou normalmente... Obrigada pela atenção

Workshop Gratuito TecnoSpeed Academy ERP para Programadores Primeiros Passos Cadastros Veja os principais cadastros que um ERP precisa ter e também algumas dicas que podem tornar os cadastros do seu sistema ainda mais ricos! Estoque Quais são os principais tipos de controle de estoque para um ERP e quais são suas particularidades. Compra e Venda Principais pontos que você precisa conhecer sobre movimentações de Compra e Venda para o seu ERP. Dicas e Boas Práticas Todas as aulas deste workshop, estão recheadas de dicas e de boas práticas que você pode implementar no seu ERP! Acesse: http://bit.ly/2H6WiAg ás aulas iniciam dia 3 de Julho. Qualquer dúvida é só chamar! Abração!! Parabéns pela união da comunidade!

Solicitei o módulo SAT-NFC-E a Software Express e no meu caso funcionou, depois de instalado o módulo as informações são retornadas direitinho. Muito obrigado @Waldir Paim

A configuração só tem efeito quando CST 60 ou CSOSN 500 e não é operação com consumidor final (tag: indFinal = 0).

Boa tarde! Comunico que consegui fazer a homologação do xml com as informações do Responsável Técnico. Grato a todos pelas intervenções e orientações.

@bilogyn Obrigado por compartilhar, mas evite colar trechos grandes de código no corpo da mensagem. Use a opção de anexar arquivos.

Bom dia. Passe o path completo para a propriedade NomeArquivo. Att.

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

Tudo indica um erro na resposta do SEFAZ... ou seja, é necessário relatar o problema ao SEFAZ Podemos verificar a resposta do WebService, ligando a propriedade ACBrNFe.Configuracoes.WebServices.Salvar as respostas serão salvas na pasta: ACBrNFe.Configuracoes.Arquivos.PathSalvar

Após uma longa pesquisa nos manuais do eSocial encontrei essa informação , Obrigada.

Tem razão. Fiz teste com o Delphi Rio e realmente não foram adicionados os paths para plataforma Windows 64 bits. Nesse caso creio que teria que ser adicionado manualmente mesmo.

Bom dia Normalmente a posição desse campo no arquivo é 14 caracteres, se esta retornado com caracteres especiais não esta ficando incompleto o CNPJ?

Por favor crie um novo tópico para um novo questionamento...

Acontece nas melhores famílias. O código que você está interessado está no arquivo ACBrEFDBloco_H_Class.pas, na procedure TBloco_H.WriteRegistroH005(RegH001: TRegistroH001), especialmente essa parte abaixo: if (FBloco_0.Registro0000.COD_VER >= vlVersao104) then begin if DT_FIN >= EncodeDate(2012,07,01) then begin case MOT_INV of miFinalPeriodo: strMotInv := '01'; miMudancaTributacao: strMotInv := '02'; miBaixaCadastral: strMotInv := '03'; miRegimePagamento: strMotInv := '04'; miDeterminacaoFiscos: strMotInv := '05'; else strMotInv := '01'; end;

Apaguei a pasta do acbr, atualizei e instalei novamente e o erro não ocorreu mais. Problema já resolvido.

Prezados, Estes parâmetros têm responsabilidade de preenchimento pelo SAT, baseado em arquivo de parametrização enviado pela Sefaz e periodicamente atualizado, como já citado acima, que o problema ocorre em varias marcas, acredito que o problema esteja neste arquivo de parametrização enviado pela Sefaz e recebido pelos equipamentos SAT. Sugiro que direcionem estes casos no fale conosco da Sefaz.

Cada município contrata sistemas que implementam a NFSe cada um a sua maneira, apesar de haver um padrão nacional e uma tentativa de implantação da NFSe Nacional ainda capengando. Alguns não exigem nem o certificado digital, podendo a comunicação ser feita via usuário e senha, ou hash de acesso. Se o município em questão permite o uso do eCPF e está implementado no ACBr, provavelmente a resposta é sim.

Muito Obrigado Daniel, me ajudou bastante

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

Boa Tarde, @EMBarbosa. Consegui da forma que orientou codificando para base64. Concordo que não é o mais indicado usar o arquivo XML, vou conversar com o responsável pelo servidor para ver se é possível fazer de outra forma. Obrigado pela atenção e pelo auxilio, pode fechar o tópico.

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

Então, Gabriel, é isso mesmo. Aqui no PR já está habilitado para homologação. Se eu não informar recebo a mensagem, usei o codigo acima e recebi a mesma mensagem, como se não tivesse informado. Cleber o retorno do erro:

Blz, @Patrick Alves Muito Obrigado! então nem vou precisar alterar meu fonte, estava com receio que estava errado. qualquer coisa se precisar estamos ai.

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, foi relatado que um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes! Ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já deveria saber que seria rejeitado. Isso é na verdade um ataque de DDOS, nos servidores do SEFAZ. Talvez um ataque sem intenção, mas não deixa de ser um... Mas nesse caso, quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós do ACBr não sabemos como seu sistema funciona, muito menos conhecemos os seus clientes. Ainda mais, qualquer solução do ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe que o item "2.1 Código de Segurança do Responsável Técnico - CSRT" nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

E quando terceiros prestam serviço de manutenção? Quem é o responsável técnico? Dúvidas assim podem surgir quando fixamos na mente mais a ideia de um "representante da classe de programação" perante a lei do que na ideia de um responsável pelo sistema. Talvez isso aconteça porque o termo usado é "responsável técnico". Logo nos vem a mente um engenheiro responsável pela obra e tal... Mas veja bem, a ideia do responsável técnico, é ter uma "pessoa" para quem a Sefaz vai mandar um e-mail quando quiser falar sobre o software emissor do DF-e. Como dito antes, suponha que o software emissor tentou retransmitir a mesma NF-e com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o mesmo XML que já sabia era rejeitado, isso por 70 mil vezes. Nesse caso, quem a SEFAZ deveria contatar? Pensar nesses termos, nos ajuda a entender o motivo das tags Responsável Técnico e assim saber como preencher. Vamos a dois exemplos, com base nas perguntas desse link: Imagine uma microempresa, distribuidora de produtos de limpeza, que para emitir a notas fiscais, paga a um programador fazer as alterações nos fontes de um sistema emissor. Esse programador é pessoa física. Como fica esta situação? Não se engane. A resposta depende mais do tipo do vínculo entre eles e menos de o programador ser uma pessoa física. A questão que deve ser respondida é: Quem é o responsável pelo software? Quem a SEFAZ deve contatar caso queira falar sobre o sistema? Isso vai depender de cada caso e talvez de cada UF. Responder algumas perguntas podem ajudar a resolver a questão: Atualmente, o sistema é da ME distribuidora de produtos de limpeza? O programador é chamado como um terceirizado ou mesmo como funcionário temporário da empresa, não tendo de fato vínculo com o sistema? Por exemplo, ele pode ser substituído por outro programador? (Note, não importa aqui o conhecimento interno do sistema...) Se a resposta a essas perguntas for sim então, a menos que algo diferente esteja em contrato, o responsável técnico é a empresa distribuidora de produtos de limpeza.  Ela contrata outra pessoa para dar manutenção mas, ainda assim, ela é responsável, porque o sistema é dela. No PAF-ECF, chamávamos isso de "sistema próprio". Quer dizer próprio da empresa. Não é um sistema que ela aluga. Caso alguma resposta para as perguntas for não, então, provavelmente, o responsável técnico é o programador. Será necessário verificar com a UF como ele deve ser informado já que ele não tem CNPJ. No caso da empresa ter uma pessoa que saiba programação e faça estas alterações mas não é programador registrado e sim diretor ou gerente ADM, como fica? Nesse caso, sem dúvida, o responsável técnico é a própria empresa. Ela tem um sistema próprio, desenvolvido internamente para emitir os DF-e. Não importa se quem faz as alterações é um programador ou o contínuo da empresa. O importante é quem é responsável perante a SEFAZ e, nesse caso, é claro que a SEFAZ não vai querer saber quem deu manutenção no sistema. Quando ela precisar falar com um responsável, ela vai querer contatar diretamente a empresa. Afinal de contas, se a empresa não quisesse isso ela teria contratado um sistema de alguém ao invés de permitir um funcionário (ou sobrinho do dono) criar o sistema.

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

Muito obg salvou minha vida !! ja estou a dois dias com esse erro. Substitui as linhas resolvido!!!

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.

Olá Já está assim no SVN . Talvez seu arquivo estivesse desatualizado. Obrigado pelo aviso. Me parece correta a alteração em vista dos erros que você está recebendo. Mas parece que não tem mais usuários do MS com o mesmo problema. Estamos avaliando o motivo... Assim que resolvido te damos um retorno ou enviamos pro SVN.

Boa tarde a todos, Conforme anunciado pelo SEFAZ, a partir de Janeiro de 2019, seria válido o layout 0.08 do XML de entrada.... e ao mesmo tempo, o (antigo e obsoleto) layout 0.06 deixaria de ser aceito.... O fato do layout ser aceito, não significa necessariamente que todos precisam migrar imediatamente para ele... Isso depende inclusive, da atualização do Software Básico dos equipamentos em campo (veja tópico a seguir ) O que realmente muda, é que o layout 0.06, deixou de ser aceito... ( bem, mesmo isso foi prorrogado ) Portanto se a sua aplicação apenas suporta o XML 0.06, CORRA e faça os ajustes necessários para suportar a 0.07 ou a 0.08... Se você já suporta o layout 0.07, então veja aqui, o que há de novo no layout 0.08, e como se ajustar a ele... O que mudou no XML de entrada 0.08 ? Conforme consta na Especificação SAT_v_ER_2_26_04, temos as seguintes alterações: Layout do XML de venda: 1. Grupo enderEmit - campo xBairro passa a ter o seu tamanho variável alterado de 2-60 para 1-60 (mínimo 1 caractere e máximo de 60). 2. Grupo emit - campo IE passa a ter o seu tamanho fixo de 12 alterado para variável: 2-14. 3. Grupo dest - campo CPF passa a ter tamanho fixo de 11 dígitos, antes o campo poderia ficar vazio. 4. Grupo prod - incluído o campo CEST (opcional) de tamanho fixo de 7 dígitos. 5. Grupo obsFiscoDet - campo xTextoDet passa a ter uma nova instrução de preenchimento: 6. O grupo obsFisco gerado pelo SAT é que teve uma mudança significativa e merece ser mencionado aqui. Esse grupo antes estava dentro do grupo infAdic, agora ele esta no mesmo nível do infAdic, portanto ambos (infAdic e obsFisco) estão dentro do grupo CFe. Layout do XML de Cancelamento: 1. Os campos referentes aos itens: 1, 2 e 3 (do layout do XML de venda) sofreram a mesma alteração, mas eles são gerados pelo SAT.

Mas aí você joga a bronca pra cima das redes....

Sim, isso ocorre... e muitas vezes inviabiliza o cancelamento, ,por falta de informações... Eles alegam questões de segurança...

@José M. S. Junior, o que acha da ideia ? Na minha opinião parece fazer sentido, e ser de simples implementação...