Painel de líderes

Bom dia a todos, Foi publicado a versão 1.20 da NT 2020/006 (16/03/2021) . O que mudou? Alteração em algumas regras de validação da SEFAZ e data de ativação tanto no ambiente de homologação quanto de produção. Veja como ficou as datas: Versão Descrição Homologação Produção 1.00 Criação de campos e Regras de Validação - seção 2 desta NT 01/02/2021 05/04/2021 1.10 Prazo de implantação desta NT v1.00 e v.1.10 para SV-AN, SP, MG e GO 01/03/2021 05/04/2021 1.10 Inclusão das regras YB01-10, YB01-20 e YB02-10 para modelo 65 01/03/2021 05/04/2021 1.10 Regra YA02-50 , observação 2 01/03/2021 05/04/2021 1.10 Regra B25c-10, observação 2 05/04/2021 01/09/2021 1.10 Regra Y08-90, observação a critério da UF 01/03/2021 05/04/2021 1.20 Regras YA02-60, YA06-10 e B25c-10, YA02a-10 e YA02a-20, inclusão do campo YA02a - xPag até 03/05/2021 01/09/2021 1.20 Regra YA02-50 foi eliminada até 03/05/2021 - Regra YA02-60 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o código do meio de pagamento (tag: tPag) existe na Tabela de códigos dos meios de pagamentos publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra YA06-10 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o Código da bandeira de cartão de crédito e/ou débito (campo: tBand) existe na tabela de códigos das operadoras de cartão de crédito e/ou débito publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra B25c-10 que é aplicada tanto para NF-e quanto para NFC-e: Se Informado indicativo de presença, tag: indPres, IGUAL a 2, 3, 4 ou 9 - Obrigatório o preenchimento do campo Indicativo do Intermediador (tag: indIntermed) Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção. Regra YA02a-10 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento (tag: tPag) for preenchido com o código 99-outros, obrigatório o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02a-20 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento for diferente 99-outros (tag: tPag<>99), proibido o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02-50 que é aplicada tanto para NF-e quanto para NFC-e: Esse regra foi eliminada das regras de validação da SEFAZ no que se refere as Informações de Pagamento. Inclusão da tag <xPag> (opcional) dentro do grupo <detPag> Grupo de Detalhamento do Pagamento para atender as regras YA02a-10 e YA02a-20. O componente vai ser atualizado assim que foi publicado os novos schemas para atender a nova tag (xPag). Sendo assim fiquem atentos as atualizações dos fontes ACBr. Como vai ter alteração nos schemas se faz necessário atualizar os schemas nas maquinas dos seus clientes assim que eles estiverem disponíveis.

