Qué tiene que hacer el conector

• ¿Se pasan los artículos a la web a mano? ¿cada cuánto?
• ¿Los pedidos se teclean en SAP uno a uno?
• ¿Cuántas horas de trabajo al mes calculáis que es eso?

Por qué lo preguntamosMarca qué parte del conector es la urgente. No es lo mismo un cliente que se ahoga metiendo pedidos que uno al que le sobra un catálogo desactualizado.

• Una persona de negocio que pueda decir «esto se hace así» sin consultar.
• Una persona de informática que tenga las llaves de SAP y de la web.

Por qué lo preguntamosEn un proyecto así salen veinte decisiones pequeñas por semana. Si cada una tiene que subir a comité, el proyecto se para.

• Si ya vende: ¿cuántos productos tiene y cuántos pedidos al mes?
• ¿Hay alguna fecha que no se pueda mover (campaña, feria, cambio de web)?

Por qué lo preguntamosCambia el plan entero. Una tienda nueva se llena de golpe; una que ya vende hay que tocarla sin romper lo que funciona, y eso obliga a emparejar antes lo que ya existe.

• Si es que sí: nadie debería tocar productos en la web, porque se perderá.
• Si es que no: decidnos exactamente qué campos se retocan en la web y el conector no debe volver a escribir.

Por qué lo preguntamosEs la regla de la que cuelga todo lo demás. Sin ella, cualquier decisión posterior queda en el aire.

• Pedidos, se da por hecho. ¿Y clientes nuevos?
• ¿Algo más: valoraciones, consumos, altas de artículos?

Por qué lo preguntamosEscribir en SAP es lo delicado del asunto: un error ahí ensucia la contabilidad. Cuanto más corta sea esta lista, más tranquilo duerme todo el mundo.

Por qué lo preguntamosSuele haber campos, series o almacenes reservados para otra cosa. Es mejor tener la lista negra por escrito que descubrirla el día que algo se descuadra.

• Versión y nivel de parche.
• ¿Base de datos HANA o SQL Server?
• ¿En vuestro servidor o alojado por un tercero? ¿quién lo mantiene?
• Nombre de la empresa (base de datos). ¿Hay más de una empresa en juego?

• Es la puerta por la que el conector habla con SAP. ¿Está instalado y arrancado?
• ¿Dirección y puerto? ¿El certificado es propio o autofirmado?
• ¿Nos dais un usuario de SAP dedicado solo al conector, con licencia?
• ¿Cuántas sesiones simultáneas admite vuestra licencia?

Por qué lo preguntamosSin esa puerta abierta no hay conector posible. Y el usuario tiene que ser propio: si compartimos el de una persona, cualquier movimiento del conector aparece firmado por ella.

Por qué lo preguntamosLos pedidos que crea el conector son documentos contables de verdad. Necesitamos un sitio donde equivocarnos sin consecuencias, y que se parezca al real: con vuestros artículos, vuestras tarifas y vuestros almacenes. Una copia vacía no vale para probar nada.

• Dirección de la tienda real y, si la hay, de la de pruebas.
• Versión de WordPress y de WooCommerce.
• Dónde está alojada y quién la mantiene (¿agencia? ¿nombre y contacto?).
• ¿Está detrás de algún sistema de protección o caché que pueda bloquearnos?

Por qué lo preguntamosIgual que con SAP. Y «copia fiel» incluye los plugins: una web de pruebas sin los complementos que tiene la real no sirve para detectar los choques.

• Sobre todo los que tocan productos, precios, existencias, impuestos, pedidos o clientes.
• Multiidioma, multimoneda, precios por tipo de cliente, mayoristas, marketplaces, otro conector anterior.

Por qué lo preguntamosWooCommerce por sí solo es previsible; con veinte complementos encima, no. Un complemento de precios por tipo de cliente puede reescribir el precio justo después de que lo dejemos puesto, y desde fuera parece que el conector no funciona.

