Painel de líderes

Olá pessoal, Gostaria da opinião de vocês com relação a nomenclatura dos enumeradores dos provedores. O componente ACBrNFSeX atende por volta 110 provedores dentre deles temos provedores que seguem a versão 1 do layout da ABRASF outros seguem a versão 2 e temos os que possuem o seu layout próprio. No inicio fomos definindo os enumeradores em função do seu nome e depois acabamos descobrindo que existem provedores que tem webservice tanto na versão 1 quanto na versão 2 do layout da ABRASF e outros que tem um webservice para o layout próprio e outro para o layout da ABRASF. Sem contar com alguns provedores que tem variações na mesma versão como é o caso do Provedor Pronim que tem na versão 2 a varia~]ao 2 e 3, ou seja, proPronim_202, proPronim_203. A minha sugestão é padronizar a nomenclatura. Todos os provedores que seguem a versão 1 do layout da ABRASF passariam a ter no final do seu nome "_100a", por exemplo: proGinfes_100a Isso deixa claro que o provedor Ginfes segue a versão 1 do layout da ABRASF. Os que seguem a versão 2 passariam a ter no final do seu nome "_200a", ou "_202a" ou "_204a" dependendo da variação. Já os provedores que tem layout próprio passariam a ter no final do nome "_100p", pro exemplo o provedor Equiplano passaria ter o enumerador: proEquiplano_100p. Note que se tratando de provedor que possui um layout próprio tem no final do seu nome a letra "P" em minúscula que significa Próprio. Já os provedores que seguem a ABRASF passariam a ter no final do seu nome a letra "A" em minúscula que significa ABRASF. O que vai ocorrer com as aplicações caso venhamos a tomar essa medida: As aplicações que usam os enumeradores como tomada de decisão vai ocorrer quebra de código, consequentemente seja necessário fazer o ajuste necessário para voltar a compilar. Por exemplo: If Provedor = proGinfes then Ocorreria erro de compilação uma vez que o enumerador foi alterado. Correção: If Provedor = proGinfes_100a then Quero deixar claro que essa alteração não foi feita, estou apenas compartilhando com vocês a minha intensão de realizar essa padronização na nomenclatura dos enumeradores dos provedores. Quero a opinião de vocês.

Deixa só eu verificar se o Zera poderia interromper as impressões, em alguns equipamentos... pode ser mais seguro, envia apenas um Fonte Normal </fn>

Italo acabei de fazer um teste aqui e funcionoum vou passar para a minha área de testes do sistema para mais testes e retorno o mais breve possível...

Fiz um pequeno ajuste aqui na procedure GerarFechamento, onde acrescentei a linha(733) FPosPrinter.Buffer.Add('</zera>') para limpar do cache a fonte condensada ao final cada impressão para que não prejudique algum outro documento de impressão direta que venha na sequência. Um exemplo é o relato nesse tópico ... https://www.projetoacbr.com.br/forum/topic/64238-impressão-escpos/ ACBrSATExtratoESCPOS.pas

No XML os campos tem nome diferente para o Layout S1.0 em relação as anteriores. Obrigado *Em outros registros a prática tem sido adicionar propriedades com os novos nomes

Boa tarde, desculpem pela demora no retorno. Após a atualização dos fontes com a revisão 22800 o boleto passou a ser gerado com os dizeres Beneficiário Final no local de Sacador/Avalista. Gostaria de agradecer a todos pela atenção e retorno! Att, Sérgio Generoso

Se partirmos da premissa, que o </zera> deveria estar no inicio de todo relatório, o problema não ocorreria... Eu não vejo (muitos) problemas em adicionar um </zera> no final do relatório... Poderíamos ter algum efeito colateral, em alguns equipamentos, pois a impressora poderia ainda estar imprimindo, quando o comando Zera fosse executado, e isso abortar a impressão... Mas o mesmo problema poderia ocorrer em todos os demais relatórios Fisciais, em EscPos, como a DANFCe

Sim, estou vendo o novo componente. Do mesmo jeito o arquivo ini está sendo configurado para o municipio de Votuporanga/SP como ginfes. E eles não utilizam esse modelo mais. Agora e esse RLZ informatica que não temos nem o provedor para esse layout. Que por sinal ficou bem melhor esse novo componente da NFS-e. Hoje tem o provedor RLZ mas não tem nada haver com o que o municipio em questão.

se quiser podemos conversar após a reunião de hoje. mas acho que poderia ter apenas o enumerador de provedor, e um sub de controle de versão do DFe. viso que um provedor pode ter os 3 casos versão 1 e 2 e próprio por exemplo, ai teria 3 enumerados de provedor;

Boa tarde, Esse provedor esta complicado, pois dependendo da cidade ou da versão o retorno do webservice é diferente, hora retorna somente um resumo, hora retorna o XML completo da NFS-e Precisamos definir corretamente o retorno para as versões: IPM, IPM_110 e IPM_120.

Comentário adicional: Essa sugestão, realmente serve apenas se você utiliza a arquitetura "Super Sever". Para as arquiteturas "Classic Server" ou "Super Classic" não é necessário nenhuma configuração. Na verdade, se você precisa de mais de um core, é provável que você precise mudar para uma dessas outras arquiteturas. Fonte: https://firebirdsql.org/manual/qsg25-appx-architectures.html

Túlio, Já esta no SVN.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 22999. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado. Tópico relacionado nesse link.

Bom dia, Recebemos a balança Digitron_UL para ajustar um erro ao pesar com a utilização da tara. Foi ajustado dentro da rotina InterpretarRepostaPeso, adicionando a tratativa da resposta que está retornando com 'E' (implementado na linha 107 da ACBrBALDigitron_UL.pas). Arquivo para validação em anexo. ACBrBALDigitron_UL.pas

