Painel de líderes

Daniel Simoes,Rafael Dias...Obrigado pelo apoio,agora deu tudo certo aqui.

Você tem mais locais com os fontes e também arquivos compilados do ACBr ou do fast report mesmo. verifique isso que resolve seu problema

Já consegui resolver olhando o tópico. https://quality.embarcadero.com/browse/RSP-20780?jql=text ~ "GetIt Internal Error" no meu \ Users \ Documents \ Embarcadero \ Studio \ 20.0 \ CatalogRepository. Eu removi a pasta do Fast Report e seu conteúdo e ai consegui instalar.

Achei o problema. Mudei a impressora padrão do windows. Grato.

Tente LarguraBobina=250 e vá fazendo um ajuste fino, aumentando o valor...

Bom dia a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.10 que trata sobre novas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Criação/Alteração de regras de validação referentes a CST e Código de Benefício Fiscal, corrigindo algumas regras da versão anterior. • Criação de regra de validação correspondente rejeição 927, para informar os números dos itens em ordem sequencial. • Define que a regra de validação referente ao valor máximo da base de cálculo é por modelo de DF-e. Datas previstas para entrada em vigor: 22/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. Alterações na aplicação do desenvolvedor: Por conta da regra H02-10, a aplicação ao atribuir o numero do item ao campo: Prod.nItem, este tem que ser um numero sequencial, consecutivo e iniciado por 1. Para quem utiliza o ACBrMonitor, não precisa se preocupar, pois o mesmo utiliza um numero sequencial, consecutivo e iniciado por 1 para o numero do item. Novas Regras de Validação: Criada a Regra de Validação H02-10, com o objetivo de informar os números do item em ordem sequencial. Criadas regras de validação a Tributo - ICMS:  Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado código de benefício fiscal para CST sem benefício fiscal (campo cBenef) [nItem: nnn] Se informado CST e informado código de benefício fiscal: - Verificar se CST possui código de benefício fiscal, conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF e por modelo de DF-e. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e. Regras que tiveram seu (Campo-Seq) alterado bem como a sua redação: Regra N07-10 agora é N12-97. Rejeição 929: Informado CST de diferimento sem as informações de diferimento [nItem: nnn] Nova Redação: Não informados campos de valores do CST 51 (Diferimento): - modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSOp (id: N16a), pDif (id: N16b), vICMSDif (id: N16c), vICMS (id: N17). Observações: Implementação a critério da UF. Regra N12-84 agora é N12-85. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal (campo: cBenef) [nItem: nnn] Nova redação: Se informado CST e não informado código de benefício fiscal: - Verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF, por modelo de DF-e e por CST. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e Regra N12-88 agora é N12-94. Rejeição 931: Informado código de benefício fiscal (campo: cBenef) incompatível com CST e UF [nItem: nnn] Nova Redação: Se informado CST e informado código de benefício fiscal: - Verificar código de benefício fiscal está vigente e corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF. Observação1: Tabela de código de benefício fiscal (cBenef) publicada no Portal Nacional da NF-e. Nota: Para itens sem benefício fiscal, a UF poderá exigir a informação da literal “SEM CBENEF” para alguns CST, vide tabela publicada no Portal Nacional da NF-e.

16/07/2019 - ATENÇÃO: Publicada a versão 1.10 da NT 2019.001 Publicada a versão 1.10 da NT 2019.001, que divulga novas regras de validação e atualiza regras existentes da NF-e/NFC-e versão 4.0, com os seguintes objetivos: Criação/Alteração de regras de validação referentes a CST e a Código de Benefício Fiscal, corrigindo algumas regras da versão anterior. Criação de regra de validação correspondente à rejeição 927, para informar os números dos itens em ordem sequencial. Define que a regra de validação referente ao valor máximo da base de cálculo é por modelo de DF-e. Assinado por: Coordenação Técnica do ENCAT Link: http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=ScmzxWjpJe8=

