Painel de líderes

Boa tarde, observando os componentes disponivel no ACBr verifiquei que não existe um especifico para sinaleiras de Self-Checkout\Terminais autônomos (Elgin, Index, Laurenti e Schalter), então desenvolvi um para esse finalidade ACBrSin. Inicialmente homologado com as Sinaleiras da Laurenti mas possívelmente nos proximo mês vou receber o modelo da "Elgin" e "Index" para homologação. Adicionei ele no pacote ACBrSerial, também herdando do ACBrDevice Segue as classes e icone do componente. Geralmente essas sinaleiras trabalham com as seguintes cores Amarelo = Self-Checkout ocupado Verde = Self-Checkout disponível Vermelho = Self-Checkout com erro ou aguardando um fiscal de pdv Segue link de video que nosso suporte gravou no cliente. @Juliana Tamizou ACBrSin.zip

Boa tarde @C4Dev, No meu teste também tive essa mesma mensagem de retorno. Eu acredito que a Receita não incluiu ainda as cidades, dai o erro. Faço parte de um grupo de Whatsapp onde tem pessoal da Receita Federal, Serpro, desenvolvedores, etc, questionei também sobre esse erro. Estou aguardando um retorno deles.

No discord, canal #pro-diversos tive uma conversar com os consultores da ACBR. O que esta acontecendo é que a nova versão esta sendo recepcionada por uma API Rest, até a 1.05.01 é recepcionada por um WebService Soap. A Equipe ACBr já esta trabalhando para anteder essa mudança. Devemos esperar pessoal atualiza o componente.

Bom dia, Esse ticket é para acompanhar o ticket interno #TK-3485. Se possível, gostaria de receber retorno sobre a tarefa. Saudações, Rafael Glauber

Bom dia Italo, Eles responderam o chamado, informando que o correto é como o componente ja mandava anterior 0.0200, recebi hoje um email. Vou retirar a alteração e fazer um novo teste, caso dê certo encerramos esse post e retiro a linha que coloquei colocando a precisão de para 2 em vez de 4. Assim que fizer um teste e autorizar eu te aviso. Obrigado.

Esse tópico tem como objetivo orientar o processo de verificação de chaves e integridade do Pinpad. O resultado do teste pode ajudar a solucionar erros relacionados à ausência de chaves de determinada adquirente. Será necessário utilizar a aplicação PPCOMP. 'Por motivos de segurança, esse aplicativo é distribuído pelos consultores do ACBr para as empresas que tem acordo de Distribuição TEF conosco. Para saber mais sobre TEF com o Projeto ACBr, acesse: https://projetoacbr.com.br/tef/ Para obter suporte técnico de nossos consultores, acesso o nosso Discord: https://discord.gg/acbr Após obter o Zip com o arquivo, descompacte para a área de trabalho e execute a aplicação. Certifique-se que o pinpad está conectado em uma porta USB (importante não utilizar HUB e que os drivers oficiais do fabricante estão instalados na máquina. 1 - Selecione a opção "1 - Busca automática pela porta" ou insira o número da porta COM relacionada ao pinpad na opção "2". Serão retornados alguns dados preliminares sobre o hardware: 2 - Selecione a opção "1 - teste completo" 3 - Será retornada uma tabela com as chaves presentes no pinpad: 4 - Caso seja necessário testar a integridade do pinpad, o teste prosseguirá solicitando algumas interações do usuário com o pinpad como apertar alguma tecla, aproximar, inserir ou passar um cartão qualquer para validar os mecanismos de captura, etc: Se o objetivo for apenas verificar as chaves do pinpad, o teste pode ser abortado no "PASSO 3". 5 - Será gerado um relatório com nome "PGTestPINpad_XXXXX_XXXX" onde constará os logs com os resultados dos testes:

Olá, é preciso ajustar no ACBrNFSeXServicos os dados referente a prefeitura de Guatambu - SC. Atualmente está informando como pronim, porém o provedor é Publica. [4206652] Nome=Guatambu UF=SC Provedor=Publica ProRecepcionar=http://nfse1.publica.inf.br/guatambu_nfse_integracao/Services HomRecepcionar=http://nfse-teste.publica.inf.br/homologa_nfse_integracao/Services ACBrNFSeXServicos.ini

complementando, Veja se driver da leitora está atualizado. Tente reinstalar. Troque a porta que está conectado.

Boa tarde Júlio, O que você pode conferir comparando o que funciona com o que não funciona: A configuração do componente é exatamente a mesma? O fornecedor do certifico é o mesmo? A versão do Windows é a mesma, se sim esta com as mesmas atualizações?

Boa tarde Carlos, Infelizmente não temos.

Blz, obrigado Diego!

