Problema al timbrar factura (Service Layer)

Hola a todos, me presento en el foro de Ayuda SAP, me llamo Eduardo López del Castillo, soy desarrollador en una empresa donde ocupan SAP B1 en México , me encuentro trabajando en una implementacion de SAP con Service Layer a una pagina web.

Mi backend esta implementado en Fast API donde me conecto al service layer.

Tengo un detalle al momento de crear facturas por medio de Service Layer, si bien la factura puedo crearla sin problemas tomando como base las ofertas de venta , el problema surge al intentar crearla timbrada al SAT , es decir, intento llamar al Electronic File Manager, pero siempre falla a pesar de enviar los mismos campos que encuentro en la respuesta de facturas creadas desde SAP GUI.

Voy a compartir un pedazo del payload que mando a mi backend.

# ─── PAYLOAD FACTURA ─────────────────────────────────────

    payload: dict = {

        "CardCode": cardcode,

        "DocDate": today,

        "DocDueDate": today,

        "TaxDate": data.tax_date or today,

        "PaymentGroupCode": payment_group_code,

        "PaymentMethod": PAYMENT_METHODS_OPYM.get(pm, ""),

        "U_B1SYS_MainUsage": invoice_data.get("cfdi_uso") or "S01",

        "U_CP": invoice_data.get("cp_fiscal") or cp,

        "FederalTaxID": invoice_data.get("lictradnum") or "XAXX010101000",

        "U_TRANSPORTES": invoice_data.get("reg_fiscal") or "616",

        "U_fpago": invoice_data.get("forma_pago") or ("PPD" if pm == "POR DEFINIR" else "PUE"),

        "EDocGenerationType": "edgt_Generate",

         "U_MetPago": "01", #METODO DE PAGO EFECTIVO PARA PASAR EL CAMPO

         

         "ShipToCode": "DIR",

         "PayToCode": "DIR",

         

        \# Fuerza el CP en la dirección de entrega

        "AddressExtension": {

            "ShipToZipCode": invoice_data.get("cp_fiscal") or cp,

            "BillToZipCode": invoice_data.get("cp_fiscal") or cp,

        },

        

        #Intentar timbrar factura 

        "ElectronicProtocols": \[

        {

            "ProtocolCode": "edpc_CFDI",

            "GenerationType": "edgt_Generate",

            "MappingID": 27,

            "TestingMode": "tNO",

            "PaymentMethod": "01",

            "CFDiExport": "01",

        }

    \],

        "DocumentLines": document_lines,

    }

El flujo de mi endpoint que consulta al service layer se resume en

  1. Consultar la info completa de la oferta de venta de donde proviene.
  2. Crear la factura sin pagar ( De hecho aqui tuve otro problema y es que tuve que poner el payment_Group_code o metodo de pago de la seccion finanzas como -1 o Cash basic ya que no me dejaba crearla y pagarla al mismo tiempo)
  3. Se intenta timbrar (lo omito para seguir haciendo pruebas)
  4. Se hace el pago de la factura
  5. Finaliza ( me da la factura con el pago recibido)

El caso es que por algun motivo el timbrado siempre falla aunque ya llene todos los campos que pide regularmente y el mensaje de error es muy generico, siempre el mismo

Can not call the Electronic File Manager y es todo.

¿Alguien ha pasado por el mismo problema al hacer implementaciones de Service Layer con las facturas?

¿Como puedo resolverlo?

Hola, Eduardo.

Pasé por un escenario similar: FastAPI → Service Layer → factura a partir de oferta, y el timbrado con EDocGenerationType / ElectronicProtocols fallando con Can not call the Electronic File Manager.

Ese error no es de CFDI. No te está rechazando U_fpago, U_MetPago, el CP ni el MappingID. Lo que falla es que el proceso de Service Layer no puede invocar Electronic File Manager. En GUI sí funciona porque el cliente de SAP B1 carga EFM en Windows. Service Layer es otro proceso (IIS o Linux) y no tiene esa llamada COM.

Por eso copiar los mismos campos de una factura creada en GUI no alcanza.

Qué está pasando

  1. EFM no corre dentro de Service Layer.
    Es un componente de Windows ligado al cliente / DI. SL hace el Add de la factura, pero al ver edgt_Generate intenta llamar a EFM y corta con ese mensaje genérico.

  2. Generar el eDoc en el mismo POST /Invoices es el patrón que más falla.
    Aunque el documento se cree, el timbrado síncrono en el alta casi nunca es estable por SL.

  3. Si Service Layer está en Linux (HANA), EFM no existe en ese servidor. Ahí el error es estructural, no de payload.

  4. PaymentGroupCode = -1 / Cash y luego pagar no es la causa del mensaje, pero sí complica CFDI (PUE/PPD). Primero hay que lograr que SL pueda llamar el generador de eDoc.

Cómo lo resolví

Paso 1. Crear la factura sin pedir generación:

  • Quitar ElectronicProtocols.
  • EDocGenerationType: edgt_NotRelevant o edgt_GenerateLater (según versión).
  • Confirmar que /Invoices deja la factura creada.

Paso 2. Timbrar después, en una llamada aparte. Según versión de B1 10:

POST /b1s/v1/Invoices(DocEntry)/GenerateEDoc

o el servicio de documentos electrónicos de esa FP.
Si esa acción tampoco existe o responde lo mismo, SL no tiene EFM disponible en ese host.

Paso 3. Validar infraestructura (esto es lo que más se omite):

  • EFM instalado y corriendo en el mismo Windows donde vive Service Layer.
  • Usuario del SL (no el de GUI) con permiso de documentos electrónicos.
  • Serie de la factura con el mapping CFDI (tu MappingID: 27) asignado en Document Settings → Electronic Documents, no solo “porque en GUI salió 27”.
  • Si SL está en Linux: el timbrado no va a salir por SL. Hay que generar el eDoc en un job Windows (DI API / addon fiscal) o mover SL a Windows.

Sobre el payload

ElectronicProtocols con edpc_CFDI + edgt_Generate en el alta es justo lo que dispara la llamada a EFM. Mientras SL no pueda ejecutarla, da igual que U_B1SYS_MainUsage, U_TRANSPORTES y AddressExtension estén bien.

Cuando EFM sí se ejecuta y el XML está mal, el error cambia: ya no es genérico, sale rechazo del PAC / schema / método de pago. Ahí sí conviene revisar PUE vs pago inmediato.

Flujo que me funcionó

  1. Crear factura desde la oferta, sin generar eDoc.
  2. Llamar generación de eDoc después (endpoint de documento electrónico, no el POST de alta).
  3. Recibir UUID / acuse.
  4. Recién entonces registrar el pago.

Si el paso 2 sigue diciendo Can not call the Electronic File Manager, el payload ya no es el tema: EFM no está accesible para Service Layer (servicio apagado, no instalado, o SL en Linux).

¿Service Layer te corre en Windows o en Linux? Con eso se acota si es configuración o si hay que sacar el timbrado de SL.


En una frase: el GUI llama a EFM; Service Layer, en tu flujo actual, no. El payload se ve bien; el fallo es de arquitectura/llamada, no de campos SAT.