[12.0] Contabilidade de custo avançada: CMV/COGS, contabilização das remessas e entradas com o mode anglo-saxon (IFRS/IAS2)

[rvalyi]

According to the Brazilian Federal Accounting Council - the Conselho Federal de Contabilidade - Brazil mostly follows the IAS2 norm of the IFRS standard when it comes to stock accounting [1][2].

This is totally logical for a country adopting the IFRS. And it happens that all countries embracing the IAS2 norm of IFRS should use the anglo-saxon mode of Odoo. Hence maybe half the Odoo localizations in the world use it already. I could also confirm IAS2 needs Odoo anglo-saxon accounting by exchanging a half dozen emails with @gdgellatly, IFRS auditor for 25 years and certainly the best anglo-saxon accounting expert in the OCA [3]

In a word, with the current default continental accounting mode, a company accounts for its Cost Of Good Sold (expense account in product form) when purchasing the products. While with the anglo-saxon mode, a company will delay the accounting of this cost until the sale operation occurs. This is exactly what happens in Brazil with the CMV (Custo da Mercadoria Vendida), the IFRS COGS equivalent. A good introduction to Odoo anglo-saxon mode can be read at [4] while in depth knowledge can be found at [5] and even on the Odoo website itself [6]

Sadly PR #1311 from @mileo and @bmessiaz (KMEE) instead is nothing less than a blind hacky attempt to start re-inventing the Odoo anglo-saxon accounting wheel as I will explain it later.

Instead by enabling the anglo-saxon mode for stock accounting and activating the real time valuation for the considered product for a remessa operation, exactly 0 line of code is required to achieve the same stock account.move.lines as demonstrated in the annexed video, the same as PR #1311 can be achieved on the current project Runbot with no extra code! But yes this current PR activates the anglo-saxon mode properly and covers more situations as I will explain later.

In fact the Brazilian remessas are just a kind of special "COGS only" invoice lines with no financial line. IFRS is mostly used to provide financial figures to investors in countries with little government control over accounting (as opposed to the continental mode). So we are not aware of IFRS countries with equivalent COGS only invoice lines. But Brazil being a federation works a bit like https://github.com/OCA/intrastat-extrastat when moving goods in Europe (something @renatonlima , @alexis-via and I have been pioneering in Odoo a decade ago before shaping the Brazilian localization).

So while one could move goods in a truck to another city in New Zealand without any bureaucracy, in Brazil the same requires an accounting transaction with a "remessa" electronic invoice. This accounting transaction is pretty much like a COGS (Cost of Good Sold or CMV - Custo da Mercadoria Vendida in Brazil) since you will credit your stock. The debit counterpart is just not the COGS or CMV but another result account like "Despesas Comerciais em Despesas Operacionais" in the case of a "brindes" remessa.

So one can basically use the native anglo-saxon COGS lines generation and just remap its account to a different account using an appropriate fiscal position, something that works again out of the box in Odoo but that I improved in this PR to take the fiscal position from the invoice line operation hence enabling to mix several kinds of COGS/remessa lines in the same invoice. Like a simples remessa and a bonification, something PR #1311 cannot do because it tries to transform the unique invoice financial line into the anglo-saxon COGS line.

As for having no financial line in the remessa operations, this was already covered by the l10n_br_account module (since v8) by filtering the financial lines generation when the CFOP (kind of fiscal position) is set to have no financial move. So with the current code, the financial accounting was already correct even with remessas. The only thing is you had the invoice receivable account move line with a 0 debit and 0 credit. This PR simply removes that empty line.

So yes, PR #1311 is useless code, the anglo-saxon mode does all of it already for you, you can do the same on Runbot already (well that is once we revert @mileo latest contribution that breaks invoice validation hard #1559. Sounds like a joke but it's not).

But mostly trying to transform the financial line into the remessa anglo-saxon line with a hacky onchange like in PR #1311 is not consistent! Consider this scenario:

1. If you do a sale with a normal delivery, with PR [12.0][NEW] Correct accounting #1311, you will get your financial move but no COGS/CMV line, You deliver the goods but you will NOT credit your Stock account and you will miss the CMV/COGS.
2. Now if instead you do a sale operation for a later delivery (venda para entrega futura). When you will do the delayed remessa (delivery) with no financial move, then with your PR [12.0][NEW] Correct accounting #1311 hack you will transform the financial move into get your remessa CMV/COGS line and credit your Stock account even without the anglo-saxon mode activated. And if you activate it now you will get your COGS/CMV line twice...

So trying to transform the invoice financial line into a remessa COGS is just inconsistent! You will do half of your stock accounting! What's the point in crying like crazy to get us merge your stock accounting hack in the l10n_br_account module (which doesn't depend on stock_account!) and credit your stock account sometimes yes and sometimes not while you deliver your products??

And this is re-inventing the wheel. Later you will come with another PR for the sale COGS/CMV, later another one for not using the expense account in the vendor bills (as the Continental mode does), later you will come with more PRs to adjust when the invoiced price doesn't match the average cost of the remessas. You will do more PRs to do the permanent inventory move reconciliations... A quick grep into Odoo v14 easily shows Odoo anglo-saxon code is no joke and is easily 4000 lines of code in total. What is KMEE's plan? Re-implement all this anglo-saxon code the KMEE™ way PR after PR when Odoo SA is investing hundreds of thousands R$ per year to maintain the core anglo-saxon mode??

The sad truth is that KMEE's records in the project show they are totally capable of trying to impose such nonsense if we open the door to it, putting a few beginners to implement it and auto-approve themselves together to push it into the project while the same coders would never get a single module accepted in other OCA repos. One can get an idea by looking at their 2017 fork [7] or at some 2021 apocalyptic PRs you need no localization expert to understand how apocalyptic they are #806, #820, #1125 or one can simply look the worst unused, untested and broken code that should have gone in other modules and that they contributed to our l10n_br_fiscal module overnight #1423 without even our approval.

For us who shaped and maintained the Odoo Brazilian accounting modules over the last decade while companies like KMEE were busy irresponsibly selling forks having 0 test and breaking totally 7 years of OCA backward compatibility [7], starting now a fantasy to re-invent the Odoo anglo-saxon wheel PR after PR is a plain no-go and this is why we blocked PR #1311 until we could test enough for several aspects of the Brazilian stock accounting, validate our approach migrates well to Odoo v14 (it does! the KMEE way to reinvent the anglo-saxon mode would just explode migrations costs instead) and find enough time to explain it. And especially the very arrogant behavior from KMEE in the whole PR #1311 and with a half dozen records of such previous broken PRs they tried to brute force into modules we designed and maintained carefully is totally unacceptable, even more unacceptable as this is yet another a foolish improvisation from KMEE who simply had no clue about the Odoo anglo saxon mode obviously.

