maiconsaraiva

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