Can I reach Global Address List language independently? - excel

I would like to create an excel tool which at some point of the operation opens the Global Address List of the Outlook. I have figured it out how to do this, but there was an issue when we tried it on a German languaged computer. I have solved it by check the UI language prior to opening the address book, but I wondered if there is a language independent way to do so? (So I don't need to create a case for every possible languages.)
My corresponding code portion is:
langCode=Application.LanguageSettings.LanguageID(msoLanguageIDUI)
Select Case langCode
Case &H409
galStr="Global Address List"
Case &H40E
galStr="Globális címlista"
Case &H407
galStr="Globale Addressliste"
Case Else
galStr="Global Address List"
End Select
Set olApp=GetObject(,"Outlook.Application")
Set olGAL=olApp.GetNamespace("MAPI"). AddressLists(galStr)
Many thanks for your help.

Use Namespace.GetGlobalAddressList - it will return the GAL of the primary Exchange account in the profile.
As for the AddrList.AddressListType property, it will return olExchangeGlobalAddressList only for the GAL of the primary Exchange account. For a secondary account, it will be a generic olExchangeContainer.
If you have more than one Exchange account in the profile, you can figure out if a particular address list is GAL by reading two MAPI properties using AddressList.PropertyAccessor: PR_AB_PROVIDER_ID must be "DCA740C8C042101AB4B908002B2FE182"and PR_DISPLAY_TYPE must be DT_GLOBAL (0x00020000).
If using Redemption (I am its author) is an option, besides exposing RDOSession.Addressbook.GAL (similar to Namespace.GetGlobalAddressList in OOM), it also exposes RDOExchangeAccount.GAL property on the account level (AllRooms property is also exposed).

For user language and programming language independence there is enumeration.
OlAddressListType enumeration (Outlook)

Instead of trying to find the correct localized sting you may iterate over all address lists and get the GAL in the following way:
If(addrList.AddressListType ==
Outlook.OlAddressListType.olExchangeGlobalAddressList) Then
' this is GAL
End If
You can use the NameSpace.CreateRecipient function which creates a Recipient object. After resolving a recipient against the address book you may get the email address.
Also I've found the following article - Get the Global Address List or a set of address lists for a store which you may find helpful.

Related

Join Account to Sub Account

I am trying to create a GI to retrieve a list of GL Accounts with each associated Sub Account value. I have looked in the database and found the GroupMask column which ties the Account and Sub tables together with a bit relationship but I don't know how to join them in the GI. Is there another resolution table I can use to link the two entities?
The only thing I find in standard Acumatica is screen GL403000 (Account by Subaccount). This screen is an inquiry into historical GL data. Although I may be wrong, I believe accounts and subaccounts are defined as separate entities and then become a legitimate combination when used together. For instance, a sub account might be mapped to a department and an inventory account mapped to the item. Material issued to the department would result in the reportable combination of account and subaccount. That means you would have to look for historical usage of an account/subaccount to get the list. That's what GL403000 appears to be doing.
I can't tell you for sure that this is proper, but see if you can find what you need from:
GL.Account -> GL.GLHistory -> GL.Sub
Join Account to GLHistory via AccountID and GLHistory to Sub via SubID. You will want to aggregate the results to unique combinations or filter by period.
The actual code behind GL403000 is:
PXSelectBase<GLHistoryByPeriod> cmd = new PXSelectJoinGroupBy<GLHistoryByPeriod,
InnerJoin<Account,
On<GLHistoryByPeriod.accountID, Equal<Account.accountID>, And<Match<Account, Current<AccessInfo.userName>>>>,
InnerJoin<Sub,
On<GLHistoryByPeriod.subID, Equal<Sub.subID>, And<Match<Sub, Current<AccessInfo.userName>>>>,
LeftJoin<GLHistory, On<GLHistoryByPeriod.accountID, Equal<GLHistory.accountID>,
And<GLHistoryByPeriod.ledgerID, Equal<GLHistory.ledgerID>,
And<GLHistoryByPeriod.branchID, Equal<GLHistory.branchID>,
And<GLHistoryByPeriod.subID, Equal<GLHistory.subID>,
And<GLHistoryByPeriod.finPeriodID, Equal<GLHistory.finPeriodID>>>>>>,
LeftJoin<AH, On<GLHistoryByPeriod.ledgerID, Equal<AH.ledgerID>,
And<GLHistoryByPeriod.branchID, Equal<AH.branchID>,
And<GLHistoryByPeriod.accountID, Equal<AH.accountID>,
And<GLHistoryByPeriod.subID, Equal<AH.subID>,
And<GLHistoryByPeriod.lastActivityPeriod, Equal<AH.finPeriodID>>>>>>>>>>,
Where<GLHistoryByPeriod.ledgerID, Equal<Current<GLHistoryEnqFilter.ledgerID>>,
And<GLHistoryByPeriod.accountID, Equal<Current<GLHistoryEnqFilter.accountID>>,
And<GLHistoryByPeriod.finPeriodID, Equal<Current<GLHistoryEnqFilter.finPeriodID>>,
And<
Where2<
Where<Account.accountID,NotEqual<Current<GLSetup.ytdNetIncAccountID>>,And<Where<Account.type, Equal<AccountType.asset>,
Or<Account.type, Equal<AccountType.liability>>>>>,
Or<Where<GLHistoryByPeriod.lastActivityPeriod, GreaterEqual<Required<GLHistoryByPeriod.lastActivityPeriod>>,
And<Where<Account.type, Equal<AccountType.expense>,
Or<Account.type, Equal<AccountType.income>,
Or<Account.accountID,Equal<Current<GLSetup.ytdNetIncAccountID>>>>>>>>>>>>>,
Aggregate<
Sum<AH.finYtdBalance,
Sum<AH.tranYtdBalance,
Sum<AH.curyFinYtdBalance,
Sum<AH.curyTranYtdBalance,
Sum<GLHistory.finPtdDebit,
Sum<GLHistory.tranPtdDebit,
Sum<GLHistory.finPtdCredit,
Sum<GLHistory.tranPtdCredit,
Sum<GLHistory.finBegBalance,
Sum<GLHistory.tranBegBalance,
Sum<GLHistory.finYtdBalance,
Sum<GLHistory.tranYtdBalance,
Sum<GLHistory.curyFinBegBalance,
Sum<GLHistory.curyTranBegBalance,
Sum<GLHistory.curyFinYtdBalance,
Sum<GLHistory.curyTranYtdBalance,
Sum<GLHistory.curyFinPtdCredit,
Sum<GLHistory.curyTranPtdCredit,
Sum<GLHistory.curyFinPtdDebit,
Sum<GLHistory.curyTranPtdDebit,
GroupBy<GLHistoryByPeriod.ledgerID,
GroupBy<GLHistoryByPeriod.accountID,
GroupBy<GLHistoryByPeriod.subID>>>>>>>>>>>>>>>>>>>>>>>>>(this);
As you can see, it joins Account to GLHistoryByPeriod and then Sub to GLHistoryByPeriod. AH inherits from GLHistory.
Account and Subaccount entities are separate entities without a relationship between each other. GroupMask field is not about their relationship, it is about access restriction. Please correct your question and explain what do you really need? Note that Account and Subaccount are only connected in the scope of some transactional or historical entities, such as GL Transactions (GLTran), AR/AP Documents (ARRegister, APRegister) and many many others.
As it was already mentioned Account and sub account doesn't have direct link between them. If you still want to have some kind of connection between them, then consider adding custom column(s). Before doing this, give an answer on this question:
What will be relationship between account and sub account?
One to one, one to many, or many to many?
What kind of rules regarding defaulting of sub accounts be applied?
As an option if some account is selected on some entity, what sub account should be picked?
Opposite to 4, if some sub account is selected at some entity, what Account should be selected.
And so on. Then you can build customization package which will provide an answer on relationshops.

Dialogflow sys.location to detect full address (?)

I cant find a why to handle this situation:
Agent: Tell me your address
User Via j.f. Kennedy, Padova
in my weebhook I would like to receive something like:
{city:"Padova", streets:"Via John Fitzgerald Kennedy"}
instead of the value of the street detect by dialogflow using sys.location:
{city:"Padova", streets:"Via j.f Kennedy"}
My goal is to have the full name of the streets in my weebhook, I read https://cloud.google.com/dialogflow-enterprise/docs/reference/system-entities but I dont find help to my problem. If its not possible handle this with diaolog flow theres another way?
as said by sid8491, in dialogflow it isn't possible, you need to use a weebhook to pass the address that you are getting from the user to an API, I had the same issue and here in France, the government has an API which list all the addresses in France. If the address isn't known, the API return a list of the most matching addresses.
Often postal compagnies have this kind of API

How can I set the shipcarrier to More on a sales order using SuiteScript in a RESTlet?

SuiteScript v1, but I'll switch to SS v2 if it's the only way to make it work.
I've tried:
salesOrder.setFieldText('shipcarrier', 'More');
salesOrder.setFieldValue('shipcarrier', 'noups');
salesOrder.setFieldValue('shipcarrier', 'nonups');
But UPS is always selected once the record is saved.
shipcarrier is a bit of an odd thing.
I'm not sure it is actually sticky - in some contexts it appears to be and in some it doesn't.
It appears to be pointless to set unless you are also setting shipmethod.
salesOrder.setFieldValue('shipcarrier', ffShipCarrier); //'ups' || 'nonups'
salesOrder.setFieldValue('shipmethod', ffShipMethod)
PS from cja: My conclusion/solution: Setting shipmode does nothing unless recordmode is dynamic and shipmethod is set at the same time. If both those conditions are met then the value shipmode will be updated.
NetSuite support have warned me against using this solution:
"With regards to your concern, I am able to set the Ship carrier field on the Sales Order record in the client script(nlapiSetFieldValue('shipcarrier', 'ups');) however I was unable to set the value of the field in the server side script. Upon further investigation, the field (ship carrier) isn't exposed in the Record browser hence the field isn't officially exposed for scripting needs. Please refer to the following Suiteanswer article for your reference.
"I am really glad that the solution worked for you perfectly. In order to explain further, I would say it is not advisable to write scripts using unexposed fields in the record browser. It may change in the future without any prior notification and can cause problem and NetSuite will not hold any kind of responsibility for the same.
"User groups contains simple solution to complex tips and tricks provided by the experienced customers. On the other hand, NetSuite Support are stickly adhering to the official documentation/processes to assist any of its customer. The solutions provided in the User groups are totally upto the consent of the customers and can be implemented at their own risk if not confirmed in the official documentation or NetSuite Support."
You need to use setFieldValue and pass the internal id of the "More" ship carrier.
nlapiSubmitField('salesorder', recordid, 'shipcarrier', 'nonups');

How do we make a crystal report print only specific fields based off of the user running the report?

We use a construction software, Viewpoint. We need a report to print the GL Accounts associated only with the user running the report. I was wondering if anyone had any ideas on how I could easily and efficiently achieve this? My "last-resort alternative" is just creating separate reports for each GL that pulls only that GL's info.
It depends on how the accounts are associated to the user. If there is a link, you can simply create a user parameter that asks for the user name. Then in the record select of the report you only pull accounts that match the user name in the parameter.
So, for example your parameter is called {?userName}. In the Record Select the formula would something like {Accounts.Salesman} = {?userName}, where {Accounts.Salesman} would be the field that links the user with the account.
You can get the current user name and use it to filter the records in your report. There are 2 ways to do this :
create a parameter, hide it and automatically fill the value. You
will need a special viewer for this scenario. Let me know if this is
what would you prefer I can give you some links. If you leave the
parameter visible the user can insert any value and view any records
use an UFL . For example this one:
http://www.viksoe.dk/code/u2lwin32.htm provides a function LoginName
which will return currently logged user. There are other UFLs which
support similar functionality, check if your company is already
using something . This one is free. You need to register the UFL on
each system which will run the report . Once registered the
available functions will become available for formulas.
I personally prefer the viewer solution because it is more flexible and will cover other scenarios too. However if you need just the username UFL will be a better approach.

NameLookup does not pull Phone number

I have 2 fields that looks for username, the gets the email address and phone number from user's person document.
Creator_Email: #NameLookup([NoUpdate]; #UserName; "OfficePhoneNumber")
Creator_Ext: #NameLookup([NoUpdate]; #UserName; "OfficePhoneNumber")
The problem is there is one user reported that the extension did not pull out. It came out blank
I have checked on the person document and the phone number is there
the email address pull out correctly, but when I tested changing the first letter of first and last name to lower case (ie. Test.User#domain.com to test.user#domain.com), the field that pulls the email address still show up with Upper case.
I have tried to take the user.id and test it on a different PC and the problem persists.
Any idea why this happens? I know there are 2 address books set up in the company and that is not ideal but I have checked the 2 address books and make sure all the needed information are there.
The #NameLookup formula does a look up to a hidden view on the database, and sometimes you run into a situation where the index for that view isn't up-to-date. You can go to the database and press CTRL+SHIFT+F9 to rebuild all the views, or you can try to use the FORCEUPDATE flag in your formula.
I think you'll find that the #NameLookup call is finding people who have created entries for themselves in their personal address books. If those entries are incomplete, the lookups will fail to find the missing fields.
The #NameLookup will use the parameter...
Go to /File/Preferences/Location then is the current location find the Server Tab and check that you defined Domino Directory server (if empty user search on local)
Check also in the Mail tab, Recipient Name lookup that could "stop after first march" or exhaustively search ALL the names known on the client.
In #NameLookup you can also use [NoUpdate]:[Exhaustive]
be aware as mention before that view may be not up to date, that caching can occurs in the #NameLookup.
In place of this, I suggest to use:
#DbLookup("":"";YourServer:"names.nsf" ; "($VIMPeople)" ; #Name([ABBREVIATE] ;#UserName) ; "OfficePhoneNumber");

Resources