sismais

29 Setembro, 2021

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.

29 Setembro, 2021

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.

8 Junho, 2021

Em 25/05/2021 at 16:35, EMBarbosa disse:

   Boa tarde.

   Boa análise... Muito obrigado. Isso facilita bastante pra gente poder dar um parecer. Vamos lá...

   De certa maneira, acredito que você tenha razão. Se o TimeOut está ocorrendo aí, então está faltando mesmo um tratamento para o retorno.

   Mas o tratamento não poderia ser feito no "SolicitarPeso", porque esse método não tem retorno.

   Teria que ser feito nos outros métodos que chamam esse "SolicitarPeso, como "LePeso" e "AguardarRespostaPeso".

   Você pode alterar e anexar aqui para que possamos avaliar sim.

   Vou pedir pra você apenas ficar atento ao seguinte:

   1) Seria bom verificar no log se o timeout está mesmo ocorrendo.

   2) fazer o ajuste apenas na classe TACBrBalClass vai ajustar a maioria dos modelos, mas alguns sobrescrevem esses métodos (em especial LeSerial e LePeso) e assim pode ser necessário um ajuste na classe delas.

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;

26 Maio, 2021

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.

19 Maio, 2021

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.

19 Maio, 2021

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.

4 Maio, 2020

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

14 Novembro, 2019

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!

13 Novembro, 2019

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.

22 Maio, 2019

1 hora atrás, EMBarbosa disse:

A validação pela Sefaz RS também passou normal. Mais uma vez acho que o problema é local.

Veja também esse tópico:

Se em todo o caso você continuar achando que o problema não é local, acho melhor você entrar em contato com a sefaz da BA.

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?

21 Maio, 2019

Segue erro completo, com cStat:

Citar

Lote de Notas não enviado ou rejeitado totalmente:
cStat = 215 - 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.

Segue XML em anexo:

29190511824118000150550030000000081000000084-nfe.xml

21 Maio, 2019

2 horas atrás, EMBarbosa disse:

Olá maicon,

Eu acredito que é um erro no seu arquivo schema local. Note que o campo vICMSSTRet é obrigatório em todas as menções dele na NT 2018.005.

Sim. A princípio ele foi o único campo que gerou problema nessa rejeição específica (938).

@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?

21 Maio, 2019

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

21 Maio, 2019

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.

7 Maio, 2019

7 horas atrás, Leonardo de Alice disse:

Legal @adilsonpazzini, mas eu fiquei com outra dúvida.

No link da TecnoSpeed ele diz que o vICMSSubstituto deve receber o vICMS da nota de entrada, mas eu não vejo sentido nisso, porque eu posso comprar 10 unidades de meu fornecedor e fazer 5 vendas de 2 unidades, para clientes diferentes.

Outra coisa, a empresa pode ter comprado de mais de um fornecedor, com alíquotas diferentes. Deve ser feita uma média? Ou pegar a última?

Tá bem complicado entender o que a SEFAZ quer.

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

25 Fevereiro, 2019

Pessoal, a Sefaz do Mato Grosso do Sul, já se manifestou.

Segue mensagem encaminhada por um cliente do estado:

Citar

Assunto: Obrigatoriedade de Identificação do Responsável Técnico

Mensagem:Em conformidade com a Not a Técnica 2018.005, vesão 1.10, no Estado de Mato Grosso do Sul será obrigatório o preenchimento pelo Responsável Técnico do Software Emissor de NF-e/NFC-e do GRUPO ZD (ID: ZD01 a ZD06).
Os campos que serão de preenchimento obrigatório são:

CNPJ: Informar o CNPJ da pessoa jurídica responsável pelo sistema utilizado na emissão do documento fiscal eletrônico;

xContato: Informar o nome da pessoa a ser contatada na empresa desenvolvedora do sistema utilizado na emissão do documento fiscal eletrônico;

email: Informar o e-mail da pessoa a ser contatada na empresa desenvolvedora do sistema;

