Ir para conteúdo
  • Cadastre-se

luizcnr

Membros
  • Total de ítens

    48
  • Registro em

  • Última visita

1 Seguidor

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

luizcnr's Achievements

Contributor

Contributor (5/14)

  • Reacting Well Rare
  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later

Recent Badges

11

Reputação

5

Community Answers

  1. Em nosso cliente, esse problema ocorre em cupons emitidos após as 22h. Pelo que foi identificado, foi no fim do mês de março. Esse problema foi identificado, pois o cliente utiliza o arquivei e ele acusa esse erro mencionado. E esse erro ocorre em apenas alguns cupons tb, deve ser algum problema no retorno da SEFAZ.
  2. Obrigado! E questionei, pois mesmo eu realizando aquela alteração que mencionei ali em cima, o problema voltou a acontecer no cliente. Eu vou tentar atualizar o windows da máquina do cliente e a pasta schemas.
  3. Juliomar, só uma dúvida. Uma pergunta "besta". Essa data e hora do recebimento, pode ter haver com a data e hora de envio?
  4. Lucimauro, acabamos solucionando o problema. Nos ajustes de data e hora do Windows 10, a máquina do cliente estava ativo definir fuso horário automaticamente. Ao desabilitar essa opção, o cupom começou a retornar o fuso horário correto. Obrigado pela ajuda!
  5. Pode ser uma situação. Mas, se tivesse alterado data e hora, na data da emissão estaria com o mesmo fuso horário. O problema em si, está sendo a data e hora do recebimento. Eu estou tendo quase a certeza que esse retorno de data e hora no dhRecbto, é a SEFAZ quem me retorna.
  6. Está sim. Tudo correto. Pelo que entendi, esse retorno é da SEFAZ. Eu tentei simular algo na minha máquina e todas as vezes, foram retornados com -03:00 no horário de recebimento
  7. Não fixei no componente, Julio. Isso está ocorrendo em um cliente em específico. Pois, na hora da emissão está correto, mas na hora de recebimento, está incorreto.
  8. Galera, boa tarde! Estou com um problema em um cliente com o retorno do XML da NFCe. A NFCe é emitida normalmente, porém, quando vai validar os dados da NFCe no validador de NFCe, https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx. É emitido o seguinte erro: Schema XML: The 'http://www.portalfiscal.inf.br/nfe:dhRecbto' element is invalid - The value '2023-03-31T22:17:14+00:44' is invalid according to its datatype 'http://www.portalfiscal.inf.br/nfe:TDateTimeUTC' - The Pattern constraint failed. Caminho: nfeProc/protNFe/infProt/dhRecbto/. O problema identificado está na tag dhRecbto: <dhRecbto>2023-03-31T22:17:14+00:44</dhRecbto> Ao corrigir, para -03:00, a NFCe é validada normalmente. Alguém pode me dizer o porque da NFCe estar retornando +00:44?
  9. Galera, diante do erro com o Certificado A3. Consegui realizar um teste em homologação com o certificado digital A1 e a emissão ocorreu normalmente. O problema então está na emissão no certificado A3 com a SEFAZ.
  10. O meu também é A3. Ainda não consegui resolver. Ao que tudo indica o problema persiste desde Outubro com o certificado A3.
  11. Bem estranho, pq eu já instalei a cadeia de certificados.
  12. Pessoal, boa tarde! Estou com um problema ao emitir a NFCe em homologação, está me retornando o seguinte erro: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeAutorizacao4.asmx Erro: 2148073481 - Já coloquei as DLLs na pasta da minha aplicação, instalei a cadeia do certificado, desativei o Firewall. Por dúvidas, testei em uma outra máquina e emitiu normalmente a NFCe, creio o problema está em minha máquina. Alguém pode me ajudar?
  13. Daniel, boa tarde! De acordo com o que você sugeriu, entrei em contato com a Elgin e eles retornaram com a solução, ou seja, criaram um .ini. Está disponibilizado no link do GIT HUB da Elgin. https://github.com/ElginDeveloperCommunity/SAT/tree/master/Elgin/SMART SAT/Bibliotecas Windows O arquivo .ini, obtém a seguinte informação: [Logging] # Aceita info, debug e trace #level = trace # Onde escrever o log #file = /tmp/sat.log [Connection] # Usar conexao continua com o dispositivo continuous = false # Hub onde o dispositivo esta conectado #hub = 2 # Porta onde o dispositivo esta conectado #port = 1 # Serial do dispositivo #serial = 900021403 No caso, a solução está no continuous, ao passar false, a própria DLL irá liberar a porta automaticamente, sem precisa passar a função pelo ACBr, sem necessitar das alterações. Abaixo segue, uma explicação de como funciona as funções da DLL Elgin: https://github.com/ElginDeveloperCommunity/SAT/wiki/Trabalhando-com-vários-SATs-no-PDV
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.