A alteração é semelhante a que recebemos nesse link aqui. Isso só confirmou a necessidade da alteração. Agradecemos a contribuição. Subi as alterações para o SVN na Revisão 22999. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado. Moderação: Como os tópicos são semelhantes, estou fechando esse. Por favor dê qualquer retorno no tópico mencionado:

Boa tarde, galera. Tive que fazer uma mudança pequena na procedure LimpaRegistros do arquivo "ACBrECDBloco_I_Class.pas", adicionando uma linha para limpar o registro i500 que não estava sendo limpo, com isso se gerasse o arquivo 2x em sequência, dava erro no I500. Se vocês puderem analisar ai e adicionar para não dar problema para outras pessoas. Obrigado! Segue em anexo o arquivo com a mudança, e a imagem do que adicionei. ACBrECDBloco_I_Class.pas

No svn #TK-1920

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn

Qual o tamanho da base? Eu sempre considerei isso normal por ser a primeira consulta, o SGBD precisa carregar o arquivo do SO, que pode demorar dependendo do tamanho.

Minha sugestão, evite o uso do with no seu código, o code complete fica perdido e é ruim pra debugar. Minha implementação do C175: var RC175: TRegistroC175; [...] for I := 0 to Length(FRegistroAnaliticoNFCeArray) - 1 do begin RC175 := SPED.Bloco_C.RegistroC175New; RC175.CFOP := IntToStr(FRegistroAnaliticoNFCeArray[I].CFOP); RC175.VL_OPR := FRegistroAnaliticoNFCeArray[I].ValorTotal; RC175.VL_DESC := FRegistroAnaliticoNFCeArray[I].ValorDescontos; RC175.CST_PIS := StrToCstPis(FRegistroAnaliticoNFCeArray[I].CSTPIS); RC175.VL_BC_PIS := FRegistroAnaliticoNFCeArray[I].BaseCalcPIS; RC175.ALIQ_PIS := FRegistroAnaliticoNFCeArray[I].AliquotaPIS; [...] Está pegando a função de mesmo nome da EFD ICMS/IPI, unit ACBrEFDBloco_C.pas: /// Registro C175 - OPERAÇÕES COM VEÍCULOS NOVOS (CÓDIGO 01, 55) TRegistroC175 = class private fIND_VEIC_OPER: TACBrIndVeicOper; /// Indicador do tipo de operação com veículo: 0- Venda para concessionária; 1- Faturamento direto; 2- Venda direta; 3- Venda da concessionária; 9- Outros fCNPJ: String; /// CNPJ da Concessionária fUF: String; /// Sigla da unidade da federação da Concessionária fCHASSI_VEIC: String; /// Chassi do veículo public property IND_VEIC_OPER: TACBrIndVeicOper read FIND_VEIC_OPER write FIND_VEIC_OPER; property CNPJ: String read FCNPJ write FCNPJ; property UF: String read FUF write FUF; property CHASSI_VEIC: String read FCHASSI_VEIC write FCHASSI_VEIC; end;

Nesse caso você não usa o cancelamento normal, e sim o cancelamento por substituição, nesse cancelamento o prazo é de 168 horas, e você precisa informar a chave da NFCe emitida em contingência que substituiu.

Você pode gerar novamente o XML, corrigindo o NCM errado, assinar novamente, e enviar. Alterar um NCM não vai alterar a chave de acesso, isso realmente não pode.

Olá pessoal, Já está no SVN, uma nova classe de Impressora para o componente ACBrPosPrinter, com o intuito de suportar as impressoras da Marca Italiana CUSTOM A Custom chegou no Brasil, através da compra da Nitere... então você poderá achar drivers e especificações dessa impressora, no site da Nitere O Site da própria Custom Itália, é mais completo: http://custom4u.it mas para utilizá-lo você deve fazer um Cadastro (gratuito) e conhecer o "part number" dos equipamentos Para descobrir o "Part Number", entre no site comercial da Custom, como por exemplo, a página da Q3X repare nos números em negrito no final da página... Copie esses números (911FF...) e cole no Edit principal, da página de Drivers da Custom .... (confuso não ?) Muito em breve, devemos fazer um relatório de testes, da Q3X, e disponibilizá-lo na área de equipamentos testados. A Custom usa um protocolo próprio, semelhante ao Epson Esc/Pos, mas não idêntico... Ele é chamado de CustomPos, por esse motivo, você deve configurar o ACBrPosPrinter usando o novo modelo: ACBrPosPrinter1.Modelo := ppCustomPos (A Unit ACBrEscCustomPos.pas, implementa a classe TACBrEscCustomPos) ATENÇÃO: Não use o comando de programação de Logo Tipo do ACBrPosPrinter, com essa Impressora... Notamos um sério Bug no Firmware da versão 3.04... o comando de programação de Logotipo, compatível com o modelo Epson Esc/Pos (ppEscPosEpson), pode danificar o Software Básico desse equipamento... Na classe "TACBrEscCustomPos", esses comandos serão ignorados (sem efeito)... porém se você se comunicar com essa impressora, usando a classe TACBrEscPosEpson, e tentar Programar um logotipo, poderá danificar o seu equipamento. Já notificamos o fabricante desse problema, e estamos trabalhando em uma solução em conjunto...

Segundo ouvi dizer do pessoal da certificadora isso será apenas mais uma opção à assinatura digital, mas ainda está fase de testes e está dando muitos problemas, tanto que só a Certisign está vendendo e sem ao menos explicar direito como funciona. Acredito que para NFC-e perderá a funcionalidade da emissão em off-line. Acho precoce se preocupar com isso agora, mesmo porque só empresas grandes com muitos pontos de acesso que optarão por isso, ou não.