Jump to content

Guilherme Borges

Pessoal da TecnoSpeed
  • Contagem de Conteúdo

    58
  • Ingressou

  • Última visita

  • Dias Ganhos

    3

Tudo que foi postado por Guilherme Borges

  1. Fala Desenvolvedor, beleza? Meu nome é Guilherme, sou consultor técnico aqui na TecnoSpeed, e atuando no atendimento referente a nossa API de boletos, percebo que podem existir alguns erros que causam certa estranheza em nossos clientes. Portanto, neste post, vou comentar sobre um deles: A rejeição ''movimento.legado.tamanho.mensagemintrucao.maximo" devolvida diretamente pelo WebService do Sicoob durante a tentativa do registro de um boleto. Geralmente, este erro é retornado pelo banco, quando os campos referente a mensagens do boleto (TituloMensagem01, TituloMensagem02, TituloMensagem03, etc) são preenchidos com mais de 40 caracteres. Com isso, para soluciona-lo basta reduzir o tamanho das mensagens inseridas nestes campos, incluindo um texto com valor igual ou inferior a 40 caracteres. E por hoje é isso DEV, espero que o POST tenha sido útil, e precisando de qualquer apoio estamos à disposição em nossos canais de atendimento. Até mais!
  2. Olá Alexandre, boa tarde! Qual rota você esta utilizando para realizar a geração da remessa em nossa API, por gentileza? Atenciosamente.
  3. Olá Denilson, boa tarde! É isso mesmo, a análise do banco esta correta. O que esta acontecendo é o seguinte: Para a inclusão de juros em nossa API, são utilizados dois campos principais, o TituloCodJuros e o TituloValorJuros. O TituloCodJuros define se o acréscimo será em reais ou porcentagem, e o TituloValorJuros define o valor dessa cobrança. Para este boleto que você me enviou, o código do Juros foi passado como 1, que significa que o acréscimo será cobrado a partir de um valor em reais definido. E o TituloValorJuros, foi passado no valor de 0,20 centavos. Porém, temos também o campo TituloMensagem01 utilizado na inclusão do boleto, e neste campo esta sendo informado que o valor do juros é 20% do valor do boleto, no caso 0,53 centavos. Para ajustar isso, você tem essas duas alternativas: 1 - Passar campo TituloMensagem01 desta maneira: "TituloMensagem01": "Juros de 0,20 centavos ao dia apos vencimentoMulta de 2,00% apos vencimentoEsta Fatura f", 2 - Passar o campo de Juros desta maneira: TituloValorJuros: 0,53 Lembrando, a escolha da alternativa deve ser tomada conforme o valor que você realmente deseja cobrar para juros. Qualquer dúvida estou à disposição. Atenciosamente.
  4. Olá Denilson, boa tarde! Na realidade, a mensagem é um dos campos utilizados para a inclusão do boleto, portanto, no momento em que o boleto é incluído você pode encaminhar uma mensagem através do campo TituloMensagem01. Isso pode ser modificado durante o envio do JSON de inclusão. Atenciosamente.
  5. Olá Denilson, bom dia! Realizei uma análise sobre o caso, e aparentemente o problema esta sendo causado pelo seguinte motivo: No JSON de inclusão do boleto o valor de juros esta sendo passado como R$ 0,20 centavos: Porém, na mensagem presente no PDF do boleto, o valor esta sendo destacado como porcentagem: Você pode corrigir este erro através do campo TituloMensagem01. Atualmente, este campo esta sendo passado da seguinte maneira: "TituloMensagem01": "Juros de 0,20% ao dia apos vencimentoMulta de 2,00% apos vencimentoEsta Fatura f", Neste caso, seria necessário apenas mudar para isso: "TituloMensagem01": "Juros de 0,20 centavos ao dia apos vencimentoMulta de 2,00% apos vencimentoEsta Fatura f", Ou seja, apenas substituir a porcentagem pelos centavos no momento de destacar o valor dos juros. Qualquer dúvida estou à disposição. Atenciosamente.
  6. Fala DEV, blz? Você esta recebendo o erro "Falha ao Criar token local filter failed" durante a emissão de um PIX para o Itaú? Caso sua resposta tenha sido sim, fica comigo aqui neste POST, que nos parágrafos a seguir vou orientar como este problema pode ser solucionado. Meu nome é Guilherme, sou Consultor Técnico aqui na operação Plugank da TecnoSpeed, e já vamos para a parte mais importante, como resolver este erro. Bora lá? Resumidamente DEV, este erro acontece quando existe alguma inconsistência nas credenciais repassadas pelo banco. Portanto, quando você receber esta mensagem de erro em sua tela, recomendamos a confirmação se o cadastro do ClientID e ClientSecret estão corretos em nossa aplicação, na maioria das vezes, este erro esta relacionado a estes dois campos, porém, também sugiro a validação do certificado digital utilizado para autenticar as requisições. Ainda neste mesmo sentido, a confirmação destas informações pode ser realizada diretamente junto ao Itaú, e para o ClientSecret você também pode confirma-lo durante os processos de conversão do certificado digital, mais especificamente no momento de converter o .CSR para .CRT. E por hoje é isso desenvolvedor, qualquer dúvida estamos à disposição. Até mais!
  7. Fala Dev, blz? Meu nome é Guilherme, sou Consultor Técnico na operação PlugBank da TecnoSpeed, e durante atendimentos envolvendo nossa API para pagamentos, percebo que podem acabar surgindo dúvidas acerca da utilização e função de cada forma de pagamento disponível em nossa aplicação. Portanto, neste material vou apresentar as definições para Crédito em Conta Corrente, TED, DOC, Transferência via Poupança. Desse modo, se você possui dúvidas sobre a utilização destas formas de pagamento, fica por aqui, que aprofundaremos o assunto nos parágrafos a seguir. Borá lá? Crédito em Conta Corrente (01): Esta forma de pagamento pode ser utilizada quando o cliente deseja realizar uma transferência entre contas correntes, porém, apenas será possível utilizar esta modalidade, quando a conta pagadora e beneficiária pertencerem a mesma instituição financeira. Portanto, se for realizada a tentativa de realizar um Crédito em Conta Corrente entre contas de bancos diferentes, provavelmente o título será rejeitado, e a transferência não será efetivada. DOC (03): Modalidade de transferência utilizada quando a conta pagadora e beneficiária são de bancos diferentes, porém, o dinheiro só acaba sendo recepcionado na conta transferida no dia seguinte. Se o DOC for realizado após as 22hrs, o tempo para conclusão da transferência pode ser ainda maior. Poupança (05): Assim como o Crédito em conta Corrente, a transferência via poupança só pode ser utilizada quando as contas pagadoras e beneficiária forem da mesma instituição financeira, porém neste caso, ela será utilizado quanto a conta do cliente for do tipo poupança. TED outra titularidade (41): Seguindo o mesmo sentido da modalidade DOC, o TED precisa ser utilizado quando as contas envolvidas na transação forem de bancos diferentes. Contudo, para o TED, o dinheiro é creditado na conta do beneficiário no mesmo dia que o título foi emitido, porém, para que isso aconteça é preciso enviar o pagamento antes das 17hrs, caso contrário, ele apenas será creditado no dia seguinte. Ainda nesse sentido, o TED se divide em dois tipos: mesma titularidade e outra titularidade. Assim, o TED outra titularidade é utilizado quando o CNPJ/CPF de pagador e beneficiário forem diferentes. TED mesma titularidade (43): Segue os mesmos padrões do TED outra titularidade, porém, esta modalidade é utilizada quando CNPJ/CPF de beneficiário e pagador forem iguais. E por hoje seria isso Desenvolvedor, espero que o conteúdo tenha agregado ao seu conhecimento. Qualquer dúvida estou à disposição! Até mais!
  8. Olá Alexandre, bom dia! Tudo bem? Como já foi gerada uma remessa sobre o boleto, recomendo esperar este título ser registrado, e gerar uma remessa de baixa sobre o boleto, conforme a doc abaixo: Solicitando baixa: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360006195654-Solicitando-a-baixa Consultando protocolo de baixa: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360006270773-Realizando-a-consulta-da-baixa- Visto que, como você já gerou uma remessa sobre este boleto, se você descarta-lo, existe a possibilidade deste título ficar como registrado no banco e descartado em nossa API, já que, o envio dele ao banco foi realizado. Portanto, eu recomendo aguardar o registro do boleto, e a geração da remessa de baixa referente ao título em questão. Porém, se você confirmar com o banco que o boleto não foi recepcionado por eles, aí basta gerar o descarte conforme a doc abaixo: Descartando um boleto: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360006197894-Descartando-um-boleto Contudo, conforme comentei, só recomendo o descarte após confirmação do banco que eles não receberam o boleto, de modo a evitar inconsistências entre nossa API e o banco. Qualquer dúvida estou à disposição. Atenciosamente.
  9. Olá Alexandre, boa tarde! Tudo bem? Analisando o boleto encaminhado acima, identifiquei a seguinte mensagem de falha: "TituloDataVencimento - Deve ser uma data posterior à informada no campo TituloDataEmissao;" Diante disso, dei uma olhada no JSON que você disponibilizou, e localizei que esta falha esta ocorrendo por conta do preenchimento destes dois campos: "TituloDataEmissao": "15\/12\/22", "TituloDataVencimento": "13\/12\/2022", Como pode observar, a data de vencimento esta preenchida com um valor menor do que a data de emissão. Com isso, é como se o boleto já fosse emitido em vencimento, e como este cenário não é possível, a validação da nossa API acaba gerando a falha que comentei acima. Portanto, será necessário gerar um novo boleto, com a data de vencimento sendo um valor posterior a data de emissão, desse modo, provavelmente a geração do boleto vai dar certo! Exemplo: "TituloDataEmissao": "15\/12\/2022", "TituloDataVencimento": "20\/12\/2022", Qualquer dúvida estou à disposição por aqui. Atenciosamente.
  10. Fala Desenvolvedor, beleza? Meu nome é Guilherme, atuo na consultoria técnica da operação PlugBank da TecnoSpeed, e realizando atendimentos referentes a nossas APIs financeiras, percebo que existem alguns tópicos que podem acabar causando dúvidas para o usuário, durante a utilização de nossos produtos. Por exemplo, ao consultor um boleto, você sabe a diferença entre os campos referentes a linha digitável e o código de barras? Caso sua resposta tenha sido não, fique comigo neste POST, que iremos detalhar as divergências nos próximos parágrafos. Bora lá? Basicamente DEV, detalhando o conceito dos dois termos, a linha digitável pode ser definida como o campo que é gerado a partir dos dados informados na emissão do título, ou seja, através da linha digitável é possível verificar todas as informações do boleto bancário, além do fato de sua leitura permitir a identificação do título/fatura em questão, e consequentemente o pagamento dos mesmos. Já o código de barras é a representação gráfica da linha digitável, permitindo a leitura em máquinas e computadores. Resumidamente, a diferença entre os campos seria esta, porém, caso tenham restado dúvidas, estamos à disposição em nossos canais de atendimento. Por hoje seria isso, até mais! 😀
  11. Fala Desenvolvedor, beleza? Durante o preenchimento dos dados de uma conta em um sistema próprio de emissão de boletos, podem surgir diversas dúvidas acerca de alguns campos específicos. E hoje vamos estar respondendo uma pergunta que pode surgir durante o preenchimento do código de beneficiário para o Banco Sicredi: O código de beneficiário sempre será igual ao número da conta? Se você possui esta dúvida, acompanhe o restante do post que vamos esclarecer esta questão. Borá lá? Resumidamente, o padrão adotado pelo banco é realmente utilizar o código de beneficiário com o mesmo valor da conta, porém, em alguns casos específicos, podem ocorrer migrações de agência, ou determinadas modificações contratuais, onde o código de beneficiário precisa ser recadastrado, e com isso, acaba ficando com um valor diferente da conta. Portanto, na maioria dos casos, o código do beneficiário será igual a conta, contudo, sempre recomendamos confirmar as informações cadastrais junto ao banco antes de realizar os devidos envios dos arquivos de remessa para validação, com o intuito de evitar possíveis inconsistências no cadastro. E por hoje seria isso DEV, espero que tenha gostado e que o conteúdo tenha agregado ao seu conhecimento. Até mais!
  12. Fala Desenvolvedor, beleza? Meu nome é Guilherme, sou consultor técnico aqui na TecnoSpeed, e como recentemente liberamos a opção de emitir PIX via arquivo de remessa para o banco Itaú, através da nossa API de pagamentos. Entendo que possam existir alguns campos, que podem causar certas dúvidas no momento da emissão do título. Portanto, neste POST, vamos comentar sobre o campo “pixType”. Bora lá? Resumidamente DEV, para o Itaú, este campo se refere ao tipo da chave PIX utilizada na emissão, podendo ser preenchido com os seguintes valores: 01, 02, 03 e 04. Assim, o significado de cada um dos valores é: 01 - Chave PIX via Telefone. 02 - Chave PIX via E-mail. 03 - Chave PIX via CPF/CNPJ. 04 - Chave PIX via Chave Aleatória. Com isso DEV, basta preencher o campo com o tipo de chave PIX que você utilizará, e realizar a emissão do pagamento normalmente. Por hoje seria isso, qualquer dúvida estamos à disposição em nossos canais de atendimento. Até mais Desenvolvedor!
  13. Fala Desenvolvedor, beleza? Meu nome é Guilherme, atuo na consultoria técnica da operação PlugBank da TecnoSpeed. E com isso, realizando o atendimento referente as APIs financeiras da TecnoSpeed, percebo alguns erros mais comuns, que podem ser solucionados de maneira mais eficaz com as orientações corretas. Diante disso, hoje vamos tratar sobre o erro “Software Cliente não identificado”, um problema que ocorre na API do PIX no momento de autenticação e emissão de um pagamento. Nesse contexto, este erro é devolvido diretamente pelo banco, e se trata de um impasse nas credenciais utilizadas para se autenticar na API. Com isso, quando o problema aparecer em sua tela, recomendamos que seja verificado se as credenciais “Client ID”, “Client Secret”, “Pix Key”, e outras informações bancárias, estão realmente corretas e habilitadas para a emissão de PIX. Além disso, para essa verificação, sugerimos que a validação seja realizada juntamente com o banco, confirmando se as credenciais bancárias estão iguais às cadastradas em nossa aplicação. Mesmo assim, se o erro permanecer, estamos à disposição nos canais de atendimento para novas validações. Por hoje seria isso Dev, espero que tenha gostado, e que o conteúdo tenha agregado ao seu conhecimento. Até mais!
  14. Fala Desenvolvedor, beleza? 👍 Meu nome é Guilherme, atuo na consultoria técnica da operação PlugBank da TecnoSpeed, e hoje venho comentar sobre um erro ocorrente em nossa API do PIX, o erro “ forbidden.exception”. Então, se você tem dúvidas sobre este erro, fica comigo aqui neste Post, que eu detalharei o problema nos próximos parágrafos. Bora lá? Resumidamente Dev, quando esta rejeição aparecer durante a sua emissão de um PIX, significa que suas credenciais bancárias informadas em nossa API, estão inválidas ou sem permissão para a emissão de um PIX no banco. Diante disso, quando você encontrar este erro, o primeiro passo é conferir se o cadastro do certificado e das outras credenciais estão corretas em nossa aplicação. Assim, caso esteja tudo certo, a próxima etapa é entrar em contato com o banco, para verificar se as credenciais já estão com permissão para a emissão do PIX. Assim, geralmente realizando estas conferências, o erro já deve ser corrigido. Porém, caso o erro permaneça, estamos à disposição nos nossos canais de atendimento, para realizar novas validações sobre o caso. Por hoje é isso Dev, qualquer dúvida estou à disposição. Até mais! 👊
  15. Fala Desenvolvedor, beleza? O PIX de cobrança com vencimento, é uma das modalidades do PIX que permitem você definir um prazo máximo para seu pagador efetuar determinada transação. Porém, uma das dúvidas que aparecem entre nossos clientes em nossos canais de atendimento é: “Se eu definir meu PIX para vencer em um feriado nacional ou final de semana, o pagador terá até o próximo dia útil para realizar o pagamento? 🤔”. Bem, se você também tem essa dúvida, fica aqui comigo neste POST, que eu vou solucioná-la nos próximos parágrafos. Bora lá? Basicamente Desenvolvedor, a resposta da pergunta realizada no início do parágrafo anterior é: sim. Ou seja, se você estipular um PIX para vencer em um final de semana ou feriado, o pagador terá até o próximo dia útil para efetivar esse pagamento. Como por exemplo, se você definiu que seu PIX vai vencer em um sábado, o pagador terá até segunda (próximo dia útil), para concluir a transação. Diante disso, podemos perceber que este tópico do PIX, segue um padrão muito parecido com o que acontece com o vencimento de um boleto. Além disso, é muito importante destacar neste POST, que isso são normas adotadas pelo próprio Banco Central, conforme é possível identificar nas documentações do BACEN: Link da documentação Banco Central: https://bacen.github.io/pix-api/index.html#/CobV/put_cobv__txid_ E por hoje é isso Desenvolvedor, espero que tenha gostado do POST, e que o conteúdo agregue ao seu conhecimento. Qualquer dúvida estou à disposição, até mais! 👊
  16. Fala Desenvolvedor, beleza? 👍 Meu nome é Guilherme, atuo na consultoria técnica da operação PlugBank da TecnoSpeed, e hoje venho através deste POST comentar sobre um erro comum em nossa API de PIX: The specified key does not exist. Bora lá? Basicamente DEV, este erro está relacionado a chave PIX cadastrada em nossa API, e um dos motivos para a ocorrência do impasse, é o fato da chave não existir no banco, ou ainda não estar habilitada para a emissão de um PIX. Assim, a chave pode até estar habilitada no sentido de abrir o APP do banco e realizar uma transferência via PIX, porém, ela ainda pode não estar disponível para a emissão de um PIX na instituição financeira. Desse modo, o erro também pode estar associado a divergência entre as credenciais repassadas pelo banco, e credenciais cadastradas na API da TecnoSpeed. Contudo, quando o erro ocorrer, nossa recomendação é: primeiramente, confirmar se a chave PIX está cadastrada corretamente em nossa API. Após isso, recomendamos que o cliente entre em contato com a instituição financeira, para que sejam verificadas as liberações da chave utilizada para as transações via PIX. E por hoje é isso Desenvolvedor, espero que tenha gostado do POST e que o conteúdo tenha agregado ao seu conhecimento. Qualquer dúvida estou à disposição, e até mais!
  17. Fala Desenvolvedor, beleza? 👍 Meu nome é Guilherme, atuo como consultor técnico aqui na operação PlugBank da TecnoSpeed, e hoje venho aqui neste POST tratar sobre um assunto que gera algumas dúvidas entre nossos clientes da API de pagamentos. Assim, o tema que estou falando é o processo de aceite de efetivação de pagamentos, que deve ser realizado via internet banking das principais instituições financeiras. Bora lá? O que seria este procedimento? 🤔 Basicamente, a maioria dos bancos que oferecem o serviço de pagamentos via CNAB 240, exigem uma confirmação da transação via plataforma online da instituição, como uma forma de segurança e prevenção contra golpes e fraudes. Dessa forma, esta etapa se resume a basicamente isso: autorização do pagamento que o cliente precisa fornecer via internet banking, após a emissão da remessa através da API da TecnoSpeed. OBS: Este processo de aceitação é relacionado aos bancos, e não se trata de uma norma da TecnoSpeed. Dessa maneira, as regras podem variar de acordo com o banco de cada cliente. Como funciona este processo para os principais bancos? 🤔 Assim, como comentei no tópico anterior, não existe um padrão estabelecido pela Febraban para a realização deste procedimento, fazendo com que cada banco tenha seu padrão de aceite estabelecido. Diante disso, em um levantamento realizado junto aos principais bancos, identificamos que inclusive algumas instituições não exigem este processo, conforme demonstraremos a seguir: Itaú: A autorização do pagamento, depende do contrato Sispag estipulado entre o cliente e o banco. Diante disso, se o contrato estabelecer que os pagamentos são pré-autorizados, o cliente não precisa realizar nenhuma autorização no Bankline. Contudo, se no contrato estiver estipulado pós-autorização, então o cliente vai precisar ir na sessão de contas à pagar e realizar a autorização do título pendente de processamento. Desse modo, essa necessidade de autorização pode ser alterada junto à agência do cliente, que deve abrir uma demanda para o setor de cash efetivar a alteração. Banco do Brasil: A autorização do pagamento sempre será necessária via internet banking. Sicredi: Nenhuma autorização é necessária. Contudo, se o pagamento for enviado por um usuário secundário, o título ficará pendente de autorização para o usuário Master da conta, porém, a autorização só será necessária neste cenário. Santander: Para qualquer pagamento é necessário a autorização via internet banking na aba “autorizações”, independente do contrato do cliente. Bradesco: Depende do contrato estipulado entre cliente e agência. Se o cliente alinhar com a agência que todos os pagamentos são autorizados previamente, nenhuma confirmação será necessária via internet banking. Agora, se o cliente possui um contrato com a agência onde os títulos precisam ser autorizados via internet banking, um usuário master vai precisar realizar as autorizações via portal do banco. Também, qualquer mudança com relação a este processo, deve ser tratada junto à agência do cliente. Sicoob: Não é necessário a confirmação, apenas se o pagamento for emitido por algum usuário sem permissão. Dessa forma, recomendamos que seja identificado junto ao banco, o lugar no internet banking onde será possível realizar a aceitação das transações bancárias realizadas via arquivos de remessa. E por hoje é isso DEV, espero que tenha gostado do conteúdo. Qualquer dúvida estou à disposição, e até mais! 👍
  18. Fala Desenvolvedor, beleza? 👍 Meu nome é Guilherme, e atuando constantemente nos atendimentos relacionados aos produtos financeiros da TecnoSpeed, percebo que existem alguns erros que podem acabar causando um pouco de estranheza por parte do usuário, na hora que a mensagem aparece na tela. Diante disso, hoje comentarei neste POST, referente ao erro “Recipient not found”, que pode ocorrer no momento da criação de um PIX em nossa API. Vamos lá? Basicamente, como o próprio nome sugere, o problema acontece quando “alguma coisa” não é localizada, no momento em que a requisição de criação do PIX é enviada. Nesse sentido, no caso do erro que estamos tratando neste POST, geralmente ele ocorre quando a conta bancária do usuário acaba não sendo localizada em nossa aplicação. Ainda nesse sentido, o impasse pode ser gerado por algumas inconsistências, como por exemplo: Cadastro incorreto da conta. Credenciais repassadas incorretamente no momento do envio da requisição. Caso você utilize o TecnoPay, o erro pode ser gerado por preenchimento equivocado de algumas informações no cadastro da conta. Com relação ao último tópico citado, este erro acontece com certa frequência em contas TecnoPay, principalmente pelo preenchimento indevido de alguns campos na inserção da conta, que não são utilizados pelo TecnoPay, como por exemplo, clientId, clientSecret e client Key. Além disso, quando o erro ocorrer para contas do TecnoPay, também é recomendável confirmar o PixKey e Bank Account cadastrados, de modo que seja verificado se existem algumas inconsistências. Na maioria dos casos, corrigindo as informações no cadastro da conta, as próximas emissões já costumam funcionar sem nenhum outro impasse. E por hoje é isso Desenvolvedor, espero que tenha gostado e que o conteúdo tenha agregado ao seu conhecimento. Qualquer dúvida estou à disposição, e até mais! 👊
  19. Fala Desenvolvedor, beleza? Quando falamos de consultas em bancos de dados, os operadores de comparação se tornam peças fundamentais para filtrar e aumentar a especificidade dos elementos devolvidos pelo nosso comando. Porém, você já tem noção de quais são, e de como funcionam os operadores de comparação para bancos de dados não relacionais? Bem, caso tenha alguma dúvida referente a este tema, fique por aqui, que a seguir demonstrarei quais são os principais operadores de comparação para bancos de dados NoSql. 1. $gt Primeiramente, temos o $gt, que serve basicamente para identificarmos se um atributo é maior que um determinado valor. Exemplo: db.collectionName.find({nomeDoCampo:{$gt:60}}) Diante disso, neste exemplo demonstrado anteriormente, serão devolvidos os elementos que possuem o valor do campo em questão, maior que 60. 2. $gte Nesse contexto, o $gte possui uma função bastante semelhante ao $gt, porém, ele verifica se o atributo é maior ou igual ao valor passado, diferentemente do $gt, que apenas verifica se o atributo é maior ou não. Exemplo: db.collectionName.find({nomeDoCampo:{$gte:60}}) Dessa forma, neste exemplo, serão apresentados os elementos que possuem o valor do campo maior ou igual a 60. 3. $lt Além disso, o operador $lt, é utilizado para analisarmos se o atributo em questão é menor que o valor repassado no comando. Exemplo: db.collectionName.find({nomeDoCampo:{$lt: 20}}) Assim, utilizando este operador, serão apresentados aqueles elementos que possuírem o valor do campo menor que 20. 4. $lte Desse modo, seguindo o mesmo padrão do $gte, o $lte vai devolver os itens que forem menores ou iguais ao valor passado na query. Exemplo: db.collectionName.find({nomeDoCampo:{$lte: 20}}) No mesmo sentido, serão apresentados aqueles elementos que possuírem o valor do campo menor ou igual a 20. 5. $or Ademais, o operador $or, vai realizar a ação de comparação das condições, utilizando a operação “Ou”. Exemplo: db.collectionName.find({$or:[{nomeDoCampo1 : “A”},{nomeDoCampo2 : “B”}]}) Diante disso, neste exemplo, serão apresentados os elementos que possuírem o campo 1 igual A ou o campo 2 igual a B. 6. $and Por fim, temos o operador $and, que compara as condições, utilizando o operador “and”. Exemplo: db.collectionName.find({nomeDoCampo1:“A”, nomeDoCampo2:“B”}) Assim, esta consulta retornará, apenas os itens que possuírem o campo 1 no valor de A, e o campo 2 no valor de B. E claro Desenvolvedor, estes não são todos os operadores de comparação em NoSql, porém, são os principais utilizados, inclusive, se gostarem do conteúdo podemos estar trazendo a continuação com o restante dos operadores 🙂 Mas por hoje seria apenas isso Dev, espero que tenha gostado do post e que o conteúdo tenha agregado ao seu conhecimento. Qualquer dúvida estou à disposição, e até a próxima!👊
  20. Fala Desenvolvedor, beleza? Um dos principais fatores que impactam diretamente o desempenho de um colaborador em seu ambiente de trabalho, é a motivação com a qual o mesmo realiza suas principais atividades diariamente. Nesse sentido, este elemento pode influenciar tanto o desempenho de um determinado colaborador, como também a qualidade de suas entregas. Porém, você já tem bem definido o conceito de Motivação em sua mente? E além disso, você sabia que a motivação pode ser classificada principalmente de duas maneiras? Bem, se em alguma dessas perguntas você acabou ficando sem respostas, acompanhe o restante deste Post que eu solucionarei suas dúvidas. Borá lá? Qual o significado de motivação? 🤔 O conceito de motivação, se resume basicamente em um conjunto de fatores psicológicos e físicos que impulsionam o indivíduo a realizar alguma determinada ação e atingir seus desejos e objetivos. Com isso, a motivação pode ser influenciada por fatores como a realização da ação, permitir ao indivíduo uma ascensão social e profissional. Além disso, a motivação também pode ser alterada por alguns aspectos negativos como o medo de falhar, ou o medo de outra pessoa estar mais capacitada que você para realizar determinada tarefa. Dessa forma, este conceito ainda é dividido em duas denominações, sendo elas a motivação intrínseca e extrínseca. Certo, e qual o significado destas duas outras denominações? 🤔 Bem, resumidamente, a motivação intrínseca ocorre quando o indivíduo realiza ação por puro interesse, desejo e satisfação, sem nenhum prêmio ou ação externa associado ao ato de realizar esta tarefa, a pessoa é movida apenas pelos desafios e diversão. Ainda nesse contexto, já no caso da motivação extrínseca, o indivíduo é influenciado por aspectos como dever, e alguma recompensa relacionada ao ato de finalizar esta ação. Dessa forma, fica evidente que o ser humano se motiva por inúmeras razões diferentes, sejam elas pelo prazer e o ideal por trás da ação, ou as vantagens e recompensas que são atribuídas a conclusão de um determinado ato. Mesmo assim, a motivação intrínseca ganha mais destaque entre os líderes educacionais e empresariais, pois quando o indivíduo que age intrinsecamente está realizando a tarefa que gosta, ele é mais produtivo e proativo durante a realização de suas atividades, uma vez que, ele está trabalhando por algo que realmente tem prazer em realizar. E por hoje é isso pessoal, espero que tenha gostado do post e que o conteúdo tenha agregado ao seu conhecimento. Qualquer dúvida estou à disposição, e até a próxima! 👊
×
×
  • Create New...