Painel de líderes

Compartilhando esse tutorial que encontrei, via firebirdnews O Tutorial foi escrito por Jan Baumgarten. Ele explica como criar uma aplicação simples usando Delphi + ZeosLib and Firebird 4RC1 para Android. O link para o artigo: https://sourceforge.net/p/zeoslib/wiki/How to use Firebird 4.0 with Zeos on Android/ Está em inglês, mas mesmo que você não entenda inglês, não é muito difícil de seguir usando o Google Translate.

Olá pessoal, Temos novidades na NF-e que vão trazer alterações no componente. "Essa Nota Técnica divulga novos campos e regras de validação para a NF-e/NFC-e versão 4.0, visando a adequação ao disposto no Ajuste SINIEF 21/2020 e 22/2020, envolvendo a identificação do intermediador ou agenciador da operação." O prazo previsto para a implementação das mudanças é: * Ambiente de Homologação (ambiente de teste das empresas): 01/02/2021 * Ambiente de Produção: 05/04/2021 Ainda não foi liberado os novos schemas. Fiquem tranquilos que o ACBrNFe será atualizado para que todos possam realizar os testes assim que o ambiente de homologação for liberado. Observação: Novos campos que vão fazer parte do layout da NF-e: elemento <indIntermet> é opcional e aceita os valores: 0 = Operação sem intermediador (em site ou plataforma própria) e 1 = Operação em site ou plataforma de terceiros (intermediadores/marketplace) grupo <infIntermed> Grupo de informações do Intermediário da Transação, contendo os elementos <CNPJ> CNPJ do Intermediador e <indCadIntTran> Nome do usuário ou identificação do perfil do vendedor no site do intermediador.

Olá pessoal, Acredito que alguém já deve ter passado por essa situação, consultar uma nota cancelada no Portal e não constar o evento de cancelamento. O que será que ocorreu? Primeiro é preciso saber se a nota em questão foi autorizada no ambiente de homologação ou de produção, pois se realizar a consulta no ambiente errado seremos informados que a nota não existe. Segundo, devemos sempre primeiro consultar na SEFAZ responsável pela autorização da nota. Exemplo 1: A UF se utiliza da SEFAZ-Virtual do RS, neste caso devemos primeiro consultar no Portal da SVRS - Notas Fiscais Eletrônicas. Depois consultar na SEFAZ da UF (caso o site da UF tenha a opção de consulta) e por fim no Portal Nacional da NF-e. Exemplo 2: A UF se utiliza da SEFAZ do Estado, neste caso devemos primeiro consultar no Portal da SEFAZ-Autorizadora, por exemplo: SEFAZ-SP. Depois consultar no Portal Nacional da NF-e. Lembre-se que existe um delay entre a SEFAZ responsável pela autorização da nota e o Ambiente Nacional.

Bom dia. O Projeto ACBr é Agente de Vendas Embarcadero, nossa consultora @aline garcia poderá lhe dar mais informações. Att.

Juliomar, o notebook que uso é relativamente novo. Nunca instalei o Delphi nele. É a primeira vez. Estou travando contato com o Delphi não pela primeira vez, pois já o conheço pelo fato de sempre ter acompanhado a área de tecnologia. Nossa empresa nem faturamento tem ainda, pois agora que está sendo registrada. Vi essa regra do faturamento. Nós estamos começando do zero e queando chegarmos a esse faturamento irrisório de U$ 5 mil ano (espero que muito antes de 12 meses de vida), vamos avaliar a compra. Nao uso cópia pirata de nada. Ou uso open source ou compro ou vou de SaaS. A propósito, quanto custa a licença?

