tradeone

bom dia Renato e Juliomar, Após reinstalarmos o fortes de forma manual, eliminou o erro. obrigado Juliomar e Renato !

boa tarde Juliomar, Obrigado pelo retorno. Quanto ao visible já tentamos com false ... Quanto alteração local no fortes ou no ACBr não fizemos. Quanto atualização do fortes, estamos na versão atual (4.0.1.2 vcl) e baixamos via git, usando o tortoise. Acbr também estamos bem atualizados. O mais intrigante é que temos outro projeto já migrado para o RIO, e este funciona sem o erro em tela.

Prezados, Estou migrando um projeto delphi xe2 para delphi rio, e estou com um problema ao imprimir o danfe do componente ACBr em fortes, estou com a seguinte mensagem de erro ao chamar o imprimir do componente: exception class EInvalidOperation with message 'Cannot make a visible window modal'. O mais estranho é que tenho outro projeto em delphi rio o qual o danfe não dá este erro, já comparei as propriedades etc e estão todas iguais em ambos os projetos. problema: ao gerar danfe do acbr fortes, esta dando uma mensagem de erro, embora o danfe seja exibido normalmente em tela. delphi: RIO componente do danfe: ACBr em fortes (componente e fortes atualizados na ultima versão) erro: exception class EInvalidOperation with message 'Cannot make a visible window modal'. Alguém já passou por este problema, ou tenha uma idéia de como resolver, ficarei grato! atenciosamente Júlio

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