Fim de correções e commits em "Trunk"

[Daniel Simoes]

Olá para todos...

Após estar mais de 2 meses trabalhando no Trunk2... Chegou a hora de abandonar o suporte ao Trunk... Essa semana, é a última que ainda envio correções para o "Trunk"

Deixo essa decisão a ser tomada individualmente para cada um dos "commiters"...  Ou seja, pode ser que outros commiter ainda esteja efetuando correções para o "Trunk"

Motivos para eu deixar de fazer o Merge de minhas correções no "Trunk"

• Estou usando o "Trunk2" a mais de 2 meses
• Está cada vez mais difícil efetuar um "merge" entre as versões, sem quebrar ou esquecer de algo
• Estou gastando muito tempo para efetuar Merges, (tempo que poderia ser aplicados em melhorias dos componentes no trunk2)

Apenas em casos de extrema necessidade, efetuarei correções no "trunk"

Nesse caso, quando receber relatório de erros... Minha primeira pergunta será:   O problema ocorre no "trunk2"  ?

Se na tentativa de reproduzir o erro... eu detectar que o problema não ocorre nos fontes do "trunk2", então resolvido está... 

 

Para reportar problemas no Trunk2, use esse fórum específico:

http://www.projetoacbr.com.br/forum/forum/55-trunk2/

 

Para saber mais sobre o Trunk2, leia esse tópico:

http://www.projetoacbr.com.br/forum/topic/22410-bem-vindo-ao-trunk2/

Editado 9 Julho, 2015 por Daniel Simoes

[Juliomar Marchetti]

Bom dia

também estou usando esse mesmo tempo o trunk2 aqui na empresa e está funcionando corretamente!

por não usar o NFSe e GNRE e estamos usando localmente Fast Report e não houve problemas 

ps: corrigindo o NFSe agora está ok

Editado 10 Julho, 2015 por Juliomar Marchetti

[Régys Silveira]

Aqui está em produção também, tudo funcionando perfeitamente com o FastReport, somente a NFS-e e a GNRE que ainda não.

[Italo Giurizzato Junior]

Bom dia a todos,

Acredito que agora é arredondar as arestas que por ventura sobraram e partir para a NFS-e e GNRE.

Quanto ao NFS-e a minha ideia é termos um INI chamado Cidades (já esta disponível) com a relação das cidades informando qual é o provedor que a atende.

Para cada provedor teríamos também um INI cujo nome é o nome do provedor, por exemplo: Ginfes (já esta disponível), este arquivo contem as particularidades do mesmo.

Os provedores que seguem o padrão ABRASF, se utilizam da versão 1 ou 2, infelizmente existem aqueles que tem algo a mais ou invertido, por exemplo as TAGs de desconto condicional e incondicional.

Para tentar remover dos fontes os valores: proXXXXX que indica um determinado provedor do tipo if FProvedor = proGinfes then ..... a ideia é passar a usar a versão do XML que a principio é 1 ou 2, poderíamos criar uma sub-versão para identificar esses algo mais ou inversão de TAGs, entre outros.

Se conseguirmos chegar a esse ponto, com o surgimento de um novo provedor, bastaria criar um INI para ele e acrescentar as cidades que são atendidas por esse provedor no INI Cidades.

Só teríamos que alterar os fontes do componente caso surgisse uma nova sub-versão.

Já os provedores que não seguem o padrão ABRASF é um caso a parte que devemos estudar qual será o procedimento.

Ou tentar encontrar uma formula que possamos no futuro acrescentar um novo provedor independente se segue ou não o padrão sem precisar realizar alterações nos fontes do componente.

Isso seria o Ideal, mas como o Ideal nem sempre conseguimos atingir vamos focar no Real.

Não estou me referindo ao nome da moeda brasileira.

[Daniel Simoes]

Oi Italo,

Eu ainda não tive tempo de ler os fontes do NFSe, para arriscar uma sugestão para o refactoring...

[Juliomar Marchetti]

Idem Daniel e Italo