Ir para conteúdo
  • Cadastre-se

sesistemas

Membros Pro
  • Total de ítens

    244
  • Registro em

  • Última visita

Tudo que sesistemas postou

  1. Bom dia, Estou tentando enviar um MDF-e mas estou tendo o seguinte retorno: 12347->Rejeicao: Falha no Schema XML especifico para o modal Já realizei vários testes e não consegui resolver este problema. Já atualizei os Schemas XML contidos na pasta \ACBr\Exemplos\ACBrMDFe\Delphi\Schemas\ e também os dos portal do MDF-e. Alguém sabe me dizer o que é este problema? Segue XML. Att, 35130802830994000280580010000123471000000019-mdfe.xml
  2. Alguém já teve este problema citado pelo Wislei? Também não estou conseguindo setar a quantidade de cópias para o DACTE em FastReport desta forma.
  3. Boa tarde. Gostaria de informar que o serviço de recepção já voltou ao normal "magicamente". Att,
  4. Bom dia. Hoje ao tentar emitir um CT-e em homologação estou tendo a mesma rejeição. "3149->Rejeicao: Falha no Schema XML especifico para o modal" Não houve nenhuma alteração no meu processo de envio, e os fontes e os XML Schema estão todos atualizados de acorod com a pasta: \ACBr\Exemplos\ACBrCTe\Delphi\Schemas\ do repositório. Mais alguém está tendo este problema em Minas Gerais? Obs: Autorizando o CT-e no SVC-SP, não ocorre este problema. Segue XML. 31130803341645000186570010000031491240761536-cte.xml
  5. Consegui resolver o meu problema alterando o número do recibo que está sendo fornecido errado para CT-e autorizado em SVC.
  6. Em Minas Gerais ainda não está disponível o EPEC, como pode ser visto neste post:
  7. Bom dia. Depois de muitas tentativas e de várias respostas que não serviram de nada do SEFAZ de São Paulo, eu consegui "contornar" o problema da Consulta de um CT-e autorizado na SVC-SP. Ao autorizar um CT-e com o TIpo de Emissão = 8 (SVC-SP), obtenho um recibo no seguinte formado: 318000003333513, onde o 31 é o código do estado (Minas Gerais no meu caso) e o 8 é o Tipo de Emissão. Não sei porque (e nem o SEFAZ de São Paulo soube me responder) se eu alterar o recibo para 351000003333513, ou seja, como se o CT-e fosse autorizado com o Tipo de Emissão 1 - Normal, e no estado de São Paulo, eu obtenho o retorno com os dados da autorização do mesmo.
  8. Boa tarde. Estou com um problema parecido ao do nosso amigo Adriano em um CT-e de Complemento de Valores, DACTE gerado pelo FastReport. Eu consegui transmitir o XML normalmente com as tags <impComp> preenchida com os valores necessários. Porém, as Informações Relativas ao Imposto no DACTE ficam todas zeradas. Será que é por eu ter preenchido a tag <imp> com os valores zerados? Mesmo em um CT-e do tipo "Complemento de Valores" ? Segue XML gerado em anexo. 31130703341645000186570010000031251135684270-cte.xml
  9. Bom dia. Há o componente responsável pela impressão do DAMDFE para FastReport ? Só vi para o QuickReport (ACBrMDFeDAMDFEQRpkg).
  10. Bom dia ìtalo, Desculpe pela demora em responder. Quanto aos Tipos Autorizadores 3,5 e 7,8 está bem claro pra mim. Eu apenas utilizei eles para teste mesmo, pois não consegui realizar a consulta alterando o recibo para nenhuma das opções (0,1,3,5,7 ou 8). Lendo a Nota Técnica 2012 003 novamente, não percebi nada de errado que estamos fazendo. Lá informa que há o serviço de consulta no SVC e também fala no item 8, que haverá um sincronismo entre o SVC e o SEFAZ após os problemas serem sanados. Portanto, posteriormente seria possível consultar no SEFAZ o CT-e autorizado na SVC pelo que entendi. Sinceramente, minhas alternativas de teste se esgotaram. Acho que até pode um problema dos WebServices. Vou entrar em contato novamente para ver se tenho alguma posição deste problema.
  11. Bom dia Ítalo, No envio deu tudo certinho, o CT-e foi autorizado e foi me retornado todos os dados da autorização, inclusive o protocolo e o número do Recibo (o qual utilizo para fazer as consultas no SEFAZ de Minas Gerais atualmente). O meu problema é na consulta deste CT-e. Estou fazendo esta operação sem nenhuma modificação, consulto este CT-e autorizado no SVC da mesma forma que os autorizados no SEFAZ de Minas Gerais. Com isso, estou tendo este retorno informando acima (473). Na página 47 do manual do CT-e, nas regras de validação da Consulta por Recibo (item E02a), informa a rejeição onde os tipos de autorização são: 0, 1, 3, 5, 7 ou 8. Já no item 5.5 do manual página 79, onde explica a estrutura da numeração do Recibo, informa que os tipos de autorizador devem ser somente 0, 1, 3 ou 5. Não informa os tipos 7 e 8 das SVC-[RS,SP]. Um número de Recibo de exemplo que recebi ao autorizar um CT-e no SVC-SP foi: '318000003257464'. Note que o tipo autorizador está correto, porém ainda estou tendo o retorno 473 ao consulta-lo. Já tentei alterar este dígito para 3, 5 e 7 e obtive o mesmo retorno. Alterando para 1, obtive o retono 106 - Lote nao localizado. Resumindo, eu estou conseguindo transmitir normalmente o CT-e para o SVC-SP, porém, não estou conseguindo consultá-lo.
  12. Alguém tem alguma posição sobre o meu problema? Já fiz vários testes e ainda não consigo realizar a consulta de um CT-e autorizado em um SVC (tpEmiss = 8). Estou utilizando um "recurso alternativo" para consultar, onde carrego o XML baixado do portal Federal e gravo as informações do protocolo em minha base de dados. O problema é que somente lendo XML eu não tenho as informações de recibo. Creio que deve ter alguma solução, pois no Portal do CT-e existe o serviço de CteConsultaCadastro Link: https://producao.cte.ms.gov.br/cteWEB/CadConsultaCadastro.asmx Se alguém souber o que posso fazer, ou tiver alguma dica, poste aqui por favor! Att, Wislei
  13. Boa tarde. Devido a alguns problemas no WebService de Minas Gerais, estamos implementando a autorização do CT-e no SEFAZ Virtal de Contingência (SVC). A autorização ocorreu tudo certo, onde foi necessário alterar apenas o tipo de emissão no XML. Porém, não está send possível consultar este CT-e autorizado no SVC-SP, pois a consulta está sendo feita em um órgão autorizador diferente do da autorização. Me parece que a minha consulta está sendo direcionada para o SEFAZ de Minas Gerais, e não para o SVC-SP. Há alguma configuração que devo fazer no componente, ou haverá um sincronismo entre o SVC-SP e o SEFAZ de MG? Obs: foi tentado a consulta por Recibo e pelo XML. Erro retornado: Código de retorno : 473 Motivo : Rejeicao: Tipo Autorizador do Recibo diverge do Orgao Autorizador Segue XML enviado em anexo. Att, Wislei 31130603341645000186570010000030448628731407-cte.xml
  14. Deu tudo certinho! Muito obrigado e parabéns pelo excelente trabalho!
  15. Boo tarde. Ao consultar um CT-e emitido para um SEFAZ Virtual de Contingência (SVC-SP) estou tendo um problema parecido. Código de retorno : 473 Motivo : Rejeicao: Tipo Autorizador do Recibo diverge do Orgao Autorizador Há alguma forma de eu "setar" o componente para direcionar a consulta para o SVC-SP? Obs: Estou consultando o CT-e pelo seu recibo.
  16. Boa tarde Ítalo. Consegui resolver este problema. Se você puder subir a alteração para o SVN para nós... A alteração foi realizada na unit \ACBr\Fontes\ACBrCTe\ACBrCTeDACTEFRDM.pas na linha 1098. Estava faltando a verificação do tipo de emissão para os SEFAZ Virtual de Contingência (teSVCSP e teSVCRS). Segue alteração e unit alterada. ... else if (FCTe.Ide.tpEmis = teSVCSP) or (FCTe.Ide.tpEmis = teSVCRS) then begin FieldByName('Contingencia_Descricao').AsString := 'PROTOCOLO DE AUTORIZAÇÃO DE USO'; FieldByName('Contingencia_Valor').AsString := FCTe.procCTe.nProt + ' ' + DFeUtil.SeSenao(FCTe.procCTe.dhRecbto <> 0, DateTimeToStr(FCTe.procCTe.dhRecbto), ''); end; ACBrCTeDACTEFRDM.pas
  17. Caso alguém esteja com a mesma situação que citei acima, no post abaixo o Ítalo explica como configurar o componente para tentar tratar este problema.
  18. Bom dia. Após as configurações sugeridas pelo Ítalo setando as opções de Salvar para True, não estou tendo mais problemas de receber o XML sem o protocolo. Porém estou tendo um problema parecido na impressão do DACTE. Devido a alguns problemas no WebService de Minas Gerais, estou autorizando o CT-e no SEFAZ Virtual (em homologação). Até ai tudo bem, o CT-e está sendo autorizado normalmente e o XML está vindo com o devido protocolo. Porém, ao imprimir o conhecimento autorizado no SVC-SP, o protocolo não está sendo exibido, e imprimindo o XML em outros visualizadores (www.geradacte.com.br/ por exemplo) o protocolo é exibido normalmente. Estou utilizando o Delphi XE3 com FastReport na versão 4.13.3. Alguém pode me ajudar? Segue XML em anexo. 31130603341645000186570010000030318420138764-cte.xml
  19. Boa tarde pessoa. Com esses problemas constantes em nosso WebService aqui em Minas Gerais, estou tendo um outro problema na impressão do DACTE. Devido a esta instabilidade, o meu cliente fica tentando enviar o documento várias vezes até ser autorizado. De tanto o usuário tentar, o CT-e é "autorizado", porém o XML e o DACTE ficam sem o número do protocolo. Tenho medo de uma hora o usuário não perceber isto e liberar o transporte sem este CT-e devidamente autorizado. Mais alguém está tendo este problema? Vocês podem me dar alguma informação para que eu possa tratar este problema?
  20. Bem irei explicar melhor. O sistema que trabalho: Sempre verifica os dados da última Redução Z da Impressora com os dados da última Red. Z do Banco de Dados. Ou seja quando emito uma Red. Z ele grava dados no banco de dados e quando abro o sistema verifica se os dados IMPRESSORA = BANCO DE DADOS estão iguais. Problema: Se , por exemplo, os dados estiverem incompativeis entre IMPRESSORA E BANCO DE DADOS, o procedimento nosso é: 1. Excluir a última Reducao Z do Banco de Dados 2. Automaticamente o sistema pega os dados da última Redução Z da Impressora e Grava no BD. 3. A data e hora da emissão não está sendo possível pegar,se, os dados da Red. Z forem gravados dias posteriores, ou se for emitida a redução dias posteriores. A única informação de Data que consegui é: DataMovimento Porém eu quero a data e hora da Emissão. Alguém poderia me informar como pego a data e a hora da EMissao da Ult Red Z no momento que eu desejar? Obs.:Data de emissão pode diferente da data de Movimento. Grato pela compreensão.
  21. Eu já utilizo o comando "Dados da Redução Z", porém a data e hora da emissão não consegui pegar! Acima eu citei que "Não achei nenhum comando ACBR" Eu preciso da data e Hora da emissão da última Redução Z, como não achei nada referente, usei comando direto.
  22. Olá pessoal, Venho aqui relatar um estudo do protocolo dos comunicações das Impressoras. Primeiramente eu precisava pegar a data e hora da emissão da última Redução Z das Impressoras. Não achei nenhum comando ACBR e nenhuma solução até o momento. Resolvi usar a função "EnviaComando" para buscar a data e hora da últ. RZ. Peguei os protocolos de comunicação (comandos diretos) da Bematech, Sweda (STX) e Daruma. Obtive os seguintes resultados (data e hora da última Red. Z): Obs.: Cada impressora tem um comando, não foi explicado pois está dentro do protocolo de cada impressora. --------------------------- Bematech: --------------------------- * Nesta Impressora a Ultima Redução Z foi: 17/05/2013 15:31:11 * Enviei o Comando: EnviaComando( #35 + #26 ) * Resposta do comando acima peguei no comando: RespostaComando --> O Resultado foi: #$17#5#$13#$15'1'#$11'@ * O que eu indentifiquei na resposta #$17#5#$13#$15'1'#$11'@ Dia: 17 Mes: 5 Ano: 13 Hora: 15 Minuto: '1', transformando em Hexa = 31 Segundo: 11 Obs.: O minuto eu transformei em hexa! --------------------------- Daruma: --------------------------- * Nesta Impressora a Ultima Redução Z foi: 15/05/2013 15:07:29 * Enviei o Comando : EnviaComando( #28 +'R' + #200 + '154') * Resposta do comando: ':È15415052013150729'#$D * Identifiquei: Data: 15052013 Hora: 150729 --------------------------- Sweda STX: --------------------------- * Nesta Impressora a Ultima Redução Z foi: 15/05/2013 13:17:45 * Enviei o Comando: EnviaComando(#51+#52+#124+#65+#50) * Resposta do comando: #2'234A0002'#0#$1B']17/05/2013'#0'13:17:45'#0#0#3'³'#2'234+0000DA˜€€€€A2'#3#$19 * Identifiquei: Data: 17/05/2013 Hora: 13:17:45 Alguem tem alguma noção como que eu trato as repostas? Em tese achei os valores. Mas preciso de um tratamento mais adequado!
  23. Boa tarde Julia, Conversando com um de nossos transportadores, chegamos a uma conclusão. Segundo o manual do CT-e versão 1,04c (pág 119), é obrigatório informar um responsável pelo seguro da carta para o modal rodoviário (a partir de hoje segundo a Nota Técnica 2013 001). Trazendo este contexto para o nosso dia-a-dia, se houver qualquer problema com a carga (perda, roubo, estragos, etc...) será a transportadora, no caso a que eu conversei, que se responsabilizará pelos danos. Sendo assim, informamos a opção 4 - Emitente do CT-e. Mas as outras opções serão preenchidas de acordo com cada contrato. Portanto, sempre haverá um responsável pela carta, seja a transportadora, o remetente, destinatário... O importante é o usuário identificar qual destes e informar nesta tag.
  24. sesistemas

    Subcontratação

    Bom dia Estou com uma duvida em um caso especifico. Uma transportadora A foi contratada para realizar um transporte, porém esta empresa contratou uma transportadora B para realizar este transporte. Neste caso somente a transportadora B deve emitir um CTe de subcontratação ou a transportadora A também deve emitir CTe? Qual tipo de CTe (normal,subcontratação) ela deve emitir ?
  25. sesistemas

    Erro Cte

    Falha na validação dos dados do Conhecimento 1 TAG:<infCte versao="1.04" Id="CTe31130103049584000188570010000000011876521045"><exped><enderExped> ID:#175/nro(Número) - Nenhum valor informado. '' violates pattern constraint of '[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}'. The element '{http://www.portalfiscal.inf.br/cte}nro' with value '' failed to parse. Alguém sabe o que é este erro ???
×
×
  • 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.

The popup will be closed in 10 segundos...