Olá pessoal. Levanta aí que vamos falar da atualização do ACBr. Resolvemos criar esse tópico devido a muitas dúvidas relacionadas a isso e depois de um debate interessante sobre o assunto. Principalmente quando entra a questão de quando atualizar o programa no cliente. Na sua empresa, vocês devem entender que o Projeto ACBr tem uma forma de desenvolvimento própria. Vocês não precisam seguir o mesmo pra seu desenvolvimento porque os objetivos talvez sejam diferentes. Mas vamos entrar em detalhes depois... agora... A pergunta mais importante: Quando Atualizar o ACBr? Podemos resumir no seguinte: atualize o o mais frequentemente quanto possível. Mas a resposta completa vai depender da sua equipe, do tamanho da empresa e das alterações que foram disponibilizadas. A chave é que vocês devem se sentir como desenvolvedores do ACBr. O código é open-source e é também de vocês. Afinal, ele roda na sua aplicação e afeta seus clientes. Além disso, geralmente as funções que usamos do ACBr são cruciais no sistema. Mesmo que vocês sejam desenvolvedores que utilizam as libs ou o ACBrMonitore e, tenham a impressão que não se encaixam nesse perfil, os princípios delineados aqui podem ajudar. Como é o fluxo de desenvolvimento do ACBr? No Projeto ACBr, em especial no desenvolvimento dos componentes, nós usamos um fluxo de desenvolvimento que não é totalmente orientado a versões. Esse fluxo é algo mais parecido com o trunk based development do que com um GitFlow. Para quem vê de fora, isso significa basicamente: Controlamos a versão dos componentes via o versionamento do próprio SVN. Assim, podemos reproduzir qual versão uma pessoa tem instalada apenas sabendo a revisão do código que ela usa; Não ficamos criando branches para desenvolvimento de funções e recursos. Nós temos um repositório branches, mas não ficamos desenvolvendo recursos nos componentes atuais nele a menos que seja estritamente necessário (Por exemplo: um refactoring total do componente); Quem usa os componentes tem os novos recursos, correções, e respostas muito mais rapidamente do que teria de outra forma; Pra não delongar mais nisso (que não é o foco desse artigo), se quiser ver um exemplo de empresa que usa esse tipo de desenvolvimento, recomendo esse artigo "Moving away from GitFlow" (de Niklas Gray). Mas isso funciona pra nós em especial porque (a) quem usa os componentes também é desenvolvedor e (b) temos uma resposta muito rápida quando acontecem problemas. Assim, isso não significa necessariamente que vai funcionar na sua empresa. Voltando a pergunta importante... Como estabelecer uma rotina de avaliar se e quando deve ser feita a atualização do ACBr? Se vocês não tem nenhuma rotina pra avaliar quando e se devem atualizar o ACBr, sugerimos que estabeleçam uma. A princípio, sugerimos o seguinte: Leiam os logs do SVN pelo menos uma vez por dia. Não é preciso atualizar para ler o log. Basta usar o "Show Log" do SVN. Ao ler o log do SVN, verifique se: Alguma alteração feita afeta seus clientes em produção? (correção de bug, alteração de legislação, etc...) Algum novo recurso que você quer utilizar foi implementado? Se são poucas alterações e elas não são essenciais, você (ou alguém na sua equipe) tem tempo para testar? São muitas alterações que foram feitas? Já passou muito tempo desde que foi feita a última atualização? Por exemplo mais de 3 semanas? Caso a resposta a qualquer pergunta acima seja "sim", atualize e teste seu desenvolvimento. No mínimo você vai estar mantendo o código do seu aplicativo com o mínimo de alterações possíveis. Então quando surgir uma situação que vocês precisem atualizar com urgência, não vai haver uma grande quantidade de trabalho acumulado. Caso negativo, siga com as suas tarefas. É claro que, se vocês estão no meio de uma situação que precisa que todo o desenvolvimento fique focado no produto de vocês, talvez não seja possível atualizar o ACBr. Por exemplo, pode ser que um problema no software esteja exigindo a atenção urgente de toda equipe. Mas geralmente, pelo menos um dev deve conseguir dar uma lida nos logs e fazer a avaliação se é necessário ou não atualizar. Nota: Vale lembrar também que nem toda atualização precisa de uma reinstalação. Você precisa reinstalar quando: As alterações envolvem partes visuais dos componentes; Os fontes não são recompilados ao fazer um build em sua aplicação; Depois de atualizar, teste as partes de sua aplicação que usam os componentes modificados assim que possível. Primeiro na sua máquina de desenvolvimento, depois em outras máquinas. O último a ser atualizado é o servidor de Build. A partir daí já entra no "deploy", quer dizer, na entrega do software para o cliente. Como impactar da menor maneira possível meu cliente com meu software após atualização do ACBr? Gostaria de enfatizar que você precisa ter estratégias diferentes. Uma para quando você deve atualizar o ACBr (desenvolvimento) e uma para quando você deve atualizar o seu sistema no seu cliente (deploy). Tudo bem que as duas estratégias podem ser interligadas, como é o caso quando se usa um sistema de "Implantação Contínua". Mas são duas coisas diferentes que você precisa ter em mente. Para reduzir o impacto nos clientes, faça o "deploy" de forma escalonada. Quer dizer, instale a nova versão primeiro em clientes selecionados. A princípio, escolha apenas dois, três ou no máximo quatro. Quanto mais crítica a alteração, mais seletivo você precisa ser. Dentre sua carteira de clientes, minha sugestão é para escolher aqueles que: Precisam da "novidade" apresentada no novo executável Tem um movimento menor (e assim darão um grau menor de dor de cabeça caso algum imprevisto aconteça) Ficam mais próximos de sua empresa (posso deslocar um técnico ou até mesmo um "dev" pra lá rapidamente se realmente necessário, nem que seja virtualmente?) São mais pacientes e compreensivos (paciência nunca é demais, apenas cuide de não abusar deles) Só depois de um tempo de teste nesses clientes, envie a nova versão para os outros. Você pode continuar escalonando a entrega avaliando o tamanho da sua equipe e número de clientes que possui. De qualquer maneira você precisa avaliar o que é melhor pra sua empresa. Mas como decidir? Muitas questões devem ser levadas em conta. É verdade que ninguém deveria ficar desesperado para instalar uma nova versão se não teve condições de fazer testes. Também, antes de enviar uma versão aos clientes é preciso levar em conta a quantidade de clientes, o tamanho da equipe de desenvolvimento, da equipe de suporte e até o plano de negócios da empresa. Mas por outro lado, as seguintes perguntas precisam também ser analisadas: Só se envia uma nova versão ao cliente para resolver problemas? Não são apresentadas ao cliente os novos recursos como algo que facilita a vida dele? Não seria muito mais interessante comercialmente se o programa tivesse sempre novidades para cativar o usuário? Não será muito mais difícil encontrar e resolver um problema se de uma versão para outra houverem muitas alterações no código? Que controle se faz de versão do software que está instalado no cliente? Consegue-se facilmente reproduzir no ambiente de desenvolvimento? Sua equipe tem tamanho suficiente pra cuidar de várias versões diferentes? Temos certeza que a análise dessas questões vão ajudar vocês a tomarem boas decisões. Bom trabalho por aí.

