Painel de líderes

Em anexo. ACBrTEFComum.pas ACBrTEFPayGoComum.pas

Olá pessoal, Quero comunicar o nascimento do mais novo membro da família ACBr. Estou falando do ACBrGTIN. Esse componente tem como objetivo realizar uma consulta na SEFAZ, onde é informado somente o GTIN do produto a ser consultado (também conhecido como código EAN) e temos como resposta informações cadastradas pelo "Dono da Marca" na GS1. Essas informações podem ser: o tipo do GTIN (que pode ser 8, 12, 13 ou 14) a descrição do produto o código NCM código do CEST. Infelizmente nem sempre teremos um retorno completo. Isso porque nem todas as empresas "Dono da Marca" cadastram os seus produtos na GS1 e muitas que cadastraram não autorizaram a divulgação dos dados. Neste caso podemos ter as seguintes rejeições: 9494: GTIN inexistente no Cadastro Centralizado de GTIN (CCG); 9495: GTIN existe no CCG com situação inválida. Solicitar ao dono da marca que entre em contato com a GS1; 9496: GTIN existe no CCG, mas dono da marca não autorizou a publicação das informações. Entrar em contato com o dono da marca; 9497: GTIN existe no CCG com NCM não cadastrado; 9498: GTIN existe no CCG com NCM inválido; Dica de uso do componente: Utilize ele ao cadastrar novo ou atualizar um produto na sua aplicação. Nunca, jamais mesmo, use o componente no momento da venda. Consta na NT 2022/001 versão 1.00 referente ao WS de Consulta do GTIN (página 6) a seguinte informação: Serão mantidos controles para identificar as situações de “uso indevido”, no consumo excessivo do Web Service em um curto espaço de tempo. As novas tentativas poderão ser rejeitadas com o erro “656–Rejeição: Consumo Indevido” Informação Importante: A Equipe ACBr esta trabalhando para disponibilizar o programa exemplo, bem como o pacote para o Lazarus e uma nova versão do ACBrInstall que permite a instalação no Delphi do novo componente: ACBrGTIN.

Será que conseguimos por esse mesmo recurso para o Clisitef? Achei algo relacionado nesse tópico: Segue unit em anexo com implementação do Tipo Voucher no Clisitef ACBrTEFCliSiTefComum.pas

Bom dia Realizamos a migração para o componente ACBrNFSeX e identificamos alguns ajustes que precisamos fazer nos fontes para os provedores IPM e Fiorilli, os quais compartilho em anexo com a comunidade. Provedor IPM: - no arquivo ACBrNFSeXServicos.ini foram comentadas as linhas de versão e as URLs de produção e homologação para a cidade de Santa Rosa - RS. Santa Rosa está usando ainda as URLs no padrão que era usado no componente antigo, configuração igual a do município de Horizontina - RS. - no arquivo IPM.LerXml.pas * método LerRps, foi ajustado para ler o campo DataEmissaoRps * método LerTomador, foi ajustado para ler o tipo da pessoa (Física, Jurídica do Município ou Jurídica fora do Município) Temos clientes de ambas as cidades emitindo nota desde abril com estes ajustes. Provedor Fiorilli (cliente é de Marau - RS): - arquivo Fiorilli.Provider.pas, no método Configuracao foi necessário informar o Namespace URI para o XML Arquivos modificados em anexo. ACBrNFSeXServicos.ini IPM.LerXml.pas Fiorilli.Provider.pas

Atualizei os fontes. Na parte de compilação parece tudo certo. Só não tenho como testar completo, pois na homologação não aceita. Mas estou passando a atualização para o cliente fazer o teste assim que possível. Obrigado!

Sim. É isso que eu estou achando mais estranho, esse número de decimais maluco. Parece que fizeram a atualização do campo lá sem usar uma função de arredondamento. Já entrei em contato e estou aguardando um retorno deles. Se tiver alguma novidade eu posto aqui. Obrigado pela atenção.

muito obrigado pela atenção, depois de muito insistir com ela aqui achei o problema. o modulo ZPL não estava tiva nela. consegui ativar e resolveu.

Boa tarde Maico, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2825