fone: Informar o telefone da pessoa a ser contatada na empresa desenvolvedora do sistema. Preencher com o Código DDD + número do telefone.

Os campos que, por enquanto, não serão de preenchimento obrigatório são:

idCSRT: Identificador do CSRT utilizado para montar o hash do CSRT;

hashCSRT: O hashCSRT é o resultado da função hash (SHA-1 – Base64) do CSRT fornecido pelo fisco mais a Chave de Acesso da NFe.

Dos campos de preenchimento obrigatório, referente aos modelos de documentos fiscais eletrônicos 55 (NF-e) e 65 (NFC-e), serão aplicadas as seguintes Regras de Validação:

ZD01-10: Não informado o grupo de informações do responsável técnico
Código de Rejeição: 972 - Obrigatória as informações do responsável técnico

ZD02-10: Informado CNPJ do responsável técnico inválido – CNPJ com zeros, nulo ou DV inválido
Código de Rejeição: 973 - CNPJ do responsável técnico inválido

Neste primeiro momento não haverá a obrigatoriedade do credenciamento de software emissor de DF-e para fornecimento do CSRT (Código de Segurança do Responsável Técnico).

Datas previstas de Implantação:
Ambiente de Homologação (Teste): 25/02/2019
Ambiente de Produção...................: 29/04/2019

22 Fevereiro, 2019

Em 20/02/2019 at 15:01, Amaury disse:

Resposta da Mensagem 7801363

Boa Tarde

Segue resposta da Sefaz SP sobre o Grupo <infRespTec> = Grupo de informações do Responsável Técnico

Prezado Amaury,

A SEFAZ-SP não aderirá o controle de Responsável Técnico pelo sistema (previsto na NT2018.005) por enquanto e não há previsão SE e QUANDO esse controle será implementado. Sugerimos que procure as demais UFs autorizadas para saber a posição destas.

Agradecemos seu contato no "Fale Conosco" da Secretaria da Fazenda.

Sua opinião é muito importante para nós. Por gentileza, clique no link abaixo e opine sobre este e-mail:

Pesquisa de Satisfação

Atenciosamente,

Secretaria da Fazenda do Estado de São Paulo

Mensagem Original:
Preenchimento da NFe
Boa Tarde
A SEFAZ-SP vai exigir que seja gerado o grupo <infRespTec> = Grupo de Informações do Responsável Técnico ?
Amaury
NÃO RESPONDA ESTE E-MAIL Para fazer uma nova pergunta, clique aqui.

Secretaria da Fazenda - Governo do Estado de Sao Paulo

" 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í.

15 Fevereiro, 2019

@EMBarbosa que ferramenta TOP.

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

15 Fevereiro, 2019

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).

15 Fevereiro, 2019

1 hora atrás, Daniel Simoes disse:

Devo iniciar a reforma no ACBrTEFD na próxima semana... alguns novos recursos, como por exemplo permitir NÃO agrupar todos os pagamento em Cartão, já estão sendo implementados por @André Ferreira de Moraes...

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.

15 Fevereiro, 2019

26 minutos atrás, Daniel Simoes disse:

Oi @maiconsaraiva... pode ser interessante... mas realmente fica um "frio na barriga" de quebrar algo que já está funcionando...

Eu nunca trabalhei com esse G.P.... você conseguiria testá-lo ?

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.

14 Fevereiro, 2019

14 horas atrás, Daniel Simoes disse:

Provavelmente a classe do " TEF Banese" foi criada antes da criação de TACBrTEFDClassTXT... acho que pouca gente usa esse G.P.

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

13 Fevereiro, 2019

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.)

13 Fevereiro, 2019

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.)

8 Fevereiro, 2019

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?

Entrar

Sobre nós...

Blocks

Notes ACBrLibNFe

Fóruns

Downloads

Calendário

Posts postados por sismais

Sobre nós...

Informação Importante