• Necesitamos claves de la interfaz de WooCommerce con permiso de lectura y escritura.
• Unas para pruebas y otras para la tienda real, distintas.

• ¿En un servidor vuestro, en uno nuestro o en la nube?
• ¿Hace falta red privada para llegar a SAP? ¿Hay que autorizar alguna dirección en el cortafuegos?
• ¿La tienda tiene restricciones de acceso por dirección o por país?

Por qué lo preguntamosEs la parte que más veces retrasa el arranque, y no por difícil, sino porque depende de terceros que tardan semanas en abrir un puerto.

Por qué lo preguntamosDetermina cuánto tarda una vuelta completa y si hay que trocearla. Con quinientos artículos todo es fácil; con cincuenta mil, hay que pensarlo.

• ¿Un campo que alguien marca? ¿Una familia o un grupo concreto? ¿Que tenga precio? ¿Que tenga foto?
• Si hoy no existe esa marca, ¿estáis dispuestos a crear un campo nuevo en SAP para eso?

Por qué lo preguntamosNecesitamos una regla que se pueda comprobar sola, sin que nadie tenga que decidirlo cada vez. Y tiene que ser una regla que vuestra gente pueda cambiar sin llamarnos.

• ¿Se oculta de la tienda? ¿Se borra? ¿Se queda visible pero agotado? ¿No se toca?
• ¿Y si se descataloga en SAP habiendo pedidos antiguos con él?

Por qué lo preguntamosBorrar en la web es irreversible y se lleva por delante las opiniones, las estadísticas y la dirección del producto en buscadores. Casi siempre es mejor ocultar.

• ¿Por qué campo se reconoce que un producto de la web es tal artículo de SAP: referencia, código de barras, otro?
• ¿Están limpios esos códigos, o hay duplicados y huecos?
• ¿Qué hacemos con los que no casen con nada?

Por qué lo preguntamosEs el trabajo más ingrato del proyecto y el que más sorpresas da. Normalmente hace falta un censo previo: cuántos casan, cuántos no y por qué.

En «¿cuándo se escribe?»Poned «siempre» si SAP manda para siempre en ese campo, o «solo al crear» si la web puede retocarlo después y no queréis que se pise.

• Categoría de la web, texto comercial, etiquetas, orden de aparición, destacados.
• ¿Quién los rellenaría y con qué criterio?

Por qué lo preguntamosCasi siempre falta algo. Crear campos nuevos en SAP es rápido; rellenarlos para todo el catálogo, no. Conviene saberlo ahora y no a mitad del proyecto.

• ¿Una sola para todos, o depende del cliente?
• ¿Esa lista se calcula a partir de otra (por ejemplo, la tarifa base menos un porcentaje)?

Por qué lo preguntamosSi el precio de la web es el resultado de un cálculo, el conector tiene que rehacer ese mismo cálculo. Necesitamos la fórmula exacta, no una aproximación.

• Los precios de esa lista en SAP, ¿llevan el IVA incluido?
• La tienda, ¿enseña los precios con IVA incluido o lo suma al final?
• ¿Qué tipos de IVA manejáis y hay artículos con tipo distinto?

Por qué lo preguntamosEs el error más caro y más fácil de cometer del proyecto entero.

• ¿Hay clientes con tarifa propia o descuento por grupo que deban verlo al entrar en la web?
• ¿Cuántos grupos distintos? ¿cuántos clientes con precio especial?

Por qué lo preguntamosEs lo que separa una tienda sencilla de un proyecto del doble de tamaño. Publicar un precio por artículo es fácil; publicar un precio por artículo y cliente multiplica el trabajo y suele necesitar un complemento en la web.

• ¿Salen de SAP o los pone marketing en la web?
• Si salen de SAP, ¿de qué campo y con qué fechas de inicio y fin?

• ¿La tienda vende solo en euros? ¿SAP trabaja en euros?
• ¿Cuántos decimales y cómo se redondea?

