Skip to content

Conversation

@antoniodavid
Copy link

@BinhexTeam T17939

@antoniodavid antoniodavid force-pushed the 16.0-add-billcom branch 2 times, most recently from 79b4d72 to a4451ab Compare November 20, 2025 06:38
@jelenapoblet
Copy link

To improve clarity, I would like to propose renaming the addon to billcom_integration. The current technical name, billcom, is quite generic and doesn’t clearly communicate the purpose of the module. Using billcom_integration makes it immediately evident that the addon provides an integration with the Bill.com platform.

@antoniodavid antoniodavid changed the title [16.0][ADD] billcom [16.0][ADD] billcom_integration Nov 20, 2025
@antoniodavid antoniodavid force-pushed the 16.0-add-billcom branch 12 times, most recently from a40928e to 594a948 Compare November 27, 2025 03:04
@antoniodavid
Copy link
Author

@rrebollo @jelenapoblet @crrodrigueztrujillo guys, reviews needed!!!

Copy link

@rrebollo rrebollo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, the code looks good. It is a huge effort and a valuable asset to contribute to the OCA ecosystem.

Most of my comments are just suggestions; only a minority require action (clarification or small fixes).

However, looking ahead, I am worried about the size of this addon. Maintenance could become a nightmare, and I think we need a strategy to make this manageable. The sheer effort required to review this would be a dealbreaker for the vast majority of the community unless there is an economic incentive to maintain the addon in its current form.

Maybe it can be split, or perhaps the logic could be encapsulated in a library?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing you left this here when renaming the addon. The full billcom directory should be deleted. Don't you think?

Image

)
)
if move:
move.with_context(skip_billcom_sync=True).write({"active": False})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about posted moves? Is it valid to archive a posted moves?

)
)
if move:
move.with_context(skip_billcom_sync=True).write({"active": False})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
move.with_context(skip_billcom_sync=True).write({"active": False})
move.with_context(skip_billcom_sync=True).action_archive()

)
)
if move:
move.with_context(skip_billcom_sync=True).write({"active": True})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
move.with_context(skip_billcom_sync=True).write({"active": True})
move.with_context(skip_billcom_sync=True).action_unarchive()

)
)
if partner:
partner.with_context(skip_billcom_sync=True).write({"active": False})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
partner.with_context(skip_billcom_sync=True).write({"active": False})
partner.with_context(skip_billcom_sync=True).action_archive()

_logger = logging.getLogger(__name__)


class BillcomWebhookLog(models.Model):

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Webhooks are a built-in (limited feateure in odoo 17.0), thinking in migration. you can checkout also OCA/webhook#13 OCA/webhook#14

Comment on lines +55 to +60
if self.child_ids:
for child in self.child_ids:
if child.type == "invoice":
billing_address = child
elif child.type == "delivery":
shipping_address = child

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if self.child_ids:
for child in self.child_ids:
if child.type == "invoice":
billing_address = child
elif child.type == "delivery":
shipping_address = child
for child in self.child_ids:
if child.type == "invoice":
billing_address = child
elif child.type == "delivery":
shipping_address = child

A partner could have multiple invoice and delivery address so ...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide instructions for configuring the initial API connection, including authentication methods and required credentials.

Add also details on the specific webhooks that need to be configured in your Bill.com account to enable real-time data synchronization.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any multicompany rule. Is this intended?

billcom_partner_phone = fields.Char(string="Bill.com Phone", readonly=True)

# Multi-currency duplicate handling
billcom_ids_json = fields.Text(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you storing a json ? why don't use fields.Binary?

@jelenapoblet
Copy link

In general, the code looks good. It is a huge effort and a valuable asset to contribute to the OCA ecosystem.

Most of my comments are just suggestions; only a minority require action (clarification or small fixes).

However, looking ahead, I am worried about the size of this addon. Maintenance could become a nightmare, and I think we need a strategy to make this manageable. The sheer effort required to review this would be a dealbreaker for the vast majority of the community unless there is an economic incentive to maintain the addon in its current form.

Maybe it can be split, or perhaps the logic could be encapsulated in a library?

This is a valid POV, we need to consider long term maintenance for this integration, it's already in v16 , what about migrations to v17 and v18 ?

@jelenapoblet
Copy link

To make this more manageable and more “OCA-friendly” long term, we should reduce the surface area of each module. As we already discussed, the right way forward is to split the integration into:

billcom_integration_base

  • Core models and technical framework
  • API client / authentication
  • Shared utilities, error handling, logging, mappers
  • Generic configuration and hooks

billcom_integration_customers

  • Customer sync
  • Customer invoices / credit notes
  • Customer payments
  • AR-specific logic

billcom_integration_vendors

  • Vendor sync
  • Vendor bills / credit notes
  • Vendor payments
  • AP-specific logic

This split will make review and testing more approachable, let users install only what they need, keep the base addon reusable, and lower the maintenance burden in the future.

I’m happy to help refine the boundaries between modules if we move in this direction, but I strongly recommend not merging this as a single, very large addon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants