giseldo/neodataset huggingface dataset:
Incorrect purchase date shown for CI minutes and true up products in ramp subscription

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
Currently the CI minutes and true-up product sections show the `startDate` value in the `Purchase date` column which is incorrect. It should instead be showing `createdAt` value.  

![image](/uploads/2f648069155b021e357a79aef64447f2/image.png)  
![image](/uploads/a1f5c0c47a513a44f3bbba12367f4560/image.png)

### Proposal
Show the displayed value from the `createdAt` field.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
Correct value from `createdAt` field should be shown in `Purchase date` column.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Refactor dotcom_subscription_renew_form subtotal, discount, and tax into their own component


### Problem
The [dotcom_renew](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d5063afcd856447e8e68e343b915ddf1a0ec5628/app/frontend/javascripts/subscription/components/dotcom_subscription_renew_form.vue#L370) subtotal, discount, and tax components bloat the template by being listed separately, especially since the values are related.

### Proposal
Since these items share styling behavior and live in their own "section", split them into their own grouped component to improve testing story and reduce the template complexity. Also reuse these components across the SaaS (`dotcom_subscription_renew_form.vue`) and SM (`subscription_renew_form.vue`) components if feasible.

Add tests for the newly introduced component to verify both the existence of the headers as well as the amounts.

Story points: 2.0
Promote `account_data_structure` feature and remove feature flag checks

### Background

As noted in [the feature flag rollout issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4867), the `account_data_structure` feature flag has been enabled in all environments.  It was [enabled in Production on Monday, 2023-02-06](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4867#note_1267484731).  We haven't noticed any major issues so far that have required disabling the feature flag and we will continue to monitor it.

### Proposal

If after a week (anytime after 2023-02-13), the feature flag is still stable, we should feel comfortable promoting the `account_data_structure` feature flag and removing the legacy code and conditions from the application code.

While removing the feature flag checks, we may encounter opportunities to refactor and simplifying existing logic.

Story points: 5.0
Sync billing accounts without salesforce id

### Problem

We need to make sure that the `BillingAccount#salesforce_account_id` is always set to the Zuora account `crm_id`.

It is OK to have blank `salesforce_account_ids` as long as the values for these in Zuora are also blank. [Reference - external](https://gitlab.slack.com/archives/C037WQ2BUGK/p1675884549880319?thread_ts=1675801765.250799&cid=C037WQ2BUGK)

> There are some valid use cases where a Zuora Billing Account does not have an SFDC CRM ID - when we switch entity, we want to use the new Billing Account, the Account is in Zuora for non-sales reasons (such as marketing), etc.

We currently have occurrences of `BillingAccount#salesforce_account_id` [being blank on our end and not in Zuora](https://customers.gitlab.com/admin/billing_account/1284). This looks like an old billing account that might have been created before the `UpdateBillingAccountService` was [updated](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6078/diffs) to set the `salesforce_account_id` attribute.

### Proposal

- [x] Write a task that will sync the `BillingAccount` records that have `salesforce_account_id` set to `nil` (aprox. 1950): https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6491
- [x] Execute task in production
- [ ] [Once the task is executed] Create and own a small issue to periodically monitor new occurrences through the next month (hopefully none)

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Link to Zuora Account from the Billing Account CDot Admin pages

### Problem

The BillingAccount list and show pages in CDot admin currently show a Zuora Account ID but without a link to the Zuora Account page.  It would be more convenient to have a link instead of forcing Admins to copy and paste this into Zuora.

### Proposal

Update the CDot Admin page for BillingAccounts to include a link to the Zuora Account.

Story points: 1.0
Add `zuora_account_number` and `zuora_entity` to BillingAccount

### Problem

We've found there are scenarios where it is useful to be able to distinguish between two BillingAccounts that have the same name.  In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5687, we want to show the Zuora Account Number in addition to the Name in some CDot Admin pages.

We also found that it would be useful to show BillingAccount Entity as well.  While we are adding Account Number, we can include Entity as well.

### Proposal

Let's add the Zuora Account Number and Entity to the fields cached from Zuora on BillingAccount.  This will involve a few changes:

1. [x] - Engage the Finsys team via an issue (e.g. https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/886) to update the existing "Account Update" Custom Event in Zuora to include changes to the `Account Number` and `Entity` fields.  I don't believe the Callout Notification will need to be updated as we only need the Account ID which is already in place.
   - https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/1126
1. [x] - Add columns `zuora_account_number` and `zuora_entity` to the `billing_accounts` table in CDot.
1. [x] - Update the Billing Account / Zuora Account syncing logic in CDot
   - [in the `BillingAccount` model](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/fef84cce0f4a2600f7591105eb68596462e108b1/app/models/billing_account.rb#L25)
   - [in the `UpdateBillingAccountService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/fef84cce0f4a2600f7591105eb68596462e108b1/app/services/customers/update_billing_account_service.rb#L50))
1. [x] - Update documentation
   - [data_architecture.md](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/83a95b12efd44ce00ea03d26e3c953a310d8228f/doc/architecture/data_architecture.md#L90)
   - [zuora_callouts.md](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1ba32625852d05582e328e3b2f46e4df7e335d2f/doc/zuora/zuora_callouts.md#L295)
1. [x] - Add `Account Number` and `Entity` to Billing Account pages (list, show) in CDot Admin
1. [x] - Create and run rake task to backfill `zuora_account_number` and `zuora_entity` for existing BillingAccounts

Story points: 3.0
Add Zuora Account Number to BillingAccountMembership display in CDot Admin

## Problem

If admins search for a `Billing Account` in the `Billing Account Membership` section of CDot admin, it can happen that multiple `Billing Accounts` with the same name appear. 

This makes it hard for the admin to identify the desired Billing Account.

Related [Slack thread](https://gitlab.slack.com/archives/C018C623KBJ/p1675744969835379?thread_ts=1675743272.802499&cid=C018C623KBJ)

Screenshot of current display:
![image](/uploads/8c37f052b887bad8c380e3ecdae89029/image.png)

## Proposal

Display the Zuora Account Number (as displayed in `Billing Accounts`) in the Billing Account Membership search result list.

## Result

Admins are able to distinct and  identify the right `Billing Account` faster in the `Billing Account Membership` search

Story points: 1.0
Query on BillingAccountMemberships Admin list page does not work

### Problem

As [reported by Support in Slack](https://gitlab.slack.com/archives/C018C623KBJ/p1675748921793539?thread_ts=1675743272.802499&cid=C018C623KBJ), it appears that using the query field on the BillingAccountMemberships page does not work.  Entering any phrase in the input field and pressing enter, returns all results.  It appears the `query` param is coming through to the Rails Admin controller but isn't being used to filter results.

Excerpt from my local server output:

```
Started GET "/admin/billing_account_membership?model_name=billing_account_membership&query=Sam&_pjax=%5Bdata-pjax-container%5D" for ::1 at 2023-02-07 10:54:52 -0500
...
Processing by RailsAdmin::MainController#index as HTML
  Parameters: {"model_name"=>"billing_account_membership", "query"=>"Sam", "_pjax"=>"[data-pjax-container]"}
...
  BillingAccountMembership Load (1.0ms)  SELECT "billing_account_memberships".* FROM "billing_account_memberships" ORDER BY billing_account_memberships.id desc LIMIT $1 OFFSET $2  [["LIMIT", 20], ["OFFSET", 0]]
```

### Proposal

Fix the search so that Admins can search by the name of the Customer or Billing Account on this page.

Story points: 1.0
Refactor Order manager service methods to a class method

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

Follow-up from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4477, where order related services were refactored to use class methods.

`OrderManagerService` was not refactored due to this [blocker](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4477#note_1033959684).

Now that `check_availability` has been [removed](https://gitlab.com/gitlab-org/customers-gitlab-com/-/commit/01ff48be53339c51832d6909b5263dd9642a7fda), we can refactor `OrderManagerService` to use class methods.

Story points: 1.0
Improve SubscriptionV2 component accessibility


### Proposal
~~Wrap cards in `<article>` tag. Use [`<articles>`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/article_role) for the SubscriptionV2 cards for better semantic separation, per [suggestion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5615#note_1263050161) from `@kpalchyk`~~ Edit: This suggestion may require further R&D based on this [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5615#note_1322266443).

Also make base_product_details_v2 a `<section>` for improved accessibility.

Evaluate if any other components in the v2 directory need improvements, and create a new follow up issue that encompasses those.

Story points: 1.0
Improve usability from Customer show page in Admin interface

### Problem

With the `account_data_structure` flag enabled, @jcolyer noted that it now takes mulitple steps to trace a particular Customer to their SFDC Account ID.  This data used to be present directly on the Customer show page in the CDot Admin interface.  Now, an Admin must click a link to the BillingAccountMembership, then click another link to the BillingAccount.  From here, they can see the Salesforce Account ID.

<details><summary>Current Flow</summary>

![Screenshot_2023-02-06_at_3.53.27_PM](/uploads/139fe629b90dbe88a283f0685a68d576/Screenshot_2023-02-06_at_3.53.27_PM.png)

:arrow_heading_down: 

![Screenshot_2023-02-06_at_3.53.32_PM](/uploads/3525b85eba4ddf92c83f36e4962e4dca/Screenshot_2023-02-06_at_3.53.32_PM.png)

:arrow_heading_down: 

![Screenshot_2023-02-06_at_3.53.41_PM](/uploads/83410daf122aa9331e3ef88cadddb1f1/Screenshot_2023-02-06_at_3.53.41_PM.png)

</details>

### Proposal

Let's try to improve this workflow. At the very least we could update the RailsAdmin config for Customers to include a section for BillingAccounts so that an Admin could link directly to the BillingAccount from the Customer show page.

Story points: 1.0
Admin ability to view Bill To/Sold To Zuora Contact data

### Problem

Currently CDot Admins have no visibility into the Bill To or Sold To Contacts associated with a Billing Account.  This must be managed directly in the Zuora UI.  It would be beneficial to the Support team to have management capabilities within the CDot Admin interface.

### Proposal

Add the ability to view Bill To / Sold To Zuora Contact information from the CDot Admin interface.  This could be a page that can be accessed from the Billing Account page.

![Screenshot_2023-02-03_at_11.27.58_AM](/uploads/f7b28bc18a3bc2688ee1dd78c077ed0b/Screenshot_2023-02-03_at_11.27.58_AM.png)

This is an MVC approach and focuses just on showing the Bill To and Sold To Contacts for the Zuora Account associated with the CDot `BillingAccount`.  Keep in mind in a later iteration, we want to allow these Contact records to be edited (e.g. changes made to Zuora).  

#### Notes

- If the Bill To Contact is the same record as Sold To, we could indicate this instead of duplicating the information.
- Fields to show for a Contact record:
  * First Name
  * Last Name
  * Work Email
  * Address 1
  * Address 2
  * City
  * Country
  * State
  * Postal Code

Story points: 3.0
Handle professional services products in ramp subscription card

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
We need to handle display of professional services products in the new ramp subscription card.

### Proposal
Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5611

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Handle true up products in ramp subscription card

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
We need to handle display of true-up products in the new ramp subscription card.

### Proposal
Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5611

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Investigate shared example usage for ReconciliationService

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6453+, a shared example is moved from the `ReconciliationService` specs into a new file. During the review, it was discovered that the shared example isn't used anymore. Its usage was removed as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6254+ where the feature flag `use_orders_api_to_preview_quoted_invoice_amount` was cleaned up. The shared example includes some test coverage for examples that aren't covered outside of the shared example (e.g. [this spec's context](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f51240cf801b31a9aebb1742ff26fda446a5db82/spec/support/shared_examples/services/reconciliation_service.rb#L343-352)).

### Proposal

Go through the shared example and determine which specs still need to be used to have better test coverage. Use the shared example in the `ReconciliationService` specs if some are needed and remove any that aren't needed anymore.

### Result

Better test coverage if some examples are needed. Otherwise some removed code.

Story points: 2.0
Spike: Create proposal for caching mechanism for BillingAccount  Contacts

### Problem

We know that Zuora Account Contacts are used frequently in CustomersDot, most importantly the Sold To Contact.  The Sold To Contact is the person who receives licenses or activations codes, or other notifications from CDot.  The Sold To Contact information is also used to find or create CDot Customer record when processing Subscription/Order related callouts from Zuora.

### Proposal

Given their importance, we could consider creating a model for BillingAccount Contacts and caching this data from Zuora in CDot.  This could function similarly to what we've built for `BillingAccount` in that we persist just the data needed for CDot.  

To keep the data in CDot in sync with Zuora, a custom event with its own callout could be created for Contacts.  A [similar custom event and callout mechanism was created for BillingAccounts](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1ba32625852d05582e328e3b2f46e4df7e335d2f/doc/zuora/zuora_callouts.md#L168) and would serve as a model for this new purpose.  The syncing mechanism for Bill To and Sold To will differ a bit from Billing Account because the bill_to_id and sold_to_id live on the billing_account which we want to keep in sync, but also the contact data itself.

#### Considerations

- Consider whether to cache all Zuora contact information in CDot or just the Bill To and Sold To.  I suspect it will be the latter but worth debate.  
- Contact information is currently help on the `Customer` model for paid customers at the moment.  If we introduce a contact model in CDot, these contact fields on Customer should not be used once the Customer converts to a paid Customer (e.g. has a `BillingAccountMembership`).

### Result

The outcome of this issue should be a proposal for caching billing account contacts in CDot.  Ideally this could be an issue, or set of issues if the work is large enough.  This proposal could be added to the overall [proposal documentation for Bill To / Sold To Contact management](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/architecture/contacts_management_proposal.md).

Story points: 3.0
Your company details form should not trigger syncing Zuora Contacts

### Problem

We discovered while working on user workflow documentation for https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6226 an unexpected behavior of the `Your company details` form for logged in customers.  You can find more details in [the original thread here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6226#note_1261379713).

> Those 2 forms are separate (e.g. they only submit the params for their own section) despite being submitted to the same API endpoint (PATCH `/customers`), and trigger the same service to update Zuora contacts and accounts.
>
> It looks like that [service won't update the Zuora Account if neither of the 2 attributes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9aa9f695d0df918de5ad3697ba4f6321d8258eef/app/services/update_contact_service.rb#L66) (name, vat_id) have changed. However, that same service also [updates the Zuora Contacts](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9aa9f695d0df918de5ad3697ba4f6321d8258eef/app/services/update_contact_service.rb#L76) and this appears to run regardless of if anything changed, so it will always sync those when called. This means, even when the account section, `Your company details`, is submitted, the contacts are still synced.

![Screenshot_2023-02-02_at_10.21.23_AM](/uploads/2c564550da8fa5f06a5c52476a513cad/Screenshot_2023-02-02_at_10.21.23_AM.png)

### Proposal

The `Your company details` form should only update the Customer company and BillingAccount data in CDot, while syncing to Zuora Account.  Contact data should not be synced with Zuora Contacts as this information should not be changed.  It's an unnecessary syncing step.

The service responsible for the sync with Zuora is [the `UpdateContactService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9aa9f695d0df918de5ad3697ba4f6321d8258eef/app/services/update_contact_service.rb#L7).  This service is triggered from the Customer model [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/80b89944453495fbb3ed3f42b105ba91ed2570a9/app/models/customer.rb#L70) in an `after_validation` callback.  We could explore ways to avoid this callback behavior altogether, as it's not ideal, but also rearchitect this service in general.  Here are some ideas:

- Split out the `UpdateContactService` into multiple jobs?  One for Account and another for Contact.  This would allow us to trigger the one that is appropriate based on attributes changed by the form.
- Perform the sync to Zuora in a background job (or jobs) instead so that it doesn't hinder performance, and we'd also benefit from the sidekiq retry mechanism.

It might be easier to wait until https://gitlab.com/groups/gitlab-org/-/epics/8950+ is live so that we can fully rely on the new account data structure for this re-architecture.

Story points: 5.0