tradeone

boa tarde Renato, Fizemos os testes e funcionou. Segue a unit alterada para analise. -- ACBrSPEDFiscal -- [-] Acrescentada a possibilidade de atribuir o opNenhum para o campo IND_PROC (Origem do Processo do Resgistro E112 - Informações Adicionais da Apuração), possibilitando desta forma deixar este campo em branco nos casos em que não houver processo. (Contribuição: Júlio Moraes, Paulo Brasil - Trade One TI) ACBrEFDBloco_E_Class.zip

pelo que analisei o E116 e E250 que usam este mesmo campo, já estão com esta correção.

Renato, acho que ficaria assim com a correção: procedure TBloco_E.WriteRegistroE112(RegE111: TRegistroE111) ; var intFor: integer; strIND_PROC: String; //alterei aqui begin if Assigned( RegE111.RegistroE112 ) then begin for intFor := 0 to RegE111.RegistroE112.Count - 1 do begin with RegE111.RegistroE112.Items[intFor] do begin case IND_PROC of opSefaz: strIND_PROC := '0'; opJusticaFederal: strIND_PROC := '1'; opJusticaEstadual: strIND_PROC := '2'; opSecexRFB: strIND_PROC := '3'; opOutros: strIND_PROC := '9'; opNenhum: strIND_PROC := ''; //alterei aqui end; Add( LFill('E112') + LFill( NUM_DA ) + LFill( NUM_PROC ) + LFill( intIND_PROC, 0 ) + LFill( PROC ) + LFill( TXT_COMPL ) ) ; end;

boa tarde Renato, Pelo que analisei e testei pelo Validador em relação ao E112, aceita este registro em branco sem erros.

Prezados colegas, Estou com a seguinte situação abaixo e não consegui identificar dentro do componente onde pode estar o problema: Registro E112, campo IND_PROC, estou passando opNenhum porém no arquivo esta gerando 9- outros onde deveria ficar em Branco. (Orientação da GIA do RS, quando não tiver número do processo esta campo fica em branco). Atenciosamente, Júlio

aqui com a gente esta ocorrendo este mesmo problema. Sefaz - RS

Solução para o Problema: Aqui no RS tivemos o mesmo problema hoje pela manhã em um único cliente, o qual usa internet da NET. Solicitamos que ele abrisse um chamado junto a net pedindo para trocar ou estabilizar a ROTA a qual trafega até chegar a Sefaz RS, dai a Net estabilizou ou trocou esta ROTA, contornando o problema de imediato. abraços a todos colegas Júlio Moras

Obrigado Italo! Vamos relatar o problema na Sefaz.

Bom dia Hugo Vinicius e Italo, Prezados colegas, Aqui no RS, estamos com este mesmo problema na emissão de CTe OS , Complementar e o de Anulação. O meu xml esta igual ao do Hugo Vinicius, ou seja, sem a tag rodoOS que é justamente onde gera o Número de registro estadual. Pela regra N22B não será aceito CTE OS sem o NroRegEstadual, para operações internas. A dúvida é : Para CTe OS COMPLEMENTAR e o de ANULAÇÃO não devemos gerar as informações de rodoOS ? Obs> no CTe OS de Substituição a tag rodoOS esta sendo criada, dai a Sefaz esta aceitando normalmente. REGRA N22B: 3.1. Validação do Tipo de Serviço (Modelo 67) # Regra de Validação Crítica Msg. Efeito N22b Se tipo de serviço = Transporte de Pessoas, modal rodoviário e Operação Interna (UF de início for igual a UF de fim da prestação, ambas diferentes de EX) Deverá ser informado o campo NroRegEstadual. Atenciosamente, Júlio

Bom dia DDegrandi na minha cidade passei pelo mesmo problema e tive que alterar a versão também no arquivo PronimV2 pois nele esta 2.02 e o Pronin esta exigindo 2.03 Segue em anexo Pronimv2 203.ini

Bom dia , Aqui no RS também estamos enfrentando este problema, tanto na ciência como na confirmação. 2254 - Falha na validação de esquema Xml

bom dia Pessoal, No DAMDFe em Fortes Report não esta aparecendo a UF FIM, somente a UF INI (UF CARREGA). No xml esta tag esta presente, portanto acredito que falta acrescentar no DANDFE este campo. atenciosamente, Júlio

Após atualizarmos o Fortes Report para a ultima versão, funcionou normalmente.

bom dia Pessoal, Estamos com o mesmo problema do colega Claudio jose, onde na impressão do DACTE em Fortes Report (trunck2), não estão aparecendo os DOCUMENTOS ORIGINÁRIOS, esta aparecendo em 2 páginas, Fizemos o que o colega fez e apareceram os documentos originários, porém isto é uma solução paliativa, alguém mais esta passando por isto??? Quanto a 2 paginas ainda não conseguimos solucionar. grato pela antenção, att Júlio

Boa tarde Italo sabe me informar se tens previsão para a implementação da cidade descrita acima Camaquã RS? Obrigado pela atenção...