[1] https://cfc.org.br/wp-content/uploads/2018/04/1_sumario.pdf  - page 12
[2] https://www.iasplus.com/en/standards/ias/ias2
[3] https://www.odoo.com/pt_BR/event/odoo-experience-2019-1629/track/advanced-anglo-saxon-accounting-management-1352 and https://www.youtube.com/watch?v=YJTb1wqRSU8
[4] https://odootricks.tips/odoo-anglo-saxon-continental-accounting
[5] https://www.cybrosys.com/blog/odoo-continental-vs-anglo-saxon-accounting
[6] https://www.odoo.com/documentation/14.0/applications/inventory_and_mrp/inventory/management/reporting/inventory_valuation_config.html
[7] https://github.com/kmee/l10n-brazil/tree/10.0-develop and #568

[OCA-git-bot]

Hi @rvalyi! Thank you very much for this contribution. As the addon you are improving does not have a declared maintainer, I take the opportunity to mention that you can consider adopting it. To do so, please read the maintainer role description, and, if interested, create a pull request to add your GitHub login to the maintainers key of the addon manifest.

[felipemotter]

Fala @rvalyi , realmente a solução parece bem sólida. Estou testando aqui e surgiu uma dúvida: ao tentar editar a CFOP para filtrar os lançamentos financeiros, conforme você instrui na PR, notei que é bloqueado a edição desta pela interface (a menos que eu esteja muito louco). Essa modificação deve ser feita no próprio xml de dados que lança a CFOP no odoo? Ou estou fazendo algo errado? Falo isso porque estou testando pelo runbot

[rvalyi]

Fala @rvalyi , realmente a solução parece bem sólida. Estou testando aqui e surgiu uma dúvida: ao tentar editar a CFOP para filtrar os lançamentos financeiros, conforme você instrui na PR, notei que é bloqueado a edição desta pela interface (a menos que eu esteja muito louco). Essa modificação deve ser feita no próprio xml de dados que lança a CFOP no odoo? Ou estou fazendo algo errado? Falo isso porque estou testando pelo runbot

Ola @felipemotter que bom que tem mais uma pessoa aqui que não esta de bobeira e e que tb não esta do lado da tentativa de carteirada do sujeito @bmessiaz... So o Brasil tem IFRS né, deve ser...

Isso da edição é um feature e nao um bug :-) O que acontece é que tem cadastros fiscais que não devem ser alterado de bobeira nem com frequencia. Por isso nao basta ser "fiscal manager", foi criado um outro grupo a qual vc tem que pertencer para poder editar: "Fiscal Data Maintenance":

Com certeza na v12 ainda que com anglo-saxon ira encontrar muitas situações que vc teria que customizar algo na hora de lidar com o calculo do custo medio, o Graeme Gellatly que é certamente o maior especialista do IFRS Odoo e nos ajudou a criar a OCA me confirmou isso. Mas pelo menos isso já nos deixa do lado certo, resolve os casos simples como os sobre quais a KMEE tava falando no PR #1311 ao invez de dar um tiro no pé e partir para mais uma maluquice que nos impediria de migrar. Mas sera se uma empresa que tava propondo de ferrar a migração de todos quando lançou aquele fork sem comptibilidade nem teste de 2017, que depois deixou largado ferrando quem seguiu, e que de novo uns meses atras fez varios PR's de v14 sem o minimo de preparo antes na v12 para impedir que ou a v12 ou a v14 seja sacrificada realmente se preocupa com a "comunidade"? Falacias interesseiras e agora tentativa de carteirada. Mas fim da palhaçada agora, uma hora ou outra a mascara cai.

Ai na v14 realmente essas questões melhoraram muito com o "stock valuation layer". Na v12 a gente tinha feito varias coisas para ajeitar o "landed cost" nas compras que agora são nativas na v14. Ai bom se livrando de re-inventar o anglo-saxon na v12 a gente tb já pode migrar mais rapidamente.

[felipemotter]

Ahh, entendi, não sabia do fiscal manager kkkk

Sobre o cálculo dos custos, estavamos conversando hoje sobre isso, tenho muito a estudar, mas tô tomando esse PR como ponto de início.

Amanhã eu e o @netosjb faremos mais testes.

[felipemotter]

Essa semana eu e o @netosjb pegamos essa PR como objeto de estudo até porque achamos um assunto bem interessante e que vai nos orientar bastante na forma geral de olhar a estrutura do odoo e da contabilidade por trás dele.

Sabemos que os clientes foco do projeto são empresas pequenas/médias, onde a contabilidade de verdade é feita em escritórios terceirizados com sistemas próprios para isso. Mas mesmo assim, acreditamos que toda evolução é um diferencial do projeto, e queremos ver e ajudar nossa comunidade a evoluir, podendo agregar cada vez mais tipos de clientes com potencial de faturamento superior.

Analisando a PR, utilizamos o seguinte exemplo:

• NF de bonificação concedida
• Um único item sem impostos(para simplificar de início)
• Custo do produto: R$500
• Valor nota: R$800

Desativando os lançamentos financeiros na CFOP e alterando as contas padrões pela posição fiscal, chegamos a essas contabilizações:

D - Despesas de Bonificação(CR): R$500,00
C - Estoques(AC): R$500,00

Mesmo não achando errado dessa forma, como a nota é de R$800, essa diferença de R$300 não está sendo registrada em nenhum lugar e consequentemente não está evidenciando devidamente as despesas de bonificação. Lendo os comentários do @bmessiaz no PR #1311 e validando com um contador de nossa confiança, referente as indicações do CPC, acreditamos que o correto seria da seguinte forma(resumidamente):

D - Despesas de Bonificação(CR): R$800,00
C - Estoques(AC): R$500,00
C - Custo de Mercadoria Vendida(CR): R$300

Usar o modo anglo-saxon me parece mais maduro e racional, mas acredito que precise de alguns ajustes para seguir 100% o CPC em relação a maioria dos casos de bonificação, onde o valor considerado geralmente é o de venda e não o de custo.

Estou fazendo esse comentário apenas porque queremos contribuir com a comunidade, sem o intuito de exigir nada de ninguém. Sabemos que podem haver outras prioridades com um custo x benefício superior a esse PR, mas como vimos que esse assunto já deu bastante polêmica e que pode ser uma necessidade futura, gostaríamos de discutir o que poderia ser feito nesse sentido e até mesmo nos propormos a ajudar.