Olá Pessoal, Hoje disponibilizamos mais um componente, o ACBrPagFor. A funcionalidade que ele permite é automatizar a autorização de pagamentos em um banco. Por exemplo, automatizar o pagamento de fornecedores que tenham emitidos contra seu cliente boletos, títulos, etc... O componente gera o arquivo para indicar aos bancos que um pagamento pode ser feito. Essa funcionalidade, de modo geral, é chamada pelos bancos de "Pagamento de Fornecedores" (veja alguns links no final do artigo). Como o componente funciona? Esse componente gera um arquivo texto segundo o padrão CNAB 240 para pagamentos de fornecedores. Ele também é capaz de fazer a leitura do retorno, de modo que você pode saber o resultado. Ele já existia antes e estava em outro repositório do ACBr chamado Branches com o nome ACBrCNAB. Resolvemos trocar o seu nome ao migrar para o Trunk2, pois assim acreditamos que os desenvolvedores estão mais familiarizados com o termo PagFor utilizado por diversos bancos. Para que bancos? Ele não contempla todos os bancos nesse momento de lançamento, mas é um pontapé inicial. Os testes iniciais foram realizados com os bancos: Itaú, HSBC, Santander, Sicred e Banco do Brasil. Contamos com a colaboração da comunidade ACBr para torná-lo mais completo e robusto. Então fique a vontade implementar no seu sistema essa nova funcionalidade e para testar e colaborar com melhorias e correções. ------- Links para essa funcionalidade em alguns bancos: https://banco.bradesco/html/pessoajuridica/solucoes-integradas/pagamentos/pag-for.shtm https://www.santander.com.br/servicos-financeiros/solucoes-de-pagamento/pagamento-a-fornecedores https://www.sicredi.com.br/site/pagamentos-e-recebimentos/para-sua-empresa/pagamento-a-fornecedores/ https://www.caixa.gov.br/empresa/pagamentos-recebimentos/pagamentos/fornecedor/Paginas/default.aspx https://www.daycoval.com.br/para-empresa/servicos/pag-for

Olá pessoal, Temos novidades na NF-e que vão trazer alterações no componente. "Essa Nota Técnica divulga novos campos e regras de validação para a NF-e/NFC-e versão 4.0, visando a adequação ao disposto no Ajuste SINIEF 21/2020 e 22/2020, envolvendo a identificação do intermediador ou agenciador da operação." O prazo previsto para a implementação das mudanças é: * Ambiente de Homologação (ambiente de teste das empresas): 01/02/2021 * Ambiente de Produção: 05/04/2021 Ainda não foi liberado os novos schemas. Fiquem tranquilos que o ACBrNFe será atualizado para que todos possam realizar os testes assim que o ambiente de homologação for liberado. Observação: Novos campos que vão fazer parte do layout da NF-e: elemento <indIntermet> é opcional e aceita os valores: 0 = Operação sem intermediador (em site ou plataforma própria) e 1 = Operação em site ou plataforma de terceiros (intermediadores/marketplace) grupo <infIntermed> Grupo de informações do Intermediário da Transação, contendo os elementos <CNPJ> CNPJ do Intermediador e <indCadIntTran> Nome do usuário ou identificação do perfil do vendedor no site do intermediador.