Por qué lo preguntamosParece una tontería y no lo es.

• ¿Cómo se calculan hoy: por peso, por importe, por zona, gratis a partir de X?
• ¿Esa tabla vive en la web o en SAP?

• ¿Uno solo, varios sumados, o depende del artículo?
• Nombres o códigos exactos de esos almacenes.

• ¿Lo que hay en la estantería, o eso menos lo ya comprometido en pedidos?
• ¿Se reserva un colchón de seguridad? ¿se publica un tope (por ejemplo, «más de 10»)?

Por qué lo preguntamosPublicar la cantidad física a secas es lo que provoca las sobreventas: hay diez unidades, pero ocho ya están apalabradas para un cliente de la tienda física.

• ¿Bajo pedido, con plazo? ¿Solo algunos artículos?
• ¿O si no hay, no se vende y punto?

• ¿Vale con cada media hora? ¿Cada cinco minutos? ¿Una vez de madrugada?

Por qué lo preguntamosCuanto más a menudo, más carga para SAP. Hay que buscar el punto en el que no sobrevendáis sin ahogar el servidor.

• ¿En una carpeta de red, dentro de SAP, en la web ya, en un servicio externo?
• ¿Cómo se llaman los ficheros? Poned tres ejemplos reales.
• ¿Cuántas por artículo, como mucho?

Por qué lo preguntamosSi el orden no está en el nombre del fichero ni en ningún campo, no hay forma de adivinarlo, y las fotos saldrán barajadas.

• Si sale de SAP, ¿de qué campo: familia, grupo, otro?
• ¿Un artículo puede estar en varias categorías a la vez?

Por qué lo preguntamosEs la pregunta donde más veces se responde «de la familia de SAP» y luego no funciona.

• ¿Un artículo distinto por cada talla y color, o uno solo con atributos?
• Si son artículos distintos, ¿qué los agrupa? ¿un código común, un campo?
• ¿Precio y existencias distintos por variante?
• ¿Cuántos productos con variantes y cuántas variantes de media?

Por qué lo preguntamosSi en SAP cada talla es un artículo suelto y en la web tiene que ser un producto con desplegable, hace falta un campo que diga cuáles van juntos y en qué orden. Sin eso, salen quince productos separados en vez de uno.

• ¿Nada más hacerlo el cliente? ¿Solo cuando está cobrado? ¿Cuando alguien lo revisa?
• ¿Y los que se pagan por transferencia o contra reembolso?

Por qué lo preguntamosMeterlos al hacerlos os llena SAP de pedidos que nunca se pagan. Meterlos solo al cobrar retrasa la preparación. Hay que elegir a sabiendas.

• ¿Pedido de venta, entrega o factura?
• ¿Entra como borrador para que alguien lo apruebe, o directamente en firme?
• ¿Serie de numeración propia para lo que venga de la web?

Por qué lo preguntamosEmpezar por borradores es lo prudente los primeros meses: si el conector se equivoca, se corrige antes de que afecte a nada. Y una serie propia os deja ver de un vistazo qué ha vendido la web.

• ¿Cómo tienen que verse en SAP: descuento en cada línea, descuento sobre el total, una línea negativa?
• ¿Hay promociones del tipo «tres por dos» o regalos?

Por qué lo preguntamosSi el importe final que le habéis cobrado al cliente no cuadra al céntimo con el que queda en SAP, la contabilidad no cierra. Y con los descuentos, redondear mal un céntimo por línea se convierte en un descuadre grande a fin de mes.

• ¿Vendéis a Canarias, Ceuta o Melilla? ¿Al resto de la Unión Europea? ¿Fuera?
• ¿Hay clientes con recargo de equivalencia?
• ¿Qué indicador de IVA corresponde a cada caso?

• Casos típicos: artículo que no existe en SAP, datos fiscales mal, SAP parado, sin stock.
• ¿A quién se avisa y cómo? ¿se reintenta solo? ¿se deja apartado para revisar?