Obrigado, Ítalo. Vou atualizar e posto o resultado. Muito obrigado, mais uma vez!

Tente informar o CPF explicitamente como terceiro parâmetro no comando de cancelamento: NFE.CancelarNFe("31190800046756078615559200000000011100000016","ERRO DE EMISSAO DE NFE ","46756078615")

Voltou a funcionar o obrigado, erro temporário.

Mudar a série permite reiniciar a numeração da nota fiscal. Se você usa a série 1 e atinge o número 999.999.999 pode alterar para série 2 e reiniciar a numeração do 1. Quando se é emitido nota fiscal por vários terminais simultaneamente, como no caso da NFCe em um supermercado, por exemplo, é recomendado usar séries distintas para cada emissor. Nunca tinha visto falar de "série virtual". Pesquisei e encontrei um ERP que usa esse conceito, com a mesma explicação dada pelo Felipe...

Bom dia, Antonio Ratero. A “Série virtual” da nota fiscal tem 2 ou 3 dígitos. Conforme a Secretaria da Fazenda a numeração da série virtual pode variar de 001 a 999. As séries de número 890 a 899 são de uso exclusivo para emissão de NF-e avulsa. As séries de número 900 a 999 de uso exclusivo de NF-e emitidas em contingência e autorizadas no Sistema de Contingência do Ambiente Nacional – SCAN.

Bom dia Este erro ( 15/08/2019 16:52:15 - Unable to open file "C:\sitex\NFCe\Entrada\ent.txt" ), ocorre quando o ACBrMonitor tentar ler o arquivo ent.txt e não consegue, provavelmente está preso pela sua aplicação. Para evitar esse problema, faça a sua aplicação gerar o arquivo de entrada com outro nome, e só após toda a escrita do método renomeie para "ent.txt". Dessa forma evita esse tipo de problema do ACBrMonitor não conseguir acessar o arquivo. O ACBrMonitor por sua vez, sempre exclui o arquivo ent.txt logo após a leitura do mesmo, então sua aplicação deve gerar um novo arquivo com outro método, apenas quando obter o retorno do método já enviado, isso evita de sua aplicação sobrepor um arquivo de entrada... Um outro detalhe que não tem haver com o erro mas pode alterar no seu processo, no método: NFe.EnviarNFe(c:\sitex\nfce\arquivos\Assinados\26190822038686000142650110000000341000000351-nfe.xml, 44,0,1,",1,0,1) O último parâmetro não precisa ser "1", isso fará o componente gerar e assinar e validar o XML novamente, O Parâmetro de Impressora, passe aspas duplas duas vezes (,"",) para abrir e encerrar o parâmetro, ou não passe nada deixe vazio: (,,)

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

Acho que é uma boa abrir um issue no git do fortes report

Todos os participantes desta edição do Dia do ACBr, ganharão um Kit de boas-vindas, contendo: 1 Agenda - Edição 2019-2020 1 Caneta - Novas cores disponíveis 1 Chaveiro - Abridor de garrafas, útil e robusto Feitos para você que usar ACBr! Gostou dos novos produtos personalizados do Projeto? Faça sua inscrição para garantir o seu Kit Boas-vindas! Lembrando que você poderá comprar mais produtos no Stand do Projeto ACBr durante o Evento! Se tem dúvidas ou gostaria mais informações, fale com nossa consultora rapidamente por meio do WhatsApp.

Olá Pessoal, Muitos tem interesse em obter o XML da transportadora (CT-e) para facilitar a entrada do Contas a Pagar, etc. Segundo a legislação, quem emite um CT-e tem por obrigação legal de disponibilizar o XML assinado e com o protocolo de autorização ao tomador do serviço, assim que a SEFAZ autorizar o conhecimento. Essa disponibilização pode ser feita por e-mail, ou seja, o emitente envia para o tomador o XML via e-mail. Sabemos que isso nem sempre ocorre, por 2 motivos: 1. No cadastro do tomador 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. O componente ACBrCTe possui os seguintes métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe: 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 do conhecimento é do Estado de São Paulo, logo o conhecimento é enviado para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional os conhecimentos que foram autorizados, o Ambiente Nacional por sua vez atribui um NSU para cada conhecimento que receber. 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: Conhecimento Completo e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um evento, o que teremos como retorno será o XML do evento e não o XML do conhecimento. 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 Conhecimentos Completas 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 novos conhecimentos forem emitidos e compartilhadas com o Ambiente Nacional. O DistribuicaoDFe não serve apenas para que possamos obter o XML da transportadora (CT-e), mas também descobrirmos se existe alguma empresa emitindo conhecimentos contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Prestação de Serviço em Desacordo. Para saber mais sobre o Distribuição DFe vide a Nota Técnica 2015/002 versão 1.00a, que se encontra disponível no Portal Nacional do CT-e e com relação ao evento Prestação de Serviços em Desacordo vide o Manual CT-e Visão Geral v3.00a que se encontra no Portal do Conhecimento de Transporte Eletrônico - SVRS. Informação importante, o serviço Distribuição DF-e, é atendido pelo Ambiente Nacional, portanto não tem nada haver com a SEFAZ-Autorizadora do emitente do conhecimento ou do tomador. Se algo falhar nesse processo, a "culpa" é do Ambiente Nacional.

Já conhecia o RDW de vídeos do Adriano e do Thulio mas nunca tinha utilizado em nenhum projeto. Hoje estou em pleno desenvolvimento de um projeto web com VueJS e RWD no backend. Além do desenvolvimento absurdamente rápido em função da linguagem object pascal, a performance do RDW na questão das requisições é absolutamente incrível. Você constrói um servidor resfull de alta performance em minutos. Os grupos são bem ativos e o suporte principalmente do Gilberto e do Alexandre é incansável seja qual for a hora. Eu mesmo já fui atendido de forma remota pelo Gilberto tarde da noite para a correção de um bug. Recomendo sem restrições.

Boa tarde @Juliomar Marchetti acabei deixando meio de lado essa situação por conta de outras pendências, mas eu resolvi o problema usando as Threads de outra maneira, referente a criação do servidor que você comentou eu sinceramente teria que estudar pois nunca trabalhei com isso mas vou dar uma estudada pra tentar melhorar essa consulta. Muito obrigado pelas dicas e tenha um ótimo dia. Abraços.

Não... não temos nada nesse sentido...

Deu certinho. Também agradeço!

Está disponível na pasta Branches, o Projeto ACBrBoleto com as classes novas para integração via WebService. Lembrando que está em fase de desenvolvimento e testes... Mas já pode ser utilizada para testes e implementação de novos bancos. Se alguém desejar realizar testes, basta substituir as Units e Packages do Projeto Principal e reinstalar o pacote. o Método a ser chamado na aplicação é: ( ACBrBoleto1.EnviarBoleto; ), da mesma forma como funciona o Boleto atualmente o Envio também trabalha com Títulos adicionados na Lista de Boletos.

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.

Boa Noite. Preciso de ajuda, no componente ACBrNFeDANFCeFortes, onde imprime o cupom fiscal, o sistema não está respeitando a impressora, somente imprime na impressora DEFAULT: //Define a Impressora ACBrNFeDANFCeFortes2.Impressora := 'hp LaserJet 3020 UPD PCL 5'; Antes de Imprimir seta a propriedade acima do componente porem só imprime na DEFAULT. Alguém tem alguma idéia do que possa está acontecendo? Verifiquei ainda que no próprio fonte do componente, sempre mostra a impressora DEFAULT, mesmo passando outro valor: if ACBrNFeDANFCeFortes.Impressora <> '' then RLPrinter.PrinterName := ACBrNFeDANFCeFortes.Impressora; Desde já Obrigado