Bom dia Pessoal, acabei de fazer a homologação para a prefeitura de Jardim/MS e o provedor usado é este mesmo da AEG. Durante meus testes eu tive que fazer algumas alterações para ficar ok, vou colocar os fontes em anexo. @Italo Giurizzato Junior caso esteja tudo ok com as alterações, solicito que sejam inseridos no repositório para compartilhar com os demais que estejam precisando, por favor. No Cidades.ini para Jardim eu alterei o provedor para AEG, estava ISSNet. pcnLeitor.pas pnfsNFSeW_ABRASFv2.pas pnfsNFSeR.pas ACBrNFSeWebServices.pas

Bom dia, atualizou a pasta Schemas também? Outro detalhe é que está informando a tag indIntermed no XML em Produção, por enquanto é aceito apenas em homologação.

ATENÇÃO! Parada programada do Portal Nacional da NF-e no dia 28/03/2021 das 8h às 12h No dia 28/03/2021, a partir das 8 h, serão executados procedimentos de manutenção que requerem que o Portal Nacional da NF-e fique indisponível. A operação vai durar no máximo 4 (quatro) horas. Assinado por: Receita Federal do Brasil

Boa tarde a todos, Os Schemas referente a essa NT na compreende na verdade 2 novos tipos de eventos: Comprovante de entrega da NF-e e o de Cancelamento do Comprovante de entrega da NF-e, já se encontram no repositório. As datas de liberação são: 01/06/2021 - Ambiente de Homologação 22/06/2021 - Ambiente de Produção Para quem tem o habito de manter os fontes sempre atualizados, quando a SEFAZ liberar basta testar, pois o componente já esta com esses dois eventos implementados.

É com muita satisfação, que estamos criando um novo serviço, para nossos usuários do ACBr Pro (SAC na modalidade de assinatura Anual). Esta inovação é orgulhosamente mantida por nossos consultores, para trazer conteúdos novos todas as semanas para os Pros. Queremos fazer a diferença no dia-a-dia desta comunidade, com conteúdos que abordam desde nossos componentes, até assuntos gerais em desenvolvimento e automação comercial. O que é o Papo Pro ACBr ? O Papo Pro ACBr é um serviço de Consultoria por Voz, que ocorrerá das 10:00hs as 11:00hs, toda terça a quinta-feira, e prestado pelos nossos Consultores / Desenvolvedores do ACBr, através do Discord A quem se destina ? Esse serviço e exclusivo à nossos assinantes ACBr Pro, ou seja, aqueles já acessam o Discord no Grupo ACBr Pro. Como funciona, esse serviço de Consultoria ? De terça-feira até quinta-feira, abriremos um horário diário para consultoria por voz, através do Discord, no Canal de Voz #Papo Pro ACBr . Cada dia, um assunto em específico será abordado... As perguntas devem ser focadas no assunto do dia, pois os consultores escolhidos para o atendimento, estarão focados no assunto do dia... Basta clicar no Canal de Voz, para ingressar na reunião, começar a receber o áudio, e ver os participantes... Para Falar.. libere o seu microfone... O Discord tem um ótimo software para captura de voz, e supressão de ruídos.. alias, esse é o ponto forte do Discord, e motivo principal para ele ser o "queridinho" dos Gamers, que jogam em grupos on-line... Caso queira sair da Sala.. basta usar o botão de desconexão... Se desejar, você pode compartilhar a sua câmera... Se você precisar compartilhar sua Tela, isso é possível.. basta clicar no botão para iniciar o compartilhamento... Após isso, o Discord perguntará qual Tela ou Aplicativo, você quer compartilhar... Escolha o Programa ou Tela que deseja compartilhar e clique no botão "Ao Vivo"... Vários usuários poderão compartilhar a tela ao mesmo tempo, observe que ao lado do nome do usuário, aparecerá em vermelho o texto "AO VIVO" Para assistir a tela compartilhada, basta clicar no nome do usuário, e em seguida em "Assistir à Transmissão" Como posso fazer minhas perguntas ? Você sempre poderá fazer suas perguntas durante a reunião, por voz.. mas além de um novo canal de Voz, criamos 4 novos canais de texto, que são exclusivos para o endereçamento de perguntas para as reuniões que ocorrerão de terça a quinta-feira... Dessa forma, recomendamos a todos usuários do ACBr Pro, que escrevam as suas perguntas, antes da reunião, para que nossos consultores já possam se preparar para uma melhor resposta... As perguntas serão respondidas por ordem de chegada... Como posso saber qual assunto será abordado ? Criamos um novo calendário no nosso fórum.. Basta acessar nosso Calendário, e ver os apontamentos da Cor Verde Posso sugerir assuntos ? Claro que SIM.. Contamos com a sua sugestão para definirmos as próximas agendas... Por favor use o canal #duvidas-gerais, do Grupo ACBr Pro, para sugerir o assunto do seu interesse... Porque não tem reunião segunda-feira ? Segunda, nossos consultores já realizam uma importante reunião de alinhamento do Sprint... E se não der tempo de responder tudo em uma hora ? Teremos reuniões diárias.. podemos continuar no próximo dia... Também podemos continuar a reunião, conforme a disponibilidade de nossos consultores / desenvolvedores Assista o vídeo:

