• Replies 17 replies
  • Subscribers 337 subscribers
  • Views 328 views
  • Users 0 members are here
Related

Best Practices in Bulk Account Creation

Tom Brown (Past Member)
$organization

Daily I'm going to create a number of Tessitura Accounts based on information we are gathering at several points around the building.  

I have a sense that there are several ways I could automate this:

  • Use the Stored Procedure used by the Standard Account Creation Reports
  • Use the Standard Tables and procedures used by Tessitura when doing Migrations
  • Use an external Process that then uses the REST API to populate these accounts.
  • Writing code from scratch that just creates records in T_Customer, T_Eaddress
  • Something that I've missed here ...

What are folks having the most success with as an approach for bulk creating accounts? Particularly methods that is robust to Tessitura System Changes over time?

What documentation exists for automating such a process?

Thanks for any help you are able to share.

--Tom

Parents
  • $organization
    Unknown said:
    Writing code from scratch that just creates records in T_Customer, T_Eaddress

    I'm biased, I suppose, but I've always found this the simplest route. Don't forget rows in TX_CUST_SAL...

  • $organization in reply to Chris Jensen

    Do you have a spare set of code hanging around that you can share that does this kind of thing?

    I'm not clear what records are necessary to produce a minimally viable customer record.

    - T_Customer

    - T_Address

    - T_Eaddress

    - TX_CUST_SALUTATION

    I know that I likely have to work with the T_Next_Record

    What I'm not clear about is what other records have to be created and updated.  Does someone know of documentation, an existing stored procedure in the database, have code they have tested that they would like to share.

  • $organization in reply to Tom Brown (Past Member)

    For a "minimally viable" customer record, I am not certain that T_EADDRESS is necessary.  That said, for an "even semi-normal person" record, it would be, as well as T_PHONE.  Otherwise, I think you have the tables needed.  And yes, you would definitely need to work with T_NEXT_ID on this one.

    Probably not necessary to remind you, but anytime I work with T_NEXT_ID, I always make sure to use Transaction functionality in SQL to make sure that it does not mess anything up (too badly) if it fails.

Reply
  • $organization in reply to Tom Brown (Past Member)

    For a "minimally viable" customer record, I am not certain that T_EADDRESS is necessary.  That said, for an "even semi-normal person" record, it would be, as well as T_PHONE.  Otherwise, I think you have the tables needed.  And yes, you would definitely need to work with T_NEXT_ID on this one.

    Probably not necessary to remind you, but anytime I work with T_NEXT_ID, I always make sure to use Transaction functionality in SQL to make sure that it does not mess anything up (too badly) if it fails.

Children
  • $organization in reply to John A. Moskal II

    I included t_eaddress because for my projects it was data that I was expecting to have as a minimum requirement in order to even attempt to create the record.

    Conversely, I don't expect to have a phone number from this group of constituents.  Do you believe that it's a requirement to create such a record in no actual data that will be filled into the field?

    Thanks for the remainder of the transaction functionality of the database.  This is an area that I don't often get into because most of my work has been reporting.

  • $organization in reply to Tom Brown (Past Member)

    Sorry if my language was confusing.  Not at all.  Assuming no data will be filled in for the constituent T_EADDRESS and T_PHONE are completely unnecessary.  And Chris Jensen is correct, actually, you theoretically would not need T_ADDRESS either since you CAN turn off that requirement.  I just skipped over that because almost every organization of which I am aware has the address field as required for the creation of an account, even if it is just some form of 'INVALID ADDRESS' standard that they use for those who do not want to give their address.

    And the Transaction functionality may not be 100% necessary, but I feel safer when I use it for stuff like this.  I have seen people get into some pretty sticky situations when they try to do things like this through the back end and mess up.  When T_NEXT_ID gets off (or I have also seen the IDs in T_TRANSACTION go wrong), it will often prevent ANY user from creating any new account/CSI/address/order/etc...  So I am always extra careful when dealing with that stuff.