Senhores, também atualizei hoje, inclusive desinstalei e removi todo o ACBr, refazendo tudo novamente, tmb manualmente. Confrontei código anterior com o atual e cheguei a seguinte situação. Na função: function TNFeInutilizacao.Executar: Boolean; (ACBrNFeWebServices) Foi adicionano o seguinte código: (comentado) inherited Executar; { if (FConfiguracoes.WebServices.UFCodigo in [29]) and (FConfiguracoes.Geral.VersaoDF = ve310) then // 29 = BA begin Servico := 'NfeInutilizacao'; SoapAction := 'http://www.portalfiscal.inf.br/nfe/wsdl/' + Servico + '/NfeInutilizacao'; end else Servico := 'NfeInutilizacao2'; SoapAction := 'http://www.portalfiscal.inf.br/nfe/wsdl/' + Servico; end; } Texto := '<?xml version="1.0" encoding="utf-8"?>'; Comentei, compilei e instalou. Espero que ajude na identificação do problema. abraço

Prezados colegas, removemos novamente a pasta acbr e atualizamos todo o projeto novamente, e desta vez o problema acima reportado não aconteceu mais. atenciosamente Julio

boa tarde Pessoal, Esta semana atualizamos o acbr como sempre fazemos constantemente. Ao fazer os testes antes de liberar para clientes identificamos o seguinte problema: Enviamos uma nfe 3.1 em homologação, o cabeçalho do xml ficou perfeito. Submetemos ao visualizador do governo e a estrutura esta OK. Mas ao fazer uma CONSULTA, CC-E ou CANCELAMENTO, o xml troca de cabeçalho para nfe 2.0, e submentendo a visualizador do governo da problema na estrutura. Conseguimos contornar a situação sempre forçando os parametros da versão 3.1 em cada um destes eventos. Mas no componente não conseguimos encontrar o momento em que ele esta trocando o parametro para 2.0. Alguém já identificou esta situação? obs. até semana passada estava funcionando perfeitamente a versão 3.1 inclusive em produção, não ocorrendo o problema acima relatado. Fica aqui o alerta. caso alguém identifique onde esta o problema favor disponibilizar aqui. atenciosamente Julio

Funcionou!!! Valeu João Henrique.

bom dia, algum colega esta passando pelo mesmo problema? caso consigam alterar o NotaFiscalEletronica.rav, favor disponibilizar. agradeço a atenção Júlio

bom dia Juliomar, Infelizmente não temos a versão do Rave que permite a edição do NotaFiscalEletronica.rav. Agradecemos a tua atenção. Júlio

Bom dia Nobres Colegas, Estamos com problema na impressão da Hora de Saída no DANFE utilizando o arquivo NotaFiscalEletronica.rav. No arquivo xml está gerando normalmente conforme o xml (3.10) como segue: dhSaiEnt>2014-06-09T19:00:00-03:00</dhSaiEnt>, ou seja, o notafiscaleletronica.rav deve estar lendo na antiga tag. Atualizamos o projeto ontem dia 09/06/2014 as 17:00, efetuamos um build, e atualizamos o arquivo NotaFiscalEletronica.rav e o problema persiste. Alguém esta enfrentando o mesmo problema? atenciosamente, Júlio

Senhores, tive um problema semelhante, mas não acredito que esteja no TS. (Fiz Testes locais e em TS. Ocorre o mesmo problema). ACBr totalmente atualizado. Na última versão tive um problema com impressão do DACTe (QR - Pagina 01/02 para apenas uma), inclusive postei. Junto com este problema, quando fazia um segundo CTe em sequência, sem sair do formulário, me dava problemas com a Sefaz me apontando como se não tinha carregado as configurações básicas, o que não ocorria há algum tempo já utilizando o ACBr. Se sair do formulário e entrar novamente protocola na Sefaz normalmente. Fiz testes na consulta do serviço no sefaz e alternava o erro ( 1=Ok, 2=Erro, 3=Ok, 4=Erro, ...). Resolvi destruir o componente e criar em tempo de execução, com o mesmo código que alimentava das propriedades, funciona perfeitamente. Ainda não tenho certeza do problema, mas solucionei temporariamente voltando uma versão dos fontes do CTe do inicio de agosto/2013 (era a ultima cópia que eu tinha). Se alguém encontrar a solução ou tenha alguma ideia por gentileza me ajudem. Obrigado.

Caro Italo, na tentativa de identificar o problema descobri um detalhe que me parece importante: Fiz dois conhecimentos sendo um parametrizado com carga lotada sim (Rodo.Lota:=ltSim) e outro não (Rodo.Lota:=ltNao). Quando Sim ocorre erro (01/02 - neste caso há mais informações no Dacte e aparentemente ultrapassa as margens), quando Não o Dacte fica correto (01/01). O Gerador de relatório mostra 1/1 em ambos os casos. Modal: Rodoviário. desde já agradeço pela atenção. att Paulo Brasil Desenvolvimento

Quanto as DCU's foram todas removidas. Quanto a URL, usamos esta svn://svn.code.sf.net/p/acbr/code Inclusive, removemos a pasta do ACBR totalmente, baixamos e instalamos tudo novamente na data de 03/09/2013. Recompilamos o projeto (BUILD). Detalhe: Entramos no código do ACBRCTEDACTQR, na linha 316, e lá consta o seguinte comentário "// Incluído por Ítalo em 27/08/2013". Acredito que seja a última versão. Att Tradeone