Boa tarde! De acordo com a NT2015/002v1.01 o serviço de DistribuicaoDFe para o CT-e distribui os seguintes documentos De acordo com o programa exemplo para o CT-e, você pode tratar o ler o retorno da seguinte maneira. ACBrCTe.DistribuicaoDFePorUltNSU(UFAutor, CNPJ, ultNSU); with ACBrCTe.WebServices.DistribuicaoDFe.retDistDFeInt do begin //... for i:= 0 to docZip.Count-1 do begin case docZip[I].schema of schresCTe://Resumo DFe schprocCTe://CTe completa schprocCTeOS://CTeOS Completa schprocGTVe://GTVe Completa schprocEvento://Resumo Evento schprocEventoCTe://Evento Completo end; end; uma das propertys da classe docZip é a docZip.XML. Você pode conferir nessa property se o XML de evento que recebeu é o de cancelamento do CT-e que precisa. Para o ACBrMonitorPLUS, as respostas vem separadas, conforme demonstrado no exemplo do comando CTe.DistribuicaoDFe. Algumas das propriedades que vem na resposta podem ser usadas para identificar e vincular CT-e<=> Evento Cancelamento.

opa, perfeito! Obrigado @Diego Foliene! Vou realizar a alteração a retorno se resolveu meu caso, para manter documentado!

O componente ACBrNFSe foi descontinuado e não sofre mais manutenções/alterações. Sugiro que migre para o ACBrNFSeX(nele o provedor para esta cidade está como IPM)

Bom dia, existe algumas peculiaridades, é possivel, mais o Danfe é necessário ser emitido em papel moeda em seu formulário, você precisa fazer o processo, alguns estados não permitem esse tipo de operação FS-IA ou FS-DA. FS-DA

Faltou o demo SinaleiraTeste.zip

Bom dia Faberson, No XML da NFS-e qual é o valor que consta na tag <BaseCalculo> ?

Olá bom dia, estou testando a nova versão dos fontes do ACBR mas pelo que analisei, mesmo tudo para os eventos do grupo 40 como o 4010, 4020 já estarem desenvolvidos, toda a forma de comunicação ainda é via SOAP, mas a documentação da nova versão do Reinf informa que a nova versão 2.1.1 é via REST. Veja o exemplo e explicação abaixo. Pela analise do código do ACBR Reinf somente é usado o modelo de envio via SOAP, acredito que o envio via REST ainda precise ser desenvolvido. Ambiente para leiaute versão 2.1.1 Foi disponibilizado em 28/11/2022 um novo ambiente e um novo banco de dados para recepção dos eventos da versão 2.1.1 de forma assíncrona. Os endereços para transmissão não foram alterados, permanecendo os mesmos que estão no manual do desenvolvedor. Os dados (lotes e eventos versão 2.1.1) transmitidos de forma assíncrona foram excluídos. Todos os lotes/eventos devem ser enviados novamente para este ambiente, incluindo os eventos de tabela. Ambiente para leiaute versão 1.5.1 A recepção da versão 1.5.1 dos eventos de tabela e da série R-2000 continuará disponível no ambiente de produção restrita, por transmissão síncrona até data ainda a ser definida. Esse ambiente não sofreu alterações no endereço e os dados foram mantidos. Importante: O banco de dados do ambiente da versão 2.1.1 não se comunica com o banco de dados da versão 1.5.1. Os dois ambientes da produção restrita funcionam de forma isolada.

Bom dia Italo, Após atualizar , realizamos um novo teste e deu certo. Retornou a impressão da NfSe. Muito obrigada pelo retorno!

Bom dia, Também entendo que seria melhor incluir a regra de negócio sobre a data do último dia trabalhado na aplicação e não no componente. No momento do cadastro da CAT no sistema, poderia validar se a data do último dia trabalhado é menor ou igual a data do acidente e maior que a admissão, e se a data do acidente é menor ou igual a data atual e maior que a admissão. Entendo que essa é uma regra da CAT, não do eSocial. Já em relação ao corte temporal da obrigatoriedade do envio (16/01/2022 para Ambiente de Teste e 16/01/2023 para Ambiente de Produção), é uma regra do eSocial, portanto, a meu ver, deveria ser tratado no componente. Entendo que a forma implementada pelo Anderson seria a mais acertada. At.te,

trás a sugestão para que possamos validar no código

bom dia realmente o problema era a versão do Lazarus, atualizei tudo seguindo o passo a passo do Daniel do InfoCotidianos: “https://www.youtube.com/watch?v=aiytLfagvXU” e deu tudo certo Obrigado

Bom dia @C4Dev, Favor entrar em contato com a prefeitura/provedor e solicitar as URLs de homologação e produção bem como o manual, pois esse que você anexou se refere a cidade de Florianópolis.

Se entendi bem, basta fazer: select coalesce(NUM_PREP, NUM_PEDIDO) as NUM_PEDIDO from PEDIDO Vai exibir NUM_PREP, mas se ele for NULL, vai exibir NUM_PEDIDO.

