OCA Mobile - Odoo React Native - a Modern Odoo APP made with React Native by Odoo Community
erpbrasil/erpbrasil.assinatura 5
Assinatura digital em python
Framework Bancário Brasileiro
mileo/account-financial-reporting 0
Financial reports for Odoo
startedhashicorp/terraform
started time in an hour
startedserverless/serverless
started time in an hour
Pull request review commentOCA/OpenUpgrade
jobs: MODULES_NEW=base,$(sed -n '/^+========/,$p' odoo/openupgrade/doc/source/modules120-130.rst | grep "Done\|Partial\|Nothing" | grep -v "theme_" | sed -r -n 's/((^\| *\|new\| *)|^\|)([0-9a-z_]*) *\|.*$/\3/g p' | sed '/^\s*$/d' | paste -d, -s) psql $DB -c "update ir_module_module set state='uninstalled' where name not in ('$(echo $MODULES_OLD | sed -e "s/,/','/g")')" echo Testing modules $MODULES_NEW- OPENUPGRADE_TESTS=1 coverage run $ODOO --database=$DB --update=$MODULES_NEW --db_host=$DB_HOST --db_port=$DB_PORT --db_port=$DB_PORT --db_password=$DB_PASSWORD --db_user=$DB_USERNAME --stop-after-init- - name: Ending- env:- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}- run: coveralls+ OPENUPGRADE_TESTS=1 $ODOO --database=$DB --update=$MODULES_NEW --db_host=$DB_HOST --db_port=$DB_PORT --db_port=$DB_PORT --db_password=$DB_PASSWORD --db_user=$DB_USERNAME --stop-after-init
There's two times db port, although it was the before, but good moment to amend it.
comment created time in 2 hours
push eventNexedi/erp5
commit sha 307470e22e7360d71f1e0ec912dc08f389a33c37
accounting: Fix timezone issues when checking periods are consecutive Opening an accounting period is refused if the start date of the period is more than one day after the stop date of the previous period, but this check did not take into account that "next day" might be more than 24 hours, like it's the case when daylight saving happen between these dates. Instead we check that the difference is less than 1.9 days. Reorganise tests to group accounting period related tests in a dedicated test class and add missing tests for period validation checks. Also fix a few race conditions with catalog indexing that are probably not a problem in real life but were revealed by the test.
commit sha 0b75935d16fe189e0c3806d7ca144d05e79231cd
erp5_accounting: Add also string_index to the list of copied properties in API script AccountingTransaction_createReversalTransaction
commit sha e5c160bcaa96919ef22dd4ee4061d8570250bc7b
fixup! erp5_web_renderjs_ui: Improve fields to propagate error_text
commit sha dc863abc3139a566d6d695cd5b901d386686565b
Revert "fixup! erp5_web_renderjs_ui: Improve fields to propagate error_text" This reverts commit e5c160bcaa96919ef22dd4ee4061d8570250bc7b.
commit sha c6a6c8625e3e298d8cd35129c3c58c13f2f38587
fixup! erp5_web_renderjs_ui: try to get a more precise float value on all platforms
commit sha 34643c13ae526139547354a67e93258b3cfad49a
erp5_ui_test: add delivery_ratio property for testing FloatField with percent.
commit sha fff7a736c402ef91b51dfae89c9134fd23753e66
erp5_web_renderjs_ui_test: test a percent FloatField with a RelationField.
commit sha dee4ec379a486a6d27ed087632056ca7b8311333
erp5_web_renderjs_ui: fix a percent FloatField issue with a RelationField.
commit sha 846c4f7fe2406b7dcd04e90c8285e22a9bbe2150
fixup! erp5_web_renderjs_ui: fix a percent FloatField issue with a RelationField.
commit sha eb25ed37483d652cde4337f33d51a0e34470fb82
fixup! erp5_ui_test: add delivery_ratio property for testing FloatField with percent.
push time in 2 hours
PR opened OCA/OpenUpgrade
Upload currently fails with
Could not submit coverage: 422 Client Error:
Unprocessable Entity for url: https://coveralls.io/api/v1/jobs
Even though coverage data is gathered successfully in the correct format.
Having coverage on the migration scripts hardly makes any sense, as it only displays which code does not run during the migration.
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
pr created time in 2 hours
pull request commentOCA/server-tools
[IMP] base_jsonify: add lang, custom resolvers, alias* support
ormcache with write date works fine :ok_hand:
comment created time in 3 hours
push eventOCA/web
commit sha 76f4444944120d86072de408f8ff393faffa0382
Translated using Weblate (Spanish) Currently translated at 100.0% (9 of 9 strings) Translation: web-12.0/web-12.0-web_company_color Translate-URL: https://translation.odoo-community.org/projects/web-12-0/web-12-0-web_company_color/es/
commit sha e4a84c9286f8708c0e861ff13f41a88916900431
Translated using Weblate (Catalan) Currently translated at 100.0% (9 of 9 strings) Translation: web-12.0/web-12.0-web_company_color Translate-URL: https://translation.odoo-community.org/projects/web-12-0/web-12-0-web_company_color/ca/
push time in 4 hours
starteddnsviz/dnsviz
started time in 4 hours
pull request commentOCA/l10n-brazil
12.0 mig l10n_br_account_payment_cobranca (renomado l10n_br_account_payment_order)
ola @luismalta "discutimos como abordar os diversos fluxos possíveis para a baixa através do pagamento manual. Foi identificado a necessidade de ter um fluxo genérico e que não conflite com nenhuma forma de pagamento. A melhor forma que achamos de fazer isso foi a partir do método de reconcile. Primeiro foi mapeado todas as formas de se fazer o pagamento e quais os passos até chegarem em um método comum, no caso o reconcile. " Acredito que é preciso implementar seguindo os métodos do "core"( repo odoo ) para não ter problema com outros módulos que possam herdar os mesmo métodos. Também existe a questão a considerar de que de forma geral é melhor ter pequenos métodos que fazem uma função especifica do que ter um grande método que faz tudo, isso é melhor para manutenção, migração e consequentemente dividindo um grande problema em pequenos, mas cada caso deve ser analisado.
"Nessa solução também estamos contemplando o pagamento parcial de alguma parcela, tendo um fluxo para criar ou adicionar a uma payment order com o valor residual do pagamento."
IMPORTANTE: acredito que para fazer isso vocês vão utilizar o Codigo de Instrução de Movimento para "Alteração do Valor do Título" https://github.com/odoo-brazil/l10n-brazil/blob/12.0-mig-l10n_br_account_payment_cobranca/l10n_br_account_payment_order/data/l10n_br_cnab_mov_instruction_code_data.xml#L41 porém essa opção não existe em todos os CNABs exemplo Banco UNICRED tanto o 400 quanto o 240( no link acima estão os dados desse CNAB também ), por isso foi feito um bloqueio para só permitir ou um pagamento de igual valor a uma parcela ou a soma de parcelas ( aqui https://github.com/odoo-brazil/l10n-brazil/blob/12.0-mig-l10n_br_account_payment_cobranca/l10n_br_account_payment_order/models/account_invoice.py#L188 ), esse processo precisa ser preservado para os casos onde não há a possibilidade de pagamentos parciais, portanto se vocês forem implementar os Pagamentos Parciais a minha sugestão é criar um Parâmetro ( ex.: Permite Pagamentos Parciais de CNAB ) onde o valor default seja Não Permitir, já que caso o usuário faça isso em um CNAB que não permite será mais complicado resolver.
Sobre o Pagamento via Extrato Bancário ( acredito que seja a importação de um arquivo, ou seria a criação manual ? ) , veja tem algumas questões importantes o arquivo CNAB é mais detalhado que o Extrato, o primeiro contém os valores de Desconto, Abatimento, Juros/Mora e Tarifa( o extrato também traz a tarifa, mas até onde sei não detalha a qual Parcela/Boleto se refere ou pode até vir junto o valor total de todas as tarifas ), por isso o arquivo CNAB permite ter uma maior consistência e segurança dos dados algo que foi comentado como importante no RFC, já que o valor de um Pagto CNAB pode vir tanto A Maior quanto A Menor ( doc de exemplo https://odoo-doc.gitbook.io/user/cnab/exemplo-de-um-retorno-de-arquivo-cnab ) e via extrato o usuário terá que tratar e será o responsável por isso, o que implica nos possíveis problemas de erros de digitação. Existe um outro problema que pode ser complexo de resolver o arquivo CNAB informa um Pagamento porém o banco tem um atraso/delay de 3 dias ( exemplo ) para disponibilizar o valor na Conta do cliente, quer dizer o arquivo CNAB informa pagto porém no Extrato só terá essa informação 3 dias depois, pelo que vi na v14 foi feita uma refatoração que atenderia esse caso e os casos de "Antecipação de Título junto ao Banco ou Factoring" veja https://www.odoo.com/forum/help-1/v14-change-in-payment-behavior-how-do-the-suspense-and-outstanding-payment-accounts-change-the-journal-entries-posted-177592 por isso devemos considerar se resolvemos isso na v12 ou na v14.
OBSERVAÇÃO: Esse PR precisa do rebase devido a reversão do PR 820 como o @rvalyi comentou, acredito que antes de qualquer commit ser adicionado, portanto alterações devem ser feitas via PR ou depois do rebase para evitar erros e outros rebase em PRs nessa branch.
comment created time in 4 hours
pull request commentakretion/l10n-brazil
[12.0-l10n_br_nfe-ak-filtered][IMP] nfe40_cobr
Entao, isso vamos ter que ver com @renatonlima porque hoje a gente simplesmente preenche essas tags a partir dos account.move.lines na hora de exportar as NFe. Mas hoje nao temos mapeamento de objeto com account.move.line ou coisa do tipo. Entao ja que essas objetos tem equivalente no Odoo pelo menos qdo tem o modulo account, nao seria bem certo deixar eles ter uma existencia concreta separada assim sei la como a gente poderia querer para uma observacao de note de importacao que nao tem equivalente no Odoo. @renatonlima vamos ter que ver essas questões com uma certa prioridade...
@rvalyi de imediato visando permitir a geração dos documentos com as tags de duplicatas, eu trabalharia seguindo a seguindo a lógica dos demais itens como detPag e transportadora. Ou seja, deixar disponível para preenchimento manual dos dados de nf40_cobr e dai temos tempo para alinhar como fica esta questão financeira e também de transporte.
Eh que se vc deixa manual vc pode ter descrepencia com os account.move.line que o Odoo ja vai gerir para vc. Hoje o que fazemos eh simplesmente gerir as tags XML certas para refletir os account.move.line (pelo menos no codigo que temos em produção). Eu acho valido tentar mostrar algo tb na tela do documento fiscal, porem talvez nao ao custo de arriscar dados inconsistentes com o dados do account. O que o Luis tinha feito ate funciona, mas temos um problema com a quantidade de codigo que se torna inutil logo que vc instala o modulo account na proposta dele (por isso e por outros motivos como o fato de copiar codigo de autoria da Odoo SA, talvez essa solucao completa ele poderia ser um modulo fora do l10n_br_fiscal).
comment created time in 4 hours
pull request commentOCA/OpenUpgrade
Merged manually because ocabot is blocked by Github actions failing on coverage push
comment created time in 4 hours
push eventOCA/OpenUpgrade
commit sha 1349b4a9df16718e89a24ee78fb95c4fa4c13550
[MIG] event Co-Authored-By: Miquel Raïch <miquel.raich@eficent.com>
commit sha 3bc514cb591974f486bc9b0c5c881a63f4e14d6f
Merge pull request #2281 from Yasaie/13.0-mig-event [13.0][MIG] event
push time in 4 hours
PR merged OCA/OpenUpgrade
Migration of event
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
pr closed time in 4 hours
push eventOCA/purchase-workflow
commit sha bc3b5bd2b5e2f34c6f2b88a995333819f2b3d0c7
Update translation files Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: purchase-workflow-12.0/purchase-workflow-12.0-procurement_purchase_no_grouping Translate-URL: https://translation.odoo-community.org/projects/purchase-workflow-12-0/purchase-workflow-12-0-procurement_purchase_no_grouping/
push time in 4 hours
pull request commentOCA/purchase-workflow
Congratulations, your PR was merged at 0e4b52783cd8baedab7cc1d925744720f87de005. Thanks a lot for contributing to OCA. ❤️
comment created time in 4 hours
delete branch OCA/purchase-workflow
delete branch : 12.0-ocabot-merge-pr-1052-by-pedrobaeza-bump-major
delete time in 4 hours
PR merged OCA/purchase-workflow
Add product_category in procured_purchase_grouping field
@Tecnativa TT27393
pr closed time in 4 hours
push eventOCA/purchase-workflow
commit sha 2ec195e5785069bf9a762878c64e03d618c150f9
[IMP] procurement_purchase_no_grouping: Add product_category in procured_purchase_grouping field
commit sha 27df36cf9f73d8b64f196c0d3ea7ef8ee88df413
Merge PR #1052 into 12.0 Signed-off-by pedrobaeza
commit sha a6156345970910407ff60fbee08cae59f1fc8891
[UPD] Update procurement_purchase_no_grouping.pot
commit sha f1b227cbb9ed2fdb1e83d814c99c1d8c438c3f88
[UPD] README.rst
commit sha 0e4b52783cd8baedab7cc1d925744720f87de005
procurement_purchase_no_grouping 12.0.2.0.0
push time in 4 hours
pull request commentakretion/l10n-brazil
[12.0-l10n_br_nfe-ak-filtered][IMP] nfe40_cobr
@rvalyi obs. masss se for tratar esta questão como prioridade.. acho válido também.
comment created time in 5 hours
Pull request review commentOCA/purchase-workflow
[14.0][MIG] purchase_order_approved
+# Copyright 2017 ForgeFlow S.L.+# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl).++from odoo import fields, models+++class PurchaseOrder(models.Model):+ _inherit = "purchase.order"++ state = fields.Selection(selection_add=[("approved", "Approved")])+ # TODO: inherit state but adding approved state in a position after 'to+ # approve' state.
state = fields.Selection(selection_add=[("approved", "Approved"), ("purchase",)])
comment created time in 6 hours
pull request commentOCA/purchase-workflow
[14.0][MIG] purchase_order_approved
It seems states inheritance is not working well for One2many field order_line.
@MiquelRForgeFlow any idea why? Omitting last push force it should work.
comment created time in 5 hours
push eventOCA/purchase-workflow
commit sha a6156345970910407ff60fbee08cae59f1fc8891
[UPD] Update procurement_purchase_no_grouping.pot
push time in 5 hours
pull request commentakretion/l10n-brazil
[12.0-l10n_br_nfe-ak-filtered][IMP] nfe40_cobr
Entao, isso vamos ter que ver com @renatonlima porque hoje a gente simplesmente preenche essas tags a partir dos account.move.lines na hora de exportar as NFe. Mas hoje nao temos mapeamento de objeto com account.move.line ou coisa do tipo. Entao ja que essas objetos tem equivalente no Odoo pelo menos qdo tem o modulo account, nao seria bem certo deixar eles ter uma existencia concreta separada assim sei la como a gente poderia querer para uma observacao de note de importacao que nao tem equivalente no Odoo. @renatonlima vamos ter que ver essas questões com uma certa prioridade...
@rvalyi de imediato visando permitir a geração dos documentos com as tags de duplicatas, eu trabalharia seguindo a mesma neste momento seguindo a lógica dos demais itens como detPag e Transportadora. Desta forma fica viabilizado a NFe e dai temos tempo para alinhar como fica esta questão financeira e também de transporte.
comment created time in 5 hours
create barnchOCA/purchase-workflow
branch : 12.0-ocabot-merge-pr-1052-by-pedrobaeza-bump-major
created branch time in 5 hours
pull request commentOCA/purchase-workflow
What a great day to merge this nice PR. Let's do it! Prepared branch 12.0-ocabot-merge-pr-1052-by-pedrobaeza-bump-major, awaiting test results.
comment created time in 5 hours
pull request commentOCA/purchase-workflow
/ocabot merge major
Please fw-port it to v13
comment created time in 5 hours
pull request commentOCA/l10n-brazil
[12.0][FIX] Fiscal Product Mixin
tou querendo testar no Runbt mas ele travou em 1h na primeira vez, dei um force rebuild nele...
comment created time in 5 hours
issue closedbacen/pix-perguntas-e-respostas
[Problema] no [SPI] - Troca de certificados do Bacen
Descreva sua dúvida ou problema Hoje em torno das 10h25 o Bacen trocou os seus certificados, durante o processo a comunicação parou completamente. É um problema e dúvida ao mesmo tempo, se isso acontecerá igual em produção.
Sistema ou Área DICT, SPI, INFRA
Identificador do Problema
Das 10h25 até 10h26 não conseguimos comunicação com o Bacen. Nosso get longpooling estava recebendo Connection Reset.
Das 10h33 até 10h34 o longpooling retornou erro 503. Xml de saída está abaixo.
Mensagens Enviadas / Recebidas
Mensagem recebida com o erro 503:
<?xml version="1.0" encoding="UTF-8"?><problem xmlns="urn:ietf:rfc:7807"><type>https://icom.pi.rsfn.net.br/api/v1/error/serviceUnavailable</type><title>IP de destino não disponivel para este servico no momento. Confira se a resolução de DNS respeita o TTL.</title></problem>
URL de conexão https://icom-h.pi.rsfn.net.br:16522/api/v1/out/92702067/stream/start
Dados adicionais Não houve teste de envio de Pix nesse horário, mas a princípio o erro seria o mesmo para ambos os casos.
Agradeço e aguardo retorno.
closed time in 5 hours
rsabin