tradeone
-
Total de ítens
35 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por tradeone
-
-
4 minutos atrás, tradeone disse:
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;pelo que analisei o E116 e E250 que usam este mesmo campo, já estão com esta correção.
-
38 minutos atrás, Renato Rubinho disse:
Boa tarde,
No validador você consegue deixar este campo em branco e validar?
Confirme no manual se existe a hipótese de ficar em branco mesmo, pois o opNenhum não está previsto no componente.
../trunk2/Fontes/ACBrTXT/ACBrSPED/ACBrSPEDFiscal/ACBrEFDBloco_E_Class.pas
procedure TBloco_E.WriteRegistroE112(RegE111: TRegistroE111) ; var intFor: integer; intIND_PROC: integer; 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: intIND_PROC := 0; opJusticaFederal: intIND_PROC := 1; opJusticaEstadual: intIND_PROC := 2; opSecexRFB: intIND_PROC := 3; opOutros: intIND_PROC := 9; else intIND_PROC := 9; end;
Caso tenha a documentação confirmando que pode ser em branco e funcionar aí no validador, você pode fazer o ajuste nesta unit e anexar aqui para análise e envio ao SVN.
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
-
11 minutos atrás, Pierobon ツAndré Felipe disse:
Boa tarde, estou tentando fazer um envio de mdfe, porém o emitente não possui RNTRC ativo, e o veiculo é de terceiros, ao informar o rntrc do proprietário do veiculo está retornando apenas 687-Rejeição: RNTRC deve estar associado ao transportador indicado, alguém saberia como resolver?
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
-
1
-
-
Obrigado Italo! Vamos relatar o problema na Sefaz.
-
1
-
-
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
-
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
-
2 horas atrás, tradeone disse:
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
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
-
1
-
-
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
Registro E112, campo IND_PROC, estou passando opNenhum porém no arquivo esta gerando 9- outros onde deveria ficar em Branco.
em ACBrSPEDFiscal
Postado
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