Lindomar S. Menezes

Inclusão da classe CancelamentoCTeResposta.cs e InutilzacaoCTeResposta.cs específicas para o CT-e, de acordo com o layout de retorno, assim como as mesmas estão presentes em outros DFe's, para auxiliar na leitura dos dados da resposta caso seja necessário, já efetuei os testes na prática e está funcionado tudo corretamente a principio, classes criadas dentro da pasta Repostas. CancelamentoCTeResposta.cs InutilizacaoCTeResposta.cs

Inclusão da propriedade CRT na classe Emitente.cs para atender a tag de acordo com o MOC 4.0. public CRT CRT { get; set; } Inclusão da classe enumerada CRT.cs no ACBrLib.Core para complementar a propriedade CRT na classe Emitente.cs do CTe. Eu fiz a inclusão da classe em ACBr\Shared\ACBrLib.Core\CTe\CRT.cs, fiz nesse diretório pois achei que era o correto, seguinte o padrão de algumas classes de enumerados que já possuem lá. Testado na geração das TAG's do XML. EmitenteCTe.cs CRT.cs

Tag infPercurso(Identificacao.cs). em desacordo com MOC. Alterado para List(Classe em anexo). public List<InfPercursoCTe> infPercurso { get; set; } = new List<InfPercursoCTe>() { }; Método ReadFromIni(ACBrIniFile iniData) da classe CTe.cs: var m = 0; InfPercursoCTe infPercurso; do { m++; infPercurso = iniData.ReadFromIni<InfPercursoCTe>($"infPercurso{m:000}"); if (infPercurso != null) Identificacao.infPercurso.Add(infPercurso); } while (infPercurso != null); Método ACBrIniFile WriteToIni() da classe CTe.cs: for (var i = 0; i < Identificacao.infPercurso.Count; i++) { var infPercurso = Identificacao.infPercurso[i]; iniData.WriteToIni(infPercurso, $"infPercurso{i + 1:000}"); } A única coisa que não consegui testar, é que não estava alimentando a classe CT-e ali no ReadFromIni(ACBrIniFile iniData), por conta de não ter a tag no iniData, mas no Write estava escrevendo certinho, fui olhar mais a fundo, e cheguei a testar um outro CT-e OS emitido pelo Delphi com percurso informado, e o infPercurso não está sendo obtido pelo ObterIni(), acredito que seja por isso que não está alimentando a classe quando carregado um XML. IdentificacaoCTe.cs

Com base nisso, e em como estou alimentando a classe, também acredito que esteja correto, com a nota exatamente igual, em Delphi é emitida normalmente.

Referente a tag entrega, esse também é o único lugar que há para alimentar a dProg e hProg, e e também estou alimentando conforme o MOC

@Alexandre de Paula Obrigado. Tenho mais algumas outras contribuições que vou ir postando no decorrer da semana, você acha interessante criar novo tópico e postar, ou dá pra ir postando neste tópico por exemplo?

Boa tarde, pequena contribuição no ACBrCTe do C#, a classe InfDoc está em desacordo com o MOC, onde diz que o infOutros pode ter mais de uma ocorrência. Na classe InfDocCTe.cs, apenas alterei o infOutros para lista: public List<InfOutrosCTe> infOutros { get; set; } = new List<InfOutrosCTe>(); Na classe CTe.cs, inseri o código para ler e escrever o INI da infOutros: Método ReadFromIni(ACBrIniFile iniData) da classe CTe.cs: var q = 0; InfOutrosCTe infOutros; do { q++; infOutros = iniData.ReadFromIni<InfOutrosCTe>($"infOutros{q:000}"); if (infOutros != null) GrupoInformacoesNormalSubstituto.infDoc.infOutros.Add(infOutros); } while (infOutros != null); Método ACBrIniFile WriteToIni() da classe CTe.cs: for (var i = 0; i < GrupoInformacoesNormalSubstituto.infDoc.infOutros.Count; i++) { var infOutros = GrupoInformacoesNormalSubstituto.infDoc.infOutros[i]; iniData.WriteToIni(infOutros, $"infOutros{i + 1:000}"); } CT-e gerado: InfDocCTe.cs