---

Observação:

• não consideramos os possíveis impostos apenas por questões de simplificação.

Legenda:

• CR: Contas do resultado

• AC: Ativo circulante

[bmessiaz]

@rvalyi

         I confess, I never saw too much NO SENSE and USELESS information  from only one person in my entire life.

         You WON, GO AHEAD AND IMPLEMENT THIS ANGLO-SAXON ACCOUNTING IN BRAZIL.

         GOOD LUCK!

         Sincerely.

        @bmessiaz 

[bmessiaz]

@felipemotter

       Não vai na onda desse @rvalyi só porque ele é o mantenedor do código. Ele não sabe o que fala quando se trata de contabilidade. 

        Concordo com a contabilização proposta pelo colega contador, mas no caso, o exemplo dado foi que o valor da NF seja emitida pelo valor do custo médio do estoque.
        Não faz muito sentido, emitir uma bonificação com valor maior que a que você tem no estoque.(Não é usual, até porque tem o problema de Não dedutibilidade para o  IRPJ/CSSL...a empresa vai pagar 34% de imposto direto sobre o valor da NF, logo, não faz sentido aumentar o valor de 500,00 para 800,00, no seu exemplo.)

       (Além disso, precisa analisar a implicação fiscal do ICMS/IPI/PIS/COFINS, quanto aos estornos de créditos dos impostos dos produtos dados em bonificação.)

       Porque o Governo, não quer que você doe nada..e mantenha o crédito do imposto, ele quer que voce venda...e PAGUE os IMPOSTOS. SIMPLES ASSIM. se você doa...problema seu..mas diminua seu crédito, para pagar mais.

        Comenta com ele, ele vai entender minha linguagem.

          Um abraço.

[rvalyi]

Again, just to make things clear. Activating the anglo-saxon mode alone won't fix all situations out of the box. As I said in PR #1311, doing the full blown legal accounting is still a huge work that will take a long time accross several versions, like in many countries. And it shouldn't be done all in the l10n_br_account module. Like just the anglo-saxon mode actually kicks in stock_account, sale_stock, purchase_stock, mrp_account... You will have a similiar module feature distribution when you will consider assets or cut-off. In no country a single module does it all this is bad design against the Odoo modularity principles.

Now yes, simply activating the anglo-saxon mode totally does what PR #1311 itself does and it is why I blocked it. And yes it's a much saner basis for basing Brazilian cost accounting than trying to hack around the continental mode trying to transform financial moves into COGS moves randomly.

@bmessiaz wow your obstination is truly impressive.

[rvalyi]

Isso. Ai fica que nem as novelas do pysped ou dos CNAB e boletos. Quem bancar arquitetura de estagiário que assume ate o fime a postura com mão na massa (em vez de so dar trabalho pros outros com ideias toscas) e 2 anos depois vemos o resultado sem esquecer quem defendia o que para não tb perpetuar as imposturas e ferrar sempre mais pessoas.

[marcelsavegnago]

Agora precisaria de apoio do @bmessiaz e do @mileo para alinhar com a KMEE esse racional e entender que tanto o anglo saxão como o continental podem coexistir. Sendo assim, provavelmente a PR #1311 deve precisar de algum refactor tanto para garantir a compatibilidade e se for o caso organizar até mesmo com algumas propostas de módulos adicionais. Enfim, teria que sentar e analisar. Mass, uma coisa é certa.... precisa olhar com carinho :D

[rvalyi]

@marcelsavegnago principalmente a #1311 deve pular fora do l10n_br_account (porque na filosofia do Odoo CMV é feito ao nivel do modulo stock_account) e deve ate pular fora do l10n_br_stock_account porque na filosofia do Odoo o CMV é pelo modo anglo-saxon, e tb porque a gente fez 90%"ou mais desses modulos esses 10 anos (basta ver as datas de ultimas alterações desses modulos no fork da KMEE de 2017 para ver que eles tinham completamente abandonado esses módulos https://github.com/kmee/l10n-brazil/tree/10.0-develop que hoje querem encher a boca para falar como se fosse trabalho deles que so trabalhavam contra mais uma vez) e não queremos ter que manter código inutil que vai atrasar as migrações, a compatibilidade entre as versões...

A verdade é que assim como essa de tentar re-inventar o anglo-saxon sem saber, a KMEE nao conseguia fazer um codigo integrado ao modulo account do Odoo, e nisso perdia ate a integraçao com os outros modulos (sale, purchase, stock, project etc...). Isso fica nitido no fork deles. mas não foi so erro de juventude não. Vc vé o @mileo tentando enfiar esse tipo de arquitetura zoada ate em PR (tao insistantes quanto) em 2020 #806 ou aqui #820 (tem que olhar para acreditar sim sim). Eu gostaria não ter que falar disso, mas se o comportamento não muda não tem saida, deixar enganar as pessoas, tentar enfiar um PSC laranja para isso e sabotar o nosso trabalho que não da...

Segundo o PR #1311 mal trata 10% do problema do CMV a não ser que a KMEE quer lançar o CMV das vendas pelos pickings na contramão do que se faz em dezenas de pais (que usam o anglo-saxon para isso). E que é totalmente inconsistente como até o @felipemotter percebeu #1561 (comment)

Mas ai eu quero ver como vai ser quando a empresa vai agrupar 5 pickings no camião, 3 de venda, 1 remessa, 1 outro de bonificação com valor diferente do custo médio na mesma NFe e depois fizer um retorno parcial disso e fazer o suporte do usuário ainda e a migração para a v14.

Ai a divida tecnológica não sera mais de 150 linhas não e não queremos ter que manter e migrar esse tipo de coisa. Porque viver de postura e de carteirada é fácil, fazer projetos de verdade é outra coisa... Eu quero ver a KMEE começar por acertar os proprios módulos deles antes de querer se meter em coisas que não tem o minimo domínio e espalhar dividas tecnológicas inuteis nos módulos dos outros. Depois a gente pode ver. Quem me achar radical, que leia com calma os comentários do PR #1311 na sequencia (e não adianta apagar a pagina e a branch estão salvos). Sendo que é a decima vez que rola palhaçada do tipo no projeto.

[antoniospneto]

Pessoal,

Apesar da melhoria proposta nessa PR, aparentemente não atende todos os casos que o @bmessiaz deseja resolver com a PR #1311, a baixo detalho dois cenários:

1. Envio/retorno de bens para concerto (utilizando as contas de estoque)

Exemplo:

Pela remessa dos bens:

