EddieBR

Verifiquei aqui.. errei um número hehe. ACBrBoletoRet_Santander_API-32917

A mudança ocorreu na revisão 32417. Na revisão 31762 o status era obtido apenas uma vez, logo no inicio do processamento do tpConsultaDetalhe. Dessa forma não funciona corretamente para todos os casos de pagamento, pois a api retorna modelos de json diferentes. Então entendo que foi alterado para ajustar esses casos. Como está atualmente quebra a consulta do titulo que não teve pagamento. Minha sugestão é juntar os dois comportamentos. Se quiser posso alterar o arquivo e enviar aqui para revisão, não tenho muita prática com o svn, apenas com git.

Após as alterações no arquivo na revisão 32417, ao fazer a consulta de um título recém enviado, a propriedade ARetornoWS.DadosRet.TituloRet.EstadoTituloCobranca está ficando vazia. Entendo que as alterações são para obter corretamente os valores de juros e de pagamentos por Pix. Abaixo segue um exempo de retorno de uma consulta de título com situação 'ATIVO' feito no postman em produção: (Endpoint https://trust-open.api.santander.com.br/collection_bill_management/v2/bills/999999.0000?tipoConsulta=settlement) Obs: Onde 999999 é o cedente e 0000 é o nosso numero { "returnCode": "000 - Consulta realizada com sucesso", "documentNumber": "0000000000000", "beneficiaryCode": 000000, "bankNumber": 9999, "clientNumber": "999", "dueDate": "2024-06-15", "nominalValue": 20.00, "issueDate": "2024-06-12", "participantCode": "", "status": "ATIVO", "settlementData": [ { "settlementDescription": "", "settlementDate": null, "receivingBankCode": 0, "receivingBranch": 0, "interestValue": 0.00, "otherValues": 0.00, "deductionValue": 0.00, "discountValue": 0.00, "settlementValue": 0.00, "settlementIofValue": 0.00, "settlementCreditDate": null, "settlementCreditedValue": 0.00, "settlementDutyValue": 0.00 } ], "writeOffData": [ { "writeOffDescription": "", "writeOffDate": null, "writeOffValue": 0.00, "writeOffDutyValue": 0.00 } ] } Reparem que não temos no JSON não temos "bankSlipData", não temos "_content" (pois é uma consulta por nosso número), e no "settlementData" não retorna o par status pois não houve pagamentos. Se alguem puder verificar, mas acredito que seria possível ler o status como estava antes dessa revisão, logo após o HTTPResultCode 200: tpConsultaDetalhe : begin case HTTPResultCode of 200 : begin ARetornoWS.DadosRet.TituloRet.EstadoTituloCobranca := AJson.Values['status'].AsString; Em seguida seguir com as operações atuais que verifica se existem os outros pares caso o EstadoTituloCobranca esteja vazio.

Mesma situação usando qualquer certificado difital, inclusive como procurador. Enviei email no fale conosco questionando e ainda não obtive resposta.

Complementando o amigo segue o desabafo kkkk. Não conheço o SIEG e ninguém de lá. Mas o suporte do pessoal passa cada informação para o contador... Hoje me mandaram print do suporte SIEG falando que nós tínhamos que aumentar o Timeout aqui. Todos os problemas nossos foram resolvidos após o contador desativar a busca no SIEG. Os não resolvidos são contadores teimosos, como citado. E pode preparar, varios escritórios falaram para nós que no fim do mês "vão habilitar para consultar tudo de uma vez", e voltará a dar problema. Sinceramente já cansamos aqui desse assunto aqui na empresa. Agora cliente que se resolva com contador, ou com a SIEG.

Temos vários casos de lentidão nos SATs da Bematech. Os Sats Bematech são lentos, e ficam mais lentos com o passar do tempo. Porém no Windows 10, pelo que testamos aqui, piora bastante, principalmente com o Windows Defender como antivírus. O que melhora bastante na nossa aplicação, é incluir nas exclusões do Windows Defender: Pasta, Executável e Nome do Processo da aplicação. Tente configurar o Windows Defender e me fale se para o seu caso melhorou. Apenas para comparação, se puder enviar a versão do driver instalado e a versão da DLL. Te falo se estamos usando a mesma.

Encontrei o problema. A configuração estava certa, mas o arquivo simcomu-s.exe que eles mandam substituir deve ser feito depois da instalação do módulo CardSE. Eu havia substituido antes. Substitui novamente e aprovou normalmente.

Pessoal, apenas relatando o teste que fiz usando o Demo Não Fiscal do ACBrTEFD, sem alterações. O Qr Code é exibido no mesmo momento que é logado (segue anexo da imagem). ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 52 TipoCampo = 4128 Buffer = Aguarde, em processamento...(35) Tam.Min = 0 Tam.Max = 0 A venda é Negada pelo simulador do Sitef, entre 1-5 segundos. O painel do QRCode deixa de ser exibido na tela do demo após a negativa da transação, o que na minha opinião é o comportamento correto. Apenas não verifique qual linha do Demo manda ocultar o painel. Talvez mais alguem esteja passando por isso, e está achando que tem algo errado no ACBr, o que não tem.

Estamos iniciando os testes aqui, não sei se é a mesma situação que o pessoal passou anteriormente. Usando o PIX pelo SITEF (Demo) no ACBrTEFD Demo não fiscal (fontes e demo atualizados), o qr code aparece rapidamente, porem a transação não é aprovada. Segue o trecho do log após receber o QRCode. ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 50 TipoCampo = 584 Buffer = You lie, in faith; for you are called plain Kate, And bonny Kate and sometimes Kate the curst; But Kate, the prettiest Kate in Christendom. Kate of Kate Hall, my super-dainty Kate, For dainties are all Kates, and therefore, Kate, Take this of me, Kate of my consolation; Hearing thy mildness praised in every town, Thy virtues spoke of, and thy beauty sounded, Yet not so deeply as to thee belongs, Myself am moved to woo thee for my wife. (William Shakespeare - The Taming of the Shrew) Tam.Min = 0 Tam.Max = 0 ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 52 TipoCampo = 4128 Buffer = Aguarde, em processamento...(35) Tam.Min = 0 Tam.Max = 0 ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 51 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 800 Buffer = 79DE19DAC3BA99B09A670736D77F389382A86A4C Tam.Min = 0 Tam.Max = 0 ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 13 TipoCampo = -1 Buffer = Tam.Min = 0 Tam.Max = 0 CliSiTef DoExibeMsg: Oper: opmRemoverMsgOperador Mensagem: CliSiTef DoExibeMsg: Oper: opmRemoverMsgCliente Mensagem: ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 2010 Buffer = 77 Tam.Min = 0 Tam.Max = 0 ContinuaFuncaoSiTefInterativo, Chamando: Continua = 0 Buffer = ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 22 TipoCampo = -1 Buffer = Transacao nao aprovada: -1 Tam.Min = 1 Tam.Max = 1 CliSiTef DoExibeMsg: Oper: opmOK Mensagem: Transacao nao aprovada: -1 Avaliando os relatórios do SITEF, a transação chega mas é negada pelo Sitef Demo.

Temos essa situação aqui com os SATs da Bematech também. A equipe de engenharia que desenvolveu esse SAT da Bematech (Todos até o BemaSAT Go) está de parabéns! Falo porque tivemos que colocar em produção lá no inicio da obrigatoriedade (Postos de Combustível), e passei por todos os problemas que possam imaginar com essa Obra Prima. Nos casos que observamos ocorre o seguinte: - Aplicação envia a venda para o SAT. - SAT demora tempo demais para processar a venda (talvez processador ruim, ou esteja fazendo outra tarefa internamente). - Aplicação recebe Timeout (normalmente a mensagem "falha na abertura da porta", retornada pela DLL). - Aplicação (ou operador) manda a venda novamente, e recebe o sucesso. Problema é que o mesmo a DLL respondendo falha, o sat efetua a venda com atraso, e transmite para a SEFAZ. Resultado é uma venda duplicada, triplicada, etc. Uma coisa que fazemos aqui que melhora esse processo, é configurar o timeout do SAT. Caso não tenha na pasta da aplicação o arquivo bemasat.xml, talvez a dll crie o mesmo automaticamente na primeira comunicação. Nos downloads da Bematech vem o xml junto com a DLL. Nesse arquivo tem o timeout padrão de todos os comandos. O de venda se me lembro bem era muito baixo. Segue o trecho do XML: <Timeouts> <ativacao>1800000</ativacao> <icp_brasil>600000</icp_brasil> <consultar_sat>30000</consultar_sat> <associar_assinatura>40000</associar_assinatura> <consultar_sessao>40000</consultar_sessao> <trocar_codigo_ativacao>40000</trocar_codigo_ativacao> <bloquear_sat>1200000</bloquear_sat> <desbloquear_sat>80000</desbloquear_sat> <extrair_logs>180000</extrair_logs> <atualizar_sat>3600000</atualizar_sat> <configurar_rede>120000</configurar_rede> <enviar_venda>60000</enviar_venda> <cancelar_venda>60000</cancelar_venda> <teste_fim_a_fim>40000</teste_fim_a_fim> <consultar_status>60000</consultar_status> </Timeouts> No exemplo acima esta com 60 segundos de timeout. Com isso a DLL não apresenta erro antes desse tempo. Como colateral, se o SAT estiver desligado, vai levar 1 minuto para apresentar o erro. Tente mudar esses timeouts e veja se vai diminuir esses problemas, temos casos que precisamos de timeouts maiores, principalmente em enviar_venda e consultar_status. No ACBrSAT não existem configurações de timeout, pois a responsabilidade é da DLL do fabricante.

Esse SAT GO da Bematech é um excelente peso para papel. Extraia os logs do equipamento. Deve apresentar erro ao sincronizar o relógio via NTP. Temos meia duzia com problema no relógio. Pelo que entendemos é o seguinte: - Em algumas conexões de internet ele simplesmente não consegue comunicar com o servidor NTP. - Ligando em outra internet sincroniza. - Ao desligar o SAT, ele volta a hora interna para a hora da emissão do último cupom, e tenta sincronizar novamente. Se não conseguir, a hora fica errada. Ele deveria manter a hora pela bateria, mas isso não acontece em nenhum SAT Go que pegamos. Recomendação, não sofra e troque por outro SAT. Aqui já não habilitamos esse SAT Go no nosso PDV para evitar problemas.

Temos apenas 1 cliente com esse Bematech GO. Tenho lembrança de ter recebido esse erro quando instalamos. Só não lembro como resolvemos. Confira qual a versão do driver no gerenciador de dispositivos. No nosso cliente está com o driver 4.0.1.36025 e a DLL 1.0.2.35. Se precisar desses arquivos para testar me mande o email por MP que envio pra vcs.

Realmente, existe a propriedade BIN, e está buscando o campo 136. Como eu precisei disso muito tempo atras, implementei aqui e não reparei essa nova propriedade.

Juliomar, esse retorno conta na Tabela de valores para TipoCampo na documentação do Sitef (SiTef - Interface Simplificada com a aplicação). Não sei em outros TEFs. Como eu precisei, criei uma propriedade para obter esse retorno. Acho válido, pois não é uma informação sensível. Ela é exibida no visualizador de tabelas, nos relatórios do Sitef, e pode ser interessante para mais pessoas.

O motivo nosso de capturar o BIN é para identificar a bandeira do cartão em casos que o campo 156 vem igual para vários cartões. Após inserir o cartão, o sitef retorna o Campo 136, conforme o log: -- 01/05 07:25:20:054 - ContinuaFuncaoSiTefInterativo, Retornos: STS = 10000 ProximoComando = 0 TipoCampo = 136 Buffer = 650485 Tam.Min = 0 Tam.Max = 0 Acredito que você consiga ler o campo da seguinte forma: ACBrTEFD1.TEFCliSiTef.Resp.LeInformacao(136).AsInteger; Aqui eu preferi criar uma propriedade nova no ACBrTEFD e capturo dentro do case do método TACBrTEFDRespCliSiTef.ConteudoToProperty: 136 : fpBin := Linha.Informacao.AsString; Espero ter ajudado.

Pegamos uma impressora dessa hoje, e acontece a mesma situação. Nunca retorna o status.

Desde sexta o WebService esta maluco. Hora recebe esse retorno vazio, hora timeout, hora erro não catalogado.

Por acaso o envio é em MG? Aqui estou com o mesmo problema, além de timeouts.

Com um timeout maior (Ex: 15000), tem hora que envia (lento mas envia), e hora retorna: <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Body><nfeResultMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeAutorizacao4"/></S:Body></S:Envelope> Também já verificamos erro não catalogada. Esta bem zoado o ambiente deles viu. Obs: Envio Sincrono.

Esqueci de mencionar, estou testando no ambiente de homologação. Em produção também apresenta problemas ao cancelar em MG?

Por aqui ainda persiste resposta 999 ao tentar cancelar qualquer nota dentro do prazo. Após o prazo de 24 horas, vem a resposta 501: Prazo de cancelamento superior ao previsto na Legislação.

Verifiquem no log do equipamento. Se for troca de Software House, o equipamento não pode ter cupons em memória e nem aguardando retorno de lotes em processamento pela sefaz. Recentemente tive problema com alguns que mesmo sem apresentar cupons armazenados, ficam de alguma forma aguardando algum lote ser processador e não processa. Isso é exibido no log.

Mais cedo o pessoal estava recebendo erro http 503 aqui.

Por aqui estamos com a mesma situação em diversos clientes desde o inicio do dia.

Mesma coisa aqui.