Boa tarde Kelvin, Muito obrigado pela colaboração, vou incluir na minha lista de tarefas.

fiz o teste. a mensagem de erro ele pega do arquivo de retorno da sefaz. em anexo imagem do xml de retorno.

Voltou a funcionar sem eu fazer nada. Acredito que seja alguma atualização do windows 10 que estava pendente, não sei ao certo. Mas foi resolvido o problema

legal, muito obrigado pela ajuda

Boa tarde Jefferson, Eu não utilizo o ACBrMonitor, mas procurei no manual do mesmo o método para imprimir o DANFE e encontrei a seguinte sintaxe. NFE.ImprimirDanfe(cArqXML,[cImpressora],[nNumCopias],[cProtocolo],[bMostrarPreview],[cMarcaDagua],[bViaConsumidor],[bSimplificado]) Parâmetros cArqXML - Caminho do arquivo XML da NF-e. cImpressora - Nome da Impressora. Obs.: Parâmetro opcional. nNumCopias - Número de Cópias. Obs.: Parâmetro opcional. cProtocolo - Número de Protocolo de NF-e. Obs.: Parâmetro opcional. bMostrarPreview - exibe o preview antes da impressão (1 - para exibir). Obs.: Parâmetro opcional. cMarcaDagua - Imprime parâmetro informado como MarcaDagua. Obs.: Parâmetro opcional. bViaConsumidor - Emitir via do Consumidor (1 - para emitir) Obs.: Parâmetro opcional. bSimplificado - Imprimir DANFe modelo Simplificado (1 - para emitir). Obs.: Parâmetro opcional. NFE.ImprimirDanfe("c:\35XXXXXXXXXXXXXXXX550010000000050000000058-nfe.xml", , , ,1) Acredito que com o comando acima você vai conseguir visualizar o DANFE na tela sem a necessidade de imprimir no papel ou gerar um PDF.

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

Boa tarde José ! Show, funcionou perfeitamente... Muito obrigado novamente.

Não. mas tu pode acompanhar no SVN na pasta branches está lá e quiser ajudar melhor ainda. até a hora que estiver funcionando o mesmo será postado aqui no fórum como noticia

Apos remover e reinstalar a validacao funcionou, obrigado pela ajuda

Não se deve confundir o CNPJ do intermediador da transação (YB02), com o CNPJ da instituição de pagamento (YA05). Porém, em algumas situações poderá ser o mesmo CNPJ. Por exemplo: caso o intermediador da transação seja o responsável por fazer o pagamento ao vendedor (emitente da NF-e), deve ser informado no campo CNPJ da instituição de pagamento o CNPJ do intermediador. Portanto, para efeitos do CNPJ da instituição de pagamento, deve ser informada a instituição/empresa que fez o repasse de pagamento para o vendedor/remetente. Em outras palavras, o CNPJ do adquirente, subadquirente, intermediador ou instituição similar que efetuou o pagamento ao vendedor. Texto extraído da Nota Técnica 2020/006 versão 1.20 (página 12).

Neste workshop abordamos os conceitos envolvidos na apuração de custos e na composição do preço de venda. Também veremos como proceder com sua modelagem e implementação no seu software de automação ou E.R.P. Com isto sua software house terá um produto mais completo na gestão de seus clientes, além de conquistá-los entregando mais produtividade e valor. Agenda do workshop: - O que são custos? - Como funciona a apuração de custos? - Custos no Simples Nacional e no Regime Normal - Como compor os preços de venda no software? - Como modelar e implementar apuração de custos e composição de preço de venda, conquistando vantagem competitiva em meu sistema? Sobre as aulas: O workshop será ao vivo, dia 19/03 às 19:30 pela plataforma ZOOM, cujo link de acesso será enviado aos inscritos no dia da aula. Acesse: https://custos.sacfiscal.com.br

