System Integration Consultant, Lebanon

Designing interfaces that survive power and internet cuts

Most integration patterns assume both systems are online when data moves. In Lebanon that assumption fails often enough to matter. A restaurant's point of sale may lose its link for an evening, a warehouse server may restart when power switches over, and a cloud ERP may be unreachable from one branch while running normally elsewhere.

I specify each interface to cope with that:

• Store and forward. The sending system keeps a queue of unsent records and releases them when the link returns, rather than dropping them or requiring manual re-entry.
• Duplicate-proof processing. Each record carries a unique reference, so a retry after a partial send cannot create a second invoice or receipt.
• Ordering rules. A refund or cancellation that arrives before its original sale is held until the original is posted.
• Visible backlogs. A simple status showing how many records are waiting, so managers know the ERP is behind before they rely on its reports.

Hosting choices affect all of this. Some Lebanese groups keep a local server for outlets and sync to a cloud ERP; others run everything in the cloud with outlets able to trade offline. I set out the trade-offs, including backup and recovery, and record the decision with its reasons.

Testing then includes deliberately cutting a connection in the middle of a transfer and checking that every record arrives exactly once, with totals matching on both sides.

Carrying currency and rate through every message

Lebanese businesses commonly record transactions in US dollars and Lebanese pounds, sometimes with more than one rate in use. Integrations are where this most often goes wrong. A connector built for a single currency may convert on its own, round differently or drop the rate altogether, and the reports in each currency stop agreeing.

My rule is that no interface converts by itself. Each message carries:

• The transaction currency and the amount in that currency.
• The rate applied and its source, as defined in the rules finance has approved.
• Where relevant, the settlement currency if payment is made in a different one.

The receiving system then records exactly what it was sent, and any conversion happens in the ERP under finance's rules. This applies equally to point-of-sale summaries, online orders, bank receipts, intercompany charges and payroll journals.

Which rate to use for which purpose is a decision for your finance team and accountant; I do not choose it. My part is making sure every interface respects that decision and that tests cover the awkward cases: a sale in dollars paid partly in pounds, a refund issued after the rate changed, a supplier paid from a dollar account against a pound invoice.

The CRM side of the same rules is described on my Lebanon CRM consultant page, and the platform view on multi-currency ERP.

Point of sale and delivery platforms for multi-outlet groups

Lebanese restaurant, cafe and retail groups often run several outlets, a central kitchen or warehouse and sometimes franchises or branches abroad. Sales arrive from outlet tills, delivery apps, phone orders and catering events. Each source has to land in the ERP in a form that supports stock control, margin by outlet and the VAT records your accountant needs.

The design points I settle early:

• Level of detail. Whether the ERP receives every ticket or a daily summary per outlet and payment method, depending on what stock and reporting require.
• Menu and item master. One owner for items, recipes and prices, published to tills and delivery listings, so a price change is not repeated in several places.
• Payment methods. Cash in each currency, cards and delivery platform settlements mapped separately, because each reconciles against a different account.
• Platform commissions and promotions. Recorded as distinct lines so the true margin on delivery sales is visible.
• Central kitchen transfers. Movements to outlets recorded as stock transfers, not as sales.

Outlets abroad usually trade under their own company and tax rules, so their feeds go to the correct entity. VAT treatment comes from your accountant; the integration only carries it accurately. For the operational picture, see food and beverage ERP.

Banks, transfer services and cash collected in two currencies

Cash still plays a large part in Lebanese trading, and it arrives in both currencies. Payments may also come through money transfer companies, wallet services, cards and bank transfers. Each channel produces its own records, and finance needs them all to reconcile against invoices and deposits.

I specify these flows channel by channel:

• Cash. Collection records from outlets, drivers or reps carry currency and amount, and deposits to the bank or safe are matched against them, with differences reported rather than absorbed.
• Bank statements. Imported by file where a feed is not available, with references mapped for matching and a check that every account in every currency is covered.
• Transfer and wallet services. Settlement reports mapped to customer receipts, with fees separated.
• Cards. Acquirer settlements split into gross sales, fees and payouts.
• Checks. Tracked from receipt to clearing in the ERP.

Banking capabilities in Lebanon vary and have changed over time, so I confirm what each bank and provider actually offers with your treasury team before designing anything. A controlled, validated file import is often more dependable than a custom connection.

Payroll follows the same pattern: the provider or payroll module calculates salaries and contributions, and the ERP receives a summarized journal with its currency clearly stated, under the rules your accountant sets.

Affiliates abroad, builders and ownership after go-live

Many Lebanese groups operate companies in the Gulf, Africa or Europe. Integration between them covers intercompany sales and recharges, shared customer or product data and feeds into group reporting. I specify each flow with a triggering document, matching references on both sides, currency and rate fields and a monthly reconciliation of intercompany balances. Where affiliates use different ERPs, I map their charts of accounts to a group structure agreed with finance.

For the build itself, my role is design, requirements, mapping, testing and oversight. Your developers, an integrator or the implementer write the interfaces. A small flow covered by a standard connector or a low-code tool is something I can sometimes set up myself. Whether to use a ready-made connector, an integration platform such as n8n, Make or Zoho Flow, or custom APIs depends on volumes, outage handling and who will support the result locally.

When integration work is done by a small implementer or a single freelance developer, documentation becomes essential. Each interface ends with a specification, test evidence, a runbook and access credentials held by the company rather than by one person. Alerts go to someone accountable in your team.

The work runs online, with visits only when arranged ahead. To keep an implementer on track, see my implementation oversight work in Lebanon; the system integration service describes my general method, and the Lebanon hub lists everything else.