sgeinformatica

O comando é esse : NFE.InutilizarNFe( cCNPJ, cJustificativa, nAno, nModelo, nSerie, nNumInicial, nNumFinal) Da uma olhada no arquivo 35160942750700010955002000001401000001401-ped-inu.xml que a justificativa esta sem acento 35160942750700010955002000001401000001401-procInutNFe.xml 35160942750700010955002000001401000001401-ped-inu.xml

Delphi XE 10 Professional Nós fizemos uma modificação em nosso TcpClient e conseguimos resolver o problema assim : Client := TIdTCPClient.Create(Application); UTF8Encoding := IndyTextEncoding_UTF8(); Client.IOHandler.DefStringEncoding := UTF8Encoding; A resposta do webservice esta vindo com acento e ja conseguimos salvar o XML no banco de dados com acento. Agora ficou somente um problema, que o ACBrMonitorPLUS está removendo o acento da justificativa NFE.InutilizarNFe( cCNPJ, cJustificativa, nAno, nModelo, nSerie, nNumInicial, nNumFinal) Até o ponto que enviamos para o ACBrMonitorPLUS está com acento, a resposta já esta sem acento. <xJust> PROBLEMA TECNICO OU OPERACIONAL/Nao/Tem/Acentuacao/ </xJust> Essa frase colocamos acento Tenta fazer uma NFe de Inutilização com acentuação na justificativa que você já vai ver o problema.

Daniel, me desculpe a demora. Nós estamos usando o ACBrMonitorPLUS para assinar o XML e enviar. Quando ele autoriza, o XML é salvo na pasta C:\ACBrMonitorPLUS\Arqs Nós recuperamos esse XML autorizado pelo comando NFe.LoadFromFile e gravamos no banco de dados (SQL SERVER) A partir daí nós usamos o componente TAcbrNFe para imprimir o XML autorizado. O XML que o ACBrMonitorPLUS salva na pasta C:\ACBrMonitorPLUS\Arqs está com acentuação correta. O método NFe.LoadFromFile que está perdendo a acentuação. Mas estamos desconfiados que o nosso cliente soket que comunica com o ACBrMonitorPLUS que não esta configurado para UTF8. Você tem algum exemplo de comunicação por soket com o ACBrMonitorPLUS ?

ACBrMonitorPLUS dá uma olhada na justificativa, nesse ponto ja esta ficando errado eu teria que usar o comando AnsiToUTF8 para a justificativa ficar correta? eu usei mas nao deu certo 35160942750700010955002000001363000001363-ped-inu.xml

Daniel, pelo jeito meu projeto inteiro ta com problema de acentuação. O retorno do XML esta correto a acentuação, mas ai eu fui ver o pedido de inutilização, na justificativa já está ficando errado. Na hora de enviar o comando NFE.InutilizarNFe( cCNPJ, cJustificativa, nAno, nModelo, nSerie, nNumInicial, nNumFinal) a justificativa tem que fazer alguma conversão?

function NFeImprimeInutilizacao(Filial, Sequencia: String): Boolean; var XMLInu, S: String; NFe: TACBrNFe; NFeDANFEFR: TACBrNFeDANFEFR; begin Result := True; try // Arquivo XML Initulização S := 'SELECT ARQUIVO_XML FROM NFE_INUT' + ' WHERE FILIAL = ' + Filial + ' AND SEQUENCIA = ' + Sequencia; XMLInu := CodigoExiste(S, 'ARQUIVO_XML'); NFe := TACBrNFe.Create(nil); NFeDANFEFR := TACBrNFeDANFEFR.Create(nil); NFe.DANFE := NFeDANFEFR; NFe.DANFE.Sistema := SH; NFeDANFEFR.FastFileInutilizacao := LeParametros('RelatoriosSistema', PCodigoFilial) + 'INUTILIZACAO.fr3'; NFeDANFEFR.MostrarPreview := True; NFeDANFEFR.MostrarStatus := True; NFeDANFEFR.ShowDialog := True; NFe.InutNFe.LerXMLFromString(XMLInu); NFe.ImprimirInutilizacao; FreeAndNil(NFe); FreeAndNil(NFeDANFEFR); except Result := False; end; end; estamos usando o AcbrMonitorPlus