D- Estoque em poder de Terceiros (conta fictícia para ilustrar)
C- Estoque

Pelo retorno dos bens consertados:

D- Estoque
C- Estoque em poder de Terceiros (conta fictícia para ilustrar)

Tentei fazer esses lançamentos alterando as posições fiscais, mas no final não consegui fazer a substituição da conta "Fornecedores" por " Estoque em poder de Terceiros" na fatura do fornecedor.

---

Apesar de eu ter tentado fazer da forma acima, para fins de testes, além de não ter sucesso, acredito ser a maneira incorreta. Pesquisando um pouco na internet, vi que o mais correto para esse caso é utilizar as contas de compensação, conforme descreve o artigo: http://www.portaldecontabilidade.com.br/guia/contascompens.htm

Exemplo:

Pela remessa dos bens:

D- Bens Remetidos para Conserto (Conta de Compensação Ativa)
C- Conserto de Bens por Terceiros (Conta de Compensação Passiva)

Pelo retorno dos bens consertados:

D- Conserto de Bens por Terceiros (Conta de Compensação Passiva)
C- Bens Remetidos para Conserto (Conta de Compensação Ativa)

fonte: https://www.contabeis.com.br/forum/contabilidade/285879/contabilizacao-de-uma-nf-de-remessa-para-conserto/

Mesmo ativando o anglo-saxon não consigo imaginar uma forma de configurar e contabilizar essas contas de compensação.
da mesma forma que não concordo que isso deva ser resolvido alterando os lançamentos financeiros, como proposto na PR #1311

Não sei se existe alguma outra maneira de lidar com isso atualmente sem alteração de código, a minha ideia é criar um modulo adicional, para que adicionasse um flag na "operação fiscal" e uma nova aba de configuração com as conta de débito e crédito das contas de compensação e sobrescrever o método da invoice para que verificasse esse flag e caso estivesse ativo, fazer os lançamentos contábeis de compensação. sem interferir nos lançamentos de financeiro e sem interferir nos lançamento de estoque.

O que vocês acham ?

@rvalyi @bmessiaz @mileo @marcelsavegnago @renatonlima

[rvalyi]

Ola @netosjb que bom que vc ta olhando melhor essas coisas. Bem de inicio me parece que vc esta errando algo: o anglo-saxon nao esta tentando lançar o CMV atraves do lançamento financeiro como o PR #1311 (que bom que vc se ligou que era erro conceitual tb).

Mas nisso, nao é a conta "Fornecedores" que tem que substituir na posiçção fiscal, é a conta "Custo da Mercadoria Vendida" ou enfim o que tiver no expense_account do produto ou na categoria de produto. Vẽ com calma meu examplo aqui: #1561 (comment)

E olha esse print em especial:

Eh aqui na direita que vc tem que enfiar a sua conta "Estoque em poder de Terceiros".

Sobre as contas de compensação eu te respondo depois mas talvez vc tem que estudar as propostas de melhorias que eu sugeri aqui para criar um write-off quando o valor no invoice não bate aqui #1561 (comment) (não faz parte do PR ainda mas são mudanças simples). Sobre onde ficaria parametrizado a conta do write-off a questão esta aberta sim, talvez na operação tem que pensar...

[antoniospneto]

@rvalyi

Então, é que na verdade, pelo que pude perceber, os lançamentos de CMV criados pelo "anglo-saxon" é somente na fatura do cliente (customer invoice). Depois, na hora de fazer o retorno dessa mercadoria com a fatura do fornecedor (vendor bill) não existe os lançamentos de CMV por esse motivo não há como fazer a substituição de contas na posição fiscal, segue a baixo uma demonstração dos lançamentos de entrada ao receber a fatura e a mercadoria, retirado do site da Odoo SA:

Quanto as contas de compensação, o valor do lançamento será sempre o valor cheio da nota fiscal ai acho que não cabe o write-off nesse caso.

Fizemos esses testes apenas para fim de avaliar até que ponto a PR consegue solucionar os problemas de contabilização e encontramos a dificuldade nestes casos. No momento isso não é um problema real para nós.

Ao meu ver a solução mais interessante para as contas de compensação seria criar um pequeno modulo adicional , que não interfira na lógica de negocio dos lançamentos financeiros, nem dos CMV, nem no estoque. Um módulo que apenas faça esses lançamentos separados de tudo. Ai por exemplo em uma nota fiscal de "Remessa de bens para concerto" no CFOP é só ativar o flag de lançamento de compensação e desativar o flag de lançamento financeiro e de estoque.
Acho interessante essa abordagem pois não mistura as lógicas. Mas como eu disse isso não é um problema real para nós, não no momento e isso pode ser proposto em outra PR, minha intenção é apenas dar o meu feedback.

Somos gratos por toda sua colaboração e paciência com a gente.

[bmessiaz]

Prezado @rvalyi @renatonlima @mileo @felipemotter @netosjb @marcelsavegnago @gabrielcardoso21 @luismalta @ygcarvalh @ananiasfilho @DiegoParadeda @sadamo

Para acabar com esse PR FAKE, segue a resposta do próprio IASB - International Accounting Standards Board (Conselhoo Internacional de Padrões Contábeis).

Caso @rvalyi insista em levar a localização brasileira do Odoo para algo "ILEGAL" NO BRASIL, a RESPONSABILIDADE SERÁ DELE E DE QUEM O APOIAR.

Logo, logo vou publicar também minha consulta o CPC/CFC. Comitê de Pronunciamentos Contábeis/Conselho Federal de Contabilidade.

TRADUZINDO O EMAIL ABAIXO:

"Resumindo, eles desconhecem a contabilidade anglo saxônica..e não podem nem comentar a mesma. Significa que não tem compatibilidade nenhuma com o IFRS. Acho que isso basta pra validar meu ponto de vista. O Mundo Sério e Organizado usa o IFRS, os demais ainda estão presos à contabilidade "alquimista", Um abraço."

[bmessiaz]