Por qué lo preguntamosLo peor que puede pasar no es que un pedido falle: es que falle en silencio y nadie se entere hasta que el cliente reclama. Hay que decidir a quién le suena la alarma.

• Un día normal, y el peor día del año (rebajas, Navidad, Black Friday).

• ¿Todos los pedidos de la web van a una ficha tipo «Ventas web», o se crea una ficha por cada comprador?

Por qué lo preguntamosEl cliente genérico es mucho más simple y mantiene SAP limpio, pero perdéis el historial por comprador. Crear fichas os da ese historial a cambio de que SAP se llene de miles de particulares, muchos de una sola compra.

• ¿Por el NIF? ¿Por el correo? ¿Por los dos?
• ¿Y los particulares que compran sin dar NIF?
• ¿Qué grupo, condiciones de pago y numeración les corresponden?

Por qué lo preguntamosSi acertamos poco, acabáis con el mismo cliente cinco veces en SAP. Si nos pasamos de listos, dos personas distintas comparten ficha, que es peor.

• ¿Entran a la web con usuario propio? ¿Cada uno con su tarifa y sus condiciones?
• ¿Quién les da de alta el usuario web?

• ¿Cuando en SAP se hace el albarán? ¿Cuando lo recoge el transportista?
• ¿De dónde sale el número de seguimiento y el nombre del transportista?
• ¿Hay envíos parciales?
• ¿Quién avisa al cliente: la web, el transportista o vosotros?

• ¿Entran en esta primera versión o se dejan para después?
• Si se anula un pedido en la web, ¿qué debe pasar en SAP? ¿Y al revés?
• ¿La factura la genera SAP? ¿el cliente se la descarga de la web?

Por qué lo preguntamosLas devoluciones suelen ser el 20% del trabajo y el 3% de las operaciones. Es muy razonable dejarlas fuera de la primera versión, pero hay que decirlo por escrito.

• ¿Hay horas en las que SAP no se puede tocar: copias de seguridad, cierres, inventarios?
• ¿La tienda tiene ventanas de mantenimiento?
• ¿Los pedidos tienen que entrar al momento o vale cada pocos minutos?

• ¿Por correo? ¿A qué direcciones?
• ¿Quién mira el registro cada día para ver que todo va bien?
• ¿Qué consideráis urgente: que no entren pedidos, que el stock se quede parado, que los precios estén mal?

Por qué lo preguntamosUn conector que se para y nadie se entera hace más daño que no tener conector. Solemos dejar un vigilante que avisa por correo si dejan de entrar pedidos, pero hace falta que alguien lea ese correo.

• ¿En un servidor vuestro, en uno nuestro, en la nube?
• ¿Quién hace las copias de seguridad y quién puede pararlo si hace falta?
• ¿Queréis contratar mantenimiento? ¿con qué horario y qué tiempos de respuesta?

• Pasar productos de la web hacia SAP (solo va en un sentido)
• Varios idiomas y traducciones
• Varias monedas
• Más de una tienda
• Marketplaces (Amazon, eBay y similares)
• Cobros, conciliación bancaria y contabilidad
• Devoluciones y abonos
• Traer el histórico de pedidos anteriores
• Diseño y desarrollo de la web
• Limpiar los datos de SAP o de la web
• Facturación electrónica

• Usuario de SAP dedicado al conector, en el entorno de pruebas
• Dirección del Service Layer y acceso desde donde vaya a correr el conector
• Claves de la interfaz de WooCommerce, en la web de pruebas
• Acceso de red o red privada, si hace falta
• Exportación de 20 artículos representativos de SAP, con todos sus campos
• Un pedido de venta real de SAP, como ejemplo de cómo tiene que quedar
• Un pedido real de la tienda, con todos sus datos
• Lista de complementos instalados en la web
• Persona de contacto de negocio y persona de contacto de informática
• Este documento contestado