Amazon allows extremely long addresses (60 characters), but apparently they do some validation. Example screen shot:
A cursory look shows that UPS and FedEx labels often limit addresses to 35 characters.
We recently received addresses of 60 characters from a B2B partner selling through Amazon, but our system takes 35 characters. We receive data through a Purchase Order in the EDI 850 format.
Does each company that does automated shipping from Amazon have to write address manipulation routines to make the data fit? Or are there ways to print the extremely long address with FedEx and UPS?
I don't want to limit this question to any one language or technology. I'm just wondering the conceptual issues and how people handle this in general.
Related
Every few months my team creates a list of parts we couldn't have predicted we'd need. For a while we've been going to digikey and mouser, typing about 1000 searches in, and seeing what supplier has the right quantity.
But part shortages have made the "quantity available now" fluctuate considerably hour to hour, and sometimes even minute to minute. Is there a way to setup notifications for when products have a certain amount available?
I've tried webscraping digikey with nodejs, and making a little dashboard of link's that turn green when they're ready to buy. That worked for a while until Digikey blocked my IP address
I've considered using their API's, but they don't appear to offer buy if <logic> event setters, and only offer 1000 requests a day
mouser api
digikey api
What would be the best tool for the job?
I am trying to extract numeric information from set of SMSs. The regexes fail in extracting balance and credit amounts as the patterns of the SMS is not consistent throughout the industry.
We are currently making assumptions to make it work like First Amount = Credit amount
Second Amount=Balance.
This has lot of limitations and error rate is gradually increasing.
Anyone has any alternatives to regexes?
There is no standard for this kind of message as every operator creates its own messages. this is marketing communication... Yet, for a given operator and a given plan all replies to balance inquiry messages should be the sames (as long as they are not changed by operators marketing teams...).
Regexes are a good tool but you need to know the message forehand and create the appropriate regex patterns
I'm pretty new to Maximo and I have a question about how things should be handled. We have a project of integrating our ERP with Maximo using MIF interfaces. I'd like to know how you performed this in your company as I'm sure we're not the only one facing this challenges.
Let's go pretty simple about the Inventory. Receiving will be performed in our ERP and sent to Maximo. "Consumption" and inventory movements will be performed in Maximo and interfaced back to our ERP. so far so good, standard process.
However, there's a difference in the real inventory vs the inventory from a Financial perspective. As an example, we have let's say 3 cutters (same part number, different serial number). We have 2 in the internal storage and 1 in the machine where its being used. Once it is in the machine, it's known as "consumed" by finance. So from a finance point of view, there's only 2 in stock. From the tooling guy however, there's 3! The one in the machine can be taken out and replaced by one of the two others.
How are things like that handled in maximo? Any help, advices would be appreciated.
Regards
M.
It depends on how you plan to track on the individual level (track cutters by individual asset tags or serial numbers) or on the group level (3 cutters with the same item number)
If the cutter is treated as inventory and not as an asset, once it is issued then it is considered used. You can opt to use "Condition Code" and give each item a value from 0 to 100. Think of this value as depreciation. If a cutter is swapped out, then the new cutter (100%) is issued, and the replaced cutter is disposed of or returned to the shelf with a diminished value (e.g. 25%).
Background -
I am not a programmer.
I do trade spot forex on an intraday basis.
I am willing to learn programming
Specific Query -
I would like to know how to export into Excel in real time 'top of book' price and volume data as displayed on the LMAX level 2 widget/frame on -
https://s3-eu-west-1.amazonaws.com/lmax-widget/website-widget-quote-prof-flex.html?a=rTWcS34L5WRQkHtC
In essence I am looking to export
price and volume data where the coloured flashes occur.
price and volume data for when the coloured flashes do not occur.
I understand that 1) and 2) will encompass all the top of book prices and volume. However i would like to keep 1) and 2) separate/distinguished as far as data collection is concerned.
Time period for which the collected data intends to be stored -> 2-3 hours.
What kind of languages do I need to know to do the above?
I understand that I need to be an advanced excel user too.
Long term goals -
I intend to use the above information to make discretionary intraday trading decisions.
In the long run I will get more involved with creating an algo or indicator to help with the decision making process, which would include the information above.
I have understood that one needs to know coding to get involved in activities such as the above. Hence I have started learning C ++. More so to get a hang/feel for coding.
I have been searching all over the web as to where to start in this endeavor. However I am quite confused and overwhelmed with all the information.
Hence apart from the specific data export query, any additional guidelines would also be helpful.
As of now I use MT4 to trade. Hence I believe to do the above - I will need more than just MT4.
Any help would be highly appreciated.
Yes, MetaTrader4 is still not able ( in spite of all white-label-ed Terminals' OrderBook Add-On(s) marketing and PR efforts ) to provide an OrderBook-L2/DoM-data into your MQL4 / NewMQL4 algorithm for any decision making. Third party software tools' integration is needed to make MQL4-code aware of the real-time L2/DoM-data.
LMAX widget has impressive look & feel, however for your Excel export it requires a lot of programming efforts to re-use it for an automated scanner to produce data for 1 & 2 while there may be some further, non-technical, troubles on legal / operational restrictions for automated scanner to be operated on such data-source. To bring an example, the data-publisher policy restrict automated Options-pricing scanners for options on { FTSE | CAC | AMS | DAX }, may re-visit the online published data-sources no more than once a quarter of an hour and get blocked / black-listed otherwise. So a care and a proper data-source engineering is in place.
Size of data collection is another issue. Excel has some restrictions on an amount of rows/columns that may get imported. Large data-files, the more the CSV-imports may strike these limits. L2/DoM-data, collected for 2-3 hours just for one single FX Major may go beyond such a limit, as there are many records per second ( tens, if not hundreds, with just a few miliseconds between them ). Static file-size of collected data-records take typically several minutes to just get written on disk, so proper distributed processing data-flow-design and non-blocking-fileIO engineering is a must.
Real-time system design is the right angle to view the problem solution approach, rather than just some programming language excersise. Having mastered some programming language is a great move, nevertheless, so called robust real-time system design, and Trading software is such a domain, requires, with all respect, a lot more insights and hands-on experience than to make an MQL4 code run multi-thread-ed & multi-process-ed with a few DLL services for a Cloud/Grid-based distributed processing system.
How much real-time traffic is expected to be there?
For just a raw idea, what the Market can produce per second, per milisecon, per microsecond, let's view a NYNEX traffic analysis for one instrument:
One second can have this wild relief:
And once looking into 5-msec sampling:
How to export
Check if the data-source owner legally permits your automated processing.
Create your own real-time DataPump software, independent of the HTML-wrapped Widget
Create your own 'DB-store' to efficiently off-load scanned data-records from real-time DataPump
Test the live data-source >> DataPump >> DB-store performance & robustness on being able to serve error-free a 24/6 duty for several FX Majors in parallel
Integrate your DataPump fed DB-store local data-source for on-line/off-line interactions with your preferred { MT4 | Excel | quantitative-analytics } package
Integrate a monitoring of any production environment irregularity in your real-time processing pipeline, which may range from network issues, VPN / hosting issues, data-source availability issues to an unexpected change in the scanned data-source format/access conditions.
I have a column which is made up of addresses as show below.
Address
1 Reid Street, Manchester, M1 2DF
12 Borough Road, London, E12,2FH
15 Jones Street, Newcastle, Tyne & Wear, NE1 3DN
etc .. etc....
I am wanting to split this into different columns to import into my SQL database. I have been trying to use Findstring to seperate by the comma but am having trouble when some addresses have more "sections" than others. ANy ideas whats the best way to go about this?
Many THanks
This is a requirements specification problem, not an implementation problem. The more you can afford to assume about the format of the addresses, the more detailed parsing you will be able to do; the other side of the same coin is that the less you will assume about the structure of the address, the fewer incorrect parses you will be blamed for.
It is crucial to determine whether you will only need to process UK postal emails, or whether worldwide addresses may occur.
Based on your examples, certain parts of the address seem to be always present, but please check this resource to determine whether they are really required in all UK email addresses.
If you find a match between the depth of parsing that you need, and the assumptions that you can safely make, you should be able to keep parsing by comma indexes (FINDSTRING); determine some components starting from the left, and some starting from the right of the string; and keep all that remains as an unparsed body.
It may also well happen that you will find that your current task is a mission impossible, especially in connection with international postal addresses. This is why most websites and other data collectors require the entry of postal address in an already parsed form by the user.
Excellent points raised by Hanika. Some of your parsing will depend on what your target destination looks like. As an ignorant yank, based on Hanika's link, I'd think your output would look something like
Addressee
Organisation
BuildingName
BuildingAddress
Locality
PostTown
Postcode
BasicsMet (boolean indicating whether minimum criteria for a good address has been met.)
In the US, just because an address could not be properly CASSed doesn't mean it couldn't be delivered - cip, my grandparent-in-laws live in enough small town that specifying their name and city is sufficient for delivery as local postal officials know who they are. For bulk mailings though, their address would not qualify for the bulk mailing rate and would default to first class mailing. I assume a similar scenario exists for UK mail
The general idea is for each row flowing through, you'll want to do your best to parse the data out into those buckets. The optimal solution for getting it "right" is to change the data entry method to validate and capture data into those discrete buckets. Since optimal never happens, it becomes your task to sort through the dross to find your gold.
Whilst you can write some fantastic expressions with FINDSTRING, I'd advise against it in this case as maintenance alone will drive you mad. Instead, add a Script Transformation and build your parsing logic in .NET (vb or c#). There will then be a cycle of running data through your transformation and having someone eyeball the results. If you find a new scenario, you go back and adjust your business rules. It's ugly, it's iterative and it's prone to producing results that a human wouldn't have.
Alternatives to rolling your address standardisation logic
buy it. Eventually your business needs outpace your ability to cope with constantly changing business rules. There are plenty of vendors out there but I'm only familiar with US based ones
upgrade to SQL Server 2012 to use DQS (Data Quality Services). You'll probably still need to buy a product to build out your knowledge base but you could offload the business rule making task to a domain expert ("Hey you, you make peanuts an hour. Make sure all the addresses coming out of this look like addresses" was how they covered this in the beginning of one of my jobs).