sismais

Show. Vou colocar então parametrizável via sistema. E deixar especificado que em alguns estados a impressão pode ser obrigatória. Obrigado pessoal.

Olá pessoal, tudo bem? Sabem me dizer se no TEF, a impressão do comprovante é opcional? Na maquininha POS comum é, mas no TEF, pelo menos na última homologação que fiz não falava se podia ou não. Um cliente perguntou, da possibilidade, fiquei na dúvida também. A ideia seria por exemplo, pergunta se deseja imprimir ou não assim que a venda for finalizada.

Obrigado pelo retorno. Como estava corrido, acabei contornando pela minha aplicação. Mas vou deixar como tarefa aqui, e faço assim que tiver um tempinho. Sobre as suas perguntas: 1. Sim, ocorre, tanto que, no método LePeso, o timeout funciona normal. O problema ocorre no SolicitarPeso que fica logo acima de LePeso. Pelo que entendi, parece funcionar de forma assíncrona, enviando o comando no SolicitarPeso, e depois pegando a resposta no LePeso. Sendo este o caso, o TimeOut está implementado apenas no LePeso. 2. Certo, farei essa checagem também;

Olá pessoal, tudo bem? Estou tendo um erro problemático em um cliente que acabou de instalar o TEF Sitef (via Dll). Modelo PinPad: Igenico IPP320 (fornecido pela Cielo) Conexão: USB A configuração aparenta estar OK, e comunicação com o PinPad também. Envio carga de atualização das tabelas no PinPad e vai normal. Porém, ao passar um cartão, no momento que o cartão é inserido, aparece esta menssagem: A98 - [0137-007] Já entrei em contato com a Skytef (que instalaram o Servidor TEF) e aparentemente a configuração do TEF está Ok, e o problema está vindo do PinPad. No meu PDV, não há nenhum retorno de erro, apenas a mensagem: "Aproxime, insira ou passe o cartão na leitora...". Ou seja, continua aguardando a inserção do cartão. Já testamos dois PinPads diferentes (ambos do mesmo modelo). Eu tenho um PinPad para testes e homologação do mesmo modelo (mas direto da Igenico), e funciona normalmente. Alguém já passou ou teria ideia do que pode ser este erro? Desde já agradeço muito.

Obs: Eu sei que, alterando o componente é possível, mas não sei até que ponto isso iria interferir em quem já usa atualmente, e seu eu poderia fazer e subir os fontes para integração ao fonte oficial.

