Hola,

Estoy teniendo el mismo problema, me alegro de que no esté aislado para mí.

Actualizamos a magento 2.1.1 y enfrentamos problemas de pago asociados con la cantidad de líneas de dirección que tiene un cliente.

Si un cliente solo tiene 1 línea de dirección completa y la configuración predeterminada es 2, se produce el error.

Si establece el valor en 1 en el panel de administración, los clientes con 1 línea de dirección pueden realizar el pago, pero con los clientes existentes que han completado 2 líneas, el problema vuelve a ocurrir.

Realmente me vendría bien una solución lo antes posible.

Gracias por adelantado
Dan

He estado atascado en este problema por un tiempo ... parece que no puedo resolverlo ... espero que alguien pueda ...

Nadie tiene una idea de eso. Estoy realmente decepcionado con magento 2.1. No creo que la versión 2.1 esté lista para la producción.

@prasannanwr , proporcione los pasos exactos que realiza y especifique los métodos de pago y envío que utiliza. ¿El problema está presente solo para el método de pago Contra reembolso o también para otros? ¿El cliente está registrado o realiza un pedido como invitado?
¿Fue una actualización de alguna versión anterior o la instalación clara de Magento?

El método de envío es Envío gratuito y el método de pago es Contra reembolso.
No he probado en otros métodos de pago. Mi requisito es el bacalao ahora. El cliente está haciendo el pedido como invitado.

He instalado magento 2.1.1 nuevo. Antes funcionaba bien. Pero después de ejecutar la actualización del sistema y compilar, obtuve este error, supongo, pero no estoy seguro.

Hola Veloraven.

Para replicar el mismo error en nuestro sitio web y un poco más de información, consulte a continuación.

El mismo error que se publicó aquí está sucediendo con nosotros. Actualizamos de 2.0.9 a 2.1.1.

También estamos experimentando los mismos problemas que se documentan aquí, que parece que esto se repite para:

https://github.com/magento/magento2/issues/4921

Dentro del panel de administración, configure las líneas de dirección para los clientes en 2:

Tiendas> Configuración> Cliente> Configuración del cliente> Opciones de nombre y dirección: el número de líneas en una dirección es 2

Luego, registre un nuevo cliente, pero solo complete una línea de dirección.

Cuando va a realizar un pedido, aparece el error originalmente publicado aquí en la última etapa.

Si cambia el valor de administrador a 1 (que fue una solución temporal para 2.1), el error ocurre con los clientes que tienen 2 líneas de dirección completadas.

Espero que esto ayude.
Dan

Finalmente descubrí el problema. Me salteé el campo Ciudad al finalizar la compra porque no necesitamos la ciudad en la dirección.
Al habilitar el campo de la ciudad, funcionó. Quiero eliminar la ciudad al finalizar la compra. ¿Hay alguna buena forma de hacerlo?

Gracias

Tengo el mismo problema, pero nada lo ha solucionado:
Cuando intento pagar:
{"message": "Se produjo un error en el servidor. Intente realizar el pedido nuevamente.", "trace": "# 0 [función interna]: Magento \ CheckoutModel \ GuestPaymentInformationManagement-> savePaymentInformationAndPlaceOrder ('3bc99aeaf443e17 ...' , 'james.vreeken@t ...', Objeto (Magento \ QuoteModel \ Quote \ Payment), Objeto (Magento \ QuoteModel \ Quote \ Address)) \ n # 1 / Users / jvreeken / Sites / morganjewelers / vendor / magento /module-webapi/Controller/Rest.php(307): call_user_func_array (Array, Array) \ n # 2 /Users/jvreeken/Sites/morganjewelers/vendor/magento/module-webapi/Controller/Rest.php(216): Magento \ Webapi \ Controller \ Rest-> processApiRequest () \ n # 3 /Users/jvreeken/Sites/morganjewelers/var/generation/Magento/Webapi/Controller/Rest/Interceptor.php(37): Magento \ Webapi \ Controller \ Rest-> dispatch (Object (Magento \ Framework \ App \ Request \ Http)) \ n # 4 /Users/jvreeken/Sites/morganjewelers/vendor/magento/framework/App/Http.php(135): Magento \ Webapi \ Controller \ Rest \ Interceptor-> dispatch (Object (Magento \ Framework \ App \ Request \ Http)) \ n # 5 / Usuario s / jvreeken / Sites / morganjewelers / vendor / magento / framework / App / Bootstrap.php (258): Magento \ Framework \ App \ Http-> launch () \ n # 6 / Users / jvreeken / Sites / morganjewelers / index. php (39): Magento \ Framework \ App \ Bootstrap-> ejecutar (Object (Magento \ Framework \ App \ Http)) \ n # 7 {main} "}

También recibo el mismo error. Estoy decepcionado con este software, esta es la primera opción de software de comercio electrónico que he probado y estoy debatiendo cambiar. PUEDO decir que, dados los errores en esta versión, no hay forma de que obtenga una licencia para EE. De ninguna manera. Errores al agregar artículos al catálogo tuve que eludirme. Ahora no puedo pagar porque recibo un error. He revisado todos los registros y no muestran nada. Todos los campos son válidos al finalizar la compra, se rompen, pero aún se procesan. Estoy usando transacciones en vivo, estoy en modo de producción (acabo de cambiar anoche)
Envío y manipulación es 0 (para recogida y entrega local). Este software debería haber sido bien examinado antes de lanzar una versión con errores y causar problemas a las personas con una base de clientes. Gracias a Dios aún no lo he lanzado.

Sin mencionar que la instalación se colgó, pero aún así el registro decía que había terminado, el front-end se colgaría para siempre. Pero la instalación se realizó.

Estoy enfrentando el mismo problema en Magento 2.1.2.

Tenemos el mismo problema Magento 2.1.2

Tengo el mismo problema con Magento 2.1.2.

Condiciones previas

1. Magento CE 2.1.2 sin datos de muestra instalados.
2. Métodos de envío de USPS y FedEx configurados.
3. Método de pago de PayPal Payments Pro configurado.
4. Productos y categorías importados de un carrito de compras anterior.
5. Establezca mode en production .

Pasos para reproducir

1. Navega al escaparate como invitado.
2. Abra una categoría importada.
3. Haga clic en "Agregar al carrito" en un producto importado.
4. Abra el mini carrito de la compra y haga clic en "Ir a pago".
5. Complete los pasos de dirección y envío del pago.
6. Seleccione "Tarjeta de crédito" para una opción de pago.
7. Ingrese los detalles de la tarjeta de crédito y haga clic en "Realizar pedido".

Resultados reales y esperados

Resultados previstos

Para ser enviado a una página de confirmación de pedido y que el pedido aparezca en 'Ventas-> Pedidos'.

Resultados actuales

Recibo un error que dice: "Se produjo un error en el servidor. Intente realizar el pedido nuevamente". con un rastro:

#0 [internal function]: Magento\Checkout\Model\GuestPaymentInformationManagement->savePaymentInformationAndPlaceOrder('****', '****', Object(Magento\Quote\Model\Quote\Payment), Object(Magento\Quote\Model\Quote\Address))
#1 ****/vendor/magento/module-webapi/Controller/Rest.php(307): call_user_func_array(Array, Array)
#2 ****/vendor/magento/module-webapi/Controller/Rest.php(216): Magento\Webapi\Controller\Rest->processApiRequest()
#3 ****/var/generation/Magento/Webapi/Controller/Rest/Interceptor.php(37): Magento\Webapi\Controller\Rest->dispatch(Object(Magento\Framework\App\Request\Http))
#4 ****/vendor/magento/framework/App/Http.php(135): Magento\Webapi\Controller\Rest\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#5 ****/vendor/magento/framework/App/Bootstrap.php(258): Magento\Framework\App\Http->launch()
#6 ****/index.php(39): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))
#7 {main}

Información Adicional

También veo HTTP 400 Bad Request errores en ****/rest/default/V1/guest-carts/****/payment-information

Me estoy encontrando con este problema exacto en magento 2.1.2

Usando el método de publicación directa de authorize.net.

Intenté cambiar la línea de dirección a 1 y comenzó a funcionar ... no estoy seguro de cuántos clientes tenían direcciones de 2 líneas ... ¿alguien encontró una solución para esto?

¿Quizás alguien pueda encontrar una consulta SQL que pueda concatenar direcciones en la base de datos que usaban 2 líneas?

Realmente no sé cómo avanzar desde esto ... tal vez deshacerse de magento e ir con shopify, foxy.io, demonios, incluso woocommerce sería un paso adelante en este punto con todos los problemas que tiene magento2 ...

Si alguien tiene alguna idea sobre cómo solucionar esto, ¡soy todo oídos!

¡Gracias!

Intenté la misma solución en nuestro servidor de ensayo cambiando las líneas de dirección a 1, pero esto no lo solucionó en el ensayo ...

La puesta en escena está en modo de producción y local en desarrollo ... ¿tal vez eso tiene algo que ver con eso?

También pensé que podría ser https vs http usando una clave de caja de arena con authorize.net, así que cambié la preparación para no forzar a https tratando de hacer una puesta en escena más en línea con mi entorno de desarrollo y lo descarté ... Voy para intentar poner el staging en modo dev e intentarlo de nuevo.

Aquí hay una captura de pantalla de las pestañas de red en el desarrollo local y la puesta en escena que muestra que funcionó en mi entorno local, pero no en la puesta en escena que está en modo de producción:

https://www.dropbox.com/s/fb17g39mo3mu9ds/Screenshot%202016-10-20%2009.50.12.png?dl=0

Mismo problema que enfrenta en Magento 2.1.2. alguna solución ?

Lo mismo para mí: de alguna manera me alegro de ver que no somos nosotros, pero maldición, ¿otro error crítico? ¿Dónde termina ...

Por favor revise sus tablas sales_sequence_meta y sales_sequence_profile
Deben ser similares a estos,

sales_sequence_profile

sales_sequence_meta

Después de arreglar estas tablas, comenzó a funcionar.

Y no olvide que si ya tiene algunos pedidos, inserte un registro en la tabla sequence_order_1 arriba del número de pedidos.
Ej: si tiene 10 pedidos, inserte un registro con 11 o 12 como sequence_value

El mismo problema aquí, pensé que era mi código de pago ... ¡supongo que no! 2.1.2

Es más un problema relacionado con la base de datos, consulte las tablas mencionadas.

@nuwaus Plus, la identificación de la tienda en la que estoy revisando es 3

Aquí está mi error:

{"message":"An error occurred on the server. Please try to place the order again.","trace":"#0 \/Users
\/ccarnell\/Sites\/vax-uk2\/vendor\/magento\/framework\/Interception\/Interceptor.php(146): Magento\
\Checkout\\Model\\GuestPaymentInformationManagement->savePaymentInformationAndPlaceOrder('83aea169274f681
...', 'ccarnell@tti-fc...', Object(Magento\\Quote\\Model\\Quote\\Payment), Object(Magento\\Quote\\Model
\\Quote\\Address\\Interceptor))\n#1 \/Users\/ccarnell\/Sites\/vax-uk2\/var\/generation\/Magento\/Checkout
\/Model\/GuestPaymentInformationManagement\/Interceptor.php(26): Magento\\Checkout\\Model\\GuestPaymentInformationManagement
\\Interceptor->___callPlugins('savePaymentInfo...', Array, Array)\n#2 [internal function]: Magento\\Checkout
\\Model\\GuestPaymentInformationManagement\\Interceptor->savePaymentInformationAndPlaceOrder('83aea169274f681
...', 'ccarnell@tti-fc...', Object(Magento\\Quote\\Model\\Quote\\Payment), Object(Magento\\Quote\\Model
\\Quote\\Address\\Interceptor))\n#3 \/Users\/ccarnell\/Sites\/vax-uk2\/vendor\/magento\/module-webapi
\/Controller\/Rest.php(307): call_user_func_array(Array, Array)\n#4 \/Users\/ccarnell\/Sites\/vax-uk2
\/vendor\/magento\/module-webapi\/Controller\/Rest.php(216): Magento\\Webapi\\Controller\\Rest->processApiRequest
()\n#5 \/Users\/ccarnell\/Sites\/vax-uk2\/vendor\/magento\/framework\/Interception\/Interceptor.php(146
): Magento\\Webapi\\Controller\\Rest->dispatch(Object(Magento\\Framework\\App\\Request\\Http))\n#6 \
/Users\/ccarnell\/Sites\/vax-uk2\/var\/generation\/Magento\/Webapi\/Controller\/Rest\/Interceptor.php
(39): Magento\\Webapi\\Controller\\Rest\\Interceptor->___callPlugins('dispatch', Array, Array)\n#7 \
/Users\/ccarnell\/Sites\/vax-uk2\/vendor\/magento\/framework\/App\/Http.php(135): Magento\\Webapi\\Controller
\\Rest\\Interceptor->dispatch(Object(Magento\\Framework\\App\\Request\\Http))\n#8 \/Users\/ccarnell\
/Sites\/vax-uk2\/vendor\/magento\/framework\/App\/Bootstrap.php(258): Magento\\Framework\\App\\Http-
>launch()\n#9 \/Users\/ccarnell\/Sites\/vax-uk2\/pub\/index.php(37): Magento\\Framework\\App\\Bootstrap-
>run(Object(Magento\\Framework\\App\\Http))\n#10 {main}"}

