UTC da carta de correção

[_asseinfo_alan]

Bom dia pessoal,

A carta de correção possui um bug onde ele monta o XML com o parâmetro de UTC fixo "-03:00" na tag "dhEvento".

Eu fiz uma correção que respeita o UTC conforme a UF do emitente e o horário de verão caso a UF utilize.

Estou enviando as unit´s modificadas em anexo.

pcnCCeNFe.pas

pcnAuxiliar.pas

Aguardo um retorno sobre o commit da solução no projeto.

Obrigado.

Alan

[Cezinha Anjos]

Olá?!

Alguém sabe dizer se isso já foi feito o merge com o SNV? Já dá pra baixar?

Muito obrigado

[Juliomar Marchetti]

Muito provavelmente não

pois acho pouco tempo de ontem para hoje para o pessoal ver e fazer o merge

assim que alguém dos commiters tiver tempo fará a avaliação a alteração

[_asseinfo_alan]

Boa tarde pessoal,

Tem alguém verificando a minha solução para o CC-e?

Abraços.

[_asseinfo_alan]

Boa tarde pessoal,

Tem alguém verificando a minha solução para o CC-e?

Abraços.

[Cezinha Anjos]

Olá?!

Será que o pessoal já fez o merge da solução?

Me parece que o fonte tá todo pronto... basta fundir.

Muito obrigado

[_asseinfo_alan]

Bom dia pessoal,

Alguém tem alguma resposta sobre o commit da solução?

Gostaria de um feedback para saber o andamento do processo.

Abraços.

[Cezinha Anjos]

Puxa vida... agora que o horário de verão acabou... será que o pessoal irá integrar este código somente no verão que vem?

[Daniel Simoes]

Acho muito deselegante a maneira como este tópico vem se desenvolvendo... Será que vocês acham que tem o direito de nos exigir uma verificação / correção ???

Todo o ACBr é OpenSource, e mantido por voluntários... Sua contribuição provavelmente é muito importante... mas isso não lhe dá o direito de exigir que ela seja analisada e aplicada no tempo que você ache conveniente...

Se ninguem lhe respondeu, muito provavelmente é porque todos estão ocupados com outros assuntos do ACBr ou de suas próprias empresas...

[Mark Apollo]

Sobre o desenrolar, não sei se faço o correto, mas, quando proponho algo e ninguém responde, costumo procurar o moderador da área de passar uma MP para ele, pois acredito que o mesmo talvez não tenha passado pelo meu post, afinal são muitos, após isto fico no aguardo, sempre obtive uma resposta, mesmo que demorada. Para evitar perder minhas alterações mantenho um projeto separado onde instalo no meu delphi, e sempre acompanho todas as alterações quando atualizo meu repositório. nunca tive problemas trabalhando desta forma!

[Cezinha Anjos]

Olá Daniel!

Fiquei muito feliz em saber que você leu o tópico.

Nós entendemos muito bem o que é trabalhar em um projeto open source. Tanto é que nós não ficamos cobrando de ninguém soluções. Nós vimos os problemas, corrigimos e enviamos o código já pronto. Nós participamos também de outras iniciativas abertas.

Eu sei que você não podem integrar tudo o que todo mundo manda. Senão a coisa toda acaba virando o “samba do crioulo doido”.

O problema é que as coisas demoram muito no ACBr em geral.

Se você quiser nossa equipe está a disposição para ser um dos revisores de código. Somos em seis desenvolvedores e eu posso designar alguém para ajudar. Ficaríamos gratos e até mesmo honrados em ajudar na iniciativa.

Existem uma série de refatorações que nós já pensamos em propor, mas no fim das contas a gente acaba desistindo, pois não sabemos se o que iremos produzir alguém irá se interessar e fazer o merge. Nós já pensamos em até construir testes unitários para determinadas áreas, mas até onde isso seria trabalho jugado fora?

Não sei se existe uma forma mais eficiente de resolver o problema. Se necessário for nós até podemos pagar o ACBrSAC para estes casos. A gente só precisa que alguém valide o nosso fonte e faça o merge.

Eu acho que as pessoas não estão reclamando porque elas acabaram dando um “jeitinho” de resolver o problema por fora. Só pra você ter uma ideia, até este momento os arquivos foram baixados em torno de 18 vezes. Alguém com certeza também está usando a solução.

Daniel: eu não quero que você me leve a mau e nem fique ofendido com minhas palavras. Só gostaria que você também desse uma olhadinha no problema com nossos olhos. A gente envia a sugestão e tem a sensação de ser sumariamente ignorado. Isso é ruim. Eu não quero ficar enchendo o seu saco com DMs ou coisa desse tipo. Acho que você delegou para os caras te ajudarem. Se o protocolo de solicitação for o descrito pelo markapollo... tudo bem... a gente posta a solução e depois fica mandando DM para o pessoal. Mas eu acho que isso não é certo.

Bom... é isso aí... mais uma vez te peço desculpas, mas eu acho que não é certo eu deixar de expor minha opinião só porque corro o risco de ser cortado do fórum ou algo desse tipo.

O projeto é muito bom – sou grato por não ter que gastar um real pra ter tudo isso... só que eu também gostaria de ajudar a evoluí-lo de alguma forma... e acho que negligenciar os problemas, ficar achar workarounds e não repassar isso pra comunidade seria uma visão muito egoísta da minha parte.

Obs: acho que agora mesmo é que não teremos mais esta integração... hehehe

[André Ferreira de Moraes]

Para este problema, iremos criar uma propriedade na classe da CCe para ser informado o UTC.

[André Ferreira de Moraes]

Ah, e como já acabou o horário de verão talvez até outubro deste ano fique pronta esta alteração.

[Cezinha Anjos]

Olá André...

A gente criou uma fórmula... baseado na regra do governo... para calcular o horário de verão. Não sei se ajuda... mas já tá naquele fonte.

Muito obrigado.

[Cezinha Anjos]

Olá André... continuando... não sei se essa info te ajuda:

Aquele fonte do Alan faz o seguinte: de acordo com a UF ele já define o UTC. As as UFs regidas pelo horário de verão ele ajusta isso automaticamente no início e no fim do mesmo utilizando a regra do governo.

Creio que a solução dele torna desnecessário tal propriedade.

Espero que ajude.

[Cezinha Anjos]

Olá André... tive uma ideia:

Se você quiser nós podemos criar duas propriedades:

UTC: string -> o usuário informaria o UTC desejado.

AutoDetectarUTC: Boolean -> o UTC seria detectado automaticamente.

Se você der carta branca nós podemos fazer isso e mandar o fonte pra você.

Só não vale commitar isso depois de outubro... hehehe.

Aguardo suas considerações.

[Cezinha Anjos]

Olá André!

Podemos fazer a implementação proposta acima? Ou você gostaria de algo diferente? Nós podemos implementar... basta nos dar um toque que a gente implementa.

Aguardo seu retorno para colocar a mão na massa.

[Danilo Pacheco]

Para a versão 3.10 que engloba NF-e e NFC-e a maioria dos campos tipo Data agora é no Formato UTC (AAAA-MM-DDThh:mm:ssTZD) atualizei o projeto ontem (29/08/2013) mas os campos ainda não foram modificados, posso fazer a modificação e commitar ou voces já estarão disponibilizando esse formato brevemente?

 

Abraços.

[Italo Giurizzato Junior]

Bom dia Danilo,

 

Assim que for liberado os schemas para a versão 3.10 e o ambiente de homologação, vamos iniciar os testes e consequentemente realizar os ajustes necessários para esta versão.