Olá pessoal, tudo bem? Já uso ACBrBAL (balança de checkout) há um tempo, e funciona bem, porém algo está me intrigando e gostaria de saber se pode ser melhorado no componente. Atualmente, na leitura de peso (seja chamando o LePeso() ou programando no evento OnLePeso), se houver problemas de TimeOut retorna o peso "-9" indicando problemas na comunicação. Porém, em dado momento, ocorre a Exception de TimeOut (em vez de retornar o "-9"). Adentrando no componente, verifiquei que o problema ocorre no ponto abaixo: -> function TACBrBALClass.LePeso(MillisecTimeOut: Integer): Double; --> procedure TACBrBALClass.SolicitarPeso; ---> procedure TACBrDevice.EnviaString(const AString: AnsiString); -----> procedure TACBrDeviceSerial.EnviaString(const AString: AnsiString); Linha 578 (ACBrDeviceSerial.pas): BytesSent := fsSerial.SendBuffer(Pointer(Buffer), BytesToSend); Nessa linha ocorre este erro: Estou fazendo testes usando o Emulador de Balança do ACBr (e um par de portas seriais virtuais). Para conseguir simular esse erro, eu fecho emulador e aciono a leitura no meu PDV. Quero simular situações onde há falhas na comunicação com a balança. Eu vi que, dentro do método LeSerial() que é chamado em TACBrBALClass.LePeso(MillisecTimeOut: Integer), o tratamento de TimeOut e retorno do "-9" é feito como esperado, mas no "SolicitarPeso", que é acionado também dentro do LePeso(), esse tratamento não é feito. No início, imaginei que fosse algo com as portas seriais virtuais, até que ocorreu em um cliente. Uma outra observação que fiz também foi: Não ocorre na primeira vez que aciono a leitura, e sim lá pela terceira em diante. (nas primeiras ela passa por esse método sem erro e retorna o código -9, quando aciona o LeSerial(). A minha dúvida é, seria possível tratar para que retorne também o código/peso "-9" em vez de gerar uma Exception? Não sei se consegui explicar corretamente. Desde já agradeço.

Esse exemplo do @Solivan é sensacional. Acredito que seja a melhor maneira de implementar.

Então, eu também fiquei me perguntando, mas como a "vBC" estava preenchida, achei estranho. Obtendo o percentual a partir da vBC, ele deveria ser 61,11 (tal como o pRedBCST). Por isso, imaginei que de fato, o fornecedor tenha preenchido errado. De qualquer forma é bom saber que existe a possibilidade dos 100%. Obrigado!

Pessoal, perdoem minha desinformação, mas, é possível se aplicar 100% de Redução na BC do ICMS? (Tag pRedBC do grupo Imposto.ICMS) Falo isso, por que percebi um problema recente em uma Nota Fiscal que um cliente recebeu de um Fornecedor, e o pRedBC estava em "100". E o pior, ainda assim a BC não estava zerada. Segue o print da parte específica no XML: Alguém já viu algo assim? Eu acredito que o fornecedor tenha preenchido a informação errada, mas como o tema "Fiscal" é do tamanho do mundo aqui no Brasil, resolvi pesquisar antes. Desde já agradeço.

Na verdade, a minha interpretação da mensagem é que ela estava acusando uma tag de ser inválida, e em seguida dá sugestões de outra tag disponível (que é a vICMSSubstituto). Eu interpretei errado ou a Sefaz não deixou muito claro. O problema realmente era do lado da Sefaz mesmo. Para tentar resolver, fiz o teste do colega do outro tópico, e, ativando a propriedade "ForcarGerarTagRejeicao938" agora foi autorizada normal. Muito obrigado! Só para eu entender melhor, a única tag a ser tratada pela propriedade "ForcarGerarTagRejeicao938 " é "vICMSSubstituto", correto?

Segue erro completo, com cStat: Segue XML em anexo: 29190511824118000150550030000000081000000084-nfe.xml

@EMBarbosa então, na Geração e Validação local passa normal, essa rejeição ai está vindo da Sefaz. O lote enviado que está sendo rejeitado. O Schema está atualizado, será que de fato não é algo na Sefaz mesmo?

Obs: Aparentemente, a propriedade "ForcarGerarTagRejeicao938" só está tratando a tag "vICMSSubstituto".

Olá, como o título do tópico é relacionado, escrevo aqui também. Estou tendo um erro contrário ao do colega, no meu caso eu não poderia gerar essa Tag, aqui na Bahia, mesmo com "ACBrNFe.Configuracoes.Geral.ForcarGerarTagRejeicao938 := ftgNunca" e não alimentando a tag, ela está sendo gerada. Ao transmitir para Sefaz BA (Bahia, que usa o SVRS), diz que o Schema do XML é inválido (localmente valida normal com o Schema atualizado). Rejeição: Rejeicao: Falha no schema XML - The element 'ICMSSN500' in namespace 'http://www.portalfiscal.inf.br/nfe' has invalid child element 'vICMSSTRet' in namespace 'http://www.portalfiscal.inf.br/nfe'. List of possible elements expected: 'vICMSSubstituto' in namespace 'http://www.portalfiscal.inf.br/nfe'. Linha: 1; Coluna: 2070. Notamos que, no código do "pcnNFe.pas" abaixo, não está sendo feito uma verificação tal como como a função "OcorrenciasVICMSSubstituto" (que checa o valor de ForcarGerarTagRejeicao938); csosn500 : begin //10g if (nfe.Ide.indFinal <> cfConsumidorFinal) and (nfe.Ide.modelo = 55) then begin Gerador.wCampo(tcDe2, 'N26', 'vBCSTRet ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vBCSTRET, DSC_VBCSTRET); if (NFe.infNFe.Versao >= 4) then begin Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N26.1', 'pST', 01, IIf(FUsar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pST, DSC_PST); // Algumas UF estão exigindo o campo abaixo preenchido mesmo quando for zero. Gerador.wCampo(tcDe2, 'N26b', 'vICMSSubstituto', 01, 15, OcorrenciasVICMSSubstituto, nfe.Det[i].Imposto.ICMS.vICMSSubstituto, DSC_VICMSSUBSTITUTO); end; Gerador.wCampo(tcDe2, 'N27', 'vICMSSTRet', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vICMSSTRET, DSC_VICMSSTRET); end; if (NFe.infNFe.Versao >= 4) then begin if (nfe.Det[i].Imposto.ICMS.vBCFCPSTRet > 0) or (nfe.Det[i].Imposto.ICMS.pFCPSTRet > 0) or (nfe.Det[i].Imposto.ICMS.vFCPSTRet > 0) then begin Gerador.wCampo(tcDe2, 'N27a', 'vBCFCPSTRet', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vBCFCPSTRet, DSC_VBCFCPST); Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N27b', 'pFCPSTRet', 01, IIf(FUsar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pFCPSTRet, DSC_PFCPSTRET); Gerador.wCampo(tcDe2, 'N27d', 'vFCPSTRet ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vFCPSTRet, DSC_VFCPSTRET); end; if (nfe.Det[i].Imposto.ICMS.pRedBCEfet > 0) or (nfe.Det[i].Imposto.ICMS.vBCEfet > 0) or (nfe.Det[i].Imposto.ICMS.pICMSEfet > 0) or (nfe.Det[i].Imposto.ICMS.vICMSEfet > 0) then begin Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N34', 'pRedBCEfet', 01, IIf(FUsar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pRedBCEfet, DSC_PREDBCEFET); Gerador.wCampo(tcDe2, 'N35', 'vBCEfet ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vBCEfet, DSC_VBCEFET); Gerador.wCampo(IIf(FUsar_tcDe4,tcDe4,tcDe2), 'N36', 'pICMSEfet', 01, IIf(FUsar_tcDe4,07,05), 1, nfe.Det[i].Imposto.ICMS.pICMSEfet, DSC_PICMSEFET); Gerador.wCampo(tcDe2, 'N37', 'vICMSEfet ', 01, 15, 1, nfe.Det[i].Imposto.ICMS.vICMSEfet, DSC_VICMSEFET); end; end; end; Já revisei, e acredito que fiz tudo certo.

Estamos com essa mesma dúvida, como os colegas estão fazendo? Armazenando um valor médio?

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?