Biens ou Services ou Mixte?

Biens ou Services ou Mixte?

In the French e-invoicing reform, the electronic invoice must be classified as an invoice for goods “G“, an invoice for services “S” or mixed “M” (both goods and services). The 3rd group “Mixed” may be often tempting but must be assigned with caution: an invoice for goods with a complimentary [shipping] service on top remains an invoice for goods (we say, the service shares the VAT flavour of the core product), see Factures mixtes (biens + services) en facturation électronique 2026.

The same classification applies to export / EU deliveries provided to the authorities via a separate e-reporting data stream.

Let’s try to solve it step-by-step. In Dynamics 365 for Finance, the Free text invoice remains an invoice for services, “S”, as a rule. Beware: many companies use FTIs to sell fixed assets, these must be treated separately.

A Sales invoice may include both. Is there a way to classify an invoice as “G”, “S” or “M” without any knowledge but the e-invoice output alone? I tend to say yes: let’s assume the [electronic] invoice is ready and all custom units of measure at the lines have been converted into the UNECE standard. Then an invoice containing any of the units

KGM TNE GRM LTR CLT MLT MMT CMT MTR KMT CMK MMK MTK MTQ MMQ BAR PR SET DZN XBE XBG XBO XBX XCI XRL XCQ XCR XCS XCT XDR XBA NMP XPK XPX XPL XPU XRG XBB XSA LEF XTN XTU HLT XCY XEN LN

is likely to be an invoice for goods.

In contrary, an invoice with any of  HUR DAY WEE MON ANN SAN QAN MIN SEC E48 ACT KWT KWH MWH E25 should be an invoice for services.

The  C62  “a unit of something” may appear in both, thus excluded. As my reader pointed out, some companies sell software licenses in “pieces”  H87 , and this unit may be ambiguous, too. One should agree on the usage of for “H87” and “C62” in the company.  

Finally, an invoice with units from both 2 classes above would be a mixed one. In contrary, invoices with products and shipping or handling on top are realised differently in ERP systems: only with the product lines and header-level charges in addition. These will nicely fall into the “G” category, right where they belong.

Automate ICO purchase invoice in Dynamics 365 Finance

Automate ICO purchase invoice in Dynamics 365 Finance

On the current occasion that spoiled my Saturday: one legal entity posts an intercompany sales invoice, but the receiving entity does not automatically react. As a result, stock and intercompany balances start to diverge, because the sales side is already fully posted while the corresponding vendor invoice on the purchasing side is either missing or only created after manual intervention. In day-to-day operations, this leads to inconsistencies and unnecessary reconciliation effort. In the ICO direct delivery – “a chain of three” SO <- ICO PO <- ICO SO – this can be fully automated out of the box, but in the “chain of two” ICO SO -> ICO PO it cannot.

The standard process requires a user to actively navigate to the purchase order in the receiving company, click Intercompany tracing / Invoice journal (it switches the legal entities in the process), and manually trigger the “Generate intercompany invoice” function. Only after this step does the vendor invoice appear. The expectation is straightforward: once the sales invoice is posted, the corresponding intercompany vendor invoice should automatically be created in the receiving entity and appear there as a pending invoice, ready for review and approval. The system already contains all the necessary logic, but it simply does not execute it at the right moment.

The solution may be a surprisingly small extension at the right place. By hooking into the invoice posting process and calling the existing intercompany update logic immediately after posting, the missing step is automated:

				
					[ExtensionOf(classStr(SalesFormLetter_Invoice))]
internal final class SalesFormLetter_Invoice_Extension
{
    public void run()
    {
        next run();

        FormletterOutputContract outputContract = this.getOutputContract();

        if (outputContract)
        {
            CustInvoiceJour custInvoiceJour = outputContract.parmJournal() as CustInvoiceJour;
            if (custInvoiceJour && custInvoiceJour.InterCompanyCompanyId)
            {
                setPrefix("@SCM:IntercompanyGenerateInvoiceMenuCaption");
                custInvoiceJour.interCompanyUpdate();
            }
        }
    }
}
				
			

The key method is deliberately NOT wrapped into the same transaction as the main run(): a workflow or a closed period in the company of the recipient should not disrupt the seller’s operations.

Time Sheet-only role and access in Business Central

Time Sheet-only role and access in Business Central

A requirement came up to give users access to the Time Sheets in Business Central, without exposing any other part of the system. Even the Standard role “D365 TEAM MEMBER” is a way too broad for this, as they allow visibility into areas that are not relevant and may contain sensitive data. Other BC users where in pursuit of the same goal: Time Sheet View Only Access?

The solution was to introduce a dedicated role, for example “Timesheet User” based on the Service Manager role, combined with a custom permission set. The timesheet role can be downloaded here – Profile_PROJECT_TIMESHEETS – and imported via the Profiles (Roles) page.

The assignment to the user(s) is on the page User Settings; assigning the “Timesheet User” role ensures that users not only have the correct permissions, but also a restricted user experience. With a tailored profile or role center, navigation can be limited to timesheet-related pages only, avoiding access to other areas of the system.

The permission set was built from scratch and only includes the required tables, these cover Time Sheet Header and Time Sheet Line, including archive tables, as well as supporting data such as Resources, Jobs, Job Tasks, Approval Entries, Workflow, cues and some others. These dependencies are necessary for the landing page to display correctly:

This custom permission set can be downloaded here: UserDefinedPermissionSets.zipunpack and import it via the Permission Sets page, assign to the user(s) via the User list / User Card.

To let the people see only their own timesheets, the Time Sheet Owner User ID may not be blank on the Resource Card, but populated with the respective user ID. The Time Sheet Approver User ID would be typically somebody else, the supervisor. On the User Setup, the user is marked to Register Time, but not as a Time Sheet Admin.

The result is a controlled setup where external users can enter and review the timesheets, including approved and archived entries, without visibility into finance, sales, or other business data.