[RFC] edição rapida "inline" de linhas de notas, vendas, compras...

[rvalyi]

Hoje, para editar as linhas de uma nota, uma venda ou uma compra, temos um popup. Isso é diferente do Odoo nativo que tem aquele tree com editable="bottom". Isso acontece porque gente herda essas visões e tira esses editable="bottom".

Pros: isso torna a edição segura e bem explicita com um bom controle dos parametros fiscais.

Cons: Eh mais lento para editar. Mas olha que quando o usario sabe usar o "Save & New" do popup nem é tão mais lento assim.

Proposta Eu não acho isso um grande problema. Mas a gente poderia imaginar de tornar isso uma escolha. Vc poderia escolher a edição rápida inline quando vc ja esta muito seguro com a sua parametrização fiscal e se vc tem algum controle depois. Ou ate para usuarios que precisam editar rapidamente sem tanta necessidade de controle. Por examplo para compras (se houver importação de Nfe depois) ou vendas se houver uma revisão fiscal na hora de validar as notas.

Como Para fazer isso seria necessário ter todos os campos do form da linha dentro do tree tb, ainda que possivelmente invisiveis. Para esses dados persistir depois da dançinha dos onchanges fiscais. Repetir esses campos no tree é o risco de esquecer um, alterar um e não o outro e fazer erros... Nas v13+ isso é ainda mais arriscado porque teria que repetir nos trees de invoice_line_ids e line_ids (segunda aba, visão contábil).

Uma forma de tornar isso uma escolha, poderia ser de ter novos grupos como "ediçao segura das linhas de notas" "ediçao segura das linhas de compras" etc... Se o usuario pertencer desse grupo de ediçao segura (poderia ser o padrão), ai ele teria aquele popup da morte fiscal, com as visões removendo o editable="bottom" desses trees.

Mas um usuario poderia tb nao pertencer a esses grupos e conservar a ediçao inline rapida do Odoo.

So na v14+? Eu tou anotando essa ideia agora aqui para não perder enquanto eu estou quebrando a cabeça migrando o l10n_br_account para as v13 e v14 (https://github.com/OCA/l10n-brazil/pull/1673 mais commits em breve).

Porem eu nao acho uma boa tentar isso no repo da OCA na 12. Na minha opiniao isso iria criar mais coisas para manter na 12.0 no modulo l10n_br_account que ja é um saco para migrar para v13+. Nisso a gente teria uma manutenção mais dificil das varias versoẽs. Minha opinião pessoal seria que a gente deveria estudar isso so depois de ter estabilizado bem na v14 (que migraria "facil" para 15). Se a gente for fazer isso na v14 e estabilizar legal, a gente poderia cogitar um backport na 12 caso nao for muito dificil. Fora esse tipo de contexto, eu sou meio contra tanta mudança na 12.0 em módulos que vão ter um diff importante com a v13+

Comentarios?

cc @renatonlima @marcelsavegnago @netosjb @felipemotter

[felipemotter]

Alguns usuários já reportaram que prefeririam a edição na própria linha, apesar de pessoalmente achar pior pela falta de controle e ter a mesma velocidade no save and New.

A vantagem é que alguns usuários não tem muito conhecimento e precisam apenas digitar um pedido básico. E aquele monte de informação acaba não tendo nenhuma utilidade e gera unicamente a sensação do odoo não ser muito amigável.

[marcelsavegnago]

Dando continuidade ao assunto, acredito que podemos direcionar nosso foco para a inclusão via linha, além de adicionar um botão "Configuração" ao final para abrir o formulário.

Recentemente, deparei-me com duas situações em que precisei adicionar alguns campos no formulário, uma vez que os módulos incluem apenas esses campos na visualização em formato de árvore. O formato atual impede o preenchimento desses campos. Portanto, a inclusão em linha seria mais adequada, pois respeita o padrão nativo de inclusão definido pelo módulo (em linha).

Entendo que ao seguir esse modelo, já eliminamos a necessidade de enfrentar situações semelhantes, como ocorre no módulo account_fleet e ocorria no account_asset_management (agora resolvido, pois submeti uma solicitação de pull request incluindo os campos no formulário da fatura).

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.