Sistema Auditor

A composição da chave de acesso é a baixo: cUF - Código da UF do emitente do Documento Fiscal; AAMM - Ano e Mês de emissão da NF-e; CNPJ - CNPJ do emitente; mod - Modelo do Documento Fiscal; serie - Série do Documento Fiscal; nNF - Número do Documento Fiscal; tpEmis – forma de emissão da NF-e; cNF - Código Numérico que compõe a Chave de Acesso; cDV - Dígito Verificador da Chave de Acesso. Minha duvida é o cNF ele pode ser repedido deste que outros campos sejam diferenciado? Exemplo em um supermercado que emiti vários cupons diários eu poderia toda vez que trocar o Ano/Mês gerar um cNF com mesma numeração do mês anterior, da seguinte forma 32230729468694000178650010005052811000000019 32230829468694000188650010005052811000000015 Como no exemplo as duas chaves tem o mesmo cNF mas com o AAMM diferente e numero da nNF diferente tbm este caso pode acontecer, sem rejeição junto a SEFAZ?

Bom dia. Alguma previsão para a alteração da TK-3919? Ao atualizarmos os fontes, o comentário feito no fonte foi substituído. O que acarretou problema em um de nossos cliente. Douglas Miiller Analista de Implantação/Suporte Sistema Auditor

Valeu vou fazer testes

Carissímos, boa tarde Possuo um arquivo zpl já pronto com o layout de impressão pronto, vocês tem algum exemplo enviando o arquivo já pronto pro AcbtEtq imprimir?

Prezados, boa tarde Eu utilizo o componente da classe TACBrETQ para imprimir etiquetas na Argox e na Zebra, gerando em cada etiqueta um número de código de barras único, porém fiz um log e no meu sistema e na minha comunicação do ACBR não ocorre das etiquetas serem duplicadas. Gostaria de saber como posso melhorar a comunicação da impressora para que a mesma limpe da memória as já impressas.

Bom dia a todos. Emissão da NFs-e de Serra/ES voltou a sua normalidade. Podem fechar o Ticket.

Bom dia, meu nome é Thiago sou o Analista\Programador fazendo o teste verifiquei o seguinte que no procedure ImprimirCheque a função de verificar se a impressora esta em linha não esta conseguindo comunicar com minha impressora mas se comentar esta validação o cheque é impresso corretamente. Então eu comentei a seguinte linha do código e funcionou corretamente: procedure TACBrCHQBematech.ImprimirCheque; Var ValStr, DataStr : String ; begin // if not fpDevice.EmLinha( 3 ) then { Impressora está em-linha ? } { raise Exception.Create(ACBrStr('A impressora de Cheques '+fpModeloStr+ ' não está pronta.')) ;} ..... A chamada da função ficou desta forma: procedure TfrCHQ.Button1Click(Sender: TObject); var ldata : TDateTime; begin ACBrCHQ1.Modelo := chqBematech; ACBrCHQ1.Porta := 'COM1'; try ACBrCHQ1.TravarCheque; ACBrCHQ1.Valor := 3594; ACBrCHQ1.Data := now; ACBrCHQ1.Favorecido := 'Evandro Almeida'; ACBrCHQ1.Cidade := 'Serra'; finally ACBrCHQ1.ImprimirCheque; end; end; ACBrCHQBematech.pas

Nosso programador dedilhou no fonte e já está conseguindo comunicar com a impressora, porém alguns campos não estão sendo impressos. Assim que terminarmos, envio o fonte para análise de vocês, e posterior alteração caso necessário.

NFS-e Serra/ES (Código IBGE 3205002) Na data de hoje nossos clientes do município da Serra/ES (Código IBGE 3205002) passaram a ter como resposta na consulta do RPS enviado a mensagem abaixo: Erro apresentado: Erros: Código : Mensagem: Erro: Erro no script NFENotaFiscalWSSaida: WRONG_DOCUMENT_ERR: Um nó é usado em um documento diferente daquele que foi criado. Correção: Código: X203 Mensagem: Não foi retornado nenhuma NFS-e. Correção: Utilizando o SOAP para consultar a referida nota fiscal, verifiquei na resposta que os sinais de maior e menor vem em código HTML. Por isso acho que o componente não está conseguindo identificar as TAGs. Em anexo, envio o caminho WSDL da referida prefeitura, a consulta com as informações da nota. Também o erro que já mencionei acima. ProjetoSoapConsultaRpsEnviado.txt RespostaNoSoap.txt MensagemRetornoLog.txt A nota foi emitida, então o envio esta correto: http://apps.serra.es.gov.br:8080/tbw/resultados/QRUNQYZQWCKZMUREDMXX.pdf

Só abri os dois aplicativos para printar a imagem. Já validei as configurações. Selecionei outro modelo, voltei para a Bematech, selecionei a porta COM1 novamente e tive a mesma mensagem

Estou utilizando em teste o “Teste ACBrCHQ” configurado na COM1, e estou recebendo a seguinte mensagem: “A impressora de Cheques Bematech não está pronta” Porem no aplicativo da Bematech, o “DP20 – Plus Document Printer”, consigo imprimir corretamente o cheque. Aplicativo configurado na mesma porta COM, no caso COM1. Imagem anexa.

Bom dia a todos. Alguma novidade quanto ao assunto?

Ok, obrigado. Vi em outro tópico que já estão vendo a nova versão e prefiro aguardar a liberação da nova versão.

