ERP Software in Israel — Priority ERP Development and Cross-Border Integration

What actually goes wrong

The Israeli clerk who was told, in Spanish, that something had failed

An Israeli manufacturer opened a plant in Mexico. Someone took the project on, flew out, and engaged a local Priority implementation firm to build the site. Capable, likeable people — working with no discipline at all.

Everything was built directly on production. There were no backups. The test environment had not been kept current, so there was nothing to fall back to. And none of what they built connected to the systems the company was already running.

In Israel, the first symptom was stalls in the system, with the message on screen coming back in Spanish.

Some assumed the company had been hit by ransomware. Others concluded the system had simply lost its mind. Nobody's first thought was that a message had been written in one language and shown to a user working in another — because nobody thinks about that until it happens to them.

We were brought in after it had already come apart. The work began with reverse-engineering: every system that exchanged data with Priority, and every piece of standard code that had been overwritten in production with no backup to restore from. Once that map existed, the local team was placed under our direction — and the plant went live about two weeks later.

Why it happens, technically

Priority holds a translation for every entity title, every message and every help text, per language. A development that only fills the base language still works perfectly — as long as every user who ever reaches that code path is working in that base language. The moment a process built for one site is touched, even indirectly, by a user working in another, the untranslated string surfaces exactly as it was typed.

It survives testing because testing is done by people working in the language the module was written in. It surfaces in production, to everyone else.

How we build instead

Every language, from the first line. Entity titles, procedure and screen messages, user help — populated in Hebrew and in the target language as part of the development, not as a translation pass bolted on at the end.
More than two, in parallel. If the organisation runs three languages, the module supports three. There is no primary language that quietly wins when the others are missing.
Written so nothing is hard-coded. Text lives where Priority expects to find it per language, which is also what lets a fourth language be added later without reopening the logic.

The other half of the job

The developer on the other side is also our job

Cross-border work almost never means writing code alone. There is a counterpart — your customer's development team, a supplier's IT department, a carrier's integration engineer, a systems house in another country and another time zone. Integrations do not usually fail on the Priority side. They fail in the gap between two teams who each assumed the other understood something. They also fail earlier than that, in what was assumed possible: what the Priority REST API can and cannot do sets out where its contract ends, and what can still be delivered by building the Priority side to meet it.

What the counterpart gets from us

A complete written specification — every field, type, constraint and sequence, in English, before anyone writes code.
Worked examples of success and failure. Not only what a valid message looks like, but what comes back when it is malformed, rejected or duplicated. The failure examples are the ones that save the schedule.
One shared vocabulary. Agreed early, so that "order", "shipment" and "customer" mean the same thing on both sides of the interface.

What that buys

The other side builds without guessing, which is what keeps a project from becoming a queue of clarification emails across time zones.
Go-lives are quiet. When both sides implemented the same document, cutover day passes without incident. That has been the outcome on nearly every project we ran end to end — the exceptions being small bugs caught before go-live, which are normal at this size.
The interface stays understandable after everyone involved has moved on, because the specification is the documentation.

What these interfaces carry

Counterpart	What the interface carries
International carriers	Shipments, labels, tracking and status returning into Priority against the original order.
3PL and overseas warehouses	Stock, receipts, dispatches and counts, reconciled against inventory held in Priority.
Your counterpart's own systems	Where an integrator abroad owns the other system, Priority is connected to it — accounting, inventory, and distribution handed to third-party shippers.
Local operating requirements	Localisation per country, and adapting standard processes to how each site actually works.
Plants and branches abroad	Operating in local languages against one Priority system.

How the work is run

One owner, from specification to go-live

On these projects the same person owned the whole chain — the specification, the development, the delivery, and the coordination in between. Sometimes as an independent consultant brought in as the API specialist, sometimes as the project manager inside a company with international operations. Either way there was no seam between whoever wrote the spec and whoever had to make it work.

What that covers

Specification and code in the same hand. The document the other side builds against is written by the person who then has to make Priority hold up its end of it.
Third parties inside your organisation. Departments and vendors nobody formally controls, whose work the interface depends on anyway.
The vendors on the other side — shipping systems, customs, distribution platforms, accounting systems, and external accountants who need a file in one exact format and no other.

Why it is worth insisting on

Run to a method, not just coded. Scope, sequence and dependencies are managed — which comes from working in implementation as well as development, not from either alone.
Nothing falls between two suppliers. The gap between "the ERP side" and "the other system's side" is where cross-border projects actually fail, and it is the part with no natural owner.
One person to ask. Across time zones that is worth more than it sounds.

Where the work has been done

Over the years — as an independent consultant running our own projects, and as project manager and senior developer inside companies with international operations — the sites and counterparts have included:

Italy
Germany
Netherlands
United States
Mexico
Australia
South Korea
Taiwan
India

The work spans manufacturing plants, shipping and distribution, logistics and warehousing, and the adaptations each site needs before a shared system fits how it actually operates. On the multinational side it has covered procurement, production, testing and distribution across sites in Taiwan, India and the United States.

We do not publish client names. Everything above can be talked through in a call, within what our agreements allow.

Asked before the first meeting

Questions we get from abroad

Can one Priority system serve users in several languages at once?

Yes. Language is a property of the user, not of the installation, so a clerk in Israel and a warehouse manager in Mexico work in their own language against the same database. That is the standard behaviour. What breaks it is development that only populated one language — which is the failure described above, and it is avoidable at the time of writing rather than afterwards.

We already have an implementation partner in the other country. How do you work with them?

Alongside them, not instead of them. They know their site, their regulations and their users; we know what the shared system will do when both sides touch it. The work that usually has no owner is exactly the seam between the two — and that seam is where the incidents come from.

Our team abroad does not read Hebrew. Is that a problem?

No, provided what they use was built for them. Statutory documents in Israel still print in Hebrew because that is what the law requires; screens, messages and help do not have to. Whether they are usable comes down to how the development was written, not to how Priority was installed.

Who writes the interface specification — you or our counterpart?

We do, in English, before development starts, and we keep it current as the interface changes. It costs a few days at the beginning and it is the single clearest predictor of whether a cross-border integration goes live cleanly.

Can Priority connect to the system our head office or partner runs?

Usually, yes. Priority exposes a REST API and supports file-based and web-service interfaces. What decides the effort is rarely Priority's side — it is what the other system is willing to expose, and how far the two data models disagree about the same object.

Do you work in English?

Yes — specification, documentation and day-to-day work with your people and your counterparts. The system, and the people using it in Israel, stay in Hebrew.

Next step

Tell us what has to talk to what

One call is usually enough to say whether you are looking at a configuration question, an interface project, or development that has to be written for more than one language from the start.

Write to us if you are

Opening a plant, branch or warehouse abroad on the same Priority system
Running Priority in more than one language, or about to
Building an interface to a carrier, a 3PL provider or a partner’s system abroad
Working with a development team overseas and need someone on the Priority side
Living with an existing development that behaves differently at each site

WhatsApp — +972 52-470-2922 Phone — +972 52-470-2922 il.erp.info@gmail.com

Israel time (UTC+2, UTC+3 in summer). We answer email and WhatsApp outside those hours too.

Your ERP crossed a border. Your development has to cross it too.