@craigcarnell
Compruebe el AUTO_INCREMENT de su sequence_order_1 si es posible eliminar sus pedidos actuales, haga lo siguiente,

SET FOREIGN_KEY_CHECKS = 0;
TRUNCATE TABLE `gift_message`;
TRUNCATE TABLE `quote`;
TRUNCATE TABLE `quote_address`;
TRUNCATE TABLE `quote_address_item`;
TRUNCATE TABLE `quote_id_mask`;
TRUNCATE TABLE `quote_item`;
TRUNCATE TABLE `quote_item_option`;
TRUNCATE TABLE `quote_payment`;
TRUNCATE TABLE `quote_shipping_rate`;
TRUNCATE TABLE `reporting_orders`;
TRUNCATE TABLE `sales_bestsellers_aggregated_daily`;
TRUNCATE TABLE `sales_bestsellers_aggregated_monthly`;
TRUNCATE TABLE `sales_bestsellers_aggregated_yearly`;
TRUNCATE TABLE `sales_creditmemo`;
TRUNCATE TABLE `sales_creditmemo_comment`;
TRUNCATE TABLE `sales_creditmemo_grid`;
TRUNCATE TABLE `sales_creditmemo_item`;
TRUNCATE TABLE `sales_invoice`;
TRUNCATE TABLE `sales_invoiced_aggregated`;
TRUNCATE TABLE `sales_invoiced_aggregated_order`;
TRUNCATE TABLE `sales_invoice_comment`;
TRUNCATE TABLE `sales_invoice_grid`;
TRUNCATE TABLE `sales_invoice_item`;
TRUNCATE TABLE `sales_order`;
TRUNCATE TABLE `sales_order_address`;
TRUNCATE TABLE `sales_order_aggregated_created`;
TRUNCATE TABLE `sales_order_aggregated_updated`;
TRUNCATE TABLE `sales_order_grid`;
TRUNCATE TABLE `sales_order_item`;
TRUNCATE TABLE `sales_order_payment`;
TRUNCATE TABLE `sales_order_status_history`;
TRUNCATE TABLE `sales_order_tax`;
TRUNCATE TABLE `sales_order_tax_item`;
TRUNCATE TABLE `sales_payment_transaction`;
TRUNCATE TABLE `sales_refunded_aggregated`;
TRUNCATE TABLE `sales_refunded_aggregated_order`;
TRUNCATE TABLE `sales_shipment`;
TRUNCATE TABLE `sales_shipment_comment`;
TRUNCATE TABLE `sales_shipment_grid`;
TRUNCATE TABLE `sales_shipment_item`;
TRUNCATE TABLE `sales_shipment_track`;
TRUNCATE TABLE `sales_shipping_aggregated`;
TRUNCATE TABLE `sales_shipping_aggregated_order`;
TRUNCATE TABLE `tax_order_aggregated_created`;
TRUNCATE TABLE `tax_order_aggregated_updated`;

ALTER TABLE `gift_message` AUTO_INCREMENT=1; 
ALTER TABLE `quote` AUTO_INCREMENT=1; 
ALTER TABLE `quote_address` AUTO_INCREMENT=1; 
ALTER TABLE `quote_address_item` AUTO_INCREMENT=1; 
ALTER TABLE `quote_id_mask` AUTO_INCREMENT=1; 
ALTER TABLE `quote_item` AUTO_INCREMENT=1; 
ALTER TABLE `quote_item_option` AUTO_INCREMENT=1; 
ALTER TABLE `quote_payment` AUTO_INCREMENT=1; 
ALTER TABLE `quote_shipping_rate` AUTO_INCREMENT=1; 
ALTER TABLE `reporting_orders` AUTO_INCREMENT=1; 
ALTER TABLE `sales_bestsellers_aggregated_daily` AUTO_INCREMENT=1; 
ALTER TABLE `sales_bestsellers_aggregated_monthly` AUTO_INCREMENT=1; 
ALTER TABLE `sales_bestsellers_aggregated_yearly` AUTO_INCREMENT=1; 
ALTER TABLE `sales_creditmemo` AUTO_INCREMENT=1; 
ALTER TABLE `sales_creditmemo_comment` AUTO_INCREMENT=1; 
ALTER TABLE `sales_creditmemo_grid` AUTO_INCREMENT=1; 
ALTER TABLE `sales_creditmemo_item` AUTO_INCREMENT=1; 
ALTER TABLE `sales_invoice` AUTO_INCREMENT=1; 
ALTER TABLE `sales_invoiced_aggregated` AUTO_INCREMENT=1; 
ALTER TABLE `sales_invoiced_aggregated_order` AUTO_INCREMENT=1; 
ALTER TABLE `sales_invoice_comment` AUTO_INCREMENT=1; 
ALTER TABLE `sales_invoice_grid` AUTO_INCREMENT=1; 
ALTER TABLE `sales_invoice_item` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_address` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_aggregated_created` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_aggregated_updated` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_grid` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_item` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_payment` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_status_history` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_tax` AUTO_INCREMENT=1; 
ALTER TABLE `sales_order_tax_item` AUTO_INCREMENT=1; 
ALTER TABLE `sales_payment_transaction` AUTO_INCREMENT=1; 
ALTER TABLE `sales_refunded_aggregated` AUTO_INCREMENT=1; 
ALTER TABLE `sales_refunded_aggregated_order` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipment` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipment_comment` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipment_grid` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipment_item` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipment_track` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipping_aggregated` AUTO_INCREMENT=1; 
ALTER TABLE `sales_shipping_aggregated_order` AUTO_INCREMENT=1; 
ALTER TABLE `tax_order_aggregated_created` AUTO_INCREMENT=1; 
ALTER TABLE `tax_order_aggregated_updated` AUTO_INCREMENT=1; 
SET FOREIGN_KEY_CHECKS = 1;

Hacer esto funcionó para mí, asegúrese de deshabilitar cualquier extensión de terceros que afecte el proceso de pedido, como módulos para puntos de recompensa, etc.

Y asegúrese de hacer una copia de seguridad de su base de datos como está antes de truncar.

@nuwaus intentó truncar mis tablas, aumentar la secuencia, no funcionó para mí, me temo :( Tendré que intentar deshabilitar módulos.

@craigcarnell

Intente realizar un pedido, luego, después de recibir el mensaje de error, vaya a la tabla sales_order y vea si ha insertado un nuevo registro. Si eso sucede, puede reducir el problema.

A veces, se realizan pedidos, pero alguna otra transacción de base de datos después de eso puede causar el problema porque también me sucedió a mí después de que se realizó el pedido. Recibí un error cuando intentaba agregar registros a la tabla de puntos de recompensas, era un módulo de terceros, por lo que Tuve que truncar esa tabla también.

Finalmente solucioné esto rastreando el problema hasta los certificados utilizados por el proveedor de pago. Recreé nuevos certificados y reemplacé los antiguos, y luego vi que la clave en la aplicación / etc / env.php se cambió _después_ de la instalación. Lo cambié de nuevo a lo que era antes y el error se resolvió.

Configuré una instalación limpia de CE 2.1.2 continuar el desarrollo. No tuve este problema con él, excepto que ahora sí. Intenté configurar la dirección en 1

{"message":"An error occurred on the server. Please try to place the order again.","trace":"#0 [internal
 function]: Magento\\Checkout\\Model\\GuestPaymentInformationManagement->savePaymentInformationAndPlaceOrder
('0208c70f22bf5c8...', 'ccarnell@tti-fc...', Object(Magento\\Quote\\Model\\Quote\\Payment), NULL)\n#1
 \/Users\/ccarnell\/Sites\/codesocial-uk2\/vendor\/magento\/module-webapi\/Controller\/Rest.php(307)
: call_user_func_array(Array, Array)\n#2 \/Users\/ccarnell\/Sites\/codesocial-uk2\/vendor\/magento\/module-webapi
\/Controller\/Rest.php(216): Magento\\Webapi\\Controller\\Rest->processApiRequest()\n#3 \/Users\/ccarnell
\/Sites\/codesocial-uk2\/var\/generation\/Magento\/Webapi\/Controller\/Rest\/Interceptor.php(37): Magento
\\Webapi\\Controller\\Rest->dispatch(Object(Magento\\Framework\\App\\Request\\Http))\n#4 \/Users\/ccarnell
\/Sites\/codesocial-uk2\/vendor\/magento\/framework\/App\/Http.php(135): Magento\\Webapi\\Controller
\\Rest\\Interceptor->dispatch(Object(Magento\\Framework\\App\\Request\\Http))\n#5 \/Users\/ccarnell\
/Sites\/codesocial-uk2\/vendor\/magento\/framework\/App\/Bootstrap.php(258): Magento\\Framework\\App
\\Http->launch()\n#6 \/Users\/ccarnell\/Sites\/codesocial-uk2\/pub\/index.php(37): Magento\\Framework
\\App\\Bootstrap->run(Object(Magento\\Framework\\App\\Http))\n#7 {main}"}

Puedo confirmar este error en Magento 2.1.2.

Siguiendo lo que dijo @kociiide , configuré las direcciones de los clientes para que solo tuvieran 1 línea. Después de esto, los NUEVOS clientes pueden realizar pedidos, pero los existentes no.

Buscando una solución ...

¿Alguna actualización aquí? Tengo el mismo problema.

Tengo el mismo problema e intento encontrar una solución desde hace varios días. Mi cliente no se divierte y yo también. Esto debe resolverse pronto. ¿Cuándo esperar la versión 2.1.3 ??? ¿Con todos arreglos?

En mi sistema Magento2.1.2 obtengo el mismo error al realizar un pedido:

400 (Bad Request)" at
http://example.com/rest/default/V1/guest-carts/36b703a23e05b25a08da0e8ba5ab031f/payment-information

No se coloca nada en sales_order. También las tablas mencionadas anteriormente son las mismas para mí.
Estas son las tablas que tengo en mi base de datos. ¿Me faltan algunas mesas?

No sé si es importante, pero migré datos de 1.9 a Magento 2 (con el módulo ubertheme) solo productos y la categoría. ¿Podría haber causado que falten algunas tablas? ¿Cómo solucionar eso? ¡O cualquier otra solución que resuelva esto!

Hola todos,

Espero encontrar una solución urgente para esto,

Tengo el mismo problema en magento 2.1.2, intenté todas las soluciones posibles descritas en muchos problemas, pero sin éxito.

Ídem. El mismo problema con 2.1.1 Recibo el mismo mensaje de error que se muestra arriba al realizar un pedido usando Authorize.net. El pago se procesa a través de Authorize.net (prueba en el sitio de prueba). Cambió la dirección a 1 línea y aún no funcionó.

Todavía no encontré una solución. Probé todas las cosas que rojo aquí.
Mirando de nuevo en la base d como lo mencionó anteriormente @nuwaus, me pregunté sobre el ID de la tienda.
¿Debería haber una tercera parte en sales_sequence_meta para la tienda con id = 2?

¿O me equivoqué con la configuración de mi tienda? Tengo esto ahora:

y he configurado una tienda en algún lugar de la configuración (no pude encontrar dónde) :)

Tengo el mismo problema con checkmo y transferencia bancaria.

• Magento 2.1.2
• Tienda en francés
• Dirección sin región en Francia
• Calle (2 líneas)

Puedo forzar la validación del pago.

Mismo problema con Cheque / Giro Postal (solo método de pago)
Magento 2.1.1
PHP 7.0.13
MySql 5.6.34
Tiendas: alemán, italiano, inglés
Calle: 1 Línea

El pedido se genera correctamente, se envía el correo electrónico de confirmación del pedido. Pero el cliente no es redirigido a la página de éxito. En su lugar, aparece el error (solo por unos segundos)
Ocurrió un error en el servidor.

, el carrito está vacío y el cliente todavía está en la página de pago. Por supuesto, el cliente no puede volver a realizar el pedido y está confundido.

common @ magento-admin Esto no puede ser cierto, su sistema no admite recibir pagos en este momento. Esto debería haberse solucionado justo cuando apareció el error.

@veloraven ¿ Cuándo esperar una solución sobre este tema "crucial"? Muchos están luchando con este problema. Si no se encuentra una solución, el sistema no se puede utilizar para administrar una tienda comercial. Profundice en esto y encuentre una solución o una actualización de Magento2.1.3 rápidamente.

De hecho, incluso me pregunto si deberíamos continuar con Magento 2. Sabemos que hay muchos errores allí, pero tener un error como este desde el 8 de octubre simplemente no es aceptable. Incluso para una aplicación de código abierto.

¡¡Todavía esperando una solución !! ¿Algún resultado con estos chicos? ¿¡¡¡Uno de ustedes, desarrolladores de Magento, está dispuesto a profundizar en esto y brindarnos una solución ahora !!!?
¡Esto no está bien! 👎

Comente el receptor de excepciones en vendor / magento / module-checkout / Model / PaymentInformationManagement.php

Luego, inténtelo de nuevo, verá un error en sus registros en el modo de producción.

Para mí, era una extensión que usaba un complemento que llamaba a una variable indefinida.

Comenta el TRY {} {catch} pero no el
$ orderId = $ this-> cartManagement-> placeOrder ($ cartId);