Bom dia, no componente ACBr para C# a TAG infCTeMultimodal está divergente de como está na NT, atualmente a classe não está como lista, aceitando somente 1 registro. Fiz a alteração da mesma, segue em anexo arquivo atualizado. alterado de: public InfCTeMultimodalCTe infCTeMultimodal { get; set; } = new InfCTeMultimodalCTe(); para: public List<InfCTeMultimodalCTe> infCTeMultimodal { get; set; } = new List<InfCTeMultimodalCTe>(); Além disso, ela é uma das classes onde não está sendo gerada no XML. Debugando para verificar o processo que é feito, dentro da CTe.cs, no método ReadFromIni(ACBrIniFile iniData), o iniData não contém a ocorrência dessa tag, o mesmo se repete utilizando o comando CarregarXML(), de um XML já emitido que contenha a TAG alimentada, quando eu utilizo o ObterIni(), ou carrego a classe CTe em minha var, com base no INI, a classe não é alimentada. InfServVincCTe.cs

O código de erro é o 460, e tomador é o expedidor, não o remetente. toma = 1

A única coisa que tem aqui no C# pra alimentar são esses 3 parâmetros, que eu acredito que seja respectivo a cada TAG, levando em consideração que comData, comHora e noPeriodo são Choice Groups na NT, oque significa que é de minha escolha qual devo gerar. semData pode ser alimentado com: semDataDefinida = 0, naData = 1, ateData = 2, apartirData = 3, noPeriodo = 4 noPeriodo pode ser alimentado com: semHoraDefinida = 0, noHorario = 1, ateHorario = 2, apartirHorario = 3, noIntervaloTempo = 4 semHora pode ser alimentado com: semHoraDefinida = 0, noHorario = 1, ateHorario = 2, apartirHorario = 3, noIntervaloTempo = 4 Como mencionado nos comentários acima, estou alimentado semData como apartirData = 3, semHora como apartirHorario = 3, e estou alimentando os campos dProg e hProg conforme pede a NT, noPeriodo está por padrão semHoraDefinida pois não utilizo período. Estou fazendo algo de errado nisso?

Linguagem C#. Bom dia, estou tentando emitir um CT-e e está retornando a seguinte rejeição: Rejeição: Não informado os dados do remetente indicado como tomador do serviço Conferindo no meu código onde alimento o Identificacao.Toma, está da seguinte forma(para esse CT-e em específico): newCTE.Identificacao.toma = (int)TomadorCTe.Expedidor Até o momento antes do .Assinar() e do .Validar(), o toma está alimentado corretamente, com o valor 1 (Expedidor), e os dados do meu expedidor estão sendo alimentados da forma correta, conforme imagens abaixo. Utilizando o parâmetro ObterIni(0) do meu CT-e carregado, após LimparLista() e utilizar o CarregarINI(CTe.ToString()) para carregar o mesmo, o toma ao invés de ser preenchido com 1 conforme eu alimentei, está sendo retornado como 0, o mesmo para o XML gerado após assinar e validar. Arquivo INI do meu CT-e em anexo. CTe.txt

Rotina: Alimentação da classe; Assinatura do XML; Validação do XML; newCTe = CTe.cs Alimentado "A partir da data" e "A partir do horário", na classe está ficando da forma correta: Primeiro limpo a lista, em seguida carrego o INI do meu CT-e(se observar os tipos estão alimentados corretamente, conforme imagem acima), após isso coloquei uma variável para retornar o INI que está no componente apenas para verificar se ambos os valores permanece iguais. ACBrCTe.LimparLista(); ACBrCTe.CarregarINI(newCTE.ToString()); var iniCTe = Dfe.ACBrCTe.ObterIni(0); Nessa var que armazeno o INI que está no componente, já está vindo incorretamente, deveria estar sendo alimentado com 3 em ambos os valores. Em relação as datas, elas também estão sendo alimentadas corretamente na classe:

Perfeito, no meu entendimento também acredito que seja incorreto fazer esse tipo de alteração, por isso imaginei que ao fazer isso ele ficava com não enviado, vou verificar aqui e adequar para a forma correta. Obrigado Alexandre.

Boa tarde, estou carregando um XML na minha classe pelo ACBrCTe.CarregarXML(); e utilizando o ACBrCTe.GravarXml() para gravá-lo novamente em outro local. Seguindo uma rotina aqui, nos enviamos o cancelamento do CT-e, e após isso carregarmos, alteramos o protCTe com as informações de cancelamento para ficar atualizado na impressão do CT-e, porém não está salvando essas informações e algumas outras ao gravar o XML, assim quando realizamos a impressão do mesmo através do ACBrCTe.Imprimir(), a impressão é visualizada como se o CT-e não tivesse sido emitido. Nós já possuíamos uma rotina parecida através do componente em Delphi, e precisaríamos que a rotina se mante-se em C#. Está correto dessa forma? Se sim, há alguma outra forma de salvar o XML com o protCTe de cancelamento atualizado?

Segue em anexo ArquivoINI do CT-e e arquivo INI das configurações: ACBrLib.ini CTe.ini