1. Not an auditor, but Chartered Accountant doing stock and inventory accounting forever. This all IMO. I know very little about Brazilian fiscal environment.
2. Anglosaxon is not a real word in accounting so can't be illegal anywhere. Outside of Odoo, and a few German academics the correct term for Anglosaxon Accounting is just Accounting
3. Odoo 'Anglosaxon' applies primarily to IAS 2 (in IFRS terms, but US GAAP is very similar). This standard has been in place, mostly unchanged in spirit since 1975, and almost identically worded since 1993 and predates IFRS. Odoo's implementation serves 3 purposes. 1. Comply with IAS2, 2. Not mess up non IFRS accounting, 3. Maintain a consistent valuation of stock between Odoo Accounting and Odoo Inventory. - unfortunately meeting all those has compromises, but it is still pretty acceptable.
4. IFRS 15 is a whole different thing. It doesn't apply here at all (Revenues not Costs) and even if it did it doesn't really apply to standard transactions. It is primarily about recognising contract revenue when obligations are performed over a period of time on contracts that cross periods. Like building a road or factory. No accounting system I know of can implement IFRS15 in an automated fashion. It is very detailed and often requires industry specific modelling and manual entries at period end if you don't structure contract revenues inline with performance obligations.
5. Insofar as standard IAS2 transactions may bring about timing differences, even if you still believe IFRS15 applies (it doesn't), they are usually a matter of hours and immaterial. But even so, it is easy to correct at period end. With Odoo anglosaxon and realtime you need to do this entry anyway (one of the compromises). IFRS is primarily focused on presentation of General Purpose Financial Reports in regulated securities markets, not day to day bookkeeping or management information systems.
6. In terms of international standards IFRS is pretty much everywhere for regulated markets now except US although IASB and FASB are in harmonization efforts with GAAP. That said very few countries adopt every IFRS word for word (mine is one of the few) and even when they do, the date of application and transitional/differential rules are often different.
7. Sounds like you all need to get a good Brazilian accountant on board. Lots of misinformation in here. There's a reason it takes upwards of 7 years to become an accountant with professional membership. If you search accounting standards without understanding their history or application you can usually find whatever answer you want.

However, if you read the history of how anglosaxon came to be in Odoo (v5, still on launchpad somewhere) it would be clear that as it stands today, for those subject to IFRS, it is Anglosaxon for realtime, no anglosaxon (with some small adjustment) for periodic. But I doubt that anyone big enough for IFRS is really using periodic. I think at the time, people just talked at cross purposes.

Dear @gdgellatly

Thanks and be welcome for your contribution, however Brazil has a very straight forward legislation regarding this matter, in summary Anglo-saxon accounting is forbidden to us.

Please read law 11.638/2008, which was the formal institution of IFRS in Brazil.

I'm under the impression that @rvalyi is not showing you the full scenarion about accounting rules in Brazil which can drive you to a wrong perspective.

In my opinion, insist on to implement it in Brazil will lead Odoo to a very, very wrong approach for the Brazilian localization, in close future OCA/ODOO will pay the huge price for this mistaken decision, potentials big customers will just run out from ODOO using anglo-saxon accounting system.

I wash my hands about the final results of this anglo saxon accounting adoption, nevertheless I tried hard to warn responsible people for it at OCA in Brazil. (@rvalyi )

You can check at our CVM(SEC) the formal instructions to use the law 11.638/08 for all companies which have stocks on SEC.(just as information, this law is also extented to SMEs. cool right? everybody uses IFRS here)

https://www.gov.br/cvm/pt-br/assuntos/noticias/cvm-edita-instrucao-n469-08-que-trata-da-implementacao-da-lei-n-11638-08-a7faf99f55284a70af665b380895009e

Being very straight and objective, in my opinion there is no "room" to use any other creative accounting method in Brazil!..so, End of History, respectfully speaking.

In addition to all aforementioned, I wrote a question to IASB about this anglosaxon accounting, please note their answer below.

I really look forward one day to meet you in person to talk about other more interesting things such as budgeting control in an ERP, or other ones. Nothing about this defined subject for our country.

Kind regards,

[rvalyi]

Prezado @rvalyi @renatonlima @mileo @felipemotter @netosjb @marcelsavegnago @gabrielcardoso21 @luismalta @ygcarvalh @ananiasfilho @DiegoParadeda @sadamo

Para acabar com esse PR FAKE, segue a resposta do próprio IASB - International Accounting Standards Board (Conselhoo Internacional de Padrões Contábeis).

@bmessiaz Pergunta tb para eles tb se eles conhecem "a contabilidade do onchange que transforma o financeiro em CMV do Luis de Itajuba" do #1311.
Ou sera se no caso do #1311 vc ta julgando pelos lançamentos e no caso do #1561 não? (como todos já perceberam aqui)

Depois mostra para gente ai como vc lança uma NFe com venda, remessa e bonificação juntas na mesma NFe com #1311. Porque sim temos projetos reais com industrias que agrupam as entregas e fazem esse tipo de coisa a contrario da KMEE. Como sera que a KMEE nao tem como a gente varios clientes que faturam milhoẽs no Brasil cada mes no Brasil com Odoo (e pequenos tb) se vcs são tao fodoẽs? Mostra ai para gente como vc lança isso #1561 (comment) com o PR #1311

Bom ja que eu vejo que vcs nem testaram o modo anglo-saxon pelo jeito e que vc so ataca isso pelo nome "anglo-saxon" sendo que ele poderia se chamar de qualquer coisa e que esse nome é apenas "legacy" como o Graeme ou o @felipemotter tentaram te explicar, vamos mesmo tirar essa configuração do plano l10n_br_coa_generic da KMEE e ai vcs se viram fazendo um modulo de CMV continental mesmo. A gente so dispara as coisas desse PR se for o modo "anglo-saxon" e vcs disparam as coisas de vcs se for o modo "continental" e ai ninguem atrasa a vida de ninguem. Eu tive alguma leve esperança que o @mileo se tocasse do erro, mas bom, ja que a KMEE ta apostando em vc que nunca fez um projeto com Odoo ainda e entende menos de open source ainda, boa sorte para vcs...

Agora vc so pode ter certeza que vou jogar isso na cara de vcs daqui alguns anos quando vcs terão abandonado e farão propaganda usando as soluções que desenhamos como é o caso hoje. Assim como vcs ababanonaram o https://github.com/aricaldeira/PySPED que vcs tinham ate contratado o autor que eu consegui trocar anos de trabalho manual dele por algumas linhas de gerador de código ou os CNAB com pycnab ou o fork de 2017 https://github.com/kmee/l10n-brazil/tree/10.0-develop de vcs onde quem seguiu se ferrou.

[rpsjr]

Galera, uma pequena contribuição aqui...
Tenho formação em contabilidade e sou pesquisador. Contabilidade Empresarial não é minha especialidade mas imagino que posso contribuir um pouco.

A contabilidade brasileira é sui generis, realmente única. Hoje, e há mais de uma década já, vivemos um processo denominado harmonização/convergência às normas internacionais (leia-se IFRS). Mas o que é esta harmonização/convergência? Pensem como um refactoring de um código (a contabilidade) que é feito com muita dificuldade pois há requisitos que não dão muita margem para modificações (leis empresariais e tributarias) do código e se divide em muitas branchs (partes empresariais). O resultado deste refactoring são os Pronunciamentos do Comitê de Pronunciamentos Contábeis. Assevero aos senhores que o empreendimento que todos vocês labutam é de uma complexidade realmente complicada.

A despeito do arquitetura proposto pela Odoo, fazendo distinção entre a contabilidade anglo-saxônica e continental, muitos companheiros já observaram que não se trata de padrões (standards) contabeis como o IFRS e o US GAAP. Todavia, esta distinção tem uma origem histórica nas divergências históricos geográficas da contabilidade aplicada no velho continente e nos EUA. E o Brasil, onde fica nisso? Bom, nos temos o BR GAAP, a origem da nossa contabilidade é continental, herança de Portugal. Mas logo após a independência passamos a sofrer um forte processo de americanização contábil, ainda ao nível das leis. Hoje, a dita convergência, busca construir práticas contábeis por meio de Pronunciamentos que conformem as nossas práticas tanto às nossas leis miscigenadas quanto às IRFS. Percebam que as leis não podem ser sobrepostas e muitas vezes o produto da convergência é uma prática similar à IFRS, muitas vezes há diferenças.

Neste PR vejo elementos robustos que apontam para uma similitude entre a contabilidade anglo-saxônica da Odoo e a BR GAAP, mas que não são suficientes para determinar se a contabilidade anglo-saxônica é mais econômica programaticamente.

Confiram este texto: https://www.treasy.com.br/blog/ifrs-x-br-gaap-x-us-gaap-gestao-orcamentaria/

Espero ter ajudado.

[marcos-mendez]

Eu gosto de ver tudo isso pois estou aprendendo muito, a lei do minimo esforço as vezes nao se aplica e no Brasil tem coisas que realmente nao da pra entender porque sao como sao. @bmessias vc tem certeza que essa eh a lei mais recente??. Mesmo sobre a questao legal acho que o legalismo eh um impecilio. A gambiarra do rafael parece funcionar tem que dar uns retoques e ai quem sabe atende o método continental. A questao legal nao me preocupa hj em dia tudo que faço eh meio ilegal sabe, mas nao eh anti etico nem imoral rsrs....temos que ver isso da funcionalidade e da legalidade @rafael acho que todos queremos uma melhoria do projeto nao precisa pegar o felipe de santo. @Milleo da a cara pra bater manolo voce sabe que temos que chegar num concenso @bmessias nao te conheco cara bc psrece ssber de contabilidade mas suas palavras sao pesadas. Pensa que isso pode causar uma rejeicao nums comunidade do tipo FOSS @marcel Savegnago ***@***.***> como vc ve essa questao legal?? La em bertioga o projeto vai precisa dessa poha nao vou por meu cu na reta se vc falar que ta tosquera. Aprovo o que voce falar mano Enfim paz para todos Nao briguem voces parecem criancas as vezes Hj perdi 8 pessoas numa UTI porque o prefeito da cidade nao comprou um filtro de ar de 30 reais. A vida eh curta e nossos projetos ambiciosos. Nao encham o saco por futilidade. Facam as relacoes serem leves e prazerosas. Quando eu morrer quero lembrar de vocês como os caras fudidos que fizeram o FOSS no brasil ser realidade. Nao como os adolecentes treteiros Bjos amo todos voces Em qua, 25 de ago de 2021 23:18, Raimundo Pereira da Silva Junior < ***@***.***> escreveu:

…

Galera, uma pequena contribuição aqui... Tenho formação em contabilidade e sou pesquisador. Contabilidade Empresarial não é minha especialidade mas imagino que posso contribuir um pouco. A contabilidade brasileira é sui generis, realmente única. Hoje, e há mais de uma década já, vivemos um processo denominado harmonização/convergência às normas internacionais (leia-se IFRS). Mas o que é esta harmonização/convergência? Pensem como um refactoring de um código (a contabilidade) que é feito com muita dificuldade pois há requisitos que não dão muita margem para modificações (leis empresariais e tributarias) do código e se divide em muitas branchs (partes empresariais). O resultado deste refactoring são os Pronunciamentos do Comitê de Pronunciamentos Contábeis. Assevero aos senhores que o empreendimento que todos vocês labutam é de uma complexidade realmente complicada. A despeito do arquitetura proposto pela Odoo, fazendo distinção entre a contabilidade anglo-saxônica e continental, muitos companheiros já observaram que não se trata de padrões (standards) contabeis como o IFRS e o US GAAP. Todavia, esta distinção tem uma origem histórica nas divergências históricos geográficas da contabilidade aplicada no velho continente e nos EUA. E o Brasil, onde fica nisso? Bom, nos temos o BR GAAP, a origem da nossa contabilidade é continental, herança de Portugal. Mas logo após a independência passamos a sofrer um forte processo de americanização contábil, ainda ao nível das leis. Hoje, a dita convergência, busca construir práticas contábeis por meio de Pronunciamentos que conformem as nossas práticas tanto às nossas leis miscigenadas quanto às IRFS. Percebam que as leis não podem ser sobrepostas e muitas vezes o produto da convergência é uma prática similar à IFRS, muitas vezes há diferenças. Neste PR vejo elementos robustos que apontam para uma similitude entre a contabilidade anglo-saxônica da Odoo e a BR GAAP, mas que não são suficientes para determinar se a contabilidade anglo-saxônica é mais econômica programaticamente. Confiram este texto: https://www.treasy.com.br/blog/ifrs-x-br-gaap-x-us-gaap-gestao-orcamentaria/ Espero ter ajudado. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJEVVIBYRMBSQRERRHJLWNDT6WP6FANCNFSM5CANBJZA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[rvalyi]

Galera, uma pequena contribuição aqui...
[...]
A despeito do arquitetura proposto pela Odoo, fazendo distinção entre a contabilidade anglo-saxônica e continental, muitos companheiros já observaram que não se trata de padrões (standards) contabeis como o IFRS e o US GAAP. Todavia, esta distinção tem uma origem histórica nas divergências históricos geográficas da contabilidade aplicada no velho continente e nos EUA. E o Brasil, onde fica nisso? Bom, nos temos o BR GAAP, a origem da nossa contabilidade é continental, herança de Portugal. Mas logo após a independência passamos a sofrer um forte processo de americanização contábil, ainda ao nível das leis. Hoje, a dita convergência, busca construir práticas contábeis por meio de Pronunciamentos que conformem as nossas práticas tanto às nossas leis miscigenadas quanto às IRFS. Percebam que as leis não podem ser sobrepostas e muitas vezes o produto da convergência é uma prática similar à IFRS, muitas vezes há diferenças.

Neste PR vejo elementos robustos que apontam para uma similitude entre a contabilidade anglo-saxônica da Odoo e a BR GAAP, mas que não são suficientes para determinar se a contabilidade anglo-saxônica é mais econômica programaticamente.

Valeu pela contextualização historica @rpsjr . Veja bem o IFRS é uma serie de normas bem extensas. Porem como o Graeme que é super especialista dessa parte explicou, e como expliquei no inicio do PR, o modo "anglo-saxon" do Odoo procura aderir apenas a norma IAS2 que vem de antes do IFRS ate como o Graeme falou e que é so uma pequena parte do IFRS a qual as normas brasileiras obedecem: "De uma maneira geral a norma brasileira é similar ao IAS2" como dito nesse tal de pronunciamento do conselho federal de contabilidade:
https://cfc.org.br/wp-content/uploads/2018/04/1_sumario.pdf - page 12

Quando vc considera o CMV da venda, e se vc toma 20 minutos para ver como é tratado o COGS=Cost Of Good Sold=Custo da Mercadoria Vendida dentro do Odoo pelo modo anglo-saxon como https://www.cybrosys.com/blog/odoo-continental-vs-anglo-saxon-accounting vc vé que isso atende perfeitamente o CMV das operações de venda.

Uma forma simples de ver que esse anglo-saxon atende tb a remessa é de imaginar uma simples remessa como uma entrega diferida da venda. Onde o Graeme na Nova Zelandia ele ja registraria o CMV de entrega dele mesmo se ele entregar 2 meses depois da venda, no Brasil vc teria uma primeira nota de venda sem lançamento "anglo-saxon" de CMV/COGS e depois vc teria uma nota de remessa dessa vez sem financeiro (o que a gente faz desde a v8) mas com o CMV/COGS que ficou faltando na venda. De forma que se vc juntar as 2 operaçoes vc tem o mesmo resultado nas contas do que se vc tivesse feito uma venda normal com a entrega direitamente.

Pois a grande diferença que tem no Brasil é mesmo essa questao da operaçao remessa. Trocando emais com o Graeme fiquei sabendo de nehnum pais que teria o IFRS junto com o conceito de remessa.
MAS @renatonlima, o nosso socio @alexis-via e eu temos muita experiencia com algo semelhante que acontece quando vc vende de um pais europeu para outro e que é feito atraves desses modulos https://github.com/OCA/intrastat-extrastat no Odoo. Fomos os primeiros a lidar com isso no Odoo la em 2009 e isso super nos ajudou a desenhar varias coisas da localização.

Isso porque o Brasil é uma federação de estados onde cada um tem uma certa soberania fiscal. Assim como acontece na Europa apesar que no Brasil a integração federal é bem maior. Nisso na Europa uma empresa digamos francesa nao poderia simplesmente transferir produtos para Belgica e vender por alguma filial com impostos menores por examplo. Se vc fizer isso vc tem que declarar a transferencia de produtos para a federação com documentos que sao um pouco semelhantes a NFe de remessa (mas sendo padrão europeu nao se encaixam tb no padrao da fatura electronica de um pais X de união).

No Brasil, alem da emissao de uma NFe de remessa, a lei obriga a fazer lançamentos de taxas (o que fazemos desde a v8) mas tb um lançamente de credito ou debito com a conta Estoque e uma outra conta de contra-partida. Como CMV ou "Estoque em poder de terceiros".

Mas enfim isso nao deixa de ser um lançamento de contabilidade de estoque para cada linha de produto exatamente como faz o modo "anglo-saxon", nao tem nada ver com o unico lançamento financeiro global da NFe (que ja é neutralizado no caso de uma remessa) e que o @mileo tanta desviar hackeando a conta de Clientes no PR #1311. Não é dificil sacar que eles fizeram isso porque nunca nem se tocaram que existia esse modo anglo-saxon e que a metade dos paises usam. Nem entenderam a diferença conceitual entre contabilidade financeira e contabilidade de estoque, o simples fato deles lidar com isso no l10n_br_account e de forma super superficial demostra isso.

---

@marcos-mendez mano testa um pouco os PRs para nao acreditar em qualquer coisa. O que define a legalidade da soluçao nao é se o nome do metodo no Odoo se chama def _anglo_saxon_sale_move_lines ou def _ifrs_ias2_sale_move_lines mas sim se faz a porra dos lançamentos correctamente. Ai o PR #1311 ja ta desmascarado faz tempo. Ele nao lança casos de bonificaçoes como o @felipemotter deu aqui #1561 (comment)
O anglo-saxon, com umas 20 linhas a mais nesse PR faria bonitinho como eu mostrei #1561 (comment)

Mas alem disso é facil entender: se vc precisa DEBITAR UMA CONTA DIFERENTE para uma linha de remessa, para uma linha de bonificação ou ate para uma linha de venda (clientes). Como vc quer então que a solução do @mileo do #1311 possa usar O UNICO DEBITO TOTAL DA UNICA LINHA FINANCEIRA DO INVOICE para fazer cada debito separado de uma linha de remessa, uma linha de bonificação e uma linha de venda na mesma NFe???? Ai vc vai falar ah tudo bem vou lançar 3 NFe's diferentes. E quando vc vai receber a NFe do seu fornecedor que vai juntar varias operações mesmo, vc vai fazer o que?? O @bmessiaz vai trazer o rivotril para seu cliente ou vai ser que nem o fork deles de 2017, o pysped ou o pycnab vai ficar tudo largado para la e vão fingir que não foi com eles?

Mas mesmo que vc nao pegue um caso tão critico porem totalmente real. Porque que uma NFe de remessa vai creditar seu estoque quando vc valida-la (e debitar seu CMV) enquanto que uma NFe de venda do mesmo produto, ela vai usar seu lançamento financeiro pro financeiro mesmo entao nao vai poder creditar o estoque nem debitar o CMV. Ai os bonitinhos da KMEE fazem lançam o CMV da venda pelo inventario permanente quando vc valida o picking de entrega. Porque essa inconsistencia toda? E sendo que faltaria bastante codigo para a venda lançar o CMV no picking e a remessa não...

---

@netosjb OK eu entendi melhor o que vc queria no seu ultimo comentario #1561 (comment) Esse caso de remessa de retorno teremos que sobrecarregar para que o anglo-saxon faça os lançamentos de estoque como se fosse um caso de "refund" de nota de cliente e nao como uma nota de fornecedor(nesse caso ele lança sim). Accredito que seja pouca coisa viu, esses dias eu testo.

[rvalyi]

Mas assim pessoal, fiquem tranquilo, a gente nao vai impor nada para ninguem nao. A KMEE vai poder fazer seu modulo de remessa sem anglo-saxon la. Assim como ela pode subir um modulo de NFe com pysped ja que na epoca das v7 e v8 a gente teve que brigar o mesmo tanto para impedir que eles contaminasse todo codebase com o pysped como fizeram no fork deles (abandonado porque sera?), ou assim como ainda esperamos o modulo de CNAB deles com pyCNAB que era tão melhor que a lib do boletosimples brcobranca que so faltou eles arrumar um laranja para declarar que era ilegal tb. Passando o teste coverage e os criterios da OCA, nao interferindo com o modo anglo-saxon a gente aprova la tranquilo o modulo deles e geral fica feliz. Nao vai demorar duas versoẽs para a seleção natural do open source fazer o trabalho, precisa de nenhum ditador não.

[marcelsavegnago]

Mas assim pessoal, fiquem tranquilo, a gente nao vai impor nada para ninguem nao. A KMEE vai poder fazer seu modulo de remessa sem anglo-saxon la. Assim como ela pode subir um modulo de NFe com pysped ja que na epoca das v7 e v8 a gente teve que brigar o mesmo tanto para impedir que eles contaminasse todo codebase com o pysped como fizeram no fork deles (abandonado porque sera?), ou assim como ainda esperamos o modulo de CNAB deles com pyCNAB que era tão melhor que a lib do boletosimples brcobranca que so faltou eles arrumar um laranja para declarar que era ilegal tb. Passando o teste coverage e os criterios da OCA, nao interferindo com o modo anglo-saxon a gente aprova la tranquilo o modulo deles e geral fica feliz. Nao vai demorar duas versoẽs para a seleção natural do open source fazer o trabalho, precisa de nenhum ditador não.

A única ressalva em relação a módulos alternativos é que se houver duas opções para fazer a mesma coisa e ambos os módulos forem instalados automáticamente no runbot, a melhor opção seria alguma configuração na empresa ou no plano de contas (como no caso do anglo-saxão) para o sistema saber qual módulo deve ser utilizado por aquela empresa.

[rvalyi]

Mas assim pessoal, fiquem tranquilo, a gente nao vai impor nada para ninguem nao. A KMEE vai poder fazer seu modulo de remessa sem anglo-saxon la. Assim como ela pode subir um modulo de NFe com pysped ja que na epoca das v7 e v8 a gente teve que brigar o mesmo tanto para impedir que eles contaminasse todo codebase com o pysped como fizeram no fork deles (abandonado porque sera?), ou assim como ainda esperamos o modulo de CNAB deles com pyCNAB que era tão melhor que a lib do boletosimples brcobranca que so faltou eles arrumar um laranja para declarar que era ilegal tb. Passando o teste coverage e os criterios da OCA, nao interferindo com o modo anglo-saxon a gente aprova la tranquilo o modulo deles e geral fica feliz. Nao vai demorar duas versoẽs para a seleção natural do open source fazer o trabalho, precisa de nenhum ditador não.

A única ressalva em relação a módulos alternativos é que se houver duas opções para fazer a mesma coisa e ambos os módulos forem instalados automáticamente no runbot, a melhor opção seria alguma configuração na empresa ou no plano de contas (como no caso do anglo-saxão) para o sistema saber qual módulo deve ser utilizado por aquela empresa.

Sim é a ideia mesmo: botar o flag anglo_saxon_accounting visivel na empresa e explicar no README que tem então duas abordagens para lidar com o CMV e orientar pro modulo da KMEE para quem nao quiser usar o modo anglo-saxon. E tb seria legitimo nao enfiar o use_anglo_saxon=True por padrão no modulo l10n_br_coa_generic que foi feito pela KMEE. Apenas garantir que seja facil trocar no Runbot . Novamente ate hoje a gente conseguiu fazer dezenas de cases com industriais faturando ate medias de 5 milhoes de BRL por mes apenas com a contabilidade fiscal e financeira (e exportando alguns outros dados sem lançar eles certinho. Na França não começamos de outra forma 10 anos atras). A gente acha então que essa questão do CMV nas vendas e remessas so interessa uns 5% das empresas que ja conseguem sobreviver a toda implantação dos processos. Então essa divergencia nao deveria ter consequencias muito grandes nem afetar muitos modulos. Na hora da gente implementar o SPED pode ser que tenha um pouco (depois de migrar para a v14?), mas ai eu aposto que ate isso acontecer, ja vai ficar claro que uma soluçao tera adoçao bem maior e a outra vai disaparecer.

Ate o site da Odoo SA avisa bem claramente:

E isso sem nem considerar o "risco brasil" dos ERPs (quando não se trata dos implementadores) por cima que não é pouca coisa...

Tanto a solução continental da KMEE vai usar o inventario permanente para lançar o CMV das vendas quanto a nossa so que pelo modo anglo-saxon tb então isso so vai interessar os fortes mesmo.

So umas coisas que seria bom fazer ainda:

1. ajustar os CFOP principais de remessa e bonificação principais para nao lançar financeiro quando o anglo_saxon_accounting for ativado. Ai isso a KMEE poderia na vdd fazer um override para continuar a lançar a linha financeira so que transformando ela em CMV como ela tanta fazer no [12.0][NEW] Correct accounting #1311. seria melhor do que apenas fazer pelo flag anglo_saxon_accounting, porque se o cara nao instalar o modulo de CMV sem anglo-saxon da KMEE (esse override aconteceria pro l10n_br_coa_generic por padrão no Runbot) pelo menos o financeiro ainda sairia correto com as remessas sem ter que ir ativar o modo anglo-saxon. Isso faria diferença para alguem que instalasse o l10n_br_coa_generic sem instalar o modulo de CMV sem anglo saxon da KMEE e sem tb entender nada sobre o assunto. Caso tipico de uma micro-empresa curiosa.
2. definir contas de Estoque interim (e conciliáveis) em todos os planos para que o anglo-saxon funcione facilmente quando for ativado.

[github-actions]

There hasn't been any activity on this pull request in the past 4 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 PR to never become stale, please ask a PSC member to apply the "no stale" label.

[mileo]

@DiegoParadeda

[DiegoParadeda]

LGTM

[rvalyi]

implementado na 14.0 em #2667