Painel de líderes

Olá pessoal, Como muitos devem saber, os fontes do Projeto ACBr, são hospedados no SourceForge, um gigantesco portal que hospeda vários Projetos de Código aberto mundialmente... Ficamos muito contente em receber um comunicado do Source Forge, que nos confere as insígnias abaixo... Esta é uma grande conquista, pois nosso projeto se qualificou para esses prêmios entre mais de 500.000 projetos de código aberto, existentes no SourceForge. O SourceForge recebe cerca de 30 milhões de usuários por mês procurando e desenvolvendo software de código aberto. Community Leader Community Choice Open Source Excellence SourceForge Favorite

Veja abaixo notícia do Portal da NFe: Suspensão dos serviços "ConsNSU" e "ConsChNFe" da NT 2014.002 Devido ao excesso de utilização indevida do WebService de Distribuição de DF-e de Interesse dos Atores da NF-e (NFeDistribuicaoDFe), serão temporariamente suspensos os pedidos "ConsNSU - Consulta DF-e Vinculado ao NSU informado" (item "b" da seção 3.4.1 da NT 2014.002 versão 1.11) e "ConsChNFe – Consulta de NF-e por chave de Acesso Informada" (item "c" da seção 3.4.1 da NT 2014.002 versão 1.11). O pedido "distNSU – Distribuição de Conjunto de DF-e a partir do NSU informado" (item "a" da seção 3.4.1 da NT 2014.002 versão 1.11) continuará funcionando normalmente. Os pedidos suspensos serão reestabelecidos assim que regras de uso indevido forem implementadas, garantindo o funcionamento para todos os usuários. Assinado por: Receita Federal do Brasil Fonte: http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=A6qvFRVbPSA= Observação: O componente ACBrNFe possui 3 métodos referente ao DistribuicaoDFe: DistribuicaoDFePorUltNSU - este continuará funcionando conforme noticia acima, pois ele se refere ao item "a" da seção 3.4.1 da NT 2014.002 versão 1.11 DistribuicaoDFePorNSU - este não vai funcionar conforme noticia acima, pois se refere ao item "b". DistribuicaoDFePorChaveNFe - este também não vai funcionar conforme noticia acima, pois se refere ao item "c". Relembrando: O método DistribuicaoDFePorUltNSU faz a pesquisa com base no ultimo NSU informado, devemos sempre usar como ultimo NSU o valor do campo ultNSU retornado na execução anterior do método. O método DistribuicaoDFePorNSU faz a pesquisa com base no NSU informado, devemos usar esse método somente quando detectarmos que um documento esta faltando. O método DistribuicaoDFePorChaveNFe faz a pesquisa com base na chave da nota informado, devemos usar esse método somente quando detectarmos que o documento referente a essa chave esta faltando. O DistribuicaoDFePorUltNSU retorna um lote de até 50 documentos já os outros 2 retorna somente um documento, logo não devemos utiliza-lo dentro de um loop.

implementation { ACBrBALMarte } Uses SysUtils, Math, StrUtils,DateUtils, ACBrConsts {$IFDEF MSWINDOWS} , Windows ; {$ENDIF}; //<======ajuste da diretiva constructor TACBrBALWeighTRUTest.Create(AOwner: TComponent); begin inherited Create(AOwner); fpModeloStr := 'Weigh TRU-Test'; end; Atualizei hoje e ao compilar no Linux reclamou, vlw!

Segue em anexo as alterações contemplando a implementação dos seguintes recursos da API de cobrança BB: Cancelar Pix de Boleto Gerar Pix de Boletos Consultar Pix de Boletos Link da Documentação https://editor.swagger.io/ ACBrBoleto.rar

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

Boa tarde João, Vários provedores exigem um cadastro para emitir notas via Site e um segundo cadastro para emitir via WebService. Foi exatamente isso que ocorreu com o seu cliente, esta faltando realizar esse segundo cadastro.

Boa tarde Edmar, Faça uma copia da unit alterada e atualize novamente os fontes, pois o LerDatas foi totalmente reformulado.

Boa Tarde, Voce informou a CSOSN 102 no item, logo ela não destaca icms, então o total vai diferir dos itens. Confirma com a contabilidade sempre a informação correta, e utiliza alguma csosn que tenha as tags de icms

Bom dia, Problema resolvido, mas temos outro Erro(s): Código : E282 Mensagem: Responsável/Retentor informado indevido. Correção: O campo Responsável/Retentor somente deverá ser preenchido quando o ISSQN for retido na fonte. Seguindo sua informação anterior estou abrindo um novo tópico

@EMBarbosa, pode por favor analisar ? muito obrigado pela contribuição @coyote sistema