Jesus, eles não se decidem.

Boa tarde, Fiz algumas alterações para tratar do Leiaute 7.0. Manual disponível em: http://sped.rfb.gov.br/arquivo/download/5717 ACBRECFBlocos.pas acrescentado ECFVersao700 em: - Type TACBrECFCodVer = (ECFVersao100, ECFVersao200, ECFVersao300, ECFVersao400, ECFVersao500, ECFVersao600, ECFVersao700); - function CodVerToStr(AValue: TACBrECFCodVer): string; - function StrToCodVer(const AValue: string): TACBrECFCodVer; ACBrECFBloco_0_Class.pas acrescentado ECFVersao700 em: - procedure TBloco_0.WriteRegistro0010; - procedure TBloco_0.WriteRegistro0020; ACBrECFBloco_Y_Class.pas acrescentado ECFVersao700 na procedure TBloco_Y.WriteRegistroY800; Seguem em anexo, arquivos alterados para verificação e commit nos fontes. ACBrECFBloco_0_Class.pas ACBrECFBloco_Y_Class.pas ACBrECFBlocos.pas

Se você olhar o tópico abaixo, o Elton fez uma varredura geral nas impressões DFe com relação as margens estarem em mm ou cm: Pelo tópico, NFCe em Fast era em mm, e o padrão do componente era em cm, então ficava 0.51 mm pra margem direita, 0.6 mm para a esquerda... Agora o padrão alterou para mm, ficando 5.1, 6, 8 e 8 mm, consequentemente mudando as margens no DANFE NFCe em Fast. Não tinha como manter como era em todos os documentos, algum ia ter modificação, foi feito da forma a ter impacto menor considerando todos os DFe. Pra finalizar, sugiro colocar a margem superior e inferior como 0, pra não cortar o rodapé do DANFe NFCe.

Bom dia a todos, Foi publicado hoje (15/02/2021) a versão 1.10 da NT 2020/006. O que mudou? Alteração em algumas regras de validação da SEFAZ e data de ativação tanto no ambiente de homologação quanto de produção. Veja como ficou as datas: Versão Descrição Homologação Produção 1.00 Criação de campos e Regras de Validação - seção 2 desta NT 01/02/2021 05/04/2021 1.10 Prazo de implantação desta NT v1.00 e v.1.10 para SV-AN, SP, MG e GO 01/03/2021 05/04/2021 1.10 Inclusão das regras YB01-10, YB01-20 e YB02-10 para modelo 65 01/03/2021 05/04/2021 1.10 Regra YA02-50 , observação 2 01/03/2021 05/04/2021 1.10 Regra B25c-10, observação 2 05/04/2021 01/09/2021 1.10 Regra Y08-90, observação a critério da UF 01/03/2021 05/04/2021 Regra YA02-50 que é aplicada tanto para NF-e quanto para NFC-e: Informado meio de pagamento tPag= 99 “Outros” Observação 1: Regra válida a partir de 01/02/2021 para homologação e 01/09/2021 para produção. Observação 2: Regra de validação não se aplica para Nota Fiscal eletrônica Avulsa emitida por Produtor Primário. Regra B25c-10 que é aplicada tanto para NF-e quanto para NFC-e: Se Informado indicativo de presença, tag: indPres, IGUAL a 1, 2, 3, 4 ou 9 - Obrigatório o preenchimento do campo Indicativo do Intermediador (tag: indIntermed) Observação 1: Regra válida a partir de 01/02/2021 para homologação e 01/09/2021 para produção. Observação 2: Regra válida para Nota Fiscal Avulsa eletrônica a partir de 05/04/2021 para homologação e 01/09/2021 para produção. Regra Y08-90 que é aplicada somente para NF-e: CFOP é de operação interestadual (inicia por 2 ou 6) e UF emitente = UF destinatário e CNPJ/CPF emissor diferente do CNPJ/CPF destinatário (NT 2010/004) Exceção: Se a tag UFCons (id:LA06) foi informada com UF diversa do emitente: CFOP iniciado com 2 ou 6 é válido. (NT 2010/010). Observação: Regra de validação opcional, a critério da UF.