¡Esto expondrá el error subyacente a una camiseta!

//tratar {
$ orderId = $ this-> cartManagement-> placeOrder ($ cartId);
/ *} catch (\ Exception $ e) {
lanzar una nueva excepción CouldNotSaveException (
__ ('CNSE1: Se produjo un error en el servidor. Intente realizar el pedido nuevamente.'. ''. $ CartId. $ Sam. ''. $ OrderId),
$ e
);
}
* /

@s southerncomputer Gracias por la respuesta. Lo probé con el código comentado y devolvió un error interno del servidor 500.

{"message": "SQLSTATE [42000]: Error de sintaxis o infracción de acceso: 1103 Nombre de tabla incorrecto '',
: INSERTAR EN "() VALORES ()",

Vea el error completo aquí: http://pastebin.com/YYxTvGis

¿Existe otro archivo / lugar donde buscar información sobre el error?

Magento \ SalesSequence \ Model \ Sequence-> getNextValue () está fallando.

¿Está utilizando la función EE de bases de datos divididas? en vendor / magento / module-sales-sequence / Model / Sequence.php debería poder acceder a las tablas sales_sequence:

ver aquí: https://github.com/magento/magento2/issues/3066

seleccione * de sales_sequence_meta;

+ --------- + ------------- + ---------- + -------------- --------- +
| meta_id | tipo_entidad | store_id | secuencia_tabla |
+ --------- + ------------- + ---------- + -------------- --------- +
| 1 | orden | 0 | secuencia_orden_0 |
| 2 | factura | 0 | sequence_invoice_0 |
| 3 | creditmemo | 0 | sequence_creditmemo_0 |
| 4 | envío | 0 | sequence_shipment_0 |
| 5 | rma_item | 0 | sequence_rma_item_0 |
| 6 | orden | 1 | sequence_order_1 |
| 7 | factura | 1 | sequence_invoice_1 |
| 8 | creditmemo | 1 | sequence_creditmemo_1 |
| 9 | envío | 1 | sequence_shipment_1 |
| 10 | rma_item | 1 | sequence_rma_item_1 |
| 11 | cita | 0 | sequence_quote_0 |
| 12 | cita | 1 | sequence_quote_1 |
+ --------- + ------------- + ---------- + -------------- --------- +
12 filas en conjunto (0.01 seg)

mysql> seleccionar * de sales_sequence_profile;
+ ------------ + --------- + -------- + -------- + -------- ----- + ------ + ------------ + --------------- + -------- --- +
| profile_id | meta_id | prefijo | sufijo | start_value | paso | max_value | warning_value | is_active |
+ ------------ + --------- + -------- + -------- + -------- ----- + ------ + ------------ + --------------- + -------- --- +
| 1 | 1 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 2 | 2 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 3 | 3 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 4 | 4 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 5 | 5 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 6 | 6 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 7 | 7 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 8 | 8 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 9 | 9 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 10 | 10 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 11 | 11 | Q15. | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 12 | 12 | Q15. | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
+ ------------ + --------- + -------- + -------- + -------- ----- + ------ + ------------ + --------------- + -------- --- +
12 filas en conjunto (0,00 seg)

¡Para cada tienda debe haber un conjunto de tablas y perfiles! ignore las líneas de cotización, ¡son personalizadas para mí!

@dreucifer gracias por los pasos.
Probé 2.1.2 en modo de producción siguiendo los pasos que describiste y realicé el pedido dos veces:
1) envío FedEx con pago con tarjeta de crédito
2) Envío de USPS con pago con tarjeta de crédito

Productos y categorías importados de un carrito de compras anterior.

¿Podría aclarar lo que quiere decir aquí?

Tratemos de entender lo que estamos haciendo de otra manera. ¿Usó otros cambios de configuración?

@craigcarnell, ¿ podría indicar los pasos para reproducir ese error?

@sjovanig necesitamos pasos para reproducir para solucionarlo. ¿Lo reproduce en la instalación limpia de Magento? ¿Qué son los cambios de configuración? ¿Qué métodos de pago y envío utilizas?

@SerhiyShkolyarenko como se mencionó anteriormente, mi ID de tienda = 2, pero lo extraño es que solo tengo 1 tienda. Entonces, ¿por qué mi store_id = 2? ¿Puedo cambiar la identificación de la tienda a 1 de alguna manera? ¿O sería mejor agregar algunas filas a sales_sequence_meta y sales_sequence_profile?

| 11 | order | 2 | sequence_order_2 |
| 12 | invoice | 2 | sequence_invoice_2|
| 13 | creditmemo | 2 | sequence_creditmemo_2 |
| 14 | shipment | 2 | sequence_shipment_2 |
| 15 | rma_item | 2 | sequence_rma_item_2 |

Pero, ¿sería eso para sales_sequence_profile que?
Me gusta esto ? :
11 | 11 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |

2 todos los que informaron de error 400 en la solicitud de API. Aclaremos cómo reproducirse. Agregué el producto al carrito en la interfaz, luego configuré la dirección de envío y el método de envío en la interfaz, luego envié la solicitud a
guest-carts/f21a5febd9e9acf68cdb03bccc8caa99/payment-information con carga útil

{
  "email": "[email protected]",
  "paymentMethod": {
    "po_number": "string",
    "method": "checkmo",
    "additional_data": [
      "string"
    ],
    "extension_attributes": {
      "agreement_ids": []
    }
  },
  "billingAddress": {
    "region_code": "CA",
    "country_id": "US",
    "street": [
      "string"
    ],
    "company": "string",
    "telephone": "string",
    "postcode": "90323",
    "city": "string",
    "firstname": "string",
    "lastname": "string",
    "middlename": "string",
    "prefix": "string",
    "suffix": "string",
    "email": "[email protected]",
    "same_as_billing": 0,
    "extension_attributes": {}
  }
}

y el pedido se realizó correctamente. ¿Qué carga útil debo utilizar para reproducir el problema?

| 11 | orden | 2 | secuencia_orden_2 |
| 12 | factura | 2 | sequence_invoice_2 |
| 13 | creditmemo | 2 | sequence_creditmemo_2 |
| 14 | envío | 2 | sequence_shipment_2 |
| 15 | rma_item | 2 | sequence_rma_item_2 |
^^^^^^^^^^^ SÍ ^^^^^^^^^^^^^^
Pero, ¿sería eso para sales_sequence_profile que?
Me gusta esto ? : [[[[[[¡SI!]]]]]]]]]]]]
11 | 11 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |

¡necesitaría crear las tablas tan bien como lo hizo arriba!

Obteniendo algo de progreso ahora, pero terminó con un nuevo error:

{"message":"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '000000000-2' for key
 'SALES_ORDER_INCREMENT_ID_STORE_ID', query was: INSERT INTO `sales_order` 

Cuando miro en sales_order store_id dice: 2?
Entonces, ¿por qué este error?

Además de @SerhiyShkolyarenko , también agregué un nuevo registro para:

sequence_creditmemo_2, sequence_invoice_2, sequence_order_2, sequence_shipment_2

¿Podría ser esa la razón de este error?

Cuando borro el registro sales_order, puedo realizar un pedido y parece funcionar. Luego de realizar un nuevo pedido, vuelvo a recibir el error:

:"SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '000000000-2' for key
 'SALES_ORDER_INCREMENT_ID_STORE_ID', query was: INSERT INTO `sales_order` 

Así es como se ve el nuevo número de pedido creado:

En la tabla sequence_order_2, ¿todos los valores son 0? ¿Eso esta bien?

@jvreeken miré la captura de pantalla

https://www.dropbox.com/s/fb17g39mo3mu9ds/Screenshot%202016-10-20%2009.50.12.png?dl=0

y vi un tema personalizado allí y un código de método de pago md_authorizecim que no es parte de Magento CE. ¿Se puede reproducir el problema en una instancia

¿Podría ser este el problema?:

Entonces, ¿también necesito crear una entidad para el ID de tienda = 2 aquí para deshacerme del "error de entrada duplicada?

¿Alguna idea de cómo solucionar este problema? ¡Me estoy perdiendo un poco ahora! Tengo la sensación de que estoy cerca pero no sé cómo llegar :)

@hocomadvies describe sequence_order_1;
+ ---------------- + ------------------ + ------ + ----- + --------- + ---------------- +
| Campo | Tipo | Nulo | Clave | Por defecto | Extra |
+ ---------------- + ------------------ + ------ + ----- + --------- + ---------------- +
| valor_secuencia | int (10) unsigned | NO | PRI | NULL | auto_increment |
+ ---------------- + ------------------ + ------ + ----- + --------- + ---------------- +
1 fila en conjunto (0,00 seg)

¿Así es como creaste sequence_order_2? ¿Qué ves en sequence_order_0, 1 y 2?

Ok, eso puede ayudar :) mi sequence_order_2 no tiene auto_increment agregado.

Ahora lo agregué así:

CREATE TABLE IF NOT EXISTS `sequence_order_2` (
  `sequence_value` int(10) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Así que también agregué esto para las otras tablas:
secuencia_factura_2
secuencia_envío_2
secuencia_crédito_2

Y ahora todo parece funcionar.

@schasiepen , ¿tiene algún registro de excepción en var/log o var/report ?

@SerhiyShkolyarenko : Al principio no hay errores en los archivos de registro ni informes. Pero cuando elimino el comentario try / catch en la función de PaymentInformationManagement savePaymentInformationAndPlaceOrder (), aparece este mensaje de error:
ID del informe: webapi-5840685d21343; Mensaje: No existe tal entidad con orderId = 2
secuencia_orden_1 tiene 231 entradas El incremento automático es 232.

Lo curioso es que se generan todos los pedidos, se envían correos electrónicos.
Me di cuenta:
la tabla eav_entity_store está vacía,
las tablas secuencia_orden_0, secuencia_orden_2 y secuencia_orden_3 (agregué _2 y _3) están vacías. Tenemos 3 visitas a la tienda (1: alemán, 2: italiano, 3: inglés).
Dado que "Compartir cuentas de cliente" está configurado como "Global", y todos los clientes se crean en la tienda 1, ¿supongo que es correcto que solo se use sequence_order_1?

Cualquier ayuda / sugerencia es muy, muy bienvenida.

¿Alguna actualización sobre este tema? ¿Alguien sabe qué consulta SQL sería responsable del error?
"webapi-5840685d21343; Mensaje: ¿No existe tal entidad con orderId = 2"?
Tengo que admitir: ¡estoy completamente perdido!

@schasiepen ¿tiene las otras tablas de secuencia para facturas / envíos / créditos? y meta tablas (consulte mi publicación superior para obtener una lista de tablas) sales_sequence_profile && sales_sequence_meta junto con las tablas para sequence_invoice / shipping / creditmemo?

¿Alguna actualización sobre este Magento ???

Me faltaban las mesas de la tienda 3.

Tengo el mismo problema. Estoy usando PayPal Payments Pro / Payflow y las tarjetas de crédito están autorizadas en lugar de completar una venta. Espero encontrar una solución a esto. Estaba emocionado por la nueva versión de Magento, pero tengo muchos problemas con ella.

Tengo la versión 2.1.1 y había intentado configurar la dirección en solo 1 campo y eso tampoco ayudó.

@hubaig @craigcarnell @schasiepen Podría ayudarlos a encontrar una solución investigando sus tablas de base de datos y eche un vistazo si son similares a las mencionadas en los temas anteriores. Parece que de alguna manera se trata de tablas faltantes en la base de datos. Asegúrese de hacer una copia de seguridad de su base de datos antes de cambiar cualquier cosa :) La mejor manera de acceder a la base de datos en este caso es a través de phpMyadmin.
Me encontré con más o menos los mismos problemas y me ayudó a que funcionara nuevamente.

Muchas gracias a todos aquí. Es bastante molesto que Magento no registre esos errores. La forma de evitarlo que encontré fue sobrescribir la clase CouldNotSaveException.