Olá @jamil, Você consegue ler a Data de Validade do Certificado com o método abaixo: https://acbr.sourceforge.io/ACBrLib/NFE_ObterCertificados.html A penúltima coluna, é a Data de Validade do Certificado... Isso é o que você tinha em mente ?

Bom dia Juliomar e Francesco, examinei a string que esta no onActive mas não acreditei que fosse o problema, depois que o Juliomar falou comentei tudo e inseri um showmessage, cada vez que mando imprimir usando preview o onActive é acionado, então migrei a string para um timer para testar e funcionou, não da mais AV. Muito obrigado Juliomar e Francesco e todos que colaboraram.

Bom dia, achei essa resposta no site contábil, não sei se seria útil. (grupo prod - ID I01), com: CFOP 5949 - Outra saída de mercadoria ou prestação de serviço não especificado; CST 40 – Isenta da tributação do ICMS (campo CST - ID N03); NCM 99; Segue abaixo, fonte da pesquisa https://www.contabeis.com.br/forum/tributos-estaduais-municipais/255233/ncm-para-gorjeta/

Olá, fiz a atualização, e só teve um detalhe, removi o inherited, pois observei que nas demais units, dos outros modelos, não tinha , então resolvi tirar tbm da unit ACBrBALWeighTRUTest. resolvi tirar pois após atualizar, em alguns testes não estava entrando nessa procedure de solicitar peso, após remover o inherited isso parou de ocorrer e esta funcionano 100%. Obrigado na procedure SolicitarPeso; begin //inherited; fpDevice.Limpar; fpDevice.EnviaString('{RW}'); end;

Bom dia Juliomar, Atualizado e validado. Fechando. Obrigado

At revision: 24761

Resolvido, muito obrigado

erro de autenticação de usuário e senha

Bom dia, Atualizei o componente e para passar o evento 2220 no s-10 tive que fazer esta alteração, colocar a ordexeme como <>, poois estava > e o orNaoInformado, o mesmo para o indResult. Aproveitei e coloquei procRealizado = '0281' , pois no manual esta obrigatório apenas para este procedimento. Isso procede ou não. Obrigado a todos.. pcesS2220.pas

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 24756. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Oi @Daniel Simoes, obrigado pela resposta! Bom, agora já sei que a impressora é capaz de fazer isso. Comecei agora a trabalhar com automação comercial e só descobri sobre o ACBr ontem. Excelente projeto, tenho certeza que vai me ajudar bastante. Mas enquanto eu não migro os sistemas pro ACBr, saberia me dizer o código ESC/POS que esta tag envia para a impressora? Procurei nesse código aqui e não achei nada.. http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/Java/PosPrinter/Imports/ACBrLibPosPrinter/src/com/acbr/posprinter/ACBrPosPrinter.java Obrigado!!

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 24753. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa noite Valdir, Correto, após a manifestação, ao executar novamente o DistribuicaoDFePorUltNSU, serão recebidos os xmls a partir do momento que a Sefaz disponibilizá-los, pois isso não é imediato.

Olá boa noite, com base nas informações do manual e na estrutura já utilizada no componentes, criei um novo modelo no componente ACBrBAL , balWeighTRUTest, para comunicar com as balanças da TRU-Test, testei em dois modelos de balança EziWeigh 7 e S3 Weigh, ambas utilizando conexão USB com porta COM Virtual. configurações utilizadas, trecho do log. "Modelo: Weigh TRU-Test - Porta: COM5 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0" Já utilizo o componente ao bom tempo com balanças comerciais, agora estou começando com essas balanças bovinas, por isso surgiu a necessidade de integrar ao Acbr para continua-lo utilizando. Arquivos em anexo para verificar possibilidade de inclusão no repositório do acbr. ACBrBALWeighTRUTest.pas ACBrBAL.pas EziWeigh 6_7 weigh scale indicator SDK V0_6.pdf