após o governo não mais dar suporte e foi para o sebrae eles não atualizaram o manual e portanto nós também não damos mais suporte. utilize o modelo ini do ACBr para enviar

faz para o cliente e embute na mensalidade

Boa tarde ítalo. Vou fazer aqui e depois retorno.

Boa tarde, Foram desenvolvidos os leiautes dos novos registros relacionados à versão 2.1, mas ainda não haviam disponibilizado o ambiente de testes. Para a nova versão foi alterada o forma de transmissão dos eventos, utilizando agora o modo assíncrono via REST, ao invés de webservices como era até então, conforme manual disponível neste link. O modo de envio assíncrono, necessário para envio na versão 2.1, ainda está na fila de implementações. Assim que for disponibilizado no componente atualizaremos este tópico.

Boa tarde, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde a todos. Concordo com a colocação do nosso amigo: @Jeihcio Francis não temos a data de admissão do trabalhador. Como sugestão que implementamos foi sem a validação para que o mesmo possa ser validado na aplicação. if ( ( (TpAmbToStr(TACBreSocial(FACBreSocial).Configuracoes.WebServices.Ambiente) = '1') and (Self.Cat.dtAcid >= StringToDateTime('16/01/2023')) ) or ( (TpAmbToStr(TACBreSocial(FACBreSocial).Configuracoes.WebServices.Ambiente) = '2') and (Self.Cat.dtAcid >= StringToDateTime('16/01/2022')) ) ) then begin Gerador.wCampo(tcDat, '', 'ultDiaTrab', 10, 10, 1, Self.Cat.ultDiaTrab); Gerador.wCampo(tcStr, '', 'houveAfast', 1, 1, 1, eSSimNaoToStr(Self.Cat.houveAfast)); end; Outra sugestão seria atualizada com a validação abaixo: if Self.Cat.ultDiaTrab <= Self.Cat.dtAcid then Outra sugestão que estamos disponibilizando aqui é a do Evento S-3000 foram implementados alguns ajustes na função GerarXML. Obrigado pela atenção. pcesS2210.pas pcesS3000.pas

@Victor H. Gonzales - Panda Te enviei o meu certificado por email, conforme me pediu!

Você já teve dúvida no momento de verificar se a cobrança PIX gerada pela sua aplicação foi realmente paga? Pois é, essa dúvida é mais comum do que imaginamos! A primeira dica é ter a certeza que está armazenando as informações de identificação da cobrança/pagamento/devolução em seu sistema, pois são através desses campos que vc conseguirá utilizar as requisições de consulta dos endpoints. A seguir vamos detalhar qual os campos indispensáveis para cada rotina. Cobrança (/cob): Ao criar uma cobrança é muito importante armazenar o campo txID. Através dele você conseguirá ter acesso a toda "vida" da cobrança e saber exatamente as ações que foram efetuadas(Pagamentos, Devoluções, etc); Pagamento (/pix): Quando o pagamento de uma cobrança é efetuado, é gerado um campo chamado E2E (End to End). Esse campo também deve ser armazenado para que seja possível consultar esse pagamento posteriormente. Devolução (/pix/{e2eid}/devolucao} : Quando uma devolução é solicitada, é necessário informar o campo "ID da Devolução", esse campo é importante, caso seja necessário futuramente efetuar uma consulta a essa devolução. A seguir, vamos realizar testes utilizando nosso demo do componente ACBrPIXCD configurado com o PSP Banco do Brasil em ambiente de Produção: Ao consultar o txID de uma cobrança recém criada, podemos verificar que o status inicial dela é: "ATIVA" Você tem acesso a essas informações através da propriedade: ACBrPixCD1.PSP.epCob.CobCompleta Quando o pagamento dessa cobrança é efetuado, ao consultá-la novamente temos o status "CONCLUIDA": Também podemos perceber que existe um objeto PIX na resposta, que contém um campo chamado "endToEndID". É aqui que encontramos todas as informações referente ao pagamento. Com esse campo E2E podemos também consultar um pagamento específico, como mostra a imagem a seguir: Essas informações são encontradas na propriedade: ACBrPixCD1.PSP.epPix.Pix Ao efetuar uma devolução e consultar novamente a nossa cobrança (utilizando ainda o txID), temos o seguinte cenário: Vemos que a cobrança continua com o status "CONCLUIDA", porém existe uma devolução com status "DEVOLVIDO". Isso quer dizer o que o valor NÃO está na conta do recebedor, ou seja, a cobrança não está paga. Portanto é sempre importante avaliar a lista de pagamentos(Pix) que a cobrança possui e verificar também a lista de Devoluções que cada pagamento possui.

Já agora é erros com eles. e ajustes de cadastros lá neles.

Estou postando um novo projeto criado por minha pessoa https://sourceforge.net/projects/ceps-opensorce/ Espero que vocês gostem CEP Cidades com código IBGE