usamos socket, e esse relatorio é do fast report FR3

o xml esta correto, o problema é somente na impressao mesmo 35160942750700010955002000001355000001355-procInutNFe.xml

Estou com um probleminha de acentuação na inutilização da NFe, esta saindo ponto de interrogação ao inves da letra acentuada. Sera que é um bug ou estou fazendo alguma coisa errada Gostaria de saber também se no AcbrMonitorPlus tem algum comando que eu possa enviar para ele limpar a pasta C:\ACBrMonitorPLUS\Arqs Se não tiver, existe a possibilidade de desenvolver ? Seria bom que tivesse um parâmetro para pode excluir somente arquivos xml com mais de 30 dias por exemplo. Obrigado

dá uma olhada no meio de pagamento e verifica se esta como cartao de credito

Eu imagino que os programas que os contadores usam, tipo contmatic vão gerar essa arquivo. Antes de desenvolver vou esperar pra ver a real necessidade de fazer esse layout.

Provavelmente o erro em nossa aplicação deve estar apos usar o método ACBrSAT1.EnviarDadosVenda(ArquivoXml) Depois do método nós extraímos do XML o nro. do cupom, data e hora de emissão e mais algumas coisas, alem de gravar o XML no banco. Para evitar esses erros no futuro, logo apos o ACBrSAT1.EnviarDadosVenda(ArquivoXml) vamos gravar um arquivo de log onde vai ter o caminho e nome completo do arquivo XML que o ACBrSAT acabou de salvar. Se acontecer algum erro e a aplicação fechar, quando abrir novamente temos condição e buscar o XML na pasta e subir para o banco. Mas você comentou sobre a tag cNF, e nós não estávamos utilizando ela. Olhei no manual e encontrei a seguinte descrição : Código numérico que compõe a Chave de Acesso. Número aleatório gerado pelo emitente para cada CF-e para evitar acessos indevidos do CF-e. Você sabe me dizer se eu mandar 2 cupom com o mesmo cNF, o SAT vai recusar o segundo?

Os 3 arquivos XML estavam na pasta que o ACBrSAT gravou automaticamente. Deve ter dado algum erro que eu nao sei qual é, o usuario deve ter fechado a aplicacao que faz a autorizacao, e como estava na fila a ser autorizado, então pediu autorizacao novamente. Mas se minha aplicação for fechada, quando abre novamente e consulta pelo numero da sessao, ela nao existe mais. Eu poderia dar carga do XML para dentro do meu sistema a partir do XML que fica na pasta que o ACBrSAT gerou. O arquivo gerado fica com esse nome mais ou menos assim : AD35160160633369000244590000273170243907756934.xml Antes de eu usar o metodo ACBrSAT1.EnviarDadosVenda(ArquivoXml) tem como eu saber esse nome?

Como eu poderia resolver isso? No caso o ACBrSAT gera um numero de sessão automático quando utiliza o metodo ACBrSAT1.EnviarDadosVenda(ArquivoXml); Eu posso gravar o numero da sessão na minha tabela utilizando o evento OnGetNumeroSessao Se houvesse uma falha na aplicação e eu não obtivesse a resposta com o xml autorizado, como eu ainda tenho o numero da sessão, seria possível eu obter esse XML autorizado passando como parâmetro o numero da sessão ?

Daniel, no log do ACBrSAT apareceu as 3 requisições de venda Na primeira venda me parece que esta normal. - 10:04:37:096 - -- 10:04:37:088 - numeroSessao: 283532 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?> Ja na segunda venda, apareceu a seguinte mensagem : - 10:09:10:840 - ACBrSAT.Inicializado - 10:09:14:053 - -- 10:09:14:004 - numeroSessao: 470985 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?> Sera que isso pode ter sido uma oscilação na energia e o aparelho de SAT desligou e ligou novamente? Constatei que e o computador esta ligado apenas no estabilizador. Mas o nosso frente de caixa fez apenas uma requisição. To meio perdido, não consigo imaginar a causa do problema LOG_ABCrSAT.txt

Verdade, nem me lembrei desses 2 arquivos de LOG Vou verificar e depois eu posto aqui o que encontrei

Se isso tivesse acontecido, o log teria registrado mais de uma linha. Veja na tela que mandei em anexo, que foi requisitado apenas 1 vez