EDIT: As alterações abaixo já se encontram no SVN desde o dia 23/02/2022. Olá Pessoal, Como sempre queremos facilitar pra vocês ao máximo o uso de nossos componentes e a manutenção de seu código. Sendo assim, achamos apropriado fazer algumas alterações no componente ACBrNFSeX. O componente antigo, ACBrNFSe, não será alterado visto que não estamos fazendo melhorias nele, apenas manutenção de erros e falhas. Para saber mais sobre como migrar do ACBrNFSe para o ACBrNFSeX, veja esse link. Vamos detalhar abaixo as mudanças e as motivações. Anteriormente, no componente tínhamos as seguintes propriedades: XML, XMLOriginal, XMLAssinado e XMLNFSe. Essas propriedades foram criadas seguindo o modelo do componente antigo e podiam ser lidas através da lista de notas, como por exemplo no código: Elas tinham a seguinte função no componente antigo: XML: o XML da NFS-e retornado pelo WebService; XMLNFSe: o XML da NFS-e retornado pelo WebService; XMLOriginal: o XML do RPS sem assinatura; XMLAssinado: o XML do RPS (que pode estar assinado ou não dependendo do provedor); Agora pense um pouco sobre o que viu. Temos duas propriedades que contem o XML da NFS-e e duas que contem o XML do RPS. Não temos necessidade dessa redundância, principalmente porque o componente novo, ACBRNFSeX, está muito mais funcional na questão de separação de comportamento dos provedores. Sendo assim, as propriedades XMLAssinado e XMLNFSe acabaram ficando sem utilidade. Estávamos na situação de que ao tentar ler as mesmas é retornado uma string vazia. Já na propriedade XMLOriginal era retornado o XML do Rps (assinado ou não conforme o provedor). Por firm, na propriedade XML era retornado o XML da NFS-e. Estamos fazendo as seguintes alterações no ACBrNFSeX: As propriedades XMLAssinado e XMLNFSe foram removidas. Elas não continham nenhuma informação. A propriedade XML foi renomeada para XmlNfse, deixando mais claro o objetivo. A propriedade XMLOriginal foi renomeada para XmlRps, dando mais clareza ao que ela contêm. Assim ao invés de 4 propriedades com nomes talvez confusos e dados redundantes, agora temos 2 funcionais. Para aqueles que desejam guardar o XML do Rps e ou da NFS-e no banco de dados basta ler as propriedades mencionadas acima podem usar um código semelhante ao abaixo XMLReciboRPS := ACBrNFSeX1.NotasFiscais.Items[ i ].XmlRps; XMLNotaServico := ACBrNFSeX1.NotasFiscais.Items[ i ].XmlNfse; Onde "i" é o índice da nota na lista, que pode variar de zero até a quantidade de documentos menos 1. Observações: Se o valor da propriedade de configuração: Configuracoes.Arquivos.Salvar for True os valores de XmlRps e XmlNfse serão salvos em disco; O conteúdo de XmlRps será salvo na pasta Recibos e o de XmlNfse na pasta Notas;

Bom dia https://www.nfe.fazenda.gov.br/portal/consultaRecaptcha.aspx?tipoConsulta=resumo&tipoConteudo=7PhJ+gAVw2g=&nfe={chaveAcesso}

Para GMail encontrei uma solução melhor "Senhas de app": https://support.google.com/accounts/answer/185833?hl=pt-BR&authuser=1#zippy=%2Csenhas-de-app-revogadas-após-a-mudança-da-senha Basta solicitar uma senha para aplicações que não são compatíveis com o OAUTH2, e assim uma senha de 16 dígitos será disponibilizada, sendo possível revogar a qualquer momento, a mesma pode ser usada no ACBrMail, não será necessário desativar o acesso de 2 passos ou ativar esse recurso de acesso a aplicações menos seguras do Gmail.

Acabei de autenticar agora aqui.. O processo é bem documentado aqui: https://developers.mercadolivre.com.br/pt_br/autenticacao-e-autorizacao#Enviar-access-token-no-header Alguns passos pra resumir Gerar o teu app lá dentro do ML com a opção offline_write! Requisitar um REFRESH TOKEN , passando o APPID e APPSECRET e URLREDIRECT Com esse REFRESH TOKEN gerar um ACCESS TOKEN, válido por 6 meses COm o ACCESS TOKEN é só partir pro abraço O certo seria fazer um componente TAuthMeli pra facilitar tudo, estou pensando em fazer essa! Forte abraço a todos Ambiente testado: Rad Studio 10.3.3 com componentes REST

Bom dia a todos. Colocando a Emissão de NFS-e em produção em alguns clientes em Ribeirão Preto - SP com o provedor GINFES, sobre essa questão do Reg.Especial de Tributação, cheguei a conclusão: - de fato para "Optante pelo Simples" é OBRIGATÓRIO o preenchimento da TAG de informação do Regime especial de Tributação; - no caso do GINFES não é aceito o valor 0 (zero - Nenhum), o schema não valida o RPS de envio; portanto temos de selecionar um tipo de Trib.Especial no Simples - isso pode ser orientado pelo contador do Cliente, qual tipo selecionar. - entretanto (o que é estranho e só poderia ser respondido pelo provedor GINFES), o XML de retorno do provedor (NFS-e autorizada e retornada pelo GINFES) vem com a TAG editada com o valor 0 (zero - Nenhum), imprimindo no DANFSe o Reg.Especial de Tributação como "Nenhum". Portanto, sempre que for optante pelo Simples no GINFES (ao menos aqui em Ribeirão), tem que selecionar o Reg. Especial de Tributação, mesmo que depois ele retorne como "Nenhum" no xml da NFSe autorizada no provedor. Abraço a todos.