Olá, Para quem utiliza o ACBrMonitorPLUS, estamos lançando uma versão Beta Test com algumas melhorias na interface... As mudanças visam uma melhor experiência dos usuários ao configurar a ferramenta e também para identificação de possíveis problemas nas validações de cada componente. Veja no vídeo abaixo o que mudou... E fica o convite para baixar essa nova versão e realizar os seus testes!!!

Olá como muitos tem necessidade em possuir duas ou mais versões do delphi para migração a exemplo sair da versão 7 e subir para uma nova, abaixo segue alguns procedimentos que devem ser feitos todas as versões que possui instalado no micro. Passos: 1) Entre na IDE de cada Delphi instalado em sua maquina 2) Vá no menu Tools->Options-> Environment Variables, 3) Procure na lista “System Variables” a opção “Path” e selecione 4) Clique na opção “Add Override”, será adicionado no quadro User Override uma opção Path 5) Selecione no quadro User Override, a opção Path que foi adicionada, clique em Edit e retire o path das outras versões, deixando somente os caminhos da versão que você estiver executando esse processo. Depois de executar essa tarefa em cada versão, cada uma ao ser iniciada, irá sobrepor a variável PATH, não indo buscar mais nada, no path das outras versões do Delphi. Lembre-se as imagens acima é da versão mais recente do delphi, os locais e disposição estão diferente nas demais versões do delphi, mas todos tem essa opção Fonte Isaque Pinheiro Blog

Olá! Alguém conseguiu dar continuidade? Pessoal do suporte da AEG não está me respondendo mais

Olá Pessoal, Muitos tem interesse em obter o XML do fornecedor para facilitar a entrada dos materiais no Estoque, Contas a Pagar, etc. Segundo a legislação, quem emite uma NF-e tem por obrigação legal de disponibilizar o XML assinado e com o protocolo de autorização ao destinatário da mercadoria, assim que a SEFAZ autorizar a nota. Essa disponibilização pode ser feita por e-mail, ou seja, o emitente envia para o destinatário o XML via e-mail. Sabemos que isso nem sempre ocorre, por 2 motivos: 1. No cadastro do destinatário não consta o endereço de e-mail; 2. A aplicação do emitente não possui esse recurso ou esta desativado. Mas temos uma alternativa. Com certeza o DANFE foi impresso e entregue junto com a mercadoria. De posse do DANFE temos a chave e com ela podemos primeiramente enviar o evento de Manifestação do Destinatário. Temos duas situações: 1. Se as mercadorias foram entregues conforme o combinado, devemos enviar o evento: Confirmação da Operação (Código: 210200); 2. Se algo estiver errado e alguma mercadoria esta errada, quebrada, ...., devemos enviar o evento: Operação não Realizada (Código: 210240), neste evento se faz necessário informar uma justificativa. Após manifestar todas as notas, podemos obter o XML através do método: DistribuicaoDFePorChaveNFe, esse método possui 3 parâmetros, sendo eles: Código da UF do Destinatário, CNPJ do Destinatário e a Chave da NF-e previamente manifestada. Conclui-se que devemos executar o método acima para cada nota manifestada. Informação importante, tanto a Manifestação do Destinatário quanto o Distribuição DF-e, são atendidos pelo Ambiente Nacional, portanto não tem nada haver com a SEFAZ-Autorizadora do emitente da nota ou do destinatário da mercadoria. Se algo falhar nesse processo, a "culpa" é do Ambiente Nacional.

Se você usa o ACBrMonitorPLUS, veja essas vídeo aulas do curso Dominando o ACBrMonitor https://www.projetoacbr.com.br/forum/video/browse/37-aula-24-distribuicao-dfe/

No tópico abaixo, temos uma excelente resposta, de @Gabriel Franciscon, sobre esse mesmo tema

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, 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á sabia era rejeitado... Isso é praticamente um ataque de DDOS, nos servidores do SEFAZ... 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 não sabemos como seu sistema funciona, nem conhecemos os seus clientes. Ainda mais, o 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, o item "2.1 Código de Segurança do Responsável Técnico - CSRT" que 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.

No meu sistema estava com o mesmo erro, o problema era que eu não estava com a última versão do emulador.

