maiconsaraiva

Pessoal, a Sefaz do Mato Grosso do Sul, já se manifestou. Segue mensagem encaminhada por um cliente do estado:

" Sugerimos que procure as demais UFs autorizadas para saber a posição destas. " Dá pra ver claramente, que até eles estão meio perdidos quanto a isso. rs Pessoal, não sei vocês, mas, não vejo isso com bons olhos. Assim como o PAF-ECF era burocrático e "fechado", estou especulando aqui que, em algum momento veremos uma movimentação semelhante para o rumo das DF-e's. Além disso, a Receita e Sefaz dos estados, depois de tentar fechar o cerco pra cima dos clientes, agora estão começando voltar seus olhos pra nós, pobres mortais. Não acredito que a finalidade será "inicialmente identificar consumo indevido". Tem coisa "preta" vindo por aí.

@EMBarbosa que ferramenta TOP. Parabéns por implementar no ACBr, e também por compartilhar exemplos de uso, isso vai ajudar muita gente.

Bom dia. No meu caso eu armazeno em dois campos: Em um eu armazeno o Nosso Número formatado (tal como é exibido no boleto), este campo eu uso mais para mostrar ao usuário. Tipo no BD: String(30) ; Em outro campo, eu armazeno o Nosso Número puro (sem nenhuma formatação) tal como o ACBr recupera, e é este que eu uso para localizar quando faço a leitura de retorno. Tipo no BD: String (mas poderia ser Bigint,, não recomendo usar Integer, pois ele pode crescer muito e ultrapassar a capacidade do Integer) Obs: O armazenamento dele eu mesmo quem controlo. Pego o "Próximo Nosso Número" na tabela de parâmetros de boleto, gero um novo boleto, mudo a sequência (incremento) e armazeno ela novamente no "Próximo Nosso Número" (ou em uma variável no caso de geração de múltiplos boletos, e gravo no BD ao final).

Perfeito. Vou verificar depois da reforma então. A depender de como ficar após ela, crio um tópico para fazermos uma votação. Obrigado.

Daniel, infelizmente não tenho como testar não. Mas, ao meu ver, a única mudança seria algumas propriedades, que ao invés de ficarem na ACBrTEDClass, ficaria na ACBrTEFDClassTXT. A classe é simples, a importância mesmo está ná ACBrTEFDClass, que é usada atualmente no TEF Banese. TACBrTEFDClassTXT = class( TACBrTEFDClass ) public constructor Create( AOwner : TComponent ) ; override; published property AutoAtivarGP ; property NumVias; property EsperaSTS; property ArqTemp ; property ArqReq ; property ArqSTS ; property ArqResp ; property GPExeName; end; constructor TACBrTEFDClassTXT.Create(AOwner : TComponent); begin inherited Create(AOwner); if Assigned( fpResp ) then fpResp.Free ; fpResp := TACBrTEFDRespTXT.Create; fpResp.TipoGP := Tipo; end; Mas, se você preferir, deixamos, e se pegar algum cliente com este TEF, faço os testes.

Bom dia Daniel, certo. Posso alterar aqui e submeter para análise e mesclagem? Mesmo que pouca gente use?

Boa tarde moderadores. Estou fazendo umas implementações dinâmicas e em uma delas verifico qual o tipo de comunicação do TEF (Troca de Arquivo ou Dedicado). Pelo que pude perceber, todos que são via troca de arquivo, a classe herda de "TACBrTEFDClassTXT" que por sua vez herda de "TACBrTEFDClass". O TEF Banese porém, é o único que está diferente. Pelo que pude perceber, ele funciona via troca de arquivos mas herda diretamente de "TACBrTEFDClass". Neste caso não deveria e/ou poderia herdar de "TACBrTEFDClassTXT"? Acredito que ficaria padronizado de forma correta e não impactaria em nada o desenvolvimento existente, além de servir para a verificação que estou fazendo e possivelmente outros membros podem querer fazer. Se puder, e realmente for troca de arquivo, me disponho a alterar e subir aqui para análise. (Só não o fiz ainda, por que nunca usei Banese e não sei se está assim por algum motivo específico.)

Olá o Tópico é antigo, mas este mês (Fevereiro/2019) homologuei com a SoftwareExpress tanto com CliSiTef DLL quanto com gpTefDial (usando o GP Client Modular ). Na homologação com GP Client Modular, segundo o pessoal a SoftwareExpress, no caso de multiplos cartões é opcional o envio da confirmação a cada cartão passado. Porém, por conta da implementação do ACBr mencionada, no meu PDV acbaou ficando a confirmação a cada cartão. Particularmente, eu preferia enviar a confirmação somente após passar todos os cartões, pois se for necessário cancelar por algum motivo, e algum cartão já tenha sido aprovado, não precisaria ter que informar a senha do operador, ler o cartão do cliente novamente, e imprimir o comprovante (uma vez que a transação já estaria conformada). Alguém considera interessante reavaliar esta mudança no Componente? Pelo visto, SoftwareExpress e Tef Direção já funcionariam desta forma (Confirmando somente após passar todos os cartões.)

Pessoal sei que o tópico é um pouco antigo, mas os conflitos são atuais. rs Como vocês estão fazendo nos seus softwares? Vocês deixam o preenchimento a critério do cliente, e enviam o CST do PIS e COFINS exatamente como preenchido no cadastro para o XML da Nota? Se sim, são válidados normalmente, mesmo no caso de NF-e, NFC-e e SAT?

Olá, tenho interesse. Faz algum desconto?

Bom dia pessoal! Gostaria de sugerir um ajuste que fiz na unit ACBrNFeNotasFiscais.pas, método ValidarRegrasdeNegocios. Nas mensagens de validações dos itens, eu adicionei o complemento: [nItem: '+IntToStr(Prod.nItem)+']', tanto no GravaLog quanto no AdicionaErro. Este complemento permite identificar de forma fácil em qual item está o problema, principalmente de notas com muitos itens. Eu vi que em algumas validações já tinham algo parecido, mas usando o índice "i" ao invés do nItem. Eu também alterei estes colocando o nItem, acredite que fique mais preciso e compatível com a o nItem no banco de dados/aplicação (caso estejam em ordem diferente ao índice do ACBr). Segue o arquivo em anexo. Desde já agradeço. ACBrNFeNotasFiscais.pas

Olá @gralak valeu pela dica, no meu caso acabei fazendo por INI mesmo.

A quem interessar, o Daniel, sugeriu uma sugestão neste link:

Pessoal, sei que já faz tempo. Mas precisei Homologar o Boleto do BNB aqui e me peguei nesta questão. Notei que não foi adicionado aos arquivos FastReport no SVN do projeto. Como ficou esta questão? Obs: Vi que se eu colocar apenas "21" na alimentação do ACBrBoleto ao invés do "4' como o colega exemplificou acima, dá certo (por que internamente o ACBr faz alguns tratamentos ), mas não seria o método correto (poderia ter problemas se novas implementações fossem efetuadas, sendo que "21" não é o Código da Carteira, e sim o "4", e deveria então ser feita a adaptação, tal como a sugerida para o FastReport (não sei se fui bem claro). Gostaria de saber como os colegas tem conseguido resolver esta questão, e a opinião da Juliana.