Prezados, presumo eu que os caminhos do Banco Sicredi estão errados. No "ACBrBoletoW_Sicredi_API.pas" C_URL = 'https://cobrancaonline.sicredi.com.br/sicredi-cobranca-ws-ecomm-api/ecomm/v1/boleto'; C_URL_HOM = 'https://cobrancaonline.sicredi.com.br/sicredi-cobranca-ws-ecomm-api/ecomm/v1/boleto'; No Manual URL Sandbox (ambiente para homologação): https://api-parceiro.sicredi.com.br/sb/auth/openapi/token URL Produção: https://api-parceiro.sicredi.com.br/auth/openapi/token

Pelo Postman, se eu usar o meu J'son, pelo menos me retorna que o boleto já existe.

Daniel, bom dia. Vou te pedir um favor. Teria como me enviar seu "executável" e seu "Ini". Ontem atualizamos os fontes e compilamos novamente o "AcbrBoletoDemo_Fast.exe", pode até ver na imagem da pasta que te envio em anexo. (Que por sinal, gostaria de sua reposta se dentro dela falta algum arquivo que seria necessário) Estou usando as mesmas configurações, mas ainda retorno o "HTTP_Result=500". Anexo tem a imagem de uma comparação dos nossos Json's, somente com uma diferença no campos JUROS, mas um campo que não tenho na tela para mudar.

Prezados, agora estou usando a API correta. Configurei os dados corretos. (Ver imagem em anexo) Porem não estou recebendo retorno, nem mensagem de erro. Ao verificar o arquivo "RetornoRegistro.txt", verifico o erro no retorno (HTTP_Result=500). Segue o arquivo em anexo. Também envio o arquivo "ArqBoletoWS.log" que me traz o erro "ErrorCode=10091" RetornoRegistro.txt ArqBoletoWS.log

Não é rejeitado, ele aceita e é o correto. Informar MG nesse MDF-e. Pois se não informar que vai passar por Minas e for pego passando, será multado. Por isso o validador apresentado não ajuda na situação em questão. Ele não aceita selecionar um terceiro estado quando o de origem e destino são limítrofes.

Boa tarde. Estou usando EXE. Fiz os testes conforme solicitado e o caminho passou a trazer corretamente o caminho do executável /remessa e /retorno. Porem a mensagem continuava. Em conversa com o programador, ele resolveu compilar o “AcbrBoletoDemo_Fast.exe”. Porem também, no momento da compilação, dava erro. O mesmo retirou do código todo “DataModulo” do Fortes, e conseguimos compilar. Preenchi todos os campos do executável e estou recebendo a mensagem abaixo: (ArqBoletoWS.log) Falha Envio: DadosPFX, ArquivoPFX, URLPFX ou NumeroSerie não especificados ! Porem dentro do Demo não acho campo que se refira a esses campos para preenchimento.

ok Obrigado.

Sim, existe.

Não estou conseguindo ver onde estou errando ao usar o "AcbrBoletoDemo_Fortes.exe" Estou recebendo a mensagem da imagem em anexo

Ok. Muito obrigado Mas ele não vai servir. Exemplo na imagem em anexo. Tenho uma cidade no Norte do ES que vai para a Bahia. Por mais que ES e BA sejam limítrofes, eu vou passa por MG.

Boa tarde a todos. O ACBr possui algum componente que me retornaria os estados a ser percorrer entre duas cidades? Seja CEP > CEP Seja IBGE > IBGE Ou a junção dos dois.

simulação acontece no meu programa erp também, ao clicar no botão Carregar xml e clicar no botão enviar o ACBR fala que o evento foi transmitido com sucesso, agora se eu pegar o mesmo evento e clicar no botão enviar, o acbr trata a mensagem da sefaz como se fosse uma exceção do Delphi. Segue imagens, xml e exemplos abaixo: <retornoLoteEventosAssincrono><ideContribuinte><tpInsc>1</tpInsc><nrInsc>47146660</nrInsc></ideContribuinte><status><cdResposta>1</cdResposta><descResposta>O lote está aguardando processamento.</descResposta></status><dadosRecepcaoLote><dhRecepcao>2023-02-28T15:23:46.6739135-03:00</dhRecepcao><versaoAplicativoRecepcao>2.0.0-1196434</versaoAplicativoRecepcao><protocoloEnvio>2.202302.122702</protocoloEnvio></dadosRecepcaoLote></retornoLoteEventosAssincrono> ideTransmissor: cdStatus : 1 descRetorno : O lote está aguardando processamento. **Ocorrencias **dadosRecepcaoLote dhRecepcao....: 28-02-2023 protocoloEnvio: 2.202302.122702 / retornoEventos Inicio TEnvioLote ERRO: WebService: http://sped.fazenda.gov.br/RecepcaoLoteReinf/ReceberLoteEventos - Inativo ou Inoperante tente novamente. Erro Interno: 0 Erro HTTP: 422 URL: https://pre-reinf.receita.economia.gov.br/recepcao/lotes <Reinf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.reinf.esocial.gov.br/schemas/retornoLoteEventosAssincrono/v1_00_00"><retornoLoteEventosAssincrono><ideContribuinte><tpInsc>1</tpInsc><nrInsc>47146660</nrInsc></ideContribuinte><status><cdResposta>7</cdResposta><descResposta>Lote não recebido - Verificar ocorrências.</descResposta><ocorrencias><ocorrencia><codigo>MS1393</codigo><descricao>Já existe lote um lote idêntico recebido na base do ambiente nacional. Protocolo: 2.202302.122702</descricao><tipo>1</tipo><localizacao /></ocorrencia></ocorrencias></status><dadosRecepcaoLote><dhRecepcao>2023-02-28T15:23:46.673</dhRecepcao><versaoAplicativoRecepcao>2.0.0-1196434</versaoAplicativoRecepcao><protocoloEnvio>2.202302.122702</protocoloEnvio></dadosRecepcaoLote></retornoLoteEventosAssincrono></Reinf> ID1471466600000002023022815232500001-R1000-Envio.xml