No dia 04/01 tivemos um problema inusitado, e descobrimos que o SAT registrou 3 vendas iguais Entramos no site da secretaria da fazenda para consultar e encontramos 3 cupom sat 24390 / 24391 / 24392 Todos com mesmo valor, e mesmo nro. lancamento de venda 581637 No nosso sistema tem apenas 1 venda, e no log que registra as requisicoes tem apenas 1 requisicao para autorizar o cupom No arquivo de LOG, ficou registrado que o programa de frente de caixa pediu autorização para imprimir o cupom as 10:04:34 Nos temos uma segunda aplicacao apenas para conversar com o SAT, e ele retornou que a autorizacao foi dada as 10:11:27 Isto é, 7 minutos depois Nesse tempo a aplicacao ficou parada aguardando o retorno. Depois disso apareceu 2 cupom extra autorizados. A algum tempo atras se nao me engano, eu li aqui no forum, que o timeout para conversar com o SAT quem determina é DLL Se fosse nossa aplicacao que tivesse autorizado, teria mais 2 linhas de LOG para o mesmo nro. de venda, o que nao ocorreu. Nos descobrimos isso, porque fiz um relatorio para mostrar nro. de cupom faltando num determinado periodo A unica explicacao que chegamos que isso provavelmente deve ser algum falha de comunicacao da DLL com o SAT Provavelmente a DLL tentou autorizar o cupom por 2 vezes, e somente na 3a que obteve reposta. Eu imagino que o componente não deve ficar tentando autorizar o cupom varias vezes, o Daniel conseguiria responder isso melhor. O SAT é da marca Elgin Alguém já passou por isso?

bom dia pessoal, hoje achei esse site do estado de Pernambuco que disponibilizou o aplicativo para validar o DeSTDA Imagino que o aplicativo deve ser o mesmo para todos os estados http://www.sedif.pe.gov.br/

ola, bom dia Esse novo arquivo tera que ser entregue agora no mes de fevereiro, mas a receita ainda nao disponibilizou o validador?

Ola Juliana, bom dia Ja vou atualizar meus fontes. Muito obrigado

Bom dia Estamos utilizando o Acbr para emitir boleto para banco Santander, e gerando o arquivo de remessa pelo layout de 240 posições (cobrança com registro) No segmento P na posição 224 tem como comandar a instrução de baixa do titulo automaticamente apos um determinado tempo de vencido 1. baixar/devolver 2. não baixar/não devolver 3. utilizar perfil do cedente Para configurar essa posição tem a propriedade no componente chamada Instrucao2 No mesmo segmento P, nas posições 226 a 227 tem como configurar o numero de dias para baixar automático, mas no componente esse campo esta fixo como 00 O pessoal do desenvolvimento teria como acrescentar um campo para configurar o valor dessa posição? Obrigado Carlo

Na tabela de CST do PIS/COFINS esta assim : 49 Outras Operações de Saida 98 Outras Operações de Entrada 99 Outras Operações 05 Operação Tributável por Substituição Tributária No meu entender 05 que é para operações com ST. Pede para seu cliente mostrar a lei onde ele esta se baseando.

A sim, é isso mesmo o cupom somente pode ser emitido para o mesmo estado. Mas a dúvida foi quanto as mensagens de erro do SAT da Bematech retornou um erro genérico, e já do Tanca voltou um erro bem explicativo. Será que seria o caso de atualizar o software da Bematech?

Olá pessoal, Hoje nos deparamos com mais um pequeno problema com o SAT. Um cliente tentou fazer uma venda para um cliente do estado do paraná, e tentou imprimir o cupom fiscal sat. Ele usa um SAT da marca bematech, e foi rejeitado com a seguinte mensagem : Erro de validação de conteúdo Eu peguei o arquivo XML para analisar, e aqui no meu escritorio fiz o teste usando meu SAT da marca tanca Ele retornou a seguinte mensagem : Rejeição: CFOP não é de Operação de saida prevista para CF-e-SAT A pergunta é, será que isso deve ser um problema do SAT da bematech que retorna uma mensagem genérica ? Será que seria o caso de fazer uma atualização de software ou entrar em contato com a bematech ?