Olá pessoal, Na postagem "Como obter o XML do Fornecedor" mostrei o uso do método DistribuicaoDFePorChaveNFe, nessa nova postagem vou mostrar mais dois métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe, que por sinal é semelhante ao do DistribuicaoDFePorChaveNFe. DistribuicaoDFePorUltNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do ultimo NSU> ) DistribuicaoDFePorNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do NSU> ) Primeiramente vamos entender o que vem a ser esse tal de NSU. NSU - numero sequencial único, é um numero atribuído pelo Ambiente Nacional ao documento ora compartilhado pelas SEFAZ-Autorizadora. Exemplo: o emitente da nota é do Estado de São Paulo, logo a nota é enviada para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional as notas que foram autorizadas, o Ambiente Nacional por sua vez atribui um NSU para cada nota que receber. Na verdade o Ambiente Nacional gera um resumo da nota e atribui o NSU a esse resumo primeiramente e não a nota propriamente dita. Um NSU só será atribuído a nota quando o destinatário enviar o evento de Manifestação do Destinatário. Lembre-se o NSU da nota será um numero diferente do NSU do resumo dela, e por ser gerado após o envio do evento de Manifestação do Destinatário, podemos concluir que o NSU da nota é maior que o NSU do resumo. Vamos agora entender como funciona os dois métodos mencionados acima. O método DistribuicaoDFePorNSU é o mais simples de entender, pois este simplesmente baixa o documento que possui o NSU informado. Note que usei o termo documento, pois o webservice DistribuicaoDFe pode retornar os seguintes tipos de documentos: Resumo de Nota, Nota Completa, Resumo de Evento e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um resumo, o que teremos como retorno será o XML do resumo e não o XML da Nota. Por outro lado o método DistribuicaoDFePorUltNSU nos retorna uma lista com até 50 documentos, cujos NSU são superiores ao NSU informado. Exemplo: DistribuicaoDFePorUltNSU( 35, 12345678000123, 450 ) ===> 450 é o valor do Ultimo NSU. Ao executar o método, como dito anteriormente poderá nos retornar uma lista com até 50 documentos, pois bem suponha que retorne 50, os NSU desse documentos retornados serão, 451, 452, 453, ...., 498, 499, 500. Lembre-se que nessa lista podemos ter Resumos de Notas, Notas Completas, Resumo de Eventos e Eventos Completos. Através de uma propriedade chamada Schema nos traz a informação do tipo de documento retornado. Temos também outras duas propriedades muito importantes, são elas: UltNSU e MaxNSU. A propriedade UltNSU nos informa o numero do NSU referente ao ultimo documento da lista, já a propriedade MaxNSU nos informar o maior NSU existente no Ambiente Nacional. Continuando o exemplo acima, vamos supor que após a execução os valores de UltNSU e MaxNSU são respectivamente 500 e 750. Era de se esperar mesmo que o valor de ultNSU seja 500 pois informamos 450 e foi retornado 50 documentos, logo o NSU do ultimo é 500. A próxima vez que formos executar o DistribuicaoDFePorUltNSU devemos informar o valor 500, para que ele retorne os documentos a partir de 501 que é o próximo da lista. E devemos repetir o procedimento até que o valor de ultNSU seja igual a maxNSU, desta forma vamos ter baixado todos os documentos disponibilizados pelo Ambiente Nacional. Lembre-se que o valor de MaxNSU tende sempre a crescer a medida que novas notas forem emitidas e compartilhadas com o Ambiente Nacional e a medida que o destinatário for enviando o evento de Manifestação do Destinatário. Entre uma execução e outra do DistribuicaoDFePorUltNSU você pode realizar a manifestação referente a cada resumo de nota obtido, ou seja, enviar o evento de Manifestação do Destinatário. Desta forma a medida que você vai avançando na lista o Ambiente Nacional já vai liberando a Nota Completa (notas manifestadas) e disponibilizando ela na lista. O DistribuicaoDFe não serve apenas para que possamos obter o XML do fornecedor, mas também descobrirmos se existe alguma empresa emitindo notas contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Manifestação do Destinatário: Desconhecimento da Operação. Esse evento diz a SEFAZ que você não comprou desse fornecedor. Para saber mais sobre Manifestação do Destinatário vide a Nota Técnica 2012/002 versão 1.02 e para saber mais sobre o Distribuição DFe vide a Nota Técnica 2014/002 versão 1.02b, ambas estão disponíveis no Portal Nacional da NF-e.

Boa noite. Algum de vcs tem um xml de São Luiz - MA válido para me enviar de exemplo para que possa verificar a estrutura, pois nos manuais aparentemente esta desatualizado e faltando tags. Já tentei varias vezes entrar em contato com suporte de lá e não consigo contato nem retorno. Agradeço!