Pesquisar na Comunidade

Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf

Estou com um problema bem estranho ao fazer um CNF, ocorre assim: Ao registrar um item CNF, estranhamente na ECF fica com 1 centavo a mais. Para complicar mais o problema, usando o EcfTeste não acontece. Já atualizei o componente e continuou na mesma. Tentei debugar e só consegui descobrir que a mudança onde acontece o acréscimo de 1 centavo é dentro de uma função do componente. Na procedure, RegistraItemNaoFiscal existe a seguinte chamada "fsECF.RegistraItemNaoFiscal(CodCNF, Valor, Obs);" Até aqui não ocorre problema mas quando entro debugando vai para "procedure TACBrECFEscECF.RegistraItemNaoFiscal(CodCNF: String; Valor: Double; Obs: AnsiString);" Nessa procedure, ao entrar em "EscECFComando.AddParamDouble( Valor ) ;" vai para procedure TACBrECFEscECFComando.AddParamDouble(ADouble: Double; Decimais: Byte); begin AddParamInteger( Round( ADouble * power(10, Decimais) ) ) ; end; e aqui a mágica acontece, acrescenta 1 centavo. Ao ir ao próximo ponto já está com o valor alterado. Já fiz de tudo, conferi a configuração do ACBrECF do EcfTeste com o do nosso sistema e não consegui encontrar o porque disso acontecer. Se alguém tiver visto isso acontecer e puder me ajudar agradeço. Em anexo o Log da ECF gerado por ambos os sistemas mas pelo que olhei, não entendo muito o conteúdo desse log, mas parece que nele não tem o conteúdo que esclarece o problema por este ocorrer antes de ir para a ECF. ECF.TXT acbrlog.txt

A tag "cNF" não esta assumindo o valor que estou passando, de acordo com a documentação que verifiquei da SEFAZ esta tag deveria ser informada pelo emitente sendo um número aleatório para compor a chave de acesso do CF-e, eu gostaria de passar a chave da minha tabela de CF-e, mas não esta ficando com o valor que estou passando estou fazendo desta forma: ACBrSAT.CFe.ide.cNF := MeuNumero; Estou fazendo errado, tem alguma propriedade quer preciso alterar?

Pessoal boa tarde. Estamos implementando o processo de pagamento utilizando o ACBrTEFD com a CliSiTef e ficamos na dúvida sobre como proceder quando houver a desistência de alguma das transações autorizadas. Devido a isto levamos o seguinte cenário para a Software Express: 1) O cliente chega ao estabelecimento e paga com 2 cartões, cada um representando metade da venda; 2) Ambas as autorizações são aprovadas pelo SiTef; 3) Passados alguns segundos, a transação ainda não foi finalizada (encerramento de CF + impressão de CCD), o cliente decide que não vai pagar mais em um dos cartões e que pagará a diferença em dinheiro, ou seja, metade será em um dos cartões e a outra em dinheiro. Como devemos proceder com este cenário, cancelamos toda a venda para que haja a impressão do comprovante de estorno (HEADER = CNC) ou simplesmente cancelamento a autorização (HEADER = NCN)? Com base no cenário levantado, a SE respondeu: No cenário apresentado você teria que mandar uma NCN (Não confirmação da venda) para o cartão que houve a desistência, pois os dois ainda não receberam a CNF (Confirmação da venda), agora se as duas já tivessem recebido a CNF, teria que mandar a CNC (Cancelamento de Venda). Implementamos o processo enviando o NCN (o SiTef muda o estado para CANC. PDV) mas quando acionamos o método para imprimir transações pendentes, a transação que não foi confirmada pelo NCN é impressa também. Ao realizar a não confirmação de uma autorização ela não deveria sair da lista de transações pendentes? Segue em anexo um exemplo onde o pagamento de R$ 100,00 não foi confirmado. A DLL utilizada é a versão 0.9.6.3. Obrigado. José Mauro trace-multiplos-cartoes.txt