Tudo sendo alimentado certinho, caso a TK-4241 ainda esteja no cronograma, irei aguardar um parece para saber se é algo no componente.

Boa tarde, atualmente ambas as linguagens(por pouco tempo), em Delphi usamos o componente, e no C# usamos as classes em conjunto com as dll's, ACBrCTe32 e 64, ambas estão atualizadas conforme publicação abaixo:

As libs você se refere as dll's (ACBrLib32.dll e ACBrLib64.dll)? Obrigado Alexandre.

Bom dia, estou com a seguinte rejeição na emissão do CT-e 4.0 em C#: Rejeição: Elemento cteCabecMsg inexistente no SOAP Header UF emissão SC. Havia conversado com o Diego Folieni no canal acbr-pro no Discord, porém como estou sem acesso ao Discord vinculado com a conta pro, vou postar por aqui. Em conversa no Discord foi comentado que era pra entrar em contato com a SEFAZ verificando qual o motivo deles estarem exigindo a tag na versão 4.0, pois ela não é necessária, porém comparando as rotinas com a linguagem Delphi, a emissão ocorre normalmente, já em C# retorna esse erro do cteCabecMsg. A configuração do componente está correta, para ser emitida em 4.0. Outra coisa estranha que notei, é no retorno do envio, está voltando como se fosse versão 3.0; Em Delphi e em C#, as classes são alimentadas da mesma forma, seguem a mesma rotina, alimentação das classes, assinatura, validação e envio, no Delphi a mesma nota é emitida normalmente enquanto no C# a nota é rejeitada.

Bom dia. Estou tentando utilizar as tags tpPer e tpHor no C#, porém as mesmas não estão sendo alimentadas. Minha var do CTe, ambos alimentados (noPeriodo, semData e semHora): Valores alimentados na classe Entrega: Estou alimentando da seguinte forma: DateTime dataProgramada = DateTime.Parse(CTESelecionado.DataProgramada.ToString()); switch (CTESelecionado.TipoPeriodo) { case "1 - NA DATA": newCTE.Complemento.semData = TipoPeriodoCTe.naData; newCTE.Entrega.dProg = dataProgramada; break; } switch (CTESelecionado.TipoHora) { case "1 - NO HORÁRIO": newCTE.Complemento.semHora = TipoHorarioCTe.noHorario; newCTE.Complemento.noPeriodo = TipoHorarioCTe.noHorario; newCTE.Entrega.hProg = CTESelecionado.HoraProgramada.ToString(); break; } Forma como estou carregando o componente com o CTe: Dfe.ACBrCTe.LimparLista(); Dfe.ACBrCTe.CarregarINI(newCTE.ToString()); var iniCTe = Dfe.ACBrCTe.ObterIni(0); ArquivoINI(newCTe) em anexo. newCTe.ini

Bom dia @Italo Giurizzato Junior, tudo bem? Muito obrigado, fico no aguardo.

Nessa caso como proceder? Verifiquei aqui e a princípio tá tudo atualizado, mas realmente verificando a classe CTe.cs, na declaração da classe dos complementos, ele realmente não está como List<>, podendo alimentar somente uma ocorrência, por mais que no nosso caso estamos alimentando somente uma ocorrência.

C#, está sendo alimentado da seguinte forma, no seguinte trecho de código: if (CTESelecionado.TipoCte == "1 - CT-E DE COMPLEMENTO DE VALORES") { if (!string.IsNullOrEmpty(CTESelecionado.ChaveAcessoCteComplementado)) CTe.DetalhamentoComplementado.chCTe = CTESelecionado.ChaveAcessoCteComplementado; }

Boa tarde, estou alimentando a classe corretamente, porém ao carregar o INI não está alimentando a classe infCteComp, causando rejeição na hora de enviar(Caso precisem do INI, posso fazer envio por e-mail). Favor, desconsiderar as sections a mais que tem no ini, são aquelas classes que irei repassar para rev para possível implementação, assim que todos os testes com a emissão ocorrerem de forma correta aqui em nosso aplicativo. Libs e fontes do ACBr todas atualizadas. Rejeição no .Validar() Falha na validação dos dados do Conhecimento: 781 TAG:<infCteComp> ID:#411/chCTe(Chave do CTe) - Conte�do inv�lido. TAG:<infCteComp> ID:#411/chCTe(Chave do CTe) - Nenhum valor informado. --> 1839 - Element '{http://www.portalfiscal.inf.br/cte}chCTe': [facet 'pattern'] The value '' is not accepted by the pattern '[0-9]{44}'.