En su módulo personalizado di.xml (p. Ej.//etc/di.xml) agregue la línea a continuación:

<preference for="Magento\Framework\Exception\CouldNotSaveException" type="<NAMESPACE>\<PACKAGE>\Exception\CouldNotSaveException" />

Luego crea el archivo y agrega el contenido a continuación:

<?php

namespace <NAMESPACE>\<PACKAGE>\Exception;

use Magento\Framework\Phrase;
use Magento\Framework\Exception\AbstractAggregateException;

class CouldNotSaveException extends AbstractAggregateException
{
    /**
     * CouldNotSaveException constructor.
     * <strong i="12">@param</strong> Phrase $phrase
     * <strong i="13">@param</strong> \Exception|null $cause
     */
    public function __construct(Phrase $phrase, \Exception $cause = null)
    {
        $this->originalPhrase = $phrase;
        parent::__construct($phrase, $cause);

        $objectManager = \Magento\Framework\App\ObjectManager::getInstance();
        $logger = $objectManager->create('\Psr\Log\LoggerInterface');
        $logger->debug($cause->getMessage());
    }
}

Entonces otra vez. No es la solución final, pero ayúdanos a rastrear los errores cuando ocurren.

Salud,

Renato.

@hocomadvies Revisé las dos tablas y se ven bien. Migré de Magento 1.9 a 2.1, ¿podría ser una causa de esto? También tengo instalado m2epro y no estoy seguro de si eso está causando algún problema. Veo que los elementos de Incremento automático están ahí. No puedo modificar ninguna tabla ahora porque los clientes ya han realizado pedidos utilizando Paypal Express Checkout.

@hubaig en mi caso, el problema era que la identificación de la tienda no coincidía con las tablas de la base de datos. Después de agregarlos (ver arriba), funciona para mí. Por lo tanto, debe profundizar en los mensajes de error y averiguar dónde se produce el problema. Actualicé de 1.9 a 2.1 y creo que eso causó los problemas que tuve.
Mire si se agregan los nuevos pedidos, mire qué ID de tienda está usando y vea si está en estas tablas:
sequence_creditmemo_, sequence_invoice_, sequence_order_, sequence_shipment_ si no es así, debe agregarlos a la base de datos (por lo tanto, sequence_order_0, sequence_order_2, sequence_order_3, etc. para la identificación de la tienda que necesita.

@hocomadvies la tienda que estoy usando, su identificación es 1 y veo que todas las tablas están ahí, el incremento automático está bien configurado. Noté una cosa. Tengo otra tienda allí con un id 2 pero las tablas no existen para ello. Esta tienda no atiende tráfico en el front-end, pero la tengo conectada a Amazon y eBay con m2epro. Solo la tienda con id 1 está intentando utilizar el flujo de PayPal. No estoy seguro si ese es el problema. Puedo intentar agregar tablas para la tienda 2 y volver a intentarlo.

Agregar estas tres tablas para la identificación de la tienda 2 no ayudó. Aún recibo errores rechazados. Veo que los usuarios han agregado formas de ver las excepciones. ¿Hay alguna manera de que alguien pueda dar información detallada sobre cómo depurar esto? Soy bastante nuevo en magento 2 y tengo problemas para obtener las excepciones para intentar solucionar este problema. Estoy alojando esto en CentOS 6 con cPanel.

Todavía tengo el problema en mi entorno de ensayo con v2.1.3 ... funciona bien en mi local ... no lo entiendo ...

Yo tuve el mismo problema. Tan pronto como comenté el bloque try / catch mencionado por @southerncomputer (https://github.com/magento/magento2/issues/6929#issuecomment-263965185), el mensaje de error se volvió más preciso: "No se pudo iniciar la transacción porque hay varias líneas de pedido con el mismo SKU ". Tiene algo que ver con el módulo de pago Saferpay en mi caso.

Nos encontramos con el mismo problema que @southerncomputer con una tienda de demostración nuestra. En nuestro caso, faltaban las tablas de secuencia para el ID de tienda 2, por lo que las agregamos ejecutando estas declaraciones SQL en nuestra base de datos y ahora podemos continuar con el proceso de pago:

INSERT INTO `sales_sequence_meta`
       (`entity_type`, `store_id`, `sequence_table`)
VALUES ('order', 2, 'sequence_order_2'),
       ('invoice', 2, 'sequence_invoice_2'),
       ('creditmemo', 2, 'sequence_creditmemo_2'),
       ('shipment', 2, 'sequence_shipment_2');

CREATE TABLE `sequence_order_2` (
  `sequence_value` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`sequence_value`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `sequence_invoice_2` (
  `sequence_value` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`sequence_value`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `sequence_creditmemo_2` (
  `sequence_value` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`sequence_value`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `sequence_shipment_2` (
  `sequence_value` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`sequence_value`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Las personas de debería poder capturar las excepciones generadas por los métodos de pago subyacentes y mostrar el error correcto en el front-end. Por el momento, cualquier solicitud a la API web simplemente se devuelve al cliente como un mensaje de error 500 genérico.

Además, Magento no proporciona ninguna forma de que el método de pago establezca correctamente el error cuando se realiza la solicitud de API. En otros métodos, como assignData (), lanzar una excepción funciona, sin embargo, en las solicitudes Authorize () y capture (), la API web no detecta las excepciones lanzadas.

@snez : https://github.com/magento/magento2/issues/6246

Tener el mismo error en el check out.

2.1.1, servidor de desarrollo, paypal pro, migración desde 1.9

no se colocan pedidos en la base de datos ...

Parece que el ID de la tienda es 1 basado en admin> store> todas las tiendas, y cuando pasas el cursor sobre el enlace, veo un "1", así que supongo que el ID de la tienda es 1

Ver adjunto, ¿importa si mi orden de meta_id no está alineado con las otras tablas ?, parece que en los ejemplos anteriores, las tablas se ordenaron en el orden correcto, ya que las mías son cualquier otra ID de tienda de 0 a 1

Realmente lamento mi ignorancia, pero estoy recibiendo el mismo problema aquí. Soy tan nuevo en esto que ni siquiera sé cómo están revisando la base de datos. ¿Qué programa está utilizando para verificar las columnas de la base de datos? Mi servidor está en Ubuntu y soy muy nuevo en Linux.

@mattlaltman bueno, podría instalar phpmyadmin en el servidor y echar un vistazo a las tablas allí. Pero antes de hacer eso, primero haga una copia de su base de datos :)

@muhupower Hola, si estoy en lo cierto, la secuencia es la clave para mirar aquí. Si observa sales_sequence_profile, puede ver que pasa por el proceso de pedido paso a paso. comenzando por 1. Por lo tanto, su tabla debe tener el mismo aspecto que algunos de los ejemplos anteriores.

Gracias hocomadvies, intenté editar la tabla para que se vea similar a la anterior.

pero recibo un error

Sigo sin poder resolver el problema. Creé todas las tablas faltantes, verifiqué las tablas sales_sequence_meta y -profile y agregué entradas faltantes. No es bueno.
Sería de gran ayuda conocer las consultas SQL detrás de la colocación del pedido. ¿Hay alguna forma de atraparlos a todos?
¿También en nuestra instalación la tabla eav_entity_store está completamente vacía? ¿Esta mesa se usa en absoluto?

Cualquier ayuda es muy, muy bienvenida.

@muhupower ¡ Estos dos también deben coincidir!

seleccione * de sales_sequence_meta;

+ --------- + ------------- + ---------- + -------------- --------- +
| meta_id | tipo_entidad | store_id | secuencia_tabla |
+ --------- + ------------- + ---------- + -------------- --------- +
| 1 | orden | 0 | secuencia_orden_0 |
| 2 | factura | 0 | sequence_invoice_0 |
| 3 | creditmemo | 0 | sequence_creditmemo_0 |
| 4 | envío | 0 | sequence_shipment_0 |
| 5 | rma_item | 0 | sequence_rma_item_0 |
| 6 | orden | 1 | sequence_order_1 |
| 7 | factura | 1 | sequence_invoice_1 |
| 8 | creditmemo | 1 | sequence_creditmemo_1 |
| 9 | envío | 1 | sequence_shipment_1 |
| 10 | rma_item | 1 | sequence_rma_item_1 |
+ --------- + ------------- + ---------- + -------------- --------- +
10 filas en conjunto (0,00 seg)

mysql> seleccionar * de sales_sequence_profile;
+ ------------ + --------- + -------- + -------- + -------- ----- + ------ + ------------ + --------------- + -------- --- +
| profile_id | meta_id | prefijo | sufijo | start_value | paso | max_value | warning_value | is_active |
+ ------------ + --------- + -------- + -------- + -------- ----- + ------ + ------------ + --------------- + -------- --- +
| 1 | 1 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 2 | 2 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 3 | 3 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 4 | 4 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 5 | 5 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 6 | 6 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 7 | 7 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 8 | 8 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 9 | 9 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| 10 | 10 | NULL | NULL | 1 | 1 | 4294967295 | 4294966295 | 1 |
| + ------------ + --------- + -------- + -------- + ------- ------ + ------ + ------------ + --------------- + ------- ---- +

eav_entity_store es antiguo y algunos módulos personalizados como cart2quote lo utilizan.

Southerncomputer, pero no puedo editar el meta_id para cambiar el orden, aparece un error

mysql> SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_SCHEMA = 'xxxx' Y REFERENCED_TABLE_NAME = 'sales_sequence_meta';
+ ------------------------ + ------------- + ---------- -------------------------------------------------- + ----------------------- + ------------------------ +
| TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME | REFERENCED_TABLE_NAME | REFERENCED_COLUMN_NAME |
+ ------------------------ + ------------- + ---------- -------------------------------------------------- + ----------------------- + ------------------------ +
| sales_sequence_profile | meta_id | SALES_SEQUENCE_PROFILE_META_ID_SALES_SEQUENCE_META_META_ID | sales_sequence_meta | meta_id |
+ ------------------------ + ------------- + ---------- -------------------------------------------------- + ----------------------- + ------------------------ +

¿Ves cómo hay una orden para cambiar estas dos tablas?

Ya veo, pero no tengo ni idea de cómo hacerlo jajaja ... ¿pueden ayudarme? no hay función de PM en gitub .. owen en messtudios punto com es mi correo electrónico

¿Cómo se ven ahora su sales_sequence_profile y _meta? tienes que agregar las filas a sales_sequence_profile antes de agregarlas a sales_sequence_meta y asegurarte de que el meta_id coincida entre ellas

intente eliminar * de sales_sequence_profile: cambie el orden de su sales_sequence_meta para que coincida con todos los demás y luego reconstruya sales_sequence_meta con los mismos valores. ¡No estoy seguro si el pedido es tan importante!

mysql> seleccionar * de la tienda;
+ ---------- + --------- + ------------ + ---------- + ---- --------------- + ------------ + ----------- +
| store_id | codigo | website_id | group_id | nombre | sort_order | is_active |
+ ---------- + --------- + ------------ + ---------- + ---- --------------- + ------------ + ----------- +
| 0 | admin | 0 | 0 | Admin | 0 | 1 |
| 1 | por defecto | 1 | 1 | Sitio de tienda predeterminado | 0 | 1 |
+ ---------- + --------- + ------------ + ---------- + ---- --------------- + ------------ + ----------- +
2 filas en conjunto (0,00 seg)

tienes solo 2 tiendas verdad?

no, solo hay 1 tienda, migramos de 1.9

¿Qué muestra tu selección * de la tienda?

mysql> describe secuencia_orden_1;
+ ---------------- + ------------------ + ------ + ----- + --------- + ---------------- +
| Campo | Tipo | Nulo | Clave | Por defecto | Extra |
+ ---------------- + ------------------ + ------ + ----- + --------- + ---------------- +
| valor_secuencia | int (10) unsigned | NO | PRI | NULL | auto_increment |
+ ---------------- + ------------------ + ------ + ----- + --------- + ---------------- +
1 fila en conjunto (0,00 seg)

mysql>
mostrar índice de secuencia_orden_1;
+ ------------------ + ------------ + ---------- + ------ -------- + ---------------- + ----------- + ------------ - + ---------- + -------- + ------ + ------------ + -------- - + --------------- +
| Tabla | Non_unique | Key_name | Seq_in_index | Column_name | Colación | Cardinalidad | Sub_part | Empacado | Nulo | Index_type | Comentar | Index_comment |
+ ------------------ + ------------ + ---------- + ------ -------- + ---------------- + ----------- + ------------ - + ---------- + -------- + ------ + ------------ + -------- - + --------------- +
| sequence_order_1 | 0 | PRIMARIO | 1 | valor_secuencia | A | 426 | NULL | NULL | | BTREE | | |
+ ------------------ + ------------ + ---------- + ------ -------- + ---------------- + ----------- + ------------ - + ---------- + -------- + ------ + ------------ + -------- - + --------------- +

cuando hiciste sequence_order_1, ¿lo configuraste exactamente como se describe arriba? ¡No parece que este sea tu problema!

Nunca lo configuré, esto ya estaba en el sistema una vez que lo migramos. Entonces, ¿lo que tengo es correcto entonces?

también tus claves para meta / perfil:
mysql> muestra el índice de sales_sequence_profile;
+ ------------------------ + ------------ + ----------- ----------------------------------- + -------------- + ------------- + ----------- + ------------- + --------- - + -------- + ------ + ------------ + --------- + --------- ------ +
| Tabla | Non_unique | Key_name | Seq_in_index | Column_name | Colación | Cardinalidad | Sub_part | Empacado | Nulo | Index_type | Comentar | Index_comment |
+ ------------------------ + ------------ + ----------- ----------------------------------- + -------------- + ------------- + ----------- + ------------- + --------- - + -------- + ------ + ------------ + --------- + --------- ------ +
| sales_sequence_profile | 0 | PRIMARIO | 1 | profile_id | A | 10 | NULL | NULL | | BTREE | | |
| sales_sequence_profile | 0 | SALES_SEQUENCE_PROFILE_META_ID_PREFIX_SUFFIX | 1 | meta_id | A | 10 | NULL | NULL | | BTREE | | |
| sales_sequence_profile | 0 | SALES_SEQUENCE_PROFILE_META_ID_PREFIX_SUFFIX | 2 | prefijo | A | 10 | NULL | NULL | SI | BTREE | | |
| sales_sequence_profile | 0 | SALES_SEQUENCE_PROFILE_META_ID_PREFIX_SUFFIX | 3 | sufijo | A | 10 | NULL | NULL | SI | BTREE | | |
+ ------------------------ + ------------ + ----------- ----------------------------------- + -------------- + ------------- + ----------- + ------------- + --------- - + -------- + ------ + ------------ + --------- + --------- ------ +
4 filas en conjunto (0,00 seg)

mysql> muestra el índice de sales_sequence_meta;
+ --------------------- + ------------ + -------------- ---------------------------- + -------------- + ------ ------- + ----------- + ------------- + ---------- + ----- --- + ------ + ------------ + --------- + --------------- +
| Tabla | Non_unique | Key_name | Seq_in_index | Column_name | Colación | Cardinalidad | Sub_part | Empacado | Nulo | Index_type | Comentar | Index_comment |
+ --------------------- + ------------ + -------------- ---------------------------- + -------------- + ------ ------- + ----------- + ------------- + ---------- + ----- --- + ------ + ------------ + --------- + --------------- +
| sales_sequence_meta | 0 | PRIMARIO | 1 | meta_id | A | 10 | NULL | NULL | | BTREE | | |
| sales_sequence_meta | 0 | SALES_SEQUENCE_META_ENTITY_TYPE_STORE_ID | 1 | tipo_entidad | A | 10 | NULL | NULL | | BTREE | | |
| sales_sequence_meta | 0 | SALES_SEQUENCE_META_ENTITY_TYPE_STORE_ID | 2 | store_id | A | 10 | NULL | NULL | | BTREE | | |
+ --------------------- + ------------ + -------------- ---------------------------- + -------------- + ------ ------- + ----------- + ------------- + ---------- + ----- --- + ------ + ------------ + --------- + --------------- +

@muhupower Yo diría que sí. ¿Qué error obtiene cuando comenta el código que mencioné originalmente?

Comente el receptor de excepciones en vendor / magento / module-checkout / Model / PaymentInformationManagement.php

Luego, inténtelo de nuevo, verá un error en sus registros en el modo de producción.

Para mí, era una extensión que usaba un complemento que llamaba a una variable indefinida.

Comenta el TRY {} {catch} pero no el
$ orderId = $ this-> cartManagement-> placeOrder ($ cartId);

¡Esto expondrá el error subyacente a una camiseta!

// tratar {
$ orderId = $ this-> cartManagement-> placeOrder ($ cartId);
/ *} catch (\ Exception $ e) {
lanzar una nueva excepción CouldNotSaveException (
__ ('CNSE1: Se produjo un error en el servidor. Intente realizar el pedido nuevamente.'. ''. $ CartId. $ Sam. ''. $ OrderId),
$ e
);
}
* /

comente // PRUEBE y / * la excepción * / código y ejecútelo en modo de desarrollo y vea qué error está obteniendo.

No pasa nada...

Incluso cambié la salida de la última letra a dice. Por favor trate de hacer el pedido de nuevo s. con una s al final, y el error sigue apareciendo sin la s.

Es como si este no fuera el archivo correcto o algo así.

Gracias por tu ayuda hasta ahora.

¿Está recompilando y vaciando el caché / reiniciando php-fpm / varnish después de hacer esos cambios?

Hice un script de shell que ejecuto desde public_html para el modo de producción:

! / bin / bash

toque pub / static / deployed_version.txt
php bin / magento deploy: mode : set production
php bin / magento cache: limpiar
chown -R scw: scw * &
reinicio del barniz de servicio y
reiniciar el servicio php-fpm y
reinicio del servicio nginx y

o para el modo de desarrollo:

! / bin / bash

php bin / magento deploy: mode : set developer
php bin / magento cache: limpiar
chown -R scw: scw * &
reinicio del barniz de servicio y
reiniciar el servicio php-fpm y
reinicio del servicio nginx y

ja ... ¿cuánto tiempo se supone que tomará esto? parece que está atascado en el "inicio de la compilación" y el sitio no funciona.

Tarda unos minutos dependiendo de su velocidad. ¡Tengo 50 núcleos y todavía me lleva unos minutos! ya que es php de un solo hilo!

@s southerncomputer cuando comento el código, ¿dónde debería ver la excepción?

Gracias por toda su ayuda ... resulta que mi cliente lo arregló, estábamos pagando con paypal, aceptando cc en el sitio web ... ¡y era una configuración interna que PayPal tuvo que cambiar para que esto funcionara!

@muhupower
¿Puedes compartir qué configuración es esta?

Esto es tan frustrante. No he podido aceptar ningún pago en mi sitio web durante un mes.

Intenté realizar try / catch en vendor / magento / module-checkout / Model / PaymentInformationManagement.php pero cuando lo hago no devuelve ninguna excepción.

Cualquier ayuda sería apreciada.

@hubaig , esto podría ayudar: https://github.com/magento/magento2/issues/6246#issuecomment -258830520
Tal vez ayude si aplica los cambios que hicieron en PaymentInformationManagement.php y GuestPaymentInformationManagement.php en esa confirmación. Entonces debería registrar el problema real en el archivo exception.log .

@hostep Gracias por la respuesta. Copié los dos archivos y todavía no obtengo ninguna excepción en var / log / exception.log

Solo un poco de antecedentes: estoy usando Magento ver. 2.1.1, usando el tema porto y migrado desde 1.9.x.

@hubaig Creo que podría ser importante tener en cuenta qué tipo de método de pago está utilizando durante el pago ... Lo extraño para mí es que usamos el procesamiento de paypal fuera del sitio y en el sitio ... el que dirigía a su paypal.com La página de pagos funcionó, pero recibimos este error al intentar procesar cc en el sitio web real. En nuestro caso, resulta que el agente de soporte técnico de PayPal pudo configurar los ajustes en su extremo para dejarlo pasar ... Entonces, si tiene este problema, pensamos que fue culpa de magento por un tiempo, y en el final resultó ser un ajuste en paypal

@muhupower , ¿sabes qué configuración habilitaron?

Usar la solución @s southerncomputer funciona para mí.

En mi caso, la tienda número 3 estaba rota, así que:

1. Se agregó meta de secuencia de ventas faltante
2. Se crearon tablas faltantes sequence_order_3, sequence_invoice_3, sequence_creditmemo_3, sequence_shipment_3
3. Se agregaron entradas faltantes a sales_sequence_profile para que coincidan con sales_sequence_meta

INSERTAR EN sales_sequence_meta
( entity_type , store_id , sequence_table )
VALORES ('orden', 3, 'secuencia_orden_3'),
('factura', 3, 'secuencia_factura_3'),
('creditmemo', 3, 'sequence_creditmemo_3'),
('envío', 3, 'secuencia_envío_3');

CREAR TABLA sequence_order_3 (
sequence_value int (10) unsigned NOT NULL AUTO_INCREMENT,
LLAVE PRIMARIA ( sequence_value )
) MOTOR = JUEGO DE CARTOS POR DEFECTO InnoDB = utf8;

CREAR TABLA sequence_invoice_3 (
sequence_value int (10) unsigned NOT NULL AUTO_INCREMENT,
LLAVE PRIMARIA ( sequence_value )
) MOTOR = JUEGO DE CARTOS POR DEFECTO InnoDB = utf8;

CREAR TABLA sequence_creditmemo_3 (
sequence_value int (10) unsigned NOT NULL AUTO_INCREMENT,
LLAVE PRIMARIA ( sequence_value )
) MOTOR = JUEGO DE CARTOS POR DEFECTO InnoDB = utf8;

CREAR TABLA sequence_shipment_3 (
sequence_value int (10) unsigned NOT NULL AUTO_INCREMENT,
LLAVE PRIMARIA ( sequence_value )
) MOTOR = JUEGO DE CARTOS POR DEFECTO InnoDB = utf8;

INSERT INTO sales_sequence_profile (profile_id, meta_id, prefix, suffix, start_value, step, max_value, warning_value, is_active)
VALORES
(13, 13, 3, NULO, 1, 1, 4294967295, 4294966295, 1),
(14, 14, 3, NULO, 1, 1, 4294967295, 4294966295, 1),
(15, 15, 3, NULO, 1, 1, 4294967295, 4294966295, 1),
(16, 16, 3, NULO, 1, 1, 4294967295, 4294966295, 1);

La tienda principal que estoy usando tiene el ID de 1, todos mis productos usan esa tienda. Aquí está la captura de pantalla de mis tablas. ¿Ven algo mal aquí?

SELECCIONAR * FROM sales_sequence_meta

SELECCIONAR * FROM sales_sequence_profile

Todas las tablas existen:

Incluso aquí está la mesa de la tienda:

SELECCIONAR * DESDE store

@nuwaus gracias por la respuesta, finalmente había tres storeids en mi tabla de tiendas, y la tabla sales_sequence_meta y sales_sequence_profile solo contienen los datos para los 2 ID de tienda, así que agregué un registro para el tercer ID de tienda y crearon tablas manualmente con el mismo nombre y resuelve mi problema

Me encontré exactamente con el mismo error vago que todos. Pasó por todos los pasos que todos sugirieron y nada. No obtendría ningún otro error en ninguna parte.

Utilizo Website Payments Pro (Canadá), así que finalmente pensé que vería si obtenía algunos códigos de error a través del portal manager.paypal. Miré el registro de transacciones y he aquí una gran cantidad de credenciales de comerciante no válidas. Pensé que proporcioné los correctos, pero supongo que no. mañana verificaré con Paypal lo que tienen que ser y veré si esto ayuda, soluciona el problema. [Necesito esperar hasta el lunes para recibir soporte de integración]

Ver también relacionado:

8254

7977

Ok habló con Paypal durante los últimos dos días, rastreó el problema a Magento y no a Paypal.

Condiciones previas
Ubuntu 16.04
Nginx 1.10.0
PHP 7.0.13 (CLI y FPM)
MariaDB-10.1.21
Barniz-4.1.1
Redis-cli 3.0.6
Magento 2.1.3 - Tienda única

Establezca el método de pago en tiendas-> Configuración-> Ventas-> Métodos de pago-> Paypal Payflow Pro (Canadá) (incluye Pago exprés) (o Pagos de sitios web Pro)

Proporcione toda la información de configuración requerida como correo electrónico, socio, etc.

pasos para reproducir

Agregue CUALQUIER producto en el carrito

Ir a la página de pago

Salida como invitado o usuario registrado

Proporcione la información de envío y elija cualquier método de envío disponible.

Elija el método de pago con tarjeta de crédito

Luego haga clic en realizar pedido

Resultado Esperado

Pedido procesado y confirmado

Resultado actual

Mensaje de error: "Se produjo un error en el servidor. Intente realizar el pedido nuevamente".

Análisis

El informe de Paypal Manager muestra:

• Transacción como error 10501. "Error 10501 Configuración no válida: esta transacción no se puede procesar debido a una configuración de comerciante no válida".
• Se envía una moneda incorrecta a PayPal USD en lugar de CAD
• Cantidad de carrito cero que se envía a paypal

Magento Debug muestra (datos del comprador anónimos):

[2017-02-07 01:03:44] main.DEBUG: matriz (
'solicitud' =>
matriz
'usuario' => ' *','vendedor' => 'frankjones','socio' => 'PayPalCa','pwd' => ' ',
'verbosity' => 'ALTO',
'BUTTONSOURCE' => 'Magento_Cart_Community',
'tender' => 'C',
'trxtype' => 'A',
'amt' => 0,
'createsecuretoken' => 'Y',
'securetokenid' => '804bbfbd34e7c38e767y5ced4b1a6a68',
'returnurl' => 'https://website.com/paypal/transparent/response/',
'errorurl' => 'https://website.com/paypal/transparent/response/',
'cancelurl' => 'https://website.com/paypal/transparent/cancel/',
'disablereceipt' => 'VERDADERO',
'silenttran' => 'VERDADERO',
'firstname' => 'Marca',
'lastname' => 'Rogers',
'street' => '101 Yonge Street',
'ciudad' => 'Toronto',
'state' => 'ON',
'zip' => 'M1A7G6',
'país' => 'CA',
'email' => NULL,
'shiptofirstname' => 'Marca',
'shiptolastname' => 'Rogers',
'shiptostreet' => '101 Yonge Street',
'shiptocity' => 'Toronto',
'shiptostate' => 'ENCENDIDO',
'shiptozip' => 'M1A7G6',
'shiptocountry' => 'CA',
),
'resultado' =>
matriz
'resultado' => '0',
'securetoken' => 'XmOcHxPoCI8Wd3kC1g4VY2wL2',
'securetokenid' => '804bbfbd34e7c38e767y5ced4b1a6a68',
'respmsg' => 'Aprobado',
'result_code' => '0',
),
) {"is_exception": false} []
[2017-02-07 01:03:47] main.DEBUG: matriz (
'ESTADO' => 'ACTIVADO',
'ACCT' => '

Consideraciones adicionales

El mismo error ocurre sin importar lo que hagamos con la configuración de CCV en Paypal o Magento.
Cambiar al enlace de Payflow (algo en lo que no estamos registrados pero lo hicimos solo para probar), envía la moneda correcta pero arroja el mismo error en última instancia.

Conclusión

Tener la capacidad de aceptar pagos es la esencia de un carrito de compras. Nos cambiamos a Magento 2 y nos preguntamos durante algunas semanas por qué nuestras ventas cayeron como locas. Solo llegó un goteo. (La gente puede pagar usando Paypal Checkout Express). Dada la cantidad de personas que utilizan PayPal como su procesador de pagos, este y otros problemas de PayPal son algunos de los más urgentes e importantes de resolver de forma rápida si es posible. Algunos de los otros errores con los que podemos vivir, pero no poder aceptar pagos, hacen que sea difícil continuar con la propuesta de Magento 2.

@gooki
Parece que tienes el mismo problema que yo. PayPal Payments Pro no envía la moneda adecuada para cobrar al cliente cuando realiza la llamada API.

También puedo confirmar que mi instalación M2 también pasa un "AMT" de 0. Luego carga la tarjeta (aunque en USD), por lo que no veo que esto sea un problema en sí mismo.

No debería haber ninguna configuración especial que sea diferente de PayPal Payments Pro y PayFlow Link, por lo que no estoy seguro de por qué tiene problemas (a menos que haya un error tipográfico, pero supongo que intentó volver a escribir todo varias veces).

Puede ser la forma en que la API está configurada para PayPalCA, puede tomar la configuración predeterminada para Paypal Payments PRO (American one) y aplicarla a Website Payments PRO (The Canadian Iteration). Así que está pasando la información incorrecta a Paypal, es decir. USD, y debido a que está enviando USD en lugar de CAD, el valor total de la transacción es cero porque no se envían CAD sino USD? Todo son conjeturas, pero puede ser el caso. Pensamientos

@gooki : Magento 2.1.4 acaba de ser lanzado y las notas de la versión dicen algo sobre cómo corregir la moneda incorrecta que se envía a PayPal, así que tal vez valga la pena intentar actualizar y probar si su problema se soluciona con la actualización.

@hostep gracias por la sugerencia lo haré y reportaré
@supanatral tal vez también pueda actualizar a 2.1.4 y háganos saber si ayudó

Probado con 2.1.4 y desafortunadamente sin dados.
Todavía se envían USD a paypal, monto cero, y en lugar de venta, su autorización de envío.
Probado con Website Payments Pro y Payflow Pro

Informe de Paypal:
Detalles del resultado de la transacción
ID de transacción:
BU0PF3D82422
Código de resultado: 5
ID de transacción de PayPal:
Marca de tiempo: 8 de febrero de 2017 14:19:49 p.m.
Mensaje de respuesta: información del comerciante no válida
Tipo de transacción: autorización
Código de autorización: 111111
Tipo de licitación: Visa
Partido callejero AVS:
Número de tarjeta de crédito: 4344
Coincidencia de código postal de AVS:
Caducidad de la tarjeta de crédito: 12/2017
Indicador AVS internacional:
Monto: 0.00 USD
Coincidencia del código de seguridad de la tarjeta:
Cantidad de impuestos: 0.00 USD
ABA #:
Monto del envío / flete: 0.00 USD
Cust Ref #:
Cantidad de derechos: 0.00 USD
Recurrente: no
Monto original: 0.00 USD
Código de aviso de pago:

estado de la transacción
Estado de transacción: 1
Fecha de liquidación: 08 de febrero de 2017 11:19:49 a.m.
Fecha de liquidación:
Código de respuesta: 10501
Código de error:
Auth Resp Text:

Esto es tan frustrante. No estoy seguro de qué hacer. Estoy usando la versión canadiense de Pay-flow y nada de lo que hago funciona. Ni siquiera sé qué método alternativo usar.

@hubaig muchas personas tienen este problema por diferentes motivos. Pegue su excepción aquí y le haré saber cómo depurarla. La excepción se puede encontrar al inspeccionar la solicitud AJAX desde la pestaña de red de su navegador en el depurador y debe tener un aspecto similar a https://github.com/magento/magento2/issues/6929#issuecomment -252723067

Estoy usando magento 2.1.4 y he intentado todo en esta página ... pero aún obtengo 400 en {magento_root} / rest / default / V1 / carts / mine / payment-information.

Otras cosas que probé fueron agregar productos que se pueden enviar (es decir, que no se pueden descargar y que tienen peso). Esto se hizo para asegurarse de tener la pestaña de envío en la página de pago. Parece que al objeto que se publica le falta la dirección de envío y otros campos no inicializados en la dirección de facturación.

Carga útil POST:
{"cartId": "1", "billingAddress": {"customerAddressId": "1", "countryId": "NL", "regionId": "0", "regionCode": null, "region": null, "customerId": "1", "street": ["wz857", "streetline2"], "phone": "9205920833", "postcode": "3011 za", "city": "amsterdam", "firstname" : "P", "apellido": "P", "saveInAddressBook": null}, "paymentMethod": {"method": "paypalngp", "po_number": null, "additional_data": null}}

PD: Estoy trabajando en un módulo de pago personalizado, que funcionó perfectamente en 2.1.3, sin usar la API REST directamente.

Odio agregar el comentario inútil de "Yo también tengo este problema", pero; He probado esto por mi parte y obtengo el mismo resultado que @gooki.

Al realizar un pedido, la llamada API no envía a PayPal el código de moneda.

Verifiqué las diferencias entre 2.1.3 y 2.1.4 y el único archivo que es diferente y se refiere a la moneda es "vendor / magento / module-paypal / Test / Unit / Model / Payflow / TransparentTest.php"

Tal vez esta sea una pregunta tonta, pero ¿alguien sabe qué archivo llama a la API de PayPal? (vendor / magento / module-paypal / Model / Api / PayflowNvp.php ???) Espero que haya una forma de que podamos codificarlo para enviar la moneda, al menos hasta que Magento corrija este error ...

@supanatral , vea este compromiso que se incluye 2.1.4: https://github.com/magento/magento2/commit/1c7f70d751f3cb2bcd2e076e97b900a3fc3912cc
Aquí es donde la moneda debe establecerse correctamente. (No estoy familiarizado con el código de Paypal en Magento, por lo que si tiene otras preguntas al respecto, probablemente no pueda responderlas).

Tal vez también sea una buena idea para todos los que tienen un problema diferente aquí, crear un problema nuevo, porque este hilo está comenzando a llenarse con muchos problemas diferentes mezclados. La gente de soporte de Magento probablemente tendrá dificultades para descubrir de qué se trata este hilo. Si crea problemas separados, el personal de soporte estará más claro de qué se trata exactamente el problema y es posible que puedan ayudarlo más rápido.

Buena llamada @hostep. Comenzaré a publicar más información en el número 7977.

Si alguien más tiene el problema de cobrar en dólares, lo invitaría a unirse a nosotros allí.

Tengo problemas con Briantree y recibo el mismo error y ahora el mensaje "el registro no existe".

Cómo reproducir:

colocar el artículo en el carrito y pasar por el proceso de pago
ingrese la tarjeta de crédito y "realizar pedido"

Debería pasar el pedido, pero aparece este error en la captura de pantalla.

Estoy usando 2.1.3 en un archivo de desarrollo que aún no está en producción. Han pasado 4 meses tratando de resolver esto y nada. No soy yo quien está haciendo la resolución de problemas (contraté a algunas personas para que lo hicieran)

Hablé con la gente de Brain Tree y esto es lo que escribieron:

Lo que puedo decirle es que la razón por la que está recibiendo el error es porque no se está completando un método de pago nonce en la llamada API a Braintree, que es algo que Magento es responsable de generar. Dado que nosotros no somos Magento, no tengo la capacidad de ayudarlo con problemas en el lado de Magento.

Hola Freddy,

Gracias por hacer un seguimiento. Pude ubicar una solicitud del 24 de enero (el día de su captura de pantalla) en los registros de nuestro servidor. Aquí está la solicitud:

Parámetros: {"transaction" => {"type" => "sale", "customer" => {"first_name" => "freddy", "last_name" => "pineda", "company" => nil, " phone "=>" 1234567890 "," email "=>" [email protected] "}," amount "=>" 106.53 "," payment_method_nonce "=> nil," order_id "=>" 000000025 "," canal " => "Magento2_Cart_Community_BT", "facturación" => {"first_name" => "freddy", "last_name" => "pineda", "company" => nil, "street_address" => "1470 SE 18th Terrace", " extended_address "=> nil," locality "=>" Homestead "," region "=>" FL "," postal_code "=>" 33035 "," country_code_alpha2 "=>" US "}," envío "=> {" first_name "=>" fred "," last_name "=>" pineda "," company "=> nil," street_address "=>" 1470 SE 18th Terrace "," extended_address "=> nil," locality "=>" Homestead "," region "=>" FL "," postal_code "=>" 33035 "," country_code_alpha2 "=>" US "}," options "=> {" store_in_vault_on_success "=> true," submit_for_settlement "=> true} }, "comerciante_id" => "x2v3v33wk5pykk4n"}

y aquí está el error que causó:

[ERRORES DE VALIDACIÓN] 91508 (No se puede determinar el método de pago), 81706 (se requiere CVV).
Este error se debe a que, como puede ver en el registro anterior, payment_method_nonce es nulo. Un nonce de método de pago es una cadena devuelta por el SDK del cliente para representar un método de pago. En su caso, probablemente indica que no ha ingresado ninguna información de tarjeta en su formulario de pago. Sugeriría revisar sus entradas e intentar otra prueba con una tarjeta válida.

PUEDO ASEGURARME DE ENTRAR EN LA INFORMACIÓN CORRECTA EN EL ESPACIO DE LA TARJETA DE CRÉDITO.

También intenté contactar a mi proveedor de alojamiento web y esto es lo que enviaron:

Lamentablemente, no pudimos determinar el motivo exacto del problema. Por alguna razón, la aplicación está regresando:

POST https://www.freezerworkwear.com/development/rest/supermarket_en/V1/guest-carts/29940bfffa2007be4f5551fd0f6c7019/payment-information 400 (solicitud incorrecta)

yo uso Magento ver. 2.1.5 y experimenté el error durante muchas semanas en una instalación ficticia con nada más que magento, sin plantilla, sin complemento. (Ocurrió un error en el servidor. Intente realizar el pedido nuevamente).
No hay solución para este problema en Braintree o Authorize.net Pensando en volver a 1.9. V1.9 funciona perfectamente.
¿Qué es una solución de comercio electrónico sin pago ........ !!! @! @ # @! @ #. MAL PASO A la v2 de MAGENTO. PENSANDO EN CAMBIAR SOLUCIÓN COMERCIO ELECTRÓNICO>

Hola,

si cambia el número de direcciones de línea 2 -> 1

puedes ejecutar esto:

ACTUALIZAR customer_address_entity SET street = REEMPLAZAR ( street , '\ n', ',')

para mi es trabajo ...

Gracias por la ayuda.

Hice el cambio. Recibo 2 mensajes de error.

Uno de magento

Atención Lo siento, pero algo salió mal. Póngase en contacto con el vendedor.

y uno por correo electrónico

Authorize.Net Developer Center Merchant,

Se agotó el tiempo de espera de la secuencia de comandos mientras intentábamos publicar los resultados de la transacción.
ID de transacción: 0
Resultado de la transacción: esta transacción ha sido aprobada.

Se mostró el siguiente mensaje al cliente :;

¡Pero la transacción completa!

Tienes una idea

Muchas gracias.

El 01/03/17 05:06 PM, los alumnos escribieron:

Hola,

si cambia el número de direcciones de línea 2 -> 1

puedes ejecutar esto:

ACTUALIZAR customer_address_entity SET street = REPLACE (street, '\ n', ',')

para mi es trabajo ...

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/magento/magento2/issues/6929#issuecomment-283486303 , o silencia el hilo https://github.com/notifications/unsubscribe-auth/ASVyfQn3lc_OLumL59IS7OJrpM0VvBUKRgaks5rhev4 .

Encontré este problema debido a que el campo de la base de datos quote.reserved_order_id es un pedido ya existente. La restricción de la base de datos hizo que fallara la instrucción de inserción. Esto fue inmediatamente después de un mal intento de pedido de PayPal, por lo que quizás la identificación reservada se actualizó en la cotización, pero la identificación de incremento de secuencia de ventas no. Solo pude resolver esto eliminando manualmente el reservado_quote_id de la base de datos.

Para empeorar las cosas, estas excepciones no se registran en la base de datos (¿WTF?), Por lo que si esto les sucede a los clientes en producción, simplemente no lo sabrá.

El problema es que el pedido se realizó utilizando el reservado_order_id en el intento n. ° 1 de cotización, por lo que ahora, cuando vuelva a intentar PayPal, intentará usar ese reservado_order_id como sales_order.increment_id y fallará.

Lo que hice fue verificar la tabla sales_order para ver si el increment_id existía antes de enviar la cotización (para convertirse en un pedido), si existe, vacío reservado_order_id y si existe $ orderData, unset increment_id. Esto obligará a la cotización a utilizar un nuevo reservado_order_id para crear un nuevo pedido y tener éxito. Ahora que PayPal conoce el reservado_order_id original o el nuevo, ¡eso es para que usted haga ejercicio!

Aquí está lo que necesitará modificar:
una página.php
adminorder / Create.php
módulo-paypal-express..checkout.php
etc ..

    $order = $this->quoteManagement->submit($quote, $orderData);

psst. ¿Alguien conoce una solución que evite que los apóstrofos eliminen el envío del pedido (en la dirección de envío?)

Recomendaría un complemento de "beforeReserveOrderId" en "Magento \ QuoteModel \ Quote".

De esta manera, no es una solución invasiva, no depende de ningún método de pedido en particular y siempre garantizará que no se utilicen ID de cotización mal reservados. Aquí está mi código de complemento para hacer precisamente eso:

public function beforeReserveOrderId(\Magento\Quote\Model\Quote $quote) {
    $reservedOrderId = $quote->getReservedOrderId();

    if($reservedOrderId) {
        $order = $this->orderFactory->create()->loadByIncrementIdAndStoreId($reservedOrderId, $quote->getStoreId());
        if($order->getId()) {
            $quote->setReservedOrderId(null);
        }
    }

    return null;
}

En cuanto a los apóstrofos en las direcciones de envío que causan problemas, hice una prueba rápida y no tuve ningún problema (utilicé "123 'Main Street". ¿Puede explicar con más detalle lo que está encontrando?

Sí, eso parece más elegante. Tenemos alrededor de 50 administradores simultáneos que crean / editan presupuestos y pedidos, por lo que el método del complemento no fue tan elegante, ya que es posible que deba forzar la restricción según el trabajo en cuestión.

Digamos que si la empresa tuviera un solo apóstrofo en customer_address_entity copiado en quote_address y usted realizó un pedido ADMIN en el backend, el método de envío y los totales bajarían a cero; al hacer clic en un método de envío, ¡diría que no hay cotizaciones disponibles para este pedido! y kaput!

Hola, espero que alguien me pueda ayudar. He heredado un Magento 2 de otro desarrollador. Hemos tenido problemas desde el principio. Mi mayor prioridad de los problemas es que algunos de nuestros clientes pueden realizar un pedido y otros reciben errores. Algunos errores son "Se produjo un error en el servidor. Intente realizar su pedido nuevamente" y otros errores relacionados con el servidor y el código postal. Recientemente actualizamos de 2.1.0 a 2.1.5. Los problemas ocurrían antes de la actualización y continúan después de la actualización. Estoy abierto a cualquier solución. El propietario de la empresa quiere deshacerse de Magento por completo. Necesito intentar guardarlo si es posible. Gracias por adelantado.

Candyjo: también he tenido problemas con el pago. Mi terrible experiencia comenzó en agosto de 2016 y decidí deshacerme de Magneto 2 a fines de enero. Después de conseguir que 4 desarrolladores diferentes intenten ayudar, nadie ha encontrado la respuesta. Ni siquiera el desarrollador del módulo de pago ... Así que después de mucho tiempo perdido y $$$, dejé todo y actualicé mi Zen Cart.

Entonces, por el momento, M2 estará disponible en un futuro próximo.

Buena suerte con tu proyecto.

Tengo los mismos problemas con Magento 2.1.1. Después de seguir todo en esta guía, no puedo encontrar una solución. Tengo la sensación de que es algo con la configuración de Varnish o de permisos. Cada vez que me comunico con mi empresa de alojamiento, pudieron solucionarlo, pero después de que un cliente se conecta a Internet para comprar un producto, vuelve a fallar. Y si falla una vez, no le permitirá usar PayPal ya que ese botón se desactiva.

Mi sitio está aquí: http://bit.ly/2nI8Qpt

(magento 2.1.5)

Yo tampoco pude hacer un pedido, con los mismos síntomas que todos aquí, así que intenté hacer un pedido usando el inicio de sesión de BACKOFFICE ADMIN y descubrí el problema exacto (dentro del mensaje de error detallado que proporciona el backoffice, al contrario que el frontend ).

Entonces, mi consejo es intentar hacer un pedido en el backoffice y verificar los errores (en la pantalla).

¿Alguien ha buscado una solución a esto? Estamos a punto de volver a Magento 1.9.x
Estoy en 2.1.5 y cada cuarto o quinto pedido muestra el mensaje "Se produjo un error en el servidor. Intente realizar el pedido nuevamente". Obviamente, esto es un error.

@riprod ¿has probado mi solución (2 publicaciones arriba?)

¿Se refiere a probar un pedido en el back-end? No puedo hacer eso porque dice "No hay métodos de pago disponibles". No estoy seguro por qué

¡extraño! Sí, esa fue la única forma en que rastreé el problema hasta un complemento.

El mensaje de error al finalizar la compra ocurre esencialmente como un "atrapar todo" para alguna parte del proceso de creación de pedidos que arroja una excepción. Debido a que hay muchas partes móviles en la creación de pedidos (complementos, eventos, etc.), la forma sencilla de averiguar exactamente por qué falla el pedido es restaurar una copia de seguridad del sitio web en un entorno de desarrollo y depurar el código. Así es como descubrí que mi problema estaba usando un reservado_order_id que ya existía como pedido. La excepción real lanzada mencionó que se violaba una restricción de base de datos de claves duplicadas.

Mi error estaba ocurriendo en "vendor \ magento \ module-quoteModel \ QuoteManagement.php" en la línea $order = $this->orderManagement->place($order);

Esa declaración está envuelta en un bloque try-catch. Agregar un punto de interrupción en el bloque de captura le permitirá ver el mensaje de error detallado. Si su error no se produce en esta línea, puede buscar en todo el código base la frase "Intente realizar el pedido de nuevo". En este momento, solo hay 4 ocurrencias que son candidatas a ser el mensaje de error que está viendo. Agregue puntos de interrupción en todos ellos y vea qué se golpea. A partir de ahí, debe seguir el código hasta que se produzca el error.

La parte complicada aquí es asegurarse de que el problema sea reproducible en el entorno de desarrollo para realizar una depuración adecuada. Es probable que deba iniciar sesión como el cliente en particular que se encuentra con el problema que puede requerir la manipulación / restablecimiento del campo de contraseña en la versión de desarrollo. En general, me doy cuenta de que esta solución no está disponible para todos, ya que requiere un desarrollador de Magento con experiencia para poder navegar y depurar el código, pero debido a que el error es tan general y NUNCA ESTÁ REGISTRADO, es probable que este sea el único método confiable de aplastar cualquier error que pueda estar ocurriendo.

Además, asegúrese de que su problema no se deba a un reservado_order_id en la cotización que coincida con un pedido de venta ya existente. Tendrá que mirar los campos de la base de datos en las tablas quote y sales_order. Si cualquier reservado_order_id en una cotización ACTIVE coincide con el increment_id de un sales_order (ambos dentro de la misma tienda), el cliente propietario de esa cotización recibirá el temido mensaje de error que está viendo cuando Magento intenta crear un pedido usando un incremento_id que ya se usado.

@AirmanAJK Muy buena respuesta. Veo que en las áreas donde ocurre el error, hay una excepción genérica lanzada sin siquiera registrar la excepción real. La forma de ver realmente la excepción exacta es agregar puntos de interrupción. La configuración de la depuración remota en su IDE realmente contribuirá en gran medida a solucionar el problema. Migré de Magento 2.0.11 a Magento 2.1.5 y comencé a experimentar el problema. En mi caso, fue un error que Región fuera un campo obligatorio.
Establecí un punto de interrupción aquí: https://github.com/magento/magento2/blob/2.1.5/app/code/Magento/Checkout/Model/PaymentInformationManagement.php#L71 para ver el error exacto.

Desactivar la configuración del administrador que requería el estado lo resolvió por mí.

Lo que me parece Magento2 es que los desarrolladores necesitaban cumplir con la fecha límite de lanzamiento porque la gerencia insistió en que tenían que hacerlo, por lo que los desarrolladores no tuvieron más remedio que lanzar el software que no estaba listo para la producción. Estuvimos entre las primeras tiendas en migrar de Magento 1.8.xa Magento 2 - En ese momento, Magento 2.0.5. Fue una experiencia horrible. Todo lo que podía salir mal salió mal. Desde ID de atributo EAV incorrectos hasta clientes que no pueden cerrar sesión, hasta carrito faltante, solo nómbrelo.
Actualmente estoy enfrentando un problema con Magento al asignar el valor de mi campo de región (cadena) a region_id (int) y, como resultado, arrojar errores de tipo de retorno. Al establecer puntos de interrupción en el navegador utilizando las herramientas de desarrollo de Chrome, parece que veo de dónde proviene el error. Sin utilizar depuradores para recorrer el código de Magento (en el navegador y en su IDE) en el modo de desarrollador, es casi imposible llegar a la raíz de los errores. Muy mal equipo de Magento.

Hola a todos, tengo el mismo error:
Ocurrió un error en el servidor. Intente realizar el pedido nuevamente.

Y lo atrapé en el tronco como:
INVALID_REQUEST: el campo [order.avsDetails.billToFirstname] no estaba en el juego de caracteres [ISO-8859-1]

Usé palabras árabes en las entradas.

Entonces cualquier cuerpo puede ayudar.

Tenemos el mismo problema. No tenemos módulos de terceros. Sucede en el tema de Porto y Luma. Authorize.net muestra transacciones exitosas y los pedidos se muestran como pendientes en el backend, pero el usuario ve un error. ¿Alguna solución todavía?

Hemos tenido el mismo problema con nuestro sitio.
Magento 2.1.4
Método de pago: Authorize.net
Proceso:
Estado del cliente: inmaterial
Coloque cualquier artículo en el carrito.
pasar por la caja
ingrese la dirección / método de envío
continuar a la página de pago
Introduzca Información del pago
Realizar pedido

Resultado Esperado:
Página de éxito del pedido
Reciba un correo electrónico de transacción con un nuevo número de pedido

Resultado actual:
la página parpadea y todos los datos permanecen en la página
sin indicación de página de éxito
ningún correo electrónico de verificación de pedido recibido por el cliente
Authorize.net recibe el pago y procede a procesar
El pedido se crea en Admin
* El cuadro de error rojo apareció brevemente durante un intento que indica "Se produjo un error en el servidor. Vuelva a intentarlo".

Los pagos se procesaron a través de Authorize.net, el pedido se creó en Admin, pero Magento2 no procedía con la página de éxito del pago o los correos electrónicos de transacción. Tuvimos un gran avance cuando creamos un pedido a través de Admin y recibimos el error "La transacción fue rechazada porque falló la validación del hash de respuesta". No configuramos la función hash md-5 entre Authorize.net y Magento por recomendación de un representante de Authorize.net.

Una vez que configuramos el hash md-5 en Authorize.net y en Magento Admin, los pedidos se procesan normalmente. ¡Di una oración para que esta solución se mantenga!

Gracias por todas las pistas.

¿Cuál es la ubicación en Magento para agregar el código hash MD5? No lo encuentro ...

Gracias por adelantado....

Se encuentra en el administrador de Magento. Vaya a: Tiendas> Configuración> Ventas> Métodos de pago> Correos directos de Authorize.net> Comerciante MD5.

También debe guardar el mismo código en Authorize.net. Puede tener hasta 20 caracteres.

Gambi52 - Muchas gracias ... el problema es que estoy usando CIM y el complemento no tiene el campo ... Lo están agregando, pero sienten que esto no resolverá el problema ... Estoy muy verde con Magento ... . lo siento por las preguntas / comentarios del novato ...

¿Puedo preguntar si alguien me puede traducir esto al inglés?

"{" mensaje ":" Se produjo un error en el servidor. Intente realizar el pedido nuevamente. "," Trace ":" # 0 /home/digidwo/public_html/app/code/Amasty/Checkout/Model/GuestPaymentInformationManagement.php(47): Magento \ Checkout \ Model \ GuestPaymentInformationManagement-> savePaymentInformationAndPlaceOrder ('f03644e07e13fad ...', 'bhills_4300 @ mai ...', Objeto (Magento \ Cotización \ Modelo \ Cotización \ Pago), Objeto (Magento \ Cotización \ Modelo \ Cotización \ Dirección \ Interceptor)) \ n # 1 [función interna]: Amasty \ Checkout \ Model \ GuestPaymentInformationManagement-> savePaymentInformationAndPlaceOrder ('f03644e07e13fad ...', 'bhills_4300 @ mai ...', Objeto (Magento \ Cotización \ Modelo \ Cotización \ Pago), Objeto (Magento \ Cotización \ Model \ Quote \ Address \ Interceptor), Array) \ n # 2 /home/digidwo/public_html/vendor/magento/module-webapi/Controller/Rest.php(307): call_user_func_array (Array, Array) \ n # 3 /home/digidwo/public_html/vendor/magento/module-webapi/Controller/Rest.php(216): Magento \ Webapi \ Controller \ Rest-> processApiRequest () \ n # 4 / home / digidwo / public_html / var / generation /Magento/Webapi/Controller/Rest/Interceptor.ph p (37): Magento \ Webapi \ Controller \ Rest-> dispatch (Object (Magento \ Framework \ App \ Request \ Http)) \ n # 5 / home / digidwo / public_html / vendor / magento / framework / App / Http. php (135): Magento \ Webapi \ Controller \ Rest \ Interceptor-> dispatch (Object (Magento \ Framework \ App \ Request \ Http)) \ n # 6 / home / digidwo / public_html / vendor / magento / framework / App / Bootstrap.php (258): Magento \ Framework \ App \ Http-> launch () \ n # 7 /home/digidwo/public_html/index.php(39): Magento \ Framework \ App \ Bootstrap-> ejecutar (Object ( Magento \ Framework \ App \ Http)) \ n # 8 {main} "}"

@brvoltz necesita parchear su código para rastrear el error real que ocurre o busque en var / log / *. log para un mejor mensaje de error. ¡vea @hostep o mis recomendaciones de publicaciones anteriores en este hilo!

@s southerncomputer - ya que estoy muy verde de este lado ... ¿Qué se necesitaría para que hicieras los cambios, para que podamos registrar lo que está sucediendo? Lo que es interesante es que no tengo problemas para realizar un pedido con tarjeta de crédito desde el lado del administrador ... solo el extremo frontal ...

¡Prueba este parche y déjame saber qué error arroja después!
https://github.com/southerncomputer/magento2/commit/79e8317e8e87b998d15f4b54fbeefce0901e4dc0

@brvoltz si aplica el parche que publicó @southerncomputer , obtendrá un error más específico que podrá depurar. Magento 2 esencialmente enmascara la verdadera causa del problema en ese método.

Muchas gracias por la ayuda ... lo que ahora es muy interesante, cambié mi tema comprado de nuevo al predeterminado (Luma), borré el caché y luego procesé una tarjeta de crédito, sin errores ... Luego cambié de nuevo al tema comprado y borró el caché y procesó una tarjeta de crédito ... SIN errores ... Imagínese ... LOL

Ahora para descubrir cómo recortar los troncos después de esto ...

Hola,

Hasta ahora, estas son las medidas que tomamos y las costuras para mejorar significativamente la tasa de disminución de transacciones. Después de aplicar las 3 soluciones, no recibimos ningún informe de que otros usuarios no pudieran realizar el pago usando Braintree en nuestra tienda Magento 2.1.

Espero que esto ayude:
https://support.weltpixel.com/hc/en-us/articles/115007753688-How-we-solved-Braintree-Magento-2-checkout-issues-with-our-Magento-2-1-store

Saludos,
Equipo WeltPixel

Bueno esto realmente interesante ... el sitio estaba funcionando y ahora se detuvo ... y dando el error, pero ni una cosa en los registros .. nada .. vacío ... pensé que era por paypal, pero yo lo desactivé, todavía estaba allí, volví al tema Luma, todavía estaba allí ... Estoy completamente perdido en este ...

Vacíe completamente su caché (es decir, redis-cli -p 6379 flushall, redis-cli -p 6380 flushall, php bin / magento cache: clean, service php-fpm restart) luego haga un nuevo inicio de sesión e intente finalizar la compra, es posible que tenga un ¡cita con un reservado_order_id ya utilizado! Por supuesto, si aplicaste el parche, ¡habría arrojado una excepción más o menos!

Lo siento, pero no sabría cómo ejecutar la descarga ...

y no importa el método de pago que utilice ... lo hace para todos ...

Ok ... no iniciaste sesión, y como "Invitado" funciona ...

¿Puedo borrar mi cuenta y volver a crearla?

¿No sabes cómo vaciar tu caché en la línea de comandos? Esta es Magento Community Edition. Todos estamos aquí para ayudarnos unos a otros, pero esta no es la edición empresarial. Debe aprender a desarrollarse en este marco o consultar con alguien que lo haga. No obtendrá una simple solución de "haga clic aquí" para este problema. Apuesto a que tiene un ID de pedido reservado duplicado, como sugiere el comentario anterior.

@AirmanAJK - Lamento mucho preguntar cómo encontrar la causa raíz / solucionar algo aquí, ya que el soporte de los complementos está tan ocupado señalando con el dedo. No sabía que este grupo no era para instalaciones CE. Lo gracioso es el soporte para los complementos que me señalaron aquí. Lo mismo con la búsqueda de Google.
Otros tienen la amabilidad de ofrecer sugerencias, se las llevo a una persona y le pido que lo intente o lo haga ... y me dé los resultados. (Se han necesitado no menos de 40 "Consultores" diferentes para encontrar a alguien que no sea un charlatán).

En el color: simplemente estaba diciendo que no te pedía que lo hicieras ni que lo explicaras.

Estoy tratando de llegar al fondo de por qué este sistema tiene tantos problemas. y estoy aprendiendo que el mundo de Magento tiene muchos "expertos autoproclamados" que simplemente están detrás de un $ sin conocimiento del sistema. La palabra que usaría es "Fleecing". (a su punto sobre consultores)

Southern tenía razón, era el ID de usuario ... Todavía no tengo idea de cómo "limpiar" para ese usuario (es mi ID de prueba) ...

@AirmanAJK Acabo de ejecutar setReserverOrderId () en mis cotizaciones en el último paso del pago en un solo paso, ya que me gusta que el OrderId real se sincronice con el OrderId en el proveedor CC. Si desperdicio algunos números de pedido no es gran cosa. ¡Los clientes también disfrutan de tener un orderId preciso en sus estados de cuenta CC!

Supongo que reservedOrderId no es válido en lugar de confiar en que no se usa, ya que entre los usuarios de backend que modifican cotizaciones / pedidos / clonaciones de cotizaciones / reordenes, el reservadoOrderId está seriamente roto.

@brvoltz : mysql: actualizar el conjunto de citas reservado_order_id = NULL;
¡debería solucionar el problema de ese usuario por ahora!

Comentar intentar, capturar para ver el error
/vendor/magento/module-checkout/Model/GuestPaymentInformationManagement.php/
/vendor/magento/module-checkout/Model/PaymentInformationManagement.php

función pública savePaymentInformationAndPlaceOrder (
$ cartId,
Magento \ Quote \ Api \ Data \ PaymentInterface $ método de pago,
Magento \ Quote \ Api \ Data \ AddressInterface $ billingAddress = null
) {
$ this-> savePaymentInformation ($ cartId, $ paymentMethod, $ billingAddress);
//tratar {
$ orderId = $ this-> cartManagement-> placeOrder ($ cartId);
/ } catch (\ Exception $ e) {// var_dump ($ e);lanzar una nueva excepción CouldNotSaveException (__ ('Se produjo un error en el servidor. Intente realizar el pedido nuevamente'),$ e);} /
return $ orderId;
}

También tuve el mismo problema y encontré la razón.

En mi caso, solo obtuve los problemas en mi servidor de prueba, localmente sin ningún problema.

La razón es que utilicé otro usuario de base de datos en mi servidor de prueba, cambié mi env.php pero todavía me estaba encontrando con el error cuando intenté hacer un pedido.

Después de registrar la base de datos, vi que algunas consultas intentaban usar mi antiguo usuario, creé un volcado de la base de datos y vi que algunos disparadores estaban usando el usuario anterior.

Así que asegúrese de que su desarrollo, producción y puesta en escena estén utilizando el mismo usuario de base de datos.

Quizás no todos los problemas descritos aquí estén relacionados con mi problema, pero espero poder ayudar al menos a algunos de ustedes.

muy decepcionado. Magento 2 para mí un desastre. Realmente lamento cambiar a magento 2. Dos problemas importantes en el pago. golpeamos ambos: 1. Paypal Express no pudo inicializarse. 2 Este problema. esto está directamente relacionado con el pago. relacionado con los ingresos!

Confirmo. Magento 2 es un desastre, demasiado lento, la programación es mala, el pago es problemático. Me quedo en magento 1 esperando elegir otra plataforma. Hicieron (equipo magento) de un éxito una pesadilla

Lo mismo para mí, yo también me arrepiento

Estoy enfrentando el mismo problema, la actualización a 2.1.8 tampoco fue la solución. Ocupado con esto durante 3 semanas. Ahora estoy en el punto de desconectar M2. Una cuestión tras otra, esto no es nada divertido.

También estaba enfrentando el mismo problema, incluso actualizado a 2.1.8. Esa tampoco era la solución. Comencé a deshabilitar módulos. Inhabilité mi herramienta de depuración Commercebug y la puse en modo de producción y las transacciones comenzaron a ejecutarse. Luego, cuando deshice esto para validar la observación. Seguía funcionando en modo de producción y modo de desarrollo. Informaré si tengo otras observaciones que agregar. Rascándome la cabeza.

Puedo confirmar que esto sucede algunas veces en 2.1.7 - ¡muy mal!

"Ahora estoy en el punto de desconectar el M2" @ Bobstar040 lo entiendo totalmente - lo mismo aquí. Un problema se resuelve, el otro problema aparece ...

¡No es productivo en absoluto!

Gasté alrededor de 20K en un tema similar a este ... NO estoy exagerando. El error que estaba experimentando era la rueca de la muerte al finalizar la compra. El error finalmente se corrigió hace varias versiones ...

Este no es el lugar para ser negativo ... Lo sé ... También sé que el personal de Magento se preocupa ... pero su alta gerencia necesita entender los problemas reales. Este es el problema más importante que tiene ... el pago tiene que funcionar. Todo lo demás debe quedar en segundo plano ... los buenos gerentes dan prioridad.

Nuestro problema está resuelto ahora, verifique todos los complementos que usan api y deshabilítelos o elimínelos. No hay registros de depuración adecuados o errores generados por magento en esto. Buena suerte con estos problemas, sé que es muy frustrante.

@ Bobstar040 para usted, ¿qué módulo fue el problema?

@puples para mí fue el complemento Belco.io, pero en mi opinión, puede ser cualquier complemento que requiera credenciales api para obtener datos del cliente.

Me acabo de enterar de que el problema (al menos en mi caso) estaba relacionado con la dirección de correo electrónico de pago del invitado. Si hubo un pedido antes con una dirección específica y usa esta dirección para pagar, Magento sugiere iniciar sesión o dejar que el cliente continúe opcionalmente sin iniciar sesión. Cuando el cliente no inicia sesión, aparece el error.

Cuando se usa una dirección de correo electrónico completamente nueva, desconocida para Magento, el pago funciona como invitado.

Tengo el mismo problema, pero al revés. Sin extensiones de terceros.

• Realice el pago como invitado utilizando el método de pago predeterminado 'Cheque / Giro postal', y todo funciona normalmente.
• Inicie sesión en mi cuenta, luego realice el pago con el mismo método de pago y aparece "Se produjo un error en el servidor".

@veloraven @ magento-team, ¿puede venir con una respuesta sobre este error?
No estoy seguro de cómo ve esto, pero si el pago no es 100% perfecto, no se puede usar todo el sistema magento2. ¡Y con 100% quiero decir 100% no 99,8!

¿Puede por favor decirnos qué planea hacer para resolver este problema?

Actualización: Nuestro equipo @outeredge ha encontrado el problema.

En nuestro caso, la 'Dirección de calle' se guardó en la base de datos como dos líneas, por ejemplo:

Unit 2
The Street

Pero Magento solo aceptará una línea en la dirección postal. Después de eliminar las múltiples líneas, el problema se resolvió por sí solo.

Esto todavía deja la pregunta de cómo logramos tener varias líneas allí en primer lugar. ¿Quizás una versión anterior de Magento 2 permitía esto, y la versión más nueva no es compatible con versiones anteriores?

¡Intentaría deshabilitar los módulos persistentes y borrar la tabla de cotizaciones para ver si se está ejecutando de manera más limpia!

@vseager ver https://github.com/magento/magento2/issues/2450

Descubrí otro problema que puede causar el mismo problema al realizar pruebas en la zona de pruebas. En la configuración de Braintree en el Panel de administración, en 'Configuración básica de Braintree' solicita Merchant ID , y en Configuración avanzada de Braintree solicita Merchant Account ID .

Al revisar el formulario rápidamente, no me di cuenta de que no son lo mismo, e ingresé mi Merchant ID en el campo Merchant Account ID . Esto producirá el mismo error:

Si comete el mismo error que yo cometí, /var/log/debug.log NO mostrará nada útil:

Para aclarar para que otra persona no cometa el mismo error:

• El merchant ID es un identificador único para toda su cuenta de puerta de enlace. Este valor es necesario para conectar su integración a Braintree, junto con el resto de sus claves API.
• El merchant account ID es un identificador único para una cuenta de comerciante específica y se utiliza para especificar qué cuenta de comerciante usar al crear una transacción. El merchant account ID se puede encontrar en el Panel de control de Braintree (Sandbox o Producción) navegando a Configuración > Procesamiento > Cuentas comerciales .
• Si solo tiene una cuenta de comerciante, no es necesario especificar una identificación de cuenta de comerciante.

Mi problema estaba sucediendo porque mi volcado de base de datos de desarrollo estaba configurando el atributo DEFINER en los desencadenadores para un usuario que no existía en la base de datos de producción. Hay una parte de los documentos de la nube de magento en la parte inferior que puede resultar útil. Básicamente, necesita ejecutar mysqldump y decirle que no configure ese usuario DEFINER. Una vez que hice esto, ¡pude pagar nuevamente! Aquí está el fragmento de código que necesitaba mysqldump -h <database host> --user=<database user name> --password=<password> --single-transaction main | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | gzip > /tmp/database_no-definer.sql.gz

Puede leer más aquí: http://devdocs.magento.com/guides/v2.0/cloud/live/stage-prod-migrate.html#troubleshooting -the-database-migration

Además, según mi leal saber y entender, no estoy usando Cloud Magento, pero esto todavía me pertenece. ¡Espero que esto ayude a alguien!

El problema se ha solucionado en MAGETWO-63651, MAGETWO-67290, MAGETWO-63650, MAGETWO-63637 y se entregó

Si tiene otros problemas, cree un nuevo problema
Gracias