Painel de líderes

Olá! Recentemente houve a necessidade por parte de meus clientes de uma forma mais detalhada de auditoria de inserções, atualizações e deleções de informações. Depois de muita dedicação consegui uma estrutura de fácil manuseio para aqueles que utilizam o FireBird da versão 2.5 em diante. A auditoria é feita em uma database externa, dessa forma o banco de dados continua independente e não sofre uma expansão referente a esses dados. Fato importante é que o banco da empresa não é afetado com possíveis exceções provenientes do banco de auditoria, ou seja, caso algo dê errado externamente o fluxo de dados na empresa não é afetado. Segue procedimento: 1) Criar banco de dados para auditoria (LOGGERAL.FDB). 2) Criação das tabelas de auditoria, etc: CREATE GENERATOR GEN_LOGOPERACAO_ID; CREATE TABLE LOGOPERACAO ( CD_LOGOPERACAO BIGINT NOT NULL, DS_TABELA VARCHAR(31) NOT NULL, FG_OPERACAO CHAR(1) NOT NULL, CD_USUARIO VARCHAR(10) NOT NULL, DT_OPERACAO TIMESTAMP NOT NULL, DS_CHAVE VARCHAR(255) NOT NULL ); ALTER TABLE LOGOPERACAO ADD CONSTRAINT PK_LOGOPERACAO PRIMARY KEY (CD_LOGOPERACAO); SET TERM ^ ; /* Trigger: LOGOPERACAO_BI */ CREATE OR ALTER TRIGGER LOGOPERACAO_BI FOR LOGOPERACAO ACTIVE BEFORE INSERT POSITION 0 as begin if (new.cd_logoperacao is null) then new.cd_logoperacao = gen_id(gen_logoperacao_id,1); end ^ SET TERM ; ^ CREATE GENERATOR GEN_LOGDATA_ID; CREATE TABLE LOGDATA ( CD_LOGDATA BIGINT NOT NULL, CD_LOGOPERACAO BIGINT NOT NULL, DS_CAMPO VARCHAR(31) NOT NULL, DS_OLD VARCHAR(4000), DS_NEW VARCHAR(4000) ); ALTER TABLE LOGDATA ADD CONSTRAINT PK_LOGDATA PRIMARY KEY (CD_LOGDATA); ALTER TABLE LOGDATA ADD CONSTRAINT FK_LOGDATA_LOGOPERACAO FOREIGN KEY (CD_LOGOPERACAO) REFERENCES LOGOPERACAO (CD_LOGOPERACAO); SET TERM ^ ; /* Trigger: LOGDATA_BI */ CREATE OR ALTER TRIGGER LOGDATA_BI FOR LOGDATA ACTIVE BEFORE INSERT POSITION 0 as begin if (new.cd_logdata is null) then new.cd_logdata = gen_id(gen_logdata_id,1); end ^ SET TERM ; ^ Explicações rápidas: 1) A tabela LOGOPERACAO registra: qual tabela (DS_TABELA) passou por uma inserção (FG_OPERACAO = 'I'), atualização (FG_OPERACAO = 'U') ou deleção (FG_OPERACAO = 'D'), qual foi o usuário responsável (CD_USUARIO), quando ocorreu a operação (DT_OPERACAO), e qual foi a PK (DS_CHAVE) afetada. 2) Vocês vão perceber que nesse processo não importa quantas chaves primárias sua tabela tem, pois o código foi pensado para concatenar as chaves separadas por pipe ('|'). 3) A tabela LOGDATA armazena informações mais detalhadas sobre a LOGOPERACAO. Nesse caso seus registros contemplam qual foi o campo afetado na tabela (DS_CAMPO) apresentando seu valor antigo (DS_OLD) e o novo (DS_NEW). 3) Criação das procedures para auditoria no banco da empresa: SET TERM ^ ; create or alter procedure PROC_LOG ( DS_TABELA varchar(31) not null) as declare variable "TYPE" smallint; declare variable DS_CAMPO varchar(31); declare variable SQL varchar(32765); declare variable AUXOPERACAO varchar(255); declare variable DS_CHAVEAUX varchar(31); declare variable DS_CHAVENEW varchar(255); declare variable DLL blob sub_type 1 segment size 256; declare variable DS_CHAVEOLD varchar(255); begin if (user = 'BACKUP') then exit; sql = ''; ds_chavenew = ''; ds_chaveold = ''; auxoperacao = ''; dll = ''; for select upper(trim(F.RDB$FIELD_NAME)), FS.RDB$FIELD_TYPE from RDB$RELATION_FIELDS F left join RDB$FIELDS FS on FS.RDB$FIELD_NAME = F.RDB$FIELD_SOURCE where F.RDB$RELATION_NAME = :ds_tabela order by F.RDB$FIELD_POSITION into :ds_campo, :type do begin if ((:type <> 261) and (:ds_campo not in ('CD_USRINCALT', 'DT_INCALT'))) then /* IGNORAR 261 = BLOB */ begin sql = sql || ' if (new.' || :ds_campo || ' is distinct from old.' || :ds_campo || ') then' || ascii_char(13) || ' execute procedure proc_logdata(' || ascii_char(13) || ' :cd_logoperacao, ' || ascii_char(13) || ' ''' || :ds_campo || ''',' || ascii_char(13) || ' old.' || :ds_campo || ',' || ascii_char(13) || ' new.' || :ds_campo || ');' || ascii_char(13); end end auxoperacao = ' if (inserting) then fg_operacao = ''I'';' || ascii_char(13) || ' else if (updating) then fg_operacao = ''U'';' || ascii_char(13) || ' else if (deleting) then fg_operacao = ''D'';' || ascii_char(13); for select trim(I.RDB$FIELD_NAME) from RDB$RELATION_CONSTRAINTS RC join RDB$INDEX_SEGMENTS I on (I.RDB$INDEX_NAME = RC.RDB$INDEX_NAME) join RDB$INDICES IDX on (IDX.RDB$INDEX_NAME = RC.RDB$INDEX_NAME) where (RC.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY') and (RC.RDB$RELATION_NAME = :ds_tabela) order by I.RDB$FIELD_POSITION into :ds_chaveaux do begin ds_chavenew = ds_chavenew || 'new.' || :ds_chaveaux || '||''|''||'; ds_chaveold = ds_chaveold || 'old.' || :ds_chaveaux || '||''|''||'; end ds_chavenew = substring(ds_chavenew from 1 for char_length(ds_chavenew) - 7); ds_chaveold = substring(ds_chaveold from 1 for char_length(ds_chaveold) - 7); dll = 'CREATE OR ALTER TRIGGER LOG_' || :ds_tabela || ' for ' || :ds_tabela || ascii_char(13) || 'ACTIVE AFTER INSERT OR UPDATE OR DELETE POSITION 32767' || ascii_char(13) || 'as' || ascii_char(13) || ' declare variable fg_operacao char(1) = null;' || ascii_char(13) || ' declare variable cd_logoperacao bigint;' || ascii_char(13) || 'begin' || ascii_char(13) || auxoperacao || ascii_char(13) || ' if (:fg_operacao is null) then exit;' || ascii_char(13) || ascii_char(13) || ' if (:fg_operacao = ''I'') then' || ascii_char(13) || ' execute procedure proc_logoperacao(' || ascii_char(13) || ' ''' || :ds_tabela || ''',' || ascii_char(13) || ' ''I'',' || ascii_char(13) || ' ' || :ds_chavenew || ')' || ascii_char(13) || ' returning_values :cd_logoperacao;' || ascii_char(13) || ' else' || ascii_char(13) || ' execute procedure proc_logoperacao(' || ascii_char(13) || ' ''' || :ds_tabela || ''',' || ascii_char(13) || ' :fg_operacao,' || ascii_char(13) || ' ' || :ds_chaveold || ')' || ascii_char(13) || ' returning_values :cd_logoperacao;' || ascii_char(13) || ascii_char(13) || sql || ascii_char(13) || ' when any do' || ascii_char(13) || ' begin' || ascii_char(13) || ascii_char(13) || ' end' || ascii_char(13) || 'end'; if (sql <> '') then execute statement :dll; end^ SET TERM ; ^ SET TERM ^ ; create or alter procedure PROC_LOGOPERACAO ( DS_TABELA varchar(31) not null, FG_OPERACAO char(1) not null, DS_CHAVE varchar(255) not null) returns ( CD_LOGOPERACAO bigint) as declare variable SQL varchar(16384); begin sql = 'insert into logoperacao(' || 'ds_tabela, ' || 'fg_operacao, ' || 'cd_usuario, ' || 'dt_operacao, ' || 'ds_chave) ' || 'values(' || ':ds_tabela, ' || ':fg_operacao, ' || ':cd_usuario, ' || ':dt_operacao, ' || ':ds_chave) ' || 'returning ' || 'cd_logoperacao'; execute statement (:sql) ( ds_tabela := :ds_tabela, fg_operacao := :fg_operacao, cd_usuario := user, dt_operacao := current_timestamp, ds_chave := :ds_chave) on external 'c:\sysfire\loggeral.fdb' as user 'SYSDBA' password 'sys@#$' with common transaction into :cd_logoperacao; end^ SET TERM ; ^ SET TERM ^ ; create or alter procedure PROC_LOGDATA ( CD_LOGOPERACAO bigint not null, DS_CAMPO varchar(31) not null, DS_OLD varchar(4000), DS_NEW varchar(4000)) as declare variable SQL varchar(16384); begin sql = 'insert into logdata(' || 'cd_logoperacao, ' || 'ds_campo, ' || 'ds_old, ' || 'ds_new) ' || 'values(' || ':cd_logoperacao, ' || ':ds_campo, ' || ':ds_old, ' || ':ds_new)'; execute statement (:sql) ( cd_logoperacao := :cd_logoperacao, ds_campo := :ds_campo, ds_old := :ds_old, ds_new := :ds_new) on external 'c:\sysfire\loggeral.fdb' as user 'SYSDBA' password 'sys@#$' with common transaction; end^ SET TERM ; ^ Explicações rápidas: 1) A PROC_LOGOPERACAO insere os registros no banco externo na tabela LOGOPERACAO. 2) A PROC_LOGDATA insere os registros no banco externo na tabela LOGDATA. 3) A PROC_LOG gera automaticamente uma trigger para after insert, update e delete (na última posição possível 32767) em uma tabela que seja necessário a auditoria. Aqui não importa quais são os campos da tabela, a geração é autônoma e independe do tipo, tamanho, etc. 3.1) Caso a tabela possua campos tipo BLOB (261) eles serão ignorados. 3.2) Se for necessário auditar campos VARCHAR com tamanho superior a 4000 será necessário rever a criação da tabela LOGDATA e da procedure PROC_LOGDATA pois na forma atual esse é o limite (o maior campo da minha estrutura de dados possui 4000 posições, esse é o motivo da minha escolha). 3.3) Os campos CD_USRINCALT e DT_INCALT estão sendo ignorados pois fazem parte das minhas tabelas e não precisam ser auditados, retirar ou deixá-los no código não afetará em nada no funcionamento. Caso existam campos que você quer ignorar, faça a inserção manual no código, a mesma coisa para tipos de campos, atualmente apenas BLOB é ignorado (você pode pesquisar no fonte para ver os códigos referentes a outros tipos). 4) Na PROC_LOGOPERACAO e PROC_LOGDATA verificar o caminho do banco de auditoria, como teste está fixo c:\sysfire\loggera.fdb. Verificar também a senha do user master SYSDBA, pois a conexão com o banco externo será feita por ele. Após realizar os passos acima só será necessário escolher as tabelas que precisam ser auditadas e chamar a PROC_LOG para geração das triggers (o nome da tabela deve ser exato, com letras maiúsculas e minúsculas, caso seja informada uma tabela que não existe em sua database uma exceção é lançada). execute procedure PROC_LOG('nome_da_tabela'); A partir daqui qualquer tipo de insert, update e delete nas tabelas executas com a PROC_LOG vão gerar registros no banco de auditoria. Bom proveito, obrigado! Edit1: caso uma tabela que já está sendo auditada sofra alterações de campos (novos campos ou drop de campos antigos) é só fazer a chamadada mesma com a PROC_LOG que as triggers serão atualizadas automaticamente. Processo fácil e rápido para manutenção.

Conforme aviso na página da NFe, entre as 18:00 do dia 22/07/2022 e as 08:00 do dia 25/07/2022, a emissão da NFe deverá ser feita em contingência.

Confere e apaga a lista de NCM local ele deve de não ter limpo o arquivo e estar com algum antigo. ACBrNCM.json esse é o nome do arquivo que deve existir junto ao monitor

Corrigido no post.

Foram publicados ainda em versão beta, os leiautes da versão S-1.1 Beta do eSocial, os quais incorporam integralmente as evoluções previstas na Minuta da Nota de Documentação Evolutiva v. S-1.0 - NDE 02/2021 - Processo Trabalhista e parcialmente as previstas na Minuta da Nota de Documentação Evolutiva v. S-1.0 - NDE 01/2021 - IR sobre Rendimentos do Trabalho. No que se refere às informações relativas ao Imposto de Renda Retido na Fonte – IRRF (NDE 01/2021) a versão S-1.1 BETA incorpora apenas os ajustes necessários para a inclusão deste tributo na DCTFWeb[1]. Importante destacar que esta versão S-1.1 não contém todos os ajustes necessários para a substituição da DIRF, os quais serão incluídos em novo versionamento a ser oportunamente publicado. Implementação no ACBr Por ainda estar em Beta, significa ainda resta a oficialização do novo layout com decretos apropriados. Após isso nós tentaremos trabalhar nas alterações no componente ACBreSocial. Mas reforçamos que, como dito no acima, essa já deve ser considerada uma "versão de trabalho final para implantação". Assim, como sempre, convidamos a todos que usam o eSocial na comunidade e queira trabalhar nessa área para adequar os fontes e nos ajudar com a alteração. Agradecemos a todos desde já. Fonte: https://www.gov.br/esocial/pt-br/noticias/publicacao-da-versao-s-1-1-dos-leiautes-do-esocial

Conforme aviso na página da NFe, entre as 06:30 e as 16:00 do dia 31/07/2022, a emissão da NFe deverá ser feita em contingência. Obs. Apesar da lista de UFs que são atendidas pela SEFAZ-RS indicar um período maior citado acima, o aviso geral publicado na própria página da NFe, indica um prazo menor, oque leva a crer que a saída da contingência poderá ocorrer antes das 16:00. Importante: Em relação a emissão dos DFes nesse período, vale observar também as orientações sobre quais dfes deverão ser emitidos utilizando o SEFAZ Virtual de Contingência (Nacional ou de SP) e quais deverão ser feitos em modo offline.

Foi disponibilizada no site do Sistema Público de Escrituração Digital (SPED), a versão beta do programa validador da Escrituração Fiscal Digital (EFD-ICMS/IPI) - PVA-EFD-ICMS/IPI, no qual foi implementado o novo leiaute do bloco K, conforme publicado no Guia Prático, versão 3.1.0, com vigência a partir de janeiro/2023, sendo que esta versão não permite a assinatura e a transmissão de arquivos. (Download disponível no link: https://www.gov.br/receitafederal/pt-br/assuntos/orientacao-tributaria/declaracoes-e-demonstrativos/sped-sistema-publico-de-escrituracao-digital/escrituracao-fiscal-digital-efd/escrituracao-fiscal-digital-efd

Publicado em 24/06/2022 Foi publicada a nova versão 3.1.0 do Guia Prático e a Nota Técnica 2022.001 v1.1 com vigência a partir de janeiro/2023, com as seguintes alterações: 1. Descontinuação dos códigos 04 e 05 da tabela 4.1.2 – Tabela Situação de Documentos a partir de 31/12/2022 2. Inclusão dos registros 0221, C855, C857, C895, C897, D700, D730, D731, D735, D737, D750, D760 e D761 3. Inclusão da exceção nº 2 na validação do registro C800 4. Alteração da regra de validação do campo 06 do registro C170 5. Alteração da regra de validação do campo 09 do registro C800 6. Alteração da regra de validação do campo 02 dos registros C181, C330, C380, C430, C480, C815 e C880 7. Alteração da regra de validação do campo 06 do registro C185 8. Alteração do tamanho do campo 02 (15 para 60 caracteres) do registro C111 9. Alteração do tamanho do campo 03 (15 para 60 caracteres) dos registros E112, E230, E312 e 1922 10. Alteração do tamanho do campo 06 (15 para 60 caracteres) dos registros E116, E250, E316 e 1926 11. Inclusão de uma nova opção de indicador para o campo 02 do registro K010 Clique aqui para acessar a documentação Fonte : Nova Versão do Guia Prático da EFD ICMS IPI (rfb.gov.br)

Realizei a atualização para a última Lib do ACBrETQ disponível no SVN, no entanto, está gerando erro ao carregar a imagem e nem mesmo a imagem de exemplo disponibilizada está sendo carregada, acontece o mesmo erro. O Erro é o seguinte "Formato da imagem deve ser: PNG, BMP, GRF OU PCX e Monocromática." Estou utilizando a .DLL da lib em C#.

boa tarde a todos. Fiz alguns ajustes nas classes do demo da NFe.API, como: ajuste em nomes de properties pra ficar compativel com o ini da nfe. adição de metodos para leitura do arquivo ini da nfe remoção do nullable para properties do tipo enuma e nos fontes da lib ACBLibNFe.dll, adicionei o metodo para gravar a lista de autXml no ini da nfe, não existia. att DemosACBRLibC#.rar Fontes ACBRLibNFe.rar

Gabriel, Muito obrigado pelos arquivos, já inclui na minha lista de tarefas para analise. TK-2928

Boa tarde! Segue todos os arquivos. Separei em pastas os arquivos retornados na emissão e quando realizado a consulta do RPS. Anexei também os exemplos do próprio provedor, que condiz com o que o componente está salvando. Modelos Araxa.rar Arquivos retorno na emissão.rar Arquivos retorno consulta RPS.rar

DFe -> Impressão -> NFe -> [x] Imprime continuação dados adicionais primeira página.

sim é verdade, pra demostrar o funcionamento é excelente ! entendi como funciona ! agradecido todos pela atenção !

Boa tarde, Realmente dizer que o responsável por isso lá faz o básico é diminuir o básico a esse nível indescritível. Bom vamos la, contato com a SIGCORP no telefone (11) 4153-2945 / (11) 4063-9632 ou por e-mail [email protected]. Liguei no provedor e me pediram para enviar um e-mail para [email protected] descrevendo o "problema" e com os XMLs em anexo, fiz isso hoje agora pouco segue a mensagem que enviei. Boa tarde, Contribuinte da cidade de Avaré/SP CNPJ 08.299.736/0001-14 IM 23874. O problema é que as tags de datas que o WebService de voces retornam estão vindo com formato diferente dependendo do servico que utilizo ao consumir o WebService, as mesmas tags eu digo, veja o exemplo: Metodo gerar quando tento emitir uma NFSe unitaria com unico RPS vejas as tags com retornam: Data emissão da NFSe = <DataEmissao>2022-07-18T00:00:00</DataEmissao> Data emissão do RPS = <DataEmissao>2022-07-18</DataEmissao> Competência = <Competencia>20220718</Competencia> Em conformidade (com exceção da competência) com o manual da ABRASF. Agora quando faco uma consulta de NFSe pelo RPS veja as mesmas tags como retornam: Data de emissão da NFSe = <DataEmissao>28/06/2022</DataEmissao> Data de emissão do RPS = <DataEmissao>28/06/2022</DataEmissao> Competência = <Competencia>20220628</Competencia> É exatamente esse o problema, mesmas tags porem dependendo do servico do WebService que consumo elas vem no formato diferente, peco encarecidamente que adotem um padrão o da ABRASF mesmo de forma correta e na integra para tornar possivel utilizar o WebService de voces. Alem dessas tags acima citadas tambem a <DataHoraCancelamento>6/28/2022 1:43:58 AM</DataHoraCancelamento> esta vindo com formato diferente conforme o servico do WebService que consumo. Segue em anexo todos os XMLs de envio e retorno referentes ao problema descrito acima. Aguardo retorno desde ja obrigado. Foi isso agora vamos aguardar o retorno deles e mantenho vocês informado aqui nesse tópico.

Analisando os fontes aqui, o que acontece é que a primeira linha do campo mensagem não é considerado para geração do arquivo, pois seguindo um padrão da Febraban a primeira linha já é informada no registro normal. Se utilizar mais de uma linha provavelmente será gerado as mensagens no registro 2. Para quebrar linha use o caractere pipe "|" ex: Mensagem=|PROTESTAR NO 7º DIA UTIL APOS O VENCIMENTO |Cobrar juros de R$... ao dia | ... Nesse caso deve deixar desabilitado a configuração "ImprimirMensagemPadrao" e passar as mensagens manual no campo "Mensagem". Experimente dessa forma, provavelmente nunca foi usada essa funcionalidade nesse Banco. Vou verificar na documentação se é correto a impressão da primeira linha também nesse caso, se sim vamos precisar alterar isso para esse Banco.

Corrigido, só não consegui editar no post. Obrigado.

Boa tarde, Sem condições de fazer alguma coisa com esse provedor. Ao enviar o Rps para o WebService o mesmo gera e retorna o XML da NFS-e cuja a data de emissão da nota e do Rps estão no formato AAAA-MM-DD e a de competência: AAAAMMDD. Em conformidade (com exceção da competência) com o manual da ABRASF. Por outro lado ao consultar a nota por Rps o WebService gera e retorna o XML da NFS-e cuja a data de emissão da nota e do Rps estão no formato DD/MM/AAAA e a de competência: AAAAMMDD. A rotina que faz a leitura do XML da nota é uma só. Não tem como ela saber se a origem do XML é do envio ou de uma consulta. Quer resolver o problema? Inunda a prefeitura com protocolos de reclamação de problemas de geração da nota. Esse provedor não é composto por amadores e nem por estagiários e sim por pessoas que acham que sabem programar.

Boa tarde, Dado ao prazo para a entrada em vigor destas mudanças e as demais demandas que tem mais urgência, esta questão deve ser vista futuramente, mas ficaremos felizes caso a comunidade queira nos ajudar com estes ajustes. At.

entendi, mas compensa usar a versão paga então igual os clientes estão fazendo

@phulano bom dia, chegou aumentar tempo de timeout ? experimente colocar timeout 30000, veja se resolve. aparentemente webservices estão todos ok.

Gabriel, Já esta no SVN.

Bom dia, o NossoNumero é outro campo... é uma sequencia numérica de controle do Banco. O NumeroDocumento pode usar para seu controle, mas será retornado no mesmo campo no retorno do banco, como: "NumeroTituloBeneficiario". Se não retornar esse campo é só na consulta detalhada mesmo que vai trazer essa informação.

Fiz algumas correções na função TACBrETQZplII.ComandoCarregarImagem no arquivo Fontes/ACBrSerial/ACBrETQZplII.pas e agora está funcionando corretamente, vou deixar upado aqui caso alguém precisar. ACBrETQZplII.pas

@EliasCesar Só pra te posicionar. Teste realizado. E geração da cobrança do Pix em Produção funcionando perfeitamente. Obrigado.

Parece que ele quer o XML dentro do JSon... estou fora do PC..amanhã tento enviar um exemplo

As resoluções desses tipos de problemas dependem muito de diversos fatores como qual gerenciador de relatórios vocês estão usando, qual o sistema operacional, qual tipo de impressora, qual a configuração das margens, se há diferenças na visualização da tela e impressão, se estão utilizando um monitor High DPI ou imprimindo numa impressora considerada de valor DPI alto, etc... No entanto, como podem ver tem vários usuários utilizando corretamente os componentes. Sugiro verificarem na seguinte ordem: Se não for nenhuma dessas opções você pode ter encontrado alguma outra situação que ainda não conheço e por tanto, vai ser necessário debugar. Se estão usando o Fast Report, certifiquem que estão usando os arquivos fr3 mais novos; As margens configuradas: Como mostrado nos tópicos acima alistados, as margens agora são passadas em milímetros (mm). Por isso, pode haver alguma alteração. Caso usem o Fast Report, tentem também passando 0 para os valores das margens. Isso vai fazer o componente ignorar o valor e usar o que estiver configurado no fr3; Se estiver usando o Fortes Report, pode ser um problema relacionado ao DPI. Nesse caso, verifique as novas propriedades "AlterarEscalaPadrao" e "NovaEscala". Não sei qual valor vai ser necessário ser passado, mas tente com 96 DPI para começar.