algo de dns, atualização do windows e etc

Juiomar, Tenho um RLPreviewSetup1, num DM relatório e as chamadas para o Preview e: var PREV: TRLPreviewSetup; e PREV:=TRLPreviewSetup.Create(Self); PREV.EnabledButtons:=[pbPrint]; PREV.ShowModal:=True; Isto é feito em alguns forms, que são criados a medida que são acionados. Como faço para atender a sua solicitação: 'consegue mostrar isso com um exemplo lá do git e se possível abra um issue lá no fortes report ce no github' ??? Obrigado. Prezados, Renato e Juliomar. Obrigado pelas dicas. Fiz o que o Renato sugeriu, funcionou corretamente. Prezados Juliomar e Renato. Acho que digitei no lugar errado... Obrigado pelas dicas, fiz o que o Renato sugeriu e funcionou perfeitamente. Abraço.

Bom dia, esse erro indica que não encontrou a ACBrLib, junto do executável. Dê uma olhada nessa passo a passo para configurar a lib usando as classes de exemplo

Bom dia Italo, desculpe a demora, fiquei doente esses dias. Retornando hj. O pessoal da COPLAN ja confirmou q os links foram modificados mesmo

Boa noite. Fizemos o debug do código, conforme o @EMBarbosa indicou e deu certo. Obrigado.

Boa noite, Verifique com a prefeitura e/ou provedor o motivo do item 11.04 estar sendo rejeitado e, se for o caso, confirme com eles qual deveria ser o código a ser utilizado para o simples nacional.

Pelo ACBrETq só é possível definir a altura do código de barras. A largura é definida automaticamente conforme o tipo do código utilizado. Vi na sua imagem que seu código está no formato EAN13 (possui o dígito verificador)... O aplicativo do fabricante está utilizando esse padrão para fazer a impressão, por isso o código de barras fica sempre com o tamanho uniforme. Envie o ImprimirBarras() utilizando o 'barEAN13' com seu código '3358300000006' e verá que sairá exatamente como está na foto. (Obs: Sobre códigos de 30 caracteres alfanuméricos... arrisco a dizer que seria impossível imprimir em uma etiqueta desse tamanho)

Será que o tipo do código é o apropriado? O Code39 é de tamanho variável. O que significa que quanto mais caracteres você colocar, mais largo vai ser o código de barras. Essa parte eu não entendi... está usando a mesma configuração, com o mesmo código sendo impresso? Nos parâmetros do método ImprimirBarras não tem a informação que você quer? Veja a documentação: https://acbr.sourceforge.io/ACBrLib/ETQ_ImprimirBarras.html

No segundo parâmetro coloquei uma variável string e deu certo. Não entendi pq, sendo que antes era um Edit.Text, mas resolveu.

Olá pessoal, O componente ACBrPagFor passou por um Refactoring. A motivação para esse Refactoring é tornar o componente mais fácil e prático no que se refere a implementar novos bancos bem como realizar manutenção no código sem correr o risco de gerar um efeito colateral nos bancos já implementados. Antes tínhamos apenas uma unit responsável por gerar o arquivo txt de remessa para todos os bancos. Isso gerava riscos na implementação e manutenção dos bancos existentes. Agora temos uma unit que gera o arquivo segundo o layout estabelecido pela Febraban e units separadas para cada banco. Assim, podemos alterar a procedure do registro ou do segmento que não segue a risca o layout da Febraban de um banco específico sem afetar outros. Desta forma dezenas de IF e CASE utilizados para identificar o banco em questão e gerar o txt corretamente, agora não existem mais. Desta forma temos um código muito mais limpo de ser lido e compreendido. Além disso foram removidas as propriedades de configuração: CNPJ e VersaoLayout que se encontravam em Configuracoes.Geral, pois estavam sem nenhuma utilidade. Agora no lugar delas temos as propriedades de configuração: Empresa e UsarDadosConfig. Novas Propriedades de Configuração: Propriedade Tipo Valor Padrão Descrição Empresa Grupo Dados da Empresa TipoInscricao TTipoInscricao tiIsento Determina o tipo de Inscrição da Empresa que pode ser: tiIsento, tiCPF, tiCNPJ, tiPISPASEP ou tiOutros. NumeroInscricao string Numero da Inscrição da Empresa conforme o tipo. Convenio string Numero do Convenio da Empresa estabelecido com o Banco. Nome string Razão Social da Empresa. Conta Grupo Dados da Conta AgenciaCodigo Integer 0 Numero da Agencia que a Empresa tem Conta. AgenciaDV string Digito Verificador da Agencia. ContaNumero Int64 0 Numero da Conta. ContaDV string Digito Verificado da Conta DV string Digito Verificado geral utilizado por alguns bancos. TipoConta Integer 0 Tipo de Conta, utilizado por alguns bancos. Endereco Grupo Dados do Endereço Logradouro string Nome do Logradouro do Endereço da Empresa. Numero string Numero ou código do Logradouro (veja a "obs." abaixo) Complemento string Complemento do Endereço. Cidade string Nome da Cidade. CEP Integer CEP do Endereço da Empresa. Estado string Sigla do Estado. UsarDadosConfig Boolean False Se True o componente vai utilizar as informações de configuração para serem utilizadas ao gerar o arquivo de remessa, caso contrario o desenvolvedor terá que alimentar diretamente os campos do componente. Observação: o tipo do campo Numero do logradouro do Endereço foi alterado de Integer para string pois a cidade de Bauru utiliza o formato xx-yy onde xx se refere ao numero da quadra em que a rua se encontra e o yy o numero do imóvel. Pasta dos fontes: Outro ponto importante é a localização das Units que compõe o componente: Pasta Descrição ACBrPagFor Pasta raiz dos fontes do componente. Bancos Pasta que contem as units dos bancos: (PagFor.NomeBanco.GravarTxtRemessa, PagFor.NomeBanco.LerTxtRetorno, PagFor.NomeBanco.Provider). Base Pasta que contem as units de classes, conversão e parâmetros. Provider Pasta que contem as units bases de geração e leitura do arquivo txt bem como a interface com as units de cada banco. Modelos Pasta que contem as units que podemos utilizada como modelo para quando for implementar um novo banco: (PagFor.Modelo.GravarTxtRemessa, PagFor.Modelo.LerTxtRetorno, PagFor.Modelo.Provider). Situação atual: Hoje o componente já conta com os seguintes bancos implementados: BancoCECRED, Banco do Brasil, Bradesco, HSBC, Itaú, Safra, Santander e Sicredi. Desafios a frente: Implementar e testar novos bancos melhorar a leitura do arquivo de retorno e extrair as ocorrências para que sejam apresentadas de forma clara e objetiva para que o desenvolvedor possa realizar os ajustes necessários Para que isso ocorra, contamos com a colaboração de todos.

Opa! Não entendi muito bem sua pergunta. Mas vamos lá... Caso queira baixar notas fiscais emitidas CONTRA o CNPJ do seu cliente. Deve-se utilizar o método de DistribuicaoDFe. (Aqui uma explicação, e aqui um exemplo prático) Observação 1: você consegue baixar um resumo das notas fiscais para que seja possível você realizar o manifesto. Após o evento de manifestação o Ambiente Nacional disponibiliza o XML da nota em questão. Observação 2: O Ambiente Nacional disponibiliza o resumo/DFe apenas se o seu cliente for o Destinatário, Transportadora ou o CNPJ estiver na tag <AutXML>. Caso queira RECUPERAR um ou mais XML EMITIDO pelo seu cliente. Deve-se alimentar o componente com os dados da venda/nota, assinar e consultar. (Aqui um exemplo prático) Observação 1: Não é muito indicado ficar fazendo isso. Já que na lei diz que o contribuinte é obrigado guardar o XML do documento fiscal. Observação 2: Caso você tenha o XML assinado, você pode carregar o XML e executar o método Consultar apenas... Dessa forma o XML será atualizado com o protocolo. Observação 3: O único método oficial pela SEFAZ é realizar o download do documento fiscal diretamente pelo portal, utilizando o certificado digital. Sites como Arquivei lite fornece um XML válido porém sem validade jurídica já que a assinatura não é a do emitente.

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.