Olá pessoal. Levanta aí que vamos falar da atualização do ACBr. Resolvemos criar esse tópico devido a muitas dúvidas relacionadas a isso e depois de um debate interessante sobre o assunto. Principalmente quando entra a questão de quando atualizar o programa no cliente. Na sua empresa, vocês devem entender que o Projeto ACBr tem uma forma de desenvolvimento própria. Vocês não precisam seguir o mesmo pra seu desenvolvimento porque os objetivos talvez sejam diferentes. Mas vamos entrar em detalhes depois... agora... A pergunta mais importante: Quando Atualizar o ACBr? Podemos resumir no seguinte: atualize o o mais frequentemente quanto possível. Mas a resposta completa vai depender da sua equipe, do tamanho da empresa e das alterações que foram disponibilizadas. A chave é que vocês devem se sentir como desenvolvedores do ACBr. O código é open-source e é também de vocês. Afinal, ele roda na sua aplicação e afeta seus clientes. Além disso, geralmente as funções que usamos do ACBr são cruciais no sistema. Mesmo que vocês sejam desenvolvedores que utilizam as libs ou o ACBrMonitore e, tenham a impressão que não se encaixam nesse perfil, os princípios delineados aqui podem ajudar. Como é o fluxo de desenvolvimento do ACBr? No Projeto ACBr, em especial no desenvolvimento dos componentes, nós usamos um fluxo de desenvolvimento que não é totalmente orientado a versões. Esse fluxo é algo mais parecido com o trunk based development do que com um GitFlow. Para quem vê de fora, isso significa basicamente: Controlamos a versão dos componentes via o versionamento do próprio SVN. Assim, podemos reproduzir qual versão uma pessoa tem instalada apenas sabendo a revisão do código que ela usa; Não ficamos criando branches para desenvolvimento de funções e recursos. Nós temos um repositório branches, mas não ficamos desenvolvendo recursos nos componentes atuais nele a menos que seja estritamente necessário (Por exemplo: um refactoring total do componente); Quem usa os componentes tem os novos recursos, correções, e respostas muito mais rapidamente do que teria de outra forma; Pra não delongar mais nisso (que não é o foco desse artigo), se quiser ver um exemplo de empresa que usa esse tipo de desenvolvimento, recomendo esse artigo "Moving away from GitFlow" (de Niklas Gray). Mas isso funciona pra nós em especial porque (a) quem usa os componentes também é desenvolvedor e (b) temos uma resposta muito rápida quando acontecem problemas. Assim, isso não significa necessariamente que vai funcionar na sua empresa. Voltando a pergunta importante... Como estabelecer uma rotina de avaliar se e quando deve ser feita a atualização do ACBr? Se vocês não tem nenhuma rotina pra avaliar quando e se devem atualizar o ACBr, sugerimos que estabeleçam uma. A princípio, sugerimos o seguinte: Leiam os logs do SVN pelo menos uma vez por dia. Não é preciso atualizar para ler o log. Basta usar o "Show Log" do SVN. Ao ler o log do SVN, verifique se: Alguma alteração feita afeta seus clientes em produção? (correção de bug, alteração de legislação, etc...) Algum novo recurso que você quer utilizar foi implementado? Se são poucas alterações e elas não são essenciais, você (ou alguém na sua equipe) tem tempo para testar? São muitas alterações que foram feitas? Já passou muito tempo desde que foi feita a última atualização? Por exemplo mais de 3 semanas? Caso a resposta a qualquer pergunta acima seja "sim", atualize e teste seu desenvolvimento. No mínimo você vai estar mantendo o código do seu aplicativo com o mínimo de alterações possíveis. Então quando surgir uma situação que vocês precisem atualizar com urgência, não vai haver uma grande quantidade de trabalho acumulado. Caso negativo, siga com as suas tarefas. É claro que, se vocês estão no meio de uma situação que precisa que todo o desenvolvimento fique focado no produto de vocês, talvez não seja possível atualizar o ACBr. Por exemplo, pode ser que um problema no software esteja exigindo a atenção urgente de toda equipe. Mas geralmente, pelo menos um dev deve conseguir dar uma lida nos logs e fazer a avaliação se é necessário ou não atualizar. Nota: Vale lembrar também que nem toda atualização precisa de uma reinstalação. Você precisa reinstalar quando: As alterações envolvem partes visuais dos componentes; Os fontes não são recompilados ao fazer um build em sua aplicação; Depois de atualizar, teste as partes de sua aplicação que usam os componentes modificados assim que possível. Primeiro na sua máquina de desenvolvimento, depois em outras máquinas. O último a ser atualizado é o servidor de Build. A partir daí já entra no "deploy", quer dizer, na entrega do software para o cliente. Como impactar da menor maneira possível meu cliente com meu software após atualização do ACBr? Gostaria de enfatizar que você precisa ter estratégias diferentes. Uma para quando você deve atualizar o ACBr (desenvolvimento) e uma para quando você deve atualizar o seu sistema no seu cliente (deploy). Tudo bem que as duas estratégias podem ser interligadas, como é o caso quando se usa um sistema de "Implantação Contínua". Mas são duas coisas diferentes que você precisa ter em mente. Para reduzir o impacto nos clientes, faça o "deploy" de forma escalonada. Quer dizer, instale a nova versão primeiro em clientes selecionados. A princípio, escolha apenas dois, três ou no máximo quatro. Quanto mais crítica a alteração, mais seletivo você precisa ser. Dentre sua carteira de clientes, minha sugestão é para escolher aqueles que: Precisam da "novidade" apresentada no novo executável Tem um movimento menor (e assim darão um grau menor de dor de cabeça caso algum imprevisto aconteça) Ficam mais próximos de sua empresa (posso deslocar um técnico ou até mesmo um "dev" pra lá rapidamente se realmente necessário, nem que seja virtualmente?) São mais pacientes e compreensivos (paciência nunca é demais, apenas cuide de não abusar deles) Só depois de um tempo de teste nesses clientes, envie a nova versão para os outros. Você pode continuar escalonando a entrega avaliando o tamanho da sua equipe e número de clientes que possui. De qualquer maneira você precisa avaliar o que é melhor pra sua empresa. Mas como decidir? Muitas questões devem ser levadas em conta. É verdade que ninguém deveria ficar desesperado para instalar uma nova versão se não teve condições de fazer testes. Também, antes de enviar uma versão aos clientes é preciso levar em conta a quantidade de clientes, o tamanho da equipe de desenvolvimento, da equipe de suporte e até o plano de negócios da empresa. Mas por outro lado, as seguintes perguntas precisam também ser analisadas: Só se envia uma nova versão ao cliente para resolver problemas? Não são apresentadas ao cliente os novos recursos como algo que facilita a vida dele? Não seria muito mais interessante comercialmente se o programa tivesse sempre novidades para cativar o usuário? Não será muito mais difícil encontrar e resolver um problema se de uma versão para outra houverem muitas alterações no código? Que controle se faz de versão do software que está instalado no cliente? Consegue-se facilmente reproduzir no ambiente de desenvolvimento? Sua equipe tem tamanho suficiente pra cuidar de várias versões diferentes? Temos certeza que a análise dessas questões vão ajudar vocês a tomarem boas decisões. Bom trabalho por aí.

Boa tarde a todos, Os Schemas referente a essa NT na compreende na verdade 2 novos tipos de eventos: Comprovante de entrega da NF-e e o de Cancelamento do Comprovante de entrega da NF-e, já se encontram no repositório. As datas de liberação são: 01/06/2021 - Ambiente de Homologação 22/06/2021 - Ambiente de Produção Para quem tem o habito de manter os fontes sempre atualizados, quando a SEFAZ liberar basta testar, pois o componente já esta com esses dois eventos implementados.

Olá Pessoal, Hoje disponibilizamos mais um componente, o ACBrPagFor. A funcionalidade que ele permite é automatizar a autorização de pagamentos em um banco. Por exemplo, automatizar o pagamento de fornecedores que tenham emitidos contra seu cliente boletos, títulos, etc... O componente gera o arquivo para indicar aos bancos que um pagamento pode ser feito. Essa funcionalidade, de modo geral, é chamada pelos bancos de "Pagamento de Fornecedores" (veja alguns links no final do artigo). Como o componente funciona? Esse componente gera um arquivo texto segundo o padrão CNAB 240 para pagamentos de fornecedores. Ele também é capaz de fazer a leitura do retorno, de modo que você pode saber o resultado. Ele já existia antes e estava em outro repositório do ACBr chamado Branches com o nome ACBrCNAB. Resolvemos trocar o seu nome ao migrar para o Trunk2, pois assim acreditamos que os desenvolvedores estão mais familiarizados com o termo PagFor utilizado por diversos bancos. Para que bancos? Ele não contempla todos os bancos nesse momento de lançamento, mas é um pontapé inicial. Os testes iniciais foram realizados com os bancos: Itaú, HSBC, Santander, Sicred e Banco do Brasil. Contamos com a colaboração da comunidade ACBr para torná-lo mais completo e robusto. Então fique a vontade implementar no seu sistema essa nova funcionalidade e para testar e colaborar com melhorias e correções. ------- Links para essa funcionalidade em alguns bancos: https://banco.bradesco/html/pessoajuridica/solucoes-integradas/pagamentos/pag-for.shtm https://www.santander.com.br/servicos-financeiros/solucoes-de-pagamento/pagamento-a-fornecedores https://www.sicredi.com.br/site/pagamentos-e-recebimentos/para-sua-empresa/pagamento-a-fornecedores/ https://www.caixa.gov.br/empresa/pagamentos-recebimentos/pagamentos/fornecedor/Paginas/default.aspx https://www.daycoval.com.br/para-empresa/servicos/pag-for

Bom dia a todos, Foi publicado a versão 1.20 da NT 2020/006 (16/03/2021) . O que mudou? Alteração em algumas regras de validação da SEFAZ e data de ativação tanto no ambiente de homologação quanto de produção. Veja como ficou as datas: Versão Descrição Homologação Produção 1.00 Criação de campos e Regras de Validação - seção 2 desta NT 01/02/2021 05/04/2021 1.10 Prazo de implantação desta NT v1.00 e v.1.10 para SV-AN, SP, MG e GO 01/03/2021 05/04/2021 1.10 Inclusão das regras YB01-10, YB01-20 e YB02-10 para modelo 65 01/03/2021 05/04/2021 1.10 Regra YA02-50 , observação 2 01/03/2021 05/04/2021 1.10 Regra B25c-10, observação 2 05/04/2021 01/09/2021 1.10 Regra Y08-90, observação a critério da UF 01/03/2021 05/04/2021 1.20 Regras YA02-60, YA06-10 e B25c-10, YA02a-10 e YA02a-20, inclusão do campo YA02a - xPag até 03/05/2021 01/09/2021 1.20 Regra YA02-50 foi eliminada até 03/05/2021 - Regra YA02-60 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o código do meio de pagamento (tag: tPag) existe na Tabela de códigos dos meios de pagamentos publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra YA06-10 que é aplicada tanto para NF-e quanto para NFC-e: Verificar se o Código da bandeira de cartão de crédito e/ou débito (campo: tBand) existe na tabela de códigos das operadoras de cartão de crédito e/ou débito publicada no Portal Nacional da Nota Fiscal Eletrônica Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção Regra B25c-10 que é aplicada tanto para NF-e quanto para NFC-e: Se Informado indicativo de presença, tag: indPres, IGUAL a 2, 3, 4 ou 9 - Obrigatório o preenchimento do campo Indicativo do Intermediador (tag: indIntermed) Observação 1: Regra válida a partir de 03/05/2021 (ou antes dependendo da SEFAZ-Autorizadora) para homologação e 01/09/2021 para produção. Regra YA02a-10 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento (tag: tPag) for preenchido com o código 99-outros, obrigatório o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02a-20 que é aplicada tanto para NF-e quanto para NFC-e: Quando o código do meio de pagamento for diferente 99-outros (tag: tPag<>99), proibido o preenchimento da descrição do meio de pagamento (tag: xPag) Regra YA02-50 que é aplicada tanto para NF-e quanto para NFC-e: Esse regra foi eliminada das regras de validação da SEFAZ no que se refere as Informações de Pagamento. Inclusão da tag <xPag> (opcional) dentro do grupo <detPag> Grupo de Detalhamento do Pagamento para atender as regras YA02a-10 e YA02a-20. O componente vai ser atualizado assim que foi publicado os novos schemas para atender a nova tag (xPag). Sendo assim fiquem atentos as atualizações dos fontes ACBr. Como vai ter alteração nos schemas se faz necessário atualizar os schemas nas maquinas dos seus